什么不是现代化应用？

现如今，应用现代化是个火热的话题。我与客户交谈时，经常会被问到为什么以及如何进行应用的现代化。驱动企业进行应用现代化的常见原因包括核心技术人员离职的风险、软硬件过保不再被支持、CAPEX减少、业务变更需求激增等。

根据定义，一个应用程序在创建的那一刻就已经是现代化的，而且很可能在之后的一段时间内都是现代化的。虽然这是一个定义，但它对我们的讨论并不十分有用。技术、工具、编程语言和平台的演进都会影响到应用程序的构成。为了改善我们对现代应用的定义，我们需要确定时间框架，定义2019年和2020年的现代应用是什么样子。

想象一下，编写一个移动应用，该应用创建并编辑电子表格，这些电子表格全部存储在内存中，并且不与任何其他设备共享，它是一个不联网的、不可扩展的单例。

从软件生命周期的角度考虑，它不使用源代码控制，不用工具来自动构建和发布新版本，并使用手机的非常特定的功能，例如只能运行在特定分辨率的终端上。

这个极端组合的风险包括：如果手机或应用发生任何故障，你将失去所有工作内容。丢失应用安装包，无法降级到以前的版本，不仅会丢失电子表格，而且代码甚至都无法构建先前的版本。

我们肯定可以在Kubernetes上运行这种设计欠佳的应用，这也说明仅在Kubernetes上的容器中运行，并不能使其成为现代化应用。在虚机或裸机上运行的应用也不一定表示它不是现代的（微服务可以在裸机或虚拟机上运行）。

因此，一个应用应该从不同的角度（比如构建、运行、管理、连接和保护）具有某些特质，才能称作是现代化的应用。即使应用只是在开发阶段缺乏某些现代化的特征，比如说代码管理和持续集成，也无法完全称作是现代化的应用。

▐ 于是我们可以对现代化应用做出以下定义▼：

下面，我们从这几个特征展开讨论。

现代化应用由很多服务组成，其中可能包括对尚未现代化的旧系统的调用。软件服务最初是从面向服务的体系结构（SOA）以及更现代的微服务中定义的。服务倾向于遵循UNIX原则，做一件事情，并且做得很好。它们是独立的，这意味着它们可以独立运行，根据访问策略被用户调用。

软件服务的前身是客户端-服务器体系结构、胖客户端和单体式应用。企业环境中有大量使用此类架构承载核心业务的旧应用。很多旧应用在可以预见的未来不会进行现代化的改造。

一种可能是随着时间的推移，通过添加新的外部服务或微服务增加新的功能，使之与现有功能同时使用，从而将旧应用修改为现代应用。

如果应用具有足够的价值并有足够的时间，那么原始旧架构的代码将被新架构完全取代，类似忒修斯之船（指一艘船的木头逐渐被替换，直到所有的木头都不是原来的木头）。

应用只有在运行的时候才能发挥价值，因此必须考虑弹性。现代软件理论认为任何系统都一定会发生故障，因此需要将故障因素纳入其设计。

应用维护团队应考虑将故意引起的故障作为应用管理和保护的一部分，比如使用ChaosMonkey和其他混沌工程工具。关键是应用要支持弹性设计原则，同时提高员工的技能和随时准备处理故障的态度。

平均无故障时间（MTBF）和平均恢复时间（MTTR）的应用是关键弹性测量。因此，现代化应用必须具有服务水平目标（SLO），该目标定义了如何衡量服务提供的价值。一旦定义了SLO，就必须对应用进行设计，以便可以维持该级别。

对于弹性和可用性的追求也会对应用的分布式追踪和可观测性提出了要求，从而去衡量和提升SLO。

通过合理的工具来管理应用生命周期，也可以提高应用的弹性。创建可靠的CI/CD pipeline自动构建、运行和测试应用是构建弹性现代化应用的一个很好的开始。

此外，渗透测试、负载测试、API输入模糊测试、静态代码分析以及漏洞扫描都应是视为现代化应用的一部分。

对弹性的追求还带来了诸如对应用自主响应的概念。例如，Kubernetes嵌入了对应用进行运行状况检查以及根据测得的运行状况重新启动或扩展服务的概念。

现代化应用是为多云部署模型设计的。大多数企业用户都在多个云提供商中运行应用。根据Gartner的调查，“在公有云用户中，有81％的受访者表示他们正在与两家或更多提供商合作。”

应用现代化的好处之一是，通过抽象将应用和底层运行环境的硬件和平台解耦出来，从而提高了可部署性。减少应用与基础架构的耦合意味着可以将应用部署到越来越多的不同环境中，同时保持可操作性和可靠性。

但是，由于应用可以在更多地方运行，开发人员需要创建或利用支持跨云管理和治理的工具。因此，应用的现代化过程中还包括改进应用，提高团队在多云环境中开发和管理应用的能力。

现代化应用更易于部署，并且可以提高整体部署的可靠性。

从裸机到虚机、从容器到无服务器的每项技术改进都显示出软件可部署性的提高。每次转换都使软件对运行代码的系统的依赖性降低。此外，CI/CD缩短了新代码投入生产所需的时间。

现代化应用不在乎它们在哪里运行。如果围绕应用的构建、运行和管理的工具和流程是自动化和协调的，则完全有可能在裸机、容器或虚拟机中运行现代化应用。虚拟机、容器和无服务器功能之间的共同主题是，它们只是将应用打包到可以运行的环境中的方式，每种技术都有其适用的使用场景。

应用的某些部分可能永远不支持在容器中运行，但这并不妨碍现代化的工作。比如，一个长期运行的数据库随时间变得不受支持，但它对应用的运行至关重要，它可能永远无法移植到容器中。

你可能会继续在虚拟机中运行应用的这一部分，尽管如此，应用现代化仍可以采取新工具和流程用于改进构建、运行和管理这部分遗留数据库。通过现代化可以现代化的部分，改善对“遗留”依赖项的支持。在企业复杂的环境中，现代化的工作可以发生在任意应用的任意阶段。

DevOps和多云是应用现代化背后许多概念的基础。在DevOps运动中涌现的测试驱动和故障处理等实践都逐步应用于企业现代化应用改造的过程中，随着团队接受风险并开始解决风险，支撑关键应用的能力也可以得到改善。

对大多数传统业务应用进行现代化升级需要花费数月甚至数年的时间，现代化永远不会完全过渡到最新技术，而是合理的使用可改进应用各个方面的技术组合，降低风险并提高整个应用的弹性。

在现代化过程中，企业可以获得一系列的隐形收益，诸如提高团队技能水平，改进开发和运营流程，更快地将应用程序价值传递给客户以及降低故障风险等。