这是一篇货真价实的大软文，作者是亚马逊现任 CTO Werner Vogels 先生。但这篇大软文挺好看的，因为 CTO 写的深入浅出，很容易让人了解到，从技术发展的维度看，为什么是亚马逊先把云计算鼓捣出来了。顺便也解释了，亚马逊的“两个披萨”文化是怎么来的，以及亚马逊快速创新的部分秘密。如果你不关心云计算技术，那么看到小标题之前就可以了。如果你关心云计算技术，也看到小标题之前就可以了，因为后边的内容太技术向了，我不敢保证能翻译准确。
原文来自公众号：西卅廿（ID：xisanian），作者： Werner Vogels（亚马逊 CTO），翻译：郝晓茹，封面来自视觉中国
创新一直是亚马逊公司 DNA 的一部分。大概 20 年前，为了让我们的创新迭代过程——“发明、发布、再发明、再发布、重新开始、大浪淘沙（rinse）、重复、一次又一次”——速度更快一些，我们经历了一场彻底的变革。这场变革不仅影响了我们如何开发产品，而且影响了我们如何组织公司。
20 年前，亚马逊网站服务的用户数量，只占今天我们所服务用户的很小一部分。但那时候，我们就知道，如果想扩展亚马逊网站提供的产品和服务项目，我们就必须改变整个网站的应用架构。
当时驱动 Amazon.com 网站的是一个大型的、单体的“在线书店”程序和对应的单体大型数据库。这种情况限制了我们的速度和敏捷度。因为主程序最初是专为我们的第一个产品——在线书店而开发的，所以每当我们想要增加新的功能，或为顾客提供新产品，比如视频串流（video streaming）功能，就必须重新编写整个程序的代码。重新编写整个程序代码的过程，漫长而笨重，需要复杂的业务和部门人员协调过程，这种情况影响我们快速创新和规模化创新的能力。
于是，我们撰写了《分布式计算宣言》，将其作为公司寻求变革的蓝图。在这份内部文档中，我们描述了新的系统应用架构。然后，遵循这份宣言，我们开始对整个系统应用进行重构，将其分割为被称为“服务”的模块，便于支撑亚马逊的规模扩张。
改变整个系统的应用架构，只完成了亚马逊这场变革故事的一半（另一半是公司组织的调整）。回到 1998 年，所有的亚马逊开发人员都在维护同一个程序，这意味着每一次新版本的发布，都需要协调所有开发团队。
为了支持新的应用架构，我们打破了职能等级，将团队重组为小型的、自治的小组。每个小组都小到只需要两个披萨就能喂饱。我们让每个小组都专注于一个具体的产品、服务或功能组，从而让他们对整个应用的某个具体模块拥有更多权限。这么做之后，我们的产品开发者就变成了产品的主人，他们可以更快速地做出会影响到自己这部分产品的决策。
打破我们的组织结构和应用架构是一个大胆的主意，好在这个主意最终成功了。因此我们能够以更快的速度，为顾客带来创新：随着亚马逊的成长，我们从每年部署几十项新功能，到如今每年能部署数百万项新特性。更戏剧性的是，我们在创建高扩展性基础设施方面取得的成功，不仅最终变成了一项亚马逊新的核心能力，也为我们在 2006 年发布 AWS 云服务打下了基础。
直到现在，我们依然坚持将团队分成“两个披萨就能喂饱”小组进行工作。
在追求快速创新的道路上，我们并不孤单。为了保持竞争力，很多公司都想要增加敏捷性，从而持续发现新的机会，开发更好的产品。因此很多公司踏上跟亚马逊同样的旅程，转向现代化的应用开发模式。这种新的开发模式，需要将传统应用的单体架构转向更小的组件集架构，或者叫微服务（microservice）架构。对于现代化应用的最佳实践而言，变革不仅涉及改变设计和运用技术的方式，也需要重新思考如何进行人员管理。
任何公司，若想在新的程序开发模式下取得成功，增加公司的敏捷性和创新速度，都应采用以下五项基础技术：微服务、专用数据库（purpose-built databases）、自动化软件发布管道、无服务器（serverless）操作模式、自动化且贯穿始终的安全性。
架构模式：微服务（Microservices）
跟亚马逊一样，大部分公司刚开始的时候都是以单体程序（monolithic application）开展业务，因为这样速度最快，也最容易开发。然而，这种将所有进程绑定在一起，作为整体服务提供的方式，存在一个问题：如果其中一个模块遇到需求高峰，那么为了应对这个模块的高负载，整个架构都需要扩展计算容量。
此外，随着代码库的增长，程序功能的添加和改进都变得更加复杂。因此，试验和实现新想法也更加困难。这种单体程序的架构还增加了整个系统的可用性风险，因为所有进程都互相依赖、紧密耦合（coupled），如果其中一个进程发生错误，就会影响整个系统。
这就是为什么，随着公司成长，大家就会开始考虑“微服务”架构。公司采用微服务架构之后，软件系统由独立的组件构成，每个进程都作为一项服务存在。而每项服务都代表一项业务能力，比如购物车。由于每项服务独立运作，由单独的开发小组负责，所以开发小组可以自主升级、部署和扩张这项服务，以满足整个系统对特定服务模块的需求。以购物车的例子来说，举行促销的时候，就可以单独为购物车扩容，以满足更大规模用户的临时需求。
很多开发者发现，随着公司程序架构从大型单体程序模式转到微服务模式，他们希望通过管道（pipeline），来管理每项服务之间的依赖关系（dependencies）。因此，开发者不得不采用新的解决方案，来打包程序和运行代码。有了新的解决方案，过去那种创建虚拟机实例（instances）的方式，不再是唯一的选项。
开发者可以使用软件容器（container）或 AWS “Lambda 函数”。软件容器是最受欢迎的代码打包选项，也是把传统应用推向现代化的重要工具，因为软件容器在配置上提供了出色的便携性和灵活性。通过 AWS Lambda，操作变得更加简单，开发者只需要写商业逻辑的代码就行。
最后，微服务之间如何“沟通”是另一个需要考虑的事情。很多应用程序继续使用 API 进行连接，但是微服务之间还有多种传递数据的方法。比如实时数据处理需要的串流模式。比如数据变化之后触发响应的事件模式。再比如，控制应用程序之间通信，实现可观察性（Observability）的 App Mesh 服务网格。开发者可根据公司业务需求，选择最适合的集成方式。
数据管理：专用数据库
现代化应用基于“计算和存储解耦架构”开发，解耦（decoupled）之后，将专用数据库与微服务一对一映射，而不是采用一个大型单体的数据库。相对传统程序架构而言，计算和存储解耦是非常重要的变化。因为就像传统的大型单体程序，随着业务扩张会遇到扩容和容错的挑战，数据库也是这样：单一数据库意味着一点出错全盘皆输，而且很难让单一数据库来满足多种不同类型微服务的专门需求。通过存储-计算解耦，开发者就可以根据自己的需求，选择最合适的数据库。
对于大部分程序来说，最佳选择也许仍然是关系型数据库，但是也有很多程序有不同的数据需求。例如，如果你需要处理高度关联的数据集，比如你在开发推荐引擎，那么可以选择图形化数据库（graph database），如 Amazon Neptune，适合存储和查找数据间的联系。
或者，如果你的程序需要实时接入数据，那么你可以选择内存数据库（in-memory database），如 Amazon ElastiCache，这种数据库经常被用于游戏和IoT（物联网）领域。通常，能充分满足微服务需求的数据库，才是最好的数据库。
软件分发：自动化软件发布管道
我们拆除了 Amazon.com 网站所采用的单体程序架构，将人员重组为“两个披萨”小组。同时，我们也不再使用单一软件发布管道，而是开始允许各小组独立发布自己的服务。
允许各小组独立发布服务之后，我们消除了开发和发布软件升级包时，所遇到的人员和业务协调难题。但是，这种将开发和发布过程权力下放的方式，也带来一系列新挑战：让所有团队都保证发布流程和质量的稳定性，变得更加困难。尤其是，如果发布流程的每一步都是手动的，那么就增加了人为出错的可能性。
我们的解决方案是双管齐下：标准化和自动化。首先，我们把软件交付流程定义为最佳实践模板，该模板提供在云环境中建模和配置基础架构资源的标准。这种模板利用了“基础架构即代码”（infrastructure as code）服务，也就是说，模板通过代码为程序提供全部技术栈，而无需手动流程，因此团队成员可以更快上手。在亚马逊，最佳实践模板确保了各个团队可以按照我们的要求，自行配置和部署他们自己的业务流程。
其次，我们消除了软件交付流程中的手动操作步骤，使用自动化的方式取而代之。通过自动化软件发布管道，我们实现了持续集成（Continuous Integration，CI）和持续部署（Continuous Deployment，CD），这样不仅能快速发布测试版本，而且能将出错的可能性最小化。通过持续集成（CI），我们的团队可以随时将代码合并到中心代码库，然后执行自动化地创建和测试，从而尽早发现问题所在。通过持续部署（CD），我们的团队在不经过任何人为操作的情况下，每天都可以多次提交代码更改，并且自动部署上线。
最初，我们认为缺少人为参与的产品部署会很容易出问题。但是，在我们花了很多时间进行测试，并部署了失效安全（fail-safe）方案之后，最终我们发现，自动化发布不仅极大地提升了我们的速度和敏捷度，而且还提升了代码的质量。
操作模式：尽可能多采用“无服务器”架构（serverless）
现代化的应用有很多活动部件（moving parts），而不仅仅只有单个程序和数据库，它还可能包含几千项服务，每个服务都有专用数据库，以及一个配套的持续发布新功能的团队。
这些活动部件，可分为两个类别：
一类是公司的核心竞争力（secret sause），是公司在市场上取得成功的原因，比如创建独特的用户体验，或者开发创新的产品。
一类我们通常称之为无差别的日常事务，这些任务是必须要做的，但是并不会带来竞争优势。对于大部分公司来说，这些任务包括服务器管理、负载均衡，以及给系统打安全补丁。
2014 年，通过发布 AWS Lambda，我们介绍了无服务器（serverless）的概念。AWS Lambda 是一项计算服务，让你可以运行代码，但不需要预先准备或管理服务器。这么做符合我们的最终目标：帮助客户公司围绕核心竞争力的优化资源，而将日常事务交给 AWS。这种理念已成为现代化应用开发中的关键原理。你的公司如果转用无服务器模式，就可以专注于那些让自己的公司更加出众的事情，比如产品创新。
当我们说“无服务器”的时候，我们指的是这样的服务模式：不需要关注基础设施的使用和扩展，服务已经内建可用性和安全性，这种模式采用只为价值付费（pay-for-valuebilling）的计价模式。终极的“无服务器”架构，不仅计算这部分是无服务器，而且整个应用的技术栈都是无服务器架构。
一个应用的技术栈，通常包括以下三个不同的组件：
计算服务，例如 AWS Fargate，用来运行程序逻辑。
数据库，比如 MySQL 和 PostgreSQL 关系型数据库，或者 Amazon Aurora，用来存储数据
一个集成层（integration layer）负责在两者之间传输数据，比如 Amazon EventBridge
大家可以在三个组件上都采用“无服务器”架构，这样开发的程序可以最大化无服务器架构的优势。
在亚马逊，我们目前还没有在所有组件里都采用“无服务器”架构。但是，我们正朝着这个方向努力。亚马逊的许多客户公司也是如此。事实上，我们预测很快就会有这样一代开发者：他们从来没有接触过服务器，只需要写业务逻辑代码就行。原因很简单，不管你是开发全新的程序，还是移植旧的程序，在计算、数据存储和集成层从一开始就使用无服务器模式，你的敏捷度就能最大化。这是原生云计算的优势。
安全：每个人的责任
过去，很多公司将安全视为魔法粉尘——等到产品发布之后，再往产品上撒一点就行。但是在持续发布的循环周期里，这种情况行不通了。所以，很多公司部署了新的安全策略，为整个程序创建防火墙。但是，这样也会存在挑战：如果整个程序的每个模块都采用同样级别的安全设置，那么当其中某个模块需要不同的安全等级设置，就会出现问题。
正因为如此，在现代化的应用中，安全特性被内置于每个模块中。而且这些安全特性可以随着每一次的服务发布，进行自动化测试和部署。这意味着，安全不再是安全团队的独有责任，而是深度集成到产品开发周期的每个阶段。工程、运营以及合规团队都需要参与其中。
就像代码库、构建管理程序（build management）和部署工具一样，安全性也被集成到工具中。安全工具既适用于软件发布管道本省，也适用于通过该管道发布的软件。通过“无服务器”服务，安全状态更易于维持，因为底层的基础设施安全操作——比如操作系统版本更新、软件打补丁以及监视，已经被内置于每一项服务中。
转型之旅
我们的客户公司，究竟是如何进行转型，如何开始部署现代化应用的？尽管因为每个公司都不同，并没有单一的成功路径，但是我们还是看到有几种常见的转型模式，也包括我们在亚马逊的转型模式。
在亚马逊，当我们决定专注于创新，对 Amazon.com 进行大规模扩展的时候，我们重构了单体式的系统程序架构，重组了公司组织结构，然后通过自动化和抽象化来优化云端程序架构。一些我们的公司客户，比如 Yelp，也采用了类似的转型路径。
有的客户公司，之前已部署了本地托管服务器（on premise），因此他们选择重新托管，将整个程序“平移”（lifting and shifting）到云端。转移到云端之后，很多客户公司就可以将诸如数据库和 API 管理这样的事情，交给 AWS 云服务，从而让自己专注于公司的核心业务逻辑。
如今，越来越多客户公司踏上“再生”之路，他们采用无服务器的微服务架构开发新的程序，让公司可以充分利用云端的优势。
尽管在 AWS 平台上，每个公司都能找到最适合自身状态的实施方式，不同架构的应用可以共存，通过多种路径实现交互。但是我们经常可以看到，客户公司部署了现代化应用之后，很快发现了新架构为整个业务带来的好处，尤其是在如何分配时间和资源方面。他们可以花更多时间在业务逻辑的定义上，可以轻松扩展以满足用户的峰值需求，也可以增加敏捷性，更快更频繁地将新功能发布到市场上。
举个例子，Edmunds.com 为买车人提供最新的车辆信息，他们的网站上线新功能的时间，已经从过去的六个月降低到一周时间。同样，创业公司 Bynder 的新产品推向市场的时间，也从一年降低到一个月。通过改变使用技术的方式，这些公司提升了业务能力。
这就是现代化应用的力量。
原文来自公众号：西卅廿（ID：xisanian），作者： Werner Vogels（亚马逊 CTO），翻译：郝晓茹，原标题：《Modern applications at AWS》，原文链接：www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html
