面对"不确定性"的最佳解：现代化应用

「长期规划」真的无效了吗？对此，我更倾向持保留意见。自从人类步入快速发展的数字化时代，「可确定的未来」在很多时候确实已成为一种奢侈，就如同新冠疫情绝不会是最后一只黑天鹅，但这并不代表不再「长期规划」有效。相反地，现在企业的「长期规划」正在回归到更为基础与核心的业务本质，也就是如何在变革的常态中，保持业务竞争力与创新的活力，让企业具备应对变化的韧性。

事实上，即使在去年商业活动最举步维艰的那段时间，我们仍看到许多具备灵活性的企业快速适应了新的环境，甚至发掘出新的成长机会。相信很多人和我一样好奇，这些企业的数字化基础设施如何能在极短的时间去适应与过去迥异的业务需求。我们很快得到了答案──从去年开始，「现代化应用」被越加频繁地提及。

这意味着，更多的企业意识到现代化应用的敏捷性、通用性及扩展性等优势，成为企业立足长期发展的「标配」。当你不知道变化将从何而来，也无法制定如同说明书一样按部就班的发展计划时，构建与业务互相搭配且更为敏捷的现代化应用架构，就成了面对不确定性的最佳解。

虽然有时候我们会用微服务、容器化、无服务器这类技术名词去描述现代化应用，但必须强调的是，现代化应用及实现过程并不是技术和产品的机械化堆栈。企业对现代化应用的向往并不是因为其技术先进，而是为了适应业务需求并助力业务拓展，以不断发现新的机会，或创造更好的产品和服务。

现代化应用：始于业务、终于业务

虽然现代化应用的价值来自一个长周期内对企业业务支持的「总量」，但基于与众多用户的沟通，我们发现现代化应用也同样是他们立足当下的现实需求。举几个有代表性的例子：有些用户会希望更少关注基础设施管理，而是专注于业务本身；有些则希望软件架构从反映企业组织架构转变为反映业务逻辑；还有些用户希望开发团队花费宝贵精力所编写的每一行代码都符合业务逻辑。

总结而言，企业使用者需要现代化应用的核心原因之一，就是从设计、构建到管理都与业务紧密相关。现代化应用一定是紧紧围绕着业务核心，正所谓「始于业务、终于业务」。

至于业务如何从现代化应用中受益，相信很多企业都有自己的看法和期待。在AWS眼中，现代化应用的基本特征，或者说优势，体现在以下几点：

一、敏捷性：快速开发、快速应用，并且能够敏捷地迭代；

二、可扩展性：例如可扩展到数百万量级的用户，确保足够的弹性以保障业务拓展；

三、全球可用：这对于正在「出海」的企业尤为重要；

四、毫秒级的回应能力：并且能够处理PB级、甚至EB级的数据。

今天，无论是提供给使用者的现代化应用服务，还是自己作为一家公司走过的现代化应用历程，我们所有的迭代与创新都来自于用户及亚马逊自身的业务需求。这些宝贵经验是AWS15年持续引领现代化应用的重要基石，正如亚马逊执行长Andy Jassy所说：经验没有压缩算法（There is no compression algorithm for experience）。我们所有的探索都不白费，每一步都是经过踏实地累积而来。

1995年亚马逊创立之初，所有的逻辑只在一个单体式应用里，也只有一个数据库。随着业务的拓展，到了2001年，亚马逊进入了面向服务架构（SOA）阶段，比如商品、订单、服务等模块都在那个时期成形。此后，亚马逊进入了更多领域，产品迭代和客户体验迭代的速度越来越快，这些已经按照SOA拆分出来的模块，自己又会变成超大的单体。所以2002年到2006年，亚马逊正式启动了微服务化架构。

为了支持新的应用架构方法，亚马逊打破职级，将开发团队重组为多个小型的自治团队，规模小到每个团队只能用两个披萨就喂饱。我们让每个「双披萨团队」集中开发一个特定的产品、服务或功能集，授权他们成为产品负责人，可以快速对他们负责的产品做出决策。从那时起，亚马逊不只是从技术，而是包括从组织架构和管理策略，建立一整套微服务体系，团队可以自行开发营运和迭代。

亚马逊在建构高度可扩展基础设施的成功拓展新的核心能力，这才有了AWS在2006年的成立。到2020年，亚马逊已经有超过10万个微服务，从起初每年部署几十个功能，到现在可以每年部署几百万个功能。

过去15年来一直在现代化应用领域持续投入与创新。与AWS「同龄」的Amazon Simple Queue Service（Amazon SQS）至今仍被许多客户采用。2012年我们推出了键值和文文件数据库Amazon DynamoDB，这个可以随着应用的拓展而几乎无限扩展的无服务器数据库，目前每天可以处理超过10兆个请求，在Amazon Prime Day期间一度达到每秒8,920万次的峰值。

2014年推出的无服务器运算服务Amazon Lambda更是一个划时代的创新。如果说我们90%的创新是基于客户提出的具体需求，那么Amazon Lambda就属于剩下的10%，此是根据客户「只提出要实现什么目标」而进行的创新。此后，又推出适用于容器的无服务器服务AWS Fargate，和高效能关系数据库Amazon Aurora──包括后来发布的Amazon Aurora Serverless V2，可在不到1秒的时间内扩展至支持几十万个数据处理交易，从而把客户「希望从基础设施管理中解放出来而专注于业务」的目标做得更极致。

什么时机、选择何种实现路径，仍由业务「做主」

企业的现代化应用转型，是否有一些可遵循的脉络？基于过往服务全球数十万客户的实战经验，总结三个可选择的路径，分别是：平移（Replatform）、重构（Refactor）和建构共享服务平台（Shared Services Platform）。

在大多数情况下，这三个路径将共同组成一个现代化应用架构的完整生命周期。因此，企业用户在进行现代化应用转型时，并非只取其一或遵守固定的顺序。在什么时机、什么需求场景、选择哪种路径，最终要由企业特性和业务需求来做主。

「平移」通常是企业上云的第一步，即利用容器把本地数据中心的应用迁移到云端，快速实现现代化应用的架构、交付模式和营运模式。对使用者来说，平移的主要目的是把核心应用快速上云，利用云端具备弹性的特点简化基础设施营运并降低维护成本。例如在本地使用了Oracle或者SQL Server，就可以快速地将数据先搬到云端托管，暂时无需考虑数据拆分。

容器化是平移的利器，在这一路径中扮演着相当重要的角色。今天云端托管的容器有80%都运行在AWS上，因为我们在容器的产品和服务方面带给使用者更灵活的选择。

而「重构」是透过微服务拆分、数据重构以实现应用基于业务逻辑的重构，从而获取数据驱动下的敏捷性和创新力。重构过程中，微服务化是最重要的方法──把业务逻辑和数据透过API向其它团队公开，打造一个高度解耦的架构。微服务的开发团队可以独立迭代、发布应用，大幅提升创新速度，同时最小化故障发生时的影响半径。

重构阶段往往是利用新技术的最佳时机。例如，在此阶段企业可以优先考虑使用Serverless，让「企业所写的每行程序代码都是应用逻辑」的愿景成真。而在AWS，Serverless并不仅仅是无服务器运算Lambda，而是提供给使用者一整套无服务器服务，来协助使用者开发基于无服务器的端到端核心应用。

从三年前开始，Comcast旗下的影音广告技术公司FreeWheel开始将多个本地数据中心逐步迁移到AWS全球的基础设施。FreeWheel透过采用Amazon Elastic Kubernetes Service（Amazon EKS）容器协调服务，在不改变现有架构的情况下实现应用迁移，让系统获得了资源弹性；使用Amazon Lambda无服务器运算打造高可用性的微服务，为各种规模的应用程序提供支持，使得系统更易于开发和部署。

一系列云端创新的行动，让FreeWheel能够在奥运会、Super Bowl、世界杯等10多个全球收视率最高的赛事活动期间，成功地支持所服务的一线媒体，顺利因应2秒内激增100倍的超大流量，大幅提升维运效率并节省了超过50%的资源使用成本。

「建构共享服务平台」则是为了实现现代化应用的规模化部署。

当企业的微服务达到一定规模，可能会面临「没有专门针对微服务应用快速部署营运平台」的挑战。建构共享服务平台就是让企业利用共享服务平台标准化、自动化的营运能力，加速现代化应用开发的规模化，协助用户专注于产品开发、提高生产力。

如何既能让每个微服务团队敏捷高效，又能让其程序代码部署管理更有一致性？AWS的AWS Proton是第一个针对容器和无服务器应用程序部署的完全托管服务。借助AWS Proton，营运平台团队可以提供统一管理的无服务器和容器的模板，使数百或数千支应用开发团队无须自己管理和维护这些基础架构，只需专注于开发业务逻辑程序代码。企业只需按任意顺序达成五个元素。

无论企业如何实践以上三个路径，最终目标都是为了建构「有效的」现代化应用，使其能够真实有效地提升企业未来的敏捷性和创新速度。

为此，企业需要做到让自身的现代化应用按任意顺序去达成五个元素，其中既包括设计和建构方式，也包括管理模式的转型。

五个元素叙述如下：

一、架构微服务化

微服务克服了单体式应用庞大、添加改进功能复杂等挑战，应用程序由独立组件组成，每个组件作为一个服务运行，实现一个特定业务功能，按照需求进行灵活更新、部署和扩展。在当下，微服务已经成为现代化应用「灵魂」般的存在。

二、数据库专用化

应用现代化之后，资料和应用也可以解耦了。数据库和微服务相辅相成，可以带来多个好处：微服务数据量成长时只需变动相对应的数据库，获得更好的扩展性；可避免单体式数据库故障而影响整个应用，容错性更强；微服务可以自由选择最适合业务需求的数据库，灵活度更高。

三、自动化的软件交付管道

当单个团队独立交付软件，尤其是在手动交付时，彼此的协调性和质量一致性就成为挑战。对此，我们采用的解决方案是标准化和自动化双管齐下。首先，将软件交付流程定义为最佳实践模板，各个团队都用模板配置基础设施资源，确保正确起步；其次，透过自动发布管道，包括持续整合和持续部署（CI/CD），可以快速测试和发布大量程序代码，最大限度地减少错误。

四、基础设施无服务器化

当我们说「无服务器」时，我们指的是那些不需要基础设施供应和扩展，具有内建的可用性和安全性，并使用按需付费模型的服务。无服务器能够让团队从那些与业务没有直接关连的基础设施维护工作中解放出来，专注于创造更有价值的用户体验和创新产品。

五、安全特性整合化

在现代化应用中，安全功能内建于每个组件，随版本变化自动测试和部署。这也意味着，安全不再只是安全团队的责任，而是深入整合到开发生命周期的各个阶段，工程、营运和合规团队都要发挥作用。

写在最后

以上是AWS对于现代化应用的一些观点和经验总结。我认为现在与大家深入探讨现代化应用恰逢其时──企业对基础设施敏捷性和弹性的高度需求是前所未见的，而作为连续11年被Gartner评为领导者的云端服务供货商，AWS带来的一整套现代化应用建构方案及方法论，也确实值得被关注和思考，因为这些探讨都经过无数实际应用的检验，而且已被证明有效。

现代化应用转型将是一个长期、持续的过程。在这趟旅途中，AWS也期待聆听所有客户的需求，并运用我们在云端服务领域卓越的广度、深度和创新速度，为每一个客户建构可支持未来长期业务创新的现代化应用架构。

（本文作者顾凡为AWS大中华区产品部总经理）