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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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