Gartner：对传统应用进行现代化改造，成功实现后浪云

想让现有的、云时代之前的企业应用程序能够充分利用云计算，存在着许多技术障碍，例如操作系统版本不受支持，与企业数据存储或者文件存储紧密集成的单体架构，而且难以满足利益相关方的期望（包括降低成本的期望）。

如果是采用云原生架构的“绿地”应用程序，它们受到这些挑战的影响就要小得多，但是这些新的应用程序在组织现有的应用程序中只占一小部分。

使用“拎包入住”方式迁移到基础架构即服务（IaaS）上重新托管的旧有应用程序通常无法充分利用所有的云特性。采用这种重新托管方法的组织经常会发现迁移团队走了捷径，提出的变通办法只是为了让应用程序能够运行起来。

之所以会出现这些捷径和变通的办法，是因为重新托管的目标是要在时间紧迫的情况下迁移应用程序，并支持其他已经运行在云端、经过了重大调整的应用程序。从来没有对旧有的应用程序进行过云原生就绪情况的全面评估，这就导致了糟糕的后果。

一个需要考虑的问题是，旧有应用程序通常会依赖传统的关系型数据库管理系统（RDBMS）和原子化、一致、隔离和持久（ACID）的事务来实现强大的数据完整性。

这些传统数据库依赖着底层坚如磐石的、可靠的基础设施。它们不是为了基础结构不稳定或者容易发生故障的环境构建的。这些数据库还意在向上而不是向外扩展，这阻碍了你利用丰富的云资源并限制了弹性扩展应用程序的能力。

然而，当代应用程序设计利用多语言持久性来优化特定用例的数据库行为。这一概念允许开发人员选择最适合数据及其编程方法的数据存储，而不是强制数据适应传统的结构化查询语言（SQL）模型。将RDBMS用于所有数据存储可能会导致设计缺乏灵活性，并在扩展数据库时产生大量成本。

采用云计算需要仔细规划，并深入了解现有应用程序向云原生架构迁移的障碍所在。Gartner的客户经常会把糟糕的规划和不恰当的迁移策略列为云使用不达标的原因。如果没有规划和结构，就经常会为了让应用程序运行，在迁移中做出决策。这会导致其与既定目标不一致。

设定目标

云迁移通常包含多种应用程序，其中一些应用程序需要大修或更新，并且可以受益于云提供的功能。这些计划因组织而异。这些举措背后的决策、流程和人员是每个组织特定的。但是，Gartner明确并介绍了几个会反复出现的技术目标。

至关重要的是，必须用特定的业务目标来指导组织的云现代化工作，并且要确保整个组织内的利益相关方都与这些目标保持一致。例如，并非所有应用程序的现代化都需要重新构建。如果数据库的分区方式不是给定应用程序的云迁移目标之一，可能就不需要对其进行调整来提高可伸缩性。

构建工作量记分卡

Gartner 提出了一个应用程序现代化的框架，涵盖了针对特定热点的架构评估。

应该评估每个热点是如何妨碍迁移的业务目标，以此确定实现应用程序现代化所需的工作量。应用程序越容易调整，采用云原生架构模式和原则所需的工作、精力和资源就越少。

此步骤要求你建立一个工作量记分卡，在评估工作的其余部分分析每个热点时填充这个卡片。

阻碍现代化的因素

有两个主要的制约因素会增加应用程序现代化的工作量——耦合和复杂性。

可以将耦合看作是应用程序内、外部相互依赖关系的数量。例如，从代码的角度看，你要检查代码块如何同彼此以及调用图交互——包括方法、类和函数的组成方式。依赖于不同代码块的脚本或代码块被视为耦合。

体系架构和代码的复杂性会让耦合问题变得更加复杂。严密耦合且严重依赖底层软、硬件细节的应用程序组件可能会带来复杂性。这种复杂性限制了面向云原生平台的部署、运行时和托管选择。实现那些相似且同时变化的底层依赖项和组件的抽象和封装非常重要。从这个意义上说，复杂性意味着具有难以实现的依赖关系。应用程序级的依赖关系——例如应用程序组件之间的依赖关系——也可能会有影响。

对应用程序的评估将揭示应用程序中耦合的深度和复杂性。它让你能够确定对应用程序中的每个热点进行现代化改造所需的总体工作量。根据这些现代化的不同程度，你可以为代码的不同部分选择不同的策略。

现代化的程度和业务目标直接相关。如果应用程序的变化能力足以满足这些目标，重构代码并将应用程序进行现代化，适应云原生平台就足够了。如果全面现代化的工作量很大，你可能就别无选择了，只能重新构建整个应用程序。但是，如果从应用程序架构的角度来看，你的现代化水平较低，而从数据持久性的角度来看现代化程度较高，你也可以重新架构并重新构建单个组件。