北京2021年11月29日 /美通社/ -- 以下为亚马逊云科技大中华区产品部总经理顾凡撰写的观点文章：
“新冠疫情让一切‘长期规划’不再有效” -- 这个说法正在得到越来越多的认同。在不少人眼里，更为明智的做法是放弃对“确定性”的探索，并且接受“不确定性”是唯一的“确定”。
“长期规划”真的无效了吗？对此我更倾向持有保留意见。自从人类步入快速发展的数字化时代，“可确定的未来”在很多时候确实已成为奢侈品，就如同新冠疫情绝不会是最后一只黑天鹅。但是，这并不意味着“长期规划”无效了。相反，现在企业的“长期规划”正在回归更为基础与核心的业务本质，即如何在变革常态中，保持业务竞争力与创新活力，让企业具备应对变化的韧性。
事实上，即使在去年商业活动最举步维艰的那段时间，我们仍能看到许多身姿灵活的企业，快速适应了新的环境，甚至发掘出新的增长机遇。相信很多人和我一样好奇，这些企业的数字化基础设施如何能在极短的时间去适应可能与过去迥异的业务需求。我们很快得到了答案 -- 从去年开始，“现代化应用”被越来越多地提及。
这意味着，更多的企业意识到，现代化应用的敏捷性、通用性及扩容能力等优势，成为企业立足长期发展的“必选项”。当你不知道变化从何而来，也无法制定如同说明书一样按部就班的发展计划，此时构建与业务相匹配，且更为敏捷的现代化应用架构，就成了面对不确定性的最优解。
虽然有时候我们会用微服务、容器化、Serverless这类技术名词去描述现代化应用，但必须强调的是，现代化应用以及实现过程并不是技术和产品的机械化堆砌。企业对现代化应用的向往并非是因为技术先进，而是为了适应业务需求、助力业务拓展，以便能够不断发现新的机会，或是创造更好的产品和服务。
现代化应用：从业务中来，到业务中去
虽然现代化应用的价值来自一个长周期内对企业业务支持的“总量”，但基于与众多用户的沟通，我们发现，现代化应用也同样是他们立足当下的现实需求。举几个有代表性的例子：有的用户会希望更少关注基础设施管理而专注于业务本身；有用户说希望软件架构从反映企业组织架构转变为反映业务逻辑；还有用户希望开发团队花费宝贵精力所编写的每一行代码都符合业务逻辑……总结起来，企业用户需要现代化应用的核心理由之一，就是从设计、构建到管理都与业务紧密相关。现代化应用一定是仅仅围绕业务核心，正所谓“从业务中来，到业务中去”。
至于业务如何从现代化应用中受益，相信很多企业都有自己的理解和期待。在亚马逊云科技眼中，现代化应用的基本特征，或者说优势，表现在以下几点：首先是敏捷性，快速开发、快速应用，并且能够敏捷迭代；第二是可扩展性，例如可扩展到数百万量级的用户，确保足够的弹性以保障业务拓展；第三是全球可用，这对于正在“出海”的中国企业尤为重要；第四是毫秒级响应能力，并能够处理PB甚至EB级别的数据。
今天，无论是提供给用户的现代化应用服务，还是自己作为一家公司走过的现代化应用历程，我们所有迭代与创新都来自用户及亚马逊自身的业务需求。这些宝贵经验，是亚马逊云科技15年持续引领现代化应用的重要基石，正如亚马逊CEO Andy Jassy所说：经验没有压缩算法。我们所有的探索都不白费，每一步都是踏实积累。
1995年亚马逊创立伊始，所有的逻辑只在一个单体应用里，也只有一个数据库。随着业务的拓展，到了2001年，亚马逊进入了面向服务架构（SOA）阶段，比如商品、订单、服务等模块都在那个时期形成。此后，亚马逊进入到了更多的领域，产品迭代和客户体验迭代的速度越来越快，这些已经按照SOA拆分出来的模块，自己又会变成超大的单体。所以2002年开始到2006年，亚马逊正式启动了微服务化架构。
为了支持新的应用架构方法，亚马逊打破职能层级，将开发团队重组为多个小型的自治团队，规模小到每个团队只能吃完两个披萨。我们让每个“双比萨团队”集中开发一个特定的产品、服务或功能集，给他们授权，让他们成为产品负责人，可以快速对所负责的产品做出决策。从那时起，亚马逊不只是从技术，而是包括从组织架构、管理策略，建立了一整套微服务体系，团队自己可以开发运营和迭代。
亚马逊在构建高度可扩展基础设施方面的成功，带来了新的核心能力拓展，这才有了亚马逊云科技在2006年成立。到2020年，亚马逊已经有超过10万个微服务，从起初每年部署几十个功能，到现在可以每年部署几百万个功能。
过去15年里，我们一直在现代化应用领域持续投入与创新。与亚马逊云科技“同龄”的Amazon Simple Queue Service (Amazon SQS)，至今仍被许多客户采用。2012年我们推出了键/值和文档数据库Amazon DynamoDB，这个可以随着应用扩展而几乎无限扩展的无服务器数据库，目前每天可以处理超过10万亿个请求，在Amazon Prime Day期间一度达到了每秒8920万次的峰值。
2014年推出的Serverless计算服务Amazon Lambda更是一个划时代的创新。如果说我们90%的创新是基于客户提出的具体需求，那么Amazon Lambda就属于剩下的10%，是我们根据客户“只提出要实现什么目标”而进行的创新。此后，我们又推出了适用于容器的Serverless服务Amazon Fargate，和高性能关系数据库Amazon Aurora -- 包括后来发布的可在不到1秒的时间内扩展至支持几十万个数据处理事务的Amazon Aurora Serverless V2，从而把客户希望从基础设施管理中解放出来而专注业务的目标做到新的极致。
什么时机、选择何种实现路径，仍由业务“做主”
企业的现代化应用转型，是否有一些可遵循的脉络？基于过往的服务全球数十万客户的实践经验，我们总结了三个可选路径，分别是：平移(Replatform)、重构(Refactor)和构建共享服务平台(Shared Services Platform) 。
在大多数情况下，这三个路径将共同组成一个现代化应用架构的完整生命周期。因此，企业用户在进行现代化应用转型时并非只取其一或遵守固定的顺序。在什么时机、什么需求场景，选择哪种路径，最终是要由企业特点和业务需求来做主。
“平移”，通常是企业上云的第一步，即利用容器把本地数据中心的应用迁移到云上，快速实现现代化应用的架构、交付模式和运营模式。对用户来说，平移的主要目的是把核心应用快速上云，利用云的弹性特点简化基础设施运营和降低维护成本。例如在本地使用了Oracle或者SQL Server，就可以快速将数据先搬到云上托管起来，暂时无需考虑数据拆分。容器化是平移的利器，在这一路径中扮演着相当重要的角色。今天云上托管的容器有80%都运行在亚马逊云上，因为我们在容器的产品和服务方面带给用户更灵活的选择。而“重构”，是通过微服务拆分、数据重构以实现应用基于业务逻辑的重构，从而获取数据驱动下的“敏捷”和创新力。重构过程中，微服务化是最重要的方法 -- 把业务逻辑和数据通过API向其它团队公开，创建一个高度解耦的架构。微服务的开发团队可以独立迭代、发布应用，极大提升创新速度，同时最小化故障发生时的爆炸半径。
重构阶段往往是利用新技术的最佳时机。比如，在此阶段企业可以优先考虑使用Serverless，让“企业写的每行代码都是应用逻辑”这一愿景成为现实。而在亚马逊云科技，Serverless并不仅仅是无服务器计算Lambda，而是提供给用户一整套Serverless服务，来帮助用户去开发基于无服务器的端到端的核心应用。
从三年前开始，Comcast旗下的领先视频广告技术公司FreeWheel开始将多个本地数据中心逐步迁移到亚马逊云科技全球的基础设施。FreeWheel通过采用Amazon Elastic Kubernetes Service（Amazon EKS）容器编排服务，实现了在现有架构不变情况下的应用迁移，使系统获得了资源弹性；使用Amazon Lambda无服务器计算构建高度可用的微服务，为各种规模的应用程序提供支持，使得系统更加易于开发和部署。一系列云上创新的举措，让FreeWheel能够在超级碗、世界杯等10多个全球收视率最高的赛事活动期间成功地支持所服务的顶级媒体，顺利应对了2秒内激增100倍的超大流量，获得了运维效率的巨大提高，节省了超过50%的资源使用成本。
“构建共享服务平台”则是为了实现现代化应用的规模化部署。当企业的微服务达到一定规模，可能会面临没有“专门针对微服务应用快速部署”运营平台的挑战。构建共享服务平台，就是让企业利用共享服务平台的标准化、自动化的运营能力，加速现代化应用开发的规模化，帮助用户专注于产品开发，提高生产力。
如何既能让每个微服务团队敏捷高效，又能让他们的代码部署管理更有一致性？亚马逊云科技在去年发布的Amazon Proton，是第一个针对容器和无服务器应用程序部署的完全托管服务。借助Amazon Proton，运营平台团队可以提供统一管理的无服务器和容器的模板，使成百上千的应用开发团队不必自己管理和维护这些基础架构，从而只需专注于业务逻辑代码的开发。
企业只需按任意顺序达成五个元素
无论企业如何实践以上三个路径，最终目标都是为了构建“有效”的现代化应用，使其能够真实有效地提升企业未来的敏捷性和创新速度。为此，企业需要做到：让自身的现代化应用按任意顺序去达成五个元素，其中既包括设计和构建方式，也包括管理模式的转型。
首先是架构微服务化。微服务颠覆了单体应用臃肿、添加改进功能复杂等顽疾，应用程序由独立组件组成，每个组件作为一个服务运行，实现一个特定业务功能，按照需求进行灵活更新、部署和扩展。在当下，微服务已经成为现代化应用“灵魂”般的存在。
第二是数据库专门化。应用现代化之后，数据和应用也可以解耦了。数据库和微服务形成一一映射，可以带来多个好处：微服务数据量增长时只需变动所对应的数据库，获得更好的扩展性；可避免单体数据库故障影响整个应用，容错性更强；微服务可以自由选择最适合业务需求的数据库，灵活度更高。
第三是自动化的软件交付通道。当单个团队独立交付软件，尤其是在手动交付时，彼此的协调性和质量一致性就成为挑战。对此，我们采用的解决方案是标准化和自动化双管齐下。首先，将软件交付流程定义为最佳实践模板，各个团队都用模板配置基础设施资源，确保正确起步；其次，通过自动发布通道，包括持续集成和持续部署 (CI/CD)，可以快速测试和发布大量代码，最大限度地减少错误。
第四是基础设施无服务器化。当我们说“无服务器”时，我们指的是那些不需要基础设施供应和扩展，具有内置的可用性和安全性，并使用付费价值计费模型的服务。无服务器能够让团队从那些与业务没有直接相关性的基础设施维护工作中解放出来，专注于创造更有价值的用户体验和创新产品。
最后是安全特性集成化。在现代化应用中，安全功能内置于每个组件，随版本变化自动测试和部署。这也意味着，安全不再只是安全团队的责任，而是深入集成到开发生命周期的每个阶段，工程、运营和合规团队都要发挥作用。
写在最后
以上，是亚马逊云科技对于现代化应用的一些观点及经验总结。我认为现在与大家深入探讨现代化应用恰逢其时 -- 企业对基础设施敏捷性和弹性的需求达到前所未有的高度，而作为连续11年被Gartner评为领导者的云服务供应商，亚马逊云科技所带来的一整套现代化应用构建方案及方法论，也的确值得被关注和思考。因为所有的这些探讨，都是基于无数实践的检验并被证明有效。
现代化应用转型将是一个长期持续的过程。在这一旅途中，亚马逊云科技也期待聆听所有客户的需求，并利用我们在云服务领域卓越的广度、深度和创新速度，为每个客户构建可支持未来长期业务创新的现代化应用架构。
