创新已经渗透到了亚马逊的DNA中......本文就从微服务、专用数据库、自动化软件发布管道、无服务器操作模型、以及自动化和安全性这五个方面介绍下亚马逊是如何利用应用程序开发来提高敏捷度和创新速度的！
作者
WernerVogels，技术总监
亚马逊译者
弯月，责编
郭芮
以下为译文：
创新已经渗透到了亚马逊的DNA中，大约在20年前，我们经历了一次彻底的转型，目标是实现更快的迭代过程：开发、发布、再开发、再发布、重新开始、反复、一次又一次。我们经历的变化不仅影响了我们构建的应用程序，还影响到了公司的组织方式。
当时，我们的客户只占亚马逊总体客户数量的很小一部分。尽管如此，我们明白如果我们想扩展我们提供的产品和服务，就必须改变我们处理应用程序体系结构的方式。
我们曾经为亚马逊网站提供“在线书店”的应用程序，但是这个庞大的应用程序和数据库限制了我们的速度和敏捷度。每当我们想为客户添加新功能或产品（例如视频流），都必须在我们专门为“在线书店”设计的应用程序的基础之上，编辑和重写大量的代码。我们的开发过程漫长而笨拙，我们需要复杂的协调，这限制了我们快速、大规模创新的能力。
后来，我们通过“分布式计算宣言”制定了变革的计划。这个宣言是一个内部文档，其中描述了新的体系结构。我们借助这个宣言将我们的应用程序重组成各个小部分，我们称之为“服务”，在这些“服务”的助力下，我们大幅扩展了亚马逊。
然而，这只是我们为改变应用程序架构而迈出的第一步。早在年，所有亚马逊的开发团队都在开发同一款应用程序，而且每次应用程序的发布都需要在各个团队之间进行协调。
为了支持这种新的体系结构方法，我们分解了职能层次结构，并将组织重组为小型的自主团队，各个团队都很小——两个比萨就够吃的规模。每个“两个比萨规模的团队”都会集中精神开发某个产品、服务或功能集，同时我们还赋予了每个团队针对应用特定部分做决定的特权。我们希望每个开发人员都能建立主人翁精神，迅速做出能够影响他们各自产品的决策。
打破组织和应用程序结构是一个大胆的想法，但是很管用。我们能够以更快的速度为客户提供创新，而且随着亚马逊的发展，我们每年能够成功部署的功能由几十个发展到了数百万个。其中最为显著的成果是，我们在构建高度可扩展基础架构方面的成功最终引发了新的核心能力，于是在年AWS问世了。
如今，我们仍然以“两个比萨规模的团队”的形式开展工作。
在追求快速创新这条路上，我们并不孤单。为了保持竞争力，各家公司都需要提高敏捷度，以便不断发现新机会并创造更好的产品。这就是为什么越来越多的客户也开始追随亚马逊的步伐，并转向现代应用程序开发的原因。尽管这种新方法需要从整体架构向组件或微服务转变，但现代应用程序的最佳实践不仅限于改变设计和构建技术的方式。你还需要重新考虑管理的方式。
为了成功地利用应用程序开发来提高敏捷度和创新速度，各个组织必须具备以下五大元素（排序不分前后）：微服务；专用数据库；自动化软件发布管道；无服务器操作模型；以及自动化的、持续安全性。
体系结构模式：微服务
大多数公司（包括亚马逊）的业务发展都始于单体应用程序，因为这种应用程序的开发最快，且开发难度最小。然而，将多个应用程序组织到一起，并作为统一的服务运行时就会出现问题。如果应用程序的某个流程遇到需求高峰，为了处理这个流程的负载，就必须扩展整个体系结构。
此外，随着代码库的增长，添加和改进功能也会变得越来越复杂，所以很难尝试和实施新的想法。整体架构还会增加应用程序可用性的风险，因为许多相互依赖且紧密耦合的处理都会增大单个处理的失败率。
于是，随着公司的发展，微服务应运而生了。在微服务架构下，应用程序由独立的组件组成，这些组件将每个应用程序的处理作为服务运行。服务是为业务功能而构建的，例如在线购物车，而且每个服务都会执行某个功能。各个服务单独运行，由一个开发团队管理，因此每个服务都可以单独更新、部署和扩展，以满足对应用程序特定功能的需求。例如，销售的购物车可以支持更多的用户。
随着各个组织从整体服务转向微服务，许多开发人员发现他们希望通过管道来管理每个服务中的依赖关系，并且他们需要建立新方法来打包应用程序和运行代码。由于这些创新的出现，服务器实例不再是云计算的唯的选择。
你还可以使用容器，或AWSLambda函数。容器是最流行的打包代码的形式，而且容器也是将遗留应用程序转换成现代化应用程序的好工具，因为容器具有出色的可移植性和设置应用程序的灵活性。而你可以利用Lambda将开发的负担降至最低，你唯一需要编写的代码就是业务逻辑。
微服务的另一个考虑因素是它们需要一种相互通信的方式。许多应用程序选择继续使用API连接，但是服务之间的数据发送还有其他选择。其中包括用于实时数据处理的流传输，用于触发数据更改引发的事件，以及用于应用程序级通信和可观察性的服务网格。你可以选择适当的集成方式从最大程度上满足你的需求。
数据管理：专用数据库
现代应用程序都采用了与数据存储解耦的方式，数据库和微服务一对一映射，整个应用程序所对应的数据库不止一个。与传统的应用程序体系结构相比，这是一个重要的转变，因为就像整体应用程序随着增长带来的扩展和容错难题一样，数据库亦是如此。另外，每个数据库都可能成为一个故障点，单个数据库很难满足一组微服务的特定需求。你可以通过分离数据与微服务，自由选择最适合的数据库。
对于许多应用程序而言，关系数据库仍然是最佳选择，但是许多应用程序具有不同的数据需求。例如，如果你运行的应用程序需要处理高度关联的数据集（例如推荐引擎），则可以选择图形数据库（例如AmazonNeptune）来存储和导航关系。
如果你的应用程序需要实时访问数据，则可以选择内存数据库，例如AmazonElastiCache，该数据库通常用于游戏和IoT应用程序中。一般来讲，只有能够完全满足你的微服务需求的数据库才是最佳选择。
软件交付：自动发布管道
当我们放弃亚马逊的整体架构，重组为“两个比萨规模的团队”时，我们不再使用单一发布渠道，并开始推进每个团队独立发布。
尽管独立发布可以消除发布和交付更新的协调难题，但分散开发和发布流程却带来了一系列的新挑战。保证所有团队的发布流程和质量是一件非常困难的事情，尤其是在发布流程的每个步骤都需要手动操作的情况下，人为错误频频发生。
我们从两个方面着手解决这个问题：标准化和自动化。首先，我们按照最佳实践模板定义了软件的交付过程，该模板为在云环境中建模和配置所有基础架构资源提供了标准。这些“基础结构即代码”模板为我们团队提供了一个良好的开端，因为该模板提供了发布应用程序所需整个技术栈的代码，帮助我们摆脱手动模式。在亚马逊，我们通过这种方式根据团队的要求配置了应用程序的发布流程和部署。
其次，我们利用自动化摆脱了软件交付工作流程中的手动工序。我们借助持续集成和持续部署（CI/CD）等自动发布管道，快速测试和发布大量代码，同时最大程度地减少错误。我们团队借助CI，定期将代码变动合并到中央代码库中。然后，运行自动化构建和测试，以便我们尽早发现问题。有了CD的助力后，我们团队每天都可以进行多次代码变更，而这些变更可以在没有任何人为干预的情况下直接投入生产。
最初，我们感觉在没有人为干预的情况下自动部署很可怕。但是，在我们努力编写了正确的测试和故障安全之后，我们发现自动部署不仅大大提高了我们的速度和敏捷度，而且还提高了代码质量。
运营模式：尽可能实现无服务器
现代应用程序有很多活动的部分。现代应用程序往往由数千个服务组成，而不仅仅包含一个应用程序和数据库，每个服务都有一个专用数据库，并由一个不断发布新功能的团队管理。
这些活动的部分可以分为两类：
有些活动的部分是公司的“秘密武器”，能够帮助公司在市场上占据优势，例如创造独特的用户体验和开发创新产品。有些活动通常我们称之为“无差别的繁重工作”，这些任务虽然是必需的，但不具备竞争优势。对于大多数企业而言，这种类型的任务包括服务器管理、负载平衡和应用安全补丁等。年，随着AWSLambda的推出，我们引入了“无服务器”的概念，AWSLambda是一种计算服务，在这种服务的帮助下，你无需提供或管理服务器即可运行代码。这大大促进了我们总体目标的推进——即通过将“无差别的繁重工作”转嫁给AWS来帮助客户优化“秘密武器”，这个目标成为了应用程序开发中的关键要素。拥抱无服务器，可以让你专注于那些能够让公司脱颖而出的工作，例如产品创新。
这里我们所说的“无服务器”指的是无需基础设施配置和扩展即可运行的服务，但具备内置的可用性和安全性，而且还采用了按价值付费的模式。无服务器不仅限于Lambda，它代表了整个应用程序栈。
应用程序栈通常包含三个部分：
AWSFargate等计算服务，用于运行应用程序的逻辑。数据存储区，例如MySQL和PostgreSQL关系数据库，或AmazonAurora，用于保存数据。事件总线AmazonEventBridge等集成层，用于移动数据。各个公司可以通过这些无服务器组件，利用无服务器模型的最大优势构建应用程序。
在亚马逊，我们还没能全面实现无服务器，但是我们正在朝着这个方向发展。我们的许多客户亦是如此。实际上，我们预计很快就会出现新一代从未接触过服务器、只知道编写业务逻辑的开发人员。原因很简单。无论是构建新的网络应用程序还是转移旧的应用程序，使用无服务器的技术完成计算、数据和集成都可以受益于云提供的最大敏捷度。
安全性：每个人的责任
以前，很多公司认为安全就是应用程序这个蛋糕上最后的点缀——只需在应用程序达到发布标准后加上去就好。然而，在连续的发布周期中，我们没有合适的时间点做最后的点缀，因此各个组织必须采用一种新方法来贯彻安全性，围绕整个应用程序构建防火墙。于是，难题也来了。相同的安全设置已遍布应用程序的每个部分，如果使用单独的微服务构建应用程序可能会需要不同的设置，这将是一个问题。
因此，在现代应用程序中，安全功能都嵌入了应用程序的每个组件中，并随每个发行版自动测试和部署。这意味着安全不再由安全团队全权负责。相反，它已深入集成到开发生命周期的每个阶段。工程、运营和合规团队都有不可推卸的责任。
安全性需要集成在工具中，例如代码存储库、构建管理程序和部署工具。它既适用于发布管道本身，也适用于通过该管道发布的软件。在无服务器的服务中，由于每个服务都嵌入了基础架构的安全性（例如操作系统版本更新、软件补丁和监视），因此更易于维护安全状态。
变革之旅
为了实现现代化应用程序，客户付出了怎样的努力才做出了这些改变？虽然我们没有统一的答案，但可以在这里总结共同点，包括我们在亚马逊采取的做法。
当我们决定专注于创新并扩大亚马逊网站的规模时，我们重构了整体架构的应用程序，重组了我们的组织，然后通过自动化和抽象对云进行了优化。Yelp等客户也采取了类似的方式。
对于从内部托管的应用程序开始的客户，最常见的方法是将应用程序重新托管，转移到云上。许多客户的下一步是使用云托管服务，将数据库和API管理等工作转移到AWS上，然后专心做好业务逻辑。
如今，越来越多的客户踏上了变革的道路，他们充分利用云，并以无服务器微服务的形式构建新的应用程序。转向现代化的方式没有对错之分，因为在AWS平台上，应用程序可以在所有状态下共存，并以各自的方式取得成功。
然而，我们发现了一个共同点：构建现代应用程序可以让客户的整个业务都受益，尤其是在时间和资源的分配方面。他们可以将更多时间花在定义业务的逻辑上，通过系统扩展轻松满足客户需求的峰值，提高敏捷度，并更快更频繁地向市场推出新功能。
例如，向客户提供最新车辆信息的Edmunds.