单体听上去就很神秘。在数千个全球组织中，单体应用程序通常是独立的，并排的，充满神秘感而令人敬畏。单体应用程序是现代商业的组成部分，也是每个关键业务流程的重要贡献者，从后台到供应链，从客户服务到商业参与等。
虽然这些单体继续为业务做出巨大贡献，但这些应用程序的现代化是一个令人沮丧和痛苦的话题。许多组织放弃了，而其他组织则通过重新定位或重新构建，将整个单体迁移到云上作为权宜之计——这是旧的“lift and shift”。2022年，新希望、新技术和新方法正在打破围绕单体应用程序的神秘。
误解#1：单体现代化是一项失败的事业
每个云提供商、云原生平台和系统集成商都有一个模型，该模型几乎包含现代化词典中的所有“R”。最初，这个行业的现代化只有五个R：重托管、重构、重新架构、重建或替换。随着现代化的成熟和更多顾问的参与，R的数量也随之增加，包括重新平台化、重写、保留和退役。这令人困惑。几乎没有数据、数学和自动化应用于单体的现代化过程。有书籍和最佳实践，还有许多顾问和解决方案架构师愿意提供建议和交付。这些都是很好的开端，但通常要么专注于DIY方法，要么专注于昂贵、高风险的外包。
新一波的工具、应用人工智能和自动化正在应用，以弥合所有DIY或所有外包选项之间的差距。这些方法的基础是基于对单体的实际架构分析，不仅是需要迁移到新版本的底层平台组件，而且是实际的业务逻辑本身。业务逻辑是应用程序的核心，架构师可以在其中开始识别可以导致更清晰的微服务领域驱动设计的领域。至少，这些服务代表的是更独立的迷你服务，或者只是具有更高排他性的普通服务。缺乏基本的数据驱动方法导致应用程序团队脱离现代化，选择迁移策略作为权宜之计，这导致我们陷入误区2。
误解#2：将单体迁移到云=现代化
将应用程序迁移到云是一个引人注目的目标，也是一个“登月计划”愿景，它将IT和应用程序团队凝聚到一个更大的目标上。但要明确的是，迁移并不等于现代化。单体迁移到云，可以获得巨大的DevOps和数据中心缩减好处。几乎所有组织都实现了这些短期收益，反过来又为希望加速和简化企业工作负载向云移动的云提供商带来了意外之财。许多技术领导者犯的错误是认为他们的工作已经完成了——我们现在已经现代化了!
这个误解很快就破灭了：现在大多数组织都清楚，云中的单体存在着与内部部署相同的棘手问题——工程速度慢、缺乏可扩展性、难以维护和低可持续性。随着成本开始上升，云效益仍然遥不可及，许多人称这一阶段为“lift-and-shift后悔”或“迁移后悔”。
要打破这一误解，必须在更大、更具战略性的现代化战略的背景下看待和规划迁移问题——只要是迈向全面现代化的基石，迁移就没问题。单体的现代化使其能够充分利用云原生架构的价值，从容器和微服务到Kubernetes和无服务器。再加上利用常见CI/CD、安全性和DevSecOps策略和平台的好处，你的业务案例就会很快到位，这让我们陷入误解3。
误解#3：构建准确的应用程序现代化业务用例是不可能的
对于大多数组织来说，应用程序现代化最困难的部分是为现代化项目构建准确的业务用例。我们探讨了误解#1中解决此问题所缺少的元素之一：预测时间和精力的架构师与批准预算和资源的业务领导之间缺乏数据驱动的讨论基础。由于缺乏共同的语言和衡量基础，领导层和管理层之间的信任出现了双向破裂。打破这种循环需要数据和测量才能开始。
从分析测量单体的复杂性和改变整体所涉及的风险开始。要理解复杂性，首先需要识别社区或依赖关系集群，这表明哪些领域是明显的，因此可以提取微服务。然后，可以通过类依赖关系在它们之间纠缠的程度来计算复杂性，从而降低代码的模块化水平。风险可以通过依赖关系链的长度来衡量，依赖关系链的长度决定了应用程序某个部分的更改对应用程序下游不相关部分的影响程度。所有这些都可以汇总成一个总体技术债务分数，该分数可以显示当前在债务与创新方面的支出，从而显示现代化项目的ROI和TCO业务用例效益。从这一强有力的量化立场来看，业务优先级更容易达成一致，这导致我们打破了误解#4。
误解#4：所有的单体都是平等的
单体有各种形状和大小，具有不同的商业价值和截然不同的复杂性。事实上，单体架构可以是各种用例的相关现代设计模型。简单的第一步是根据今天的业务价值对单体进行堆叠排序。评估它们的业务实用性和工程负载、功能积压和维护成本。通常，这些应该是一致的，因为团队的规模、待办事项功能的数量和维护成本应该与企业单体的业务价值一致。事实上，这些单体抵制“传统”标签，因为它们仍然是企业和支持它们的工程团队的一等公民。一个不断老化、业务价值不断下降的单体，是简单重组或最终退休的绝佳选择。
如果应用程序仍然是可行的业务贡献者，那么就必须全面评估其复杂性以及与现代化相关的风险(参见误解#3)，以制定最佳计划，从而制定更准确的业务用例。通过计算这些关键业务单元的复杂性、风险和由此产生的技术债务，你可以使用基于AI的自动化工具将较不复杂的部分转移到更快的应用程序现代化项目中，以加速该过程。更复杂的单体(通常称为“megaliths”)将需要更多的时间，应该遵循更迭代的重构方法，使用扼杀模式将控制从单体切换到新服务，一次有选择地提取一个或两个微服务。这些单片应用程序可以存在于任何地方，甚至在云中。
误解#5：单体是一个内部问题
诚然，今天的大部分单体仍然存在于内部，牢固地固定在其原有的基础设施上。但越来越多的单体已成功迁移到云，在云提供商的IaaS基础设施中运行，使用提供商的电源、CPU和内存，但不幸的是，它们仍然作为单体运行。云中的这些单体可能会成功运行一段时间，但当出现可伸缩性问题时，唯一的解决方案是以越来越多的费用购买越来越大的镜像——更多的CPU和更多的内存。这些可能需要更昂贵的保留实例，云工程师必须始终在红线级别上运行这些实例——没有弹性，没有横向可扩展性。
上述相同的数据驱动评估方法和优先级划分方法与云中的这些单体完全相关，甚至可能更相关。为什么?数据驱动的评估、支持人工智能的现代化和迁移后重构是所有解决方案和软件架构师所需的关键能力。云中的单体离完全实现其现代化命运如此之近。一旦单体重构过程完成，容器、Kubernetes、DevOps、无服务器和服务网格服务就可以在云上启动。
误解#6：单体依赖关系无法解开
承担维护任务的架构师面临着严峻的挑战，更不用说在他们的责任下对单体进行现代化改造了。大多数时候，他们不是最初的架构师或开发人员，即使他们是，单体也会随着时间的推移而发展，承担越来越多的技术债务，这可能会埋葬大部分的原始意图。这些错综复杂的单体有很多相似之处。
AI可以提供帮助。当一个系统可以将单体的深度依赖关系表示为一个图形时，图形机器学习可以检测到形成潜在领域活动社区的集群和链接，这带来了一系列好处，从了解复杂性和变化风险到实际检测潜在的微服务和社区之间的边界。构建支持它的图形和模型需要动态和静态分析的结合，但最终的结果是更加高效和有效的现代化工作。单体现代化成为可能，它们可以变得更加可预测和更快。
误解#7：单体现代化永远做不完
在打破了上述六个误解之后，应该清楚的是，如果你遵循这些建议，时间和预算应该不会成为现代化的一个因素。现在，讨论的应该是实现哪些现代化，从而带来业务效益和成果。清晰的评估和数据驱动的规划也应该塑造实现现代化的方式。复杂度较高的应用程序应该遵循迭代的、选择性的重构策略，在这种策略中，不太复杂的业务关键型整体可以更快地通过流程。
在过去十年中，应用程序现代化一直是一种人力密集型最佳实践，需要广泛的培训和文化、组织变革。这些实践都是关键技能，但由于缺乏自动化和支持工具，由于技能差距和故障疲劳，这一过程已放缓到停滞状态。这里有一些新的工具，它们采用这些方法，并通过人工智能和自动化将它们提升到新的水平。下一步是部署一种持续现代化方法，该方法插入CI/CD管道，并在应用程序的整个生命周期中检测和修复技术债务。