近期，亚马逊宣布消费者业务部关闭了最后的Oracle数据库，AWS首席布道师Jeff Barr在其博文中说，“我们将存储在近7500个Oracle数据库中的75PB内部数据迁移到多项AWS数据库服务，包括Amazon DynamoDB，Amazon Aurora，Amazon Relational Database Service（RDS）和Amazon Redshift。”

其实长久以来亚马逊一直在“不妥协”的让其从花费大量时间管理成本与扩展数千个陈旧的Oracle数据库的掣肘中摆脱出来。业界也多有揣测，比如亚马逊每年要支付不菲的Oracle数据库许可费用，这确是曾经的现实情况；也有二者在公有云业务方面不断增加的竞争，使二者的嫌隙不断加大。但最核心的原因是这样吗？

“亚马逊模式”是用户必听的故事

其实，这种“不妥协”更体现在亚马逊和AWS二十多年来对构建现代应用的“雄心”，而“去O”仅仅是其漫漫征途中的一部分。

在对外宣布消费者业务部关闭最后的Oracle数据库的同时，Amazon.com的首席技术官Werner Vogels撰写了一篇署名文章，总结AWS这二十多年来，如何通过变革应用程序架构、调整企业组织架构等方式，让构建现代应用的客户，“将更多时间花在定义业务逻辑上，扩展系统以轻松满足高峰期客户需求，提高敏捷性，同时更快、更频繁地向市场发布新功能”。

在文中，能清晰的看到亚马逊的技术、架构、业务和企业组织架构如何不断创新、迭代，甚至是否定自己。比如通过《分布式计算宣言》建立起变革蓝图；随着变革而将企业组织重新编排为被称做“双披萨”的小型自治团队；在构建高度可扩展基础设施方面获得的成功，从而在2006年诞生了AWS；之后，AWS对云的布道、颠覆和持续创新，得以让其云业务快速发展。

在保持市场竞争力的同时，AWS也把自身的技术创新不断融入到云上来提升企业的敏捷性，让企业借助AWS与其一起不断向现代化应用挺进。今天，鲜明的“亚马逊模式”在用户迈向AWS云端的时候，都直接或间接影响着他们。

向现代化应用的“新世界”转型

在向现代化应用转型之前，亚马逊拥有庞大的整体式应用程序和臃肿的数据库，虽然“单体应用(monolithic application)”能够给亚马逊的业务带来所需，但它限制了亚马逊需要的创新速度和灵活性。每一次新功能和产品的发布，都需要其内部充分的协调，在单体应用上编写和修改大量代码，这是一个漫长而又笨拙的过程，大大限制了快速推进的大规模创新能力。

AWS 现代化应用产品市场负责人Aaron Kao

“在2001年的时候，我们想改变构建应用的方式，将应用程序分解为多个微服务，并且打造‘双披萨’团队，拆分组织和应用程序架构，得以让亚马逊的创新与业务更加灵活迅捷”， AWS 现代化应用产品市场负责人Aaron Kao说。

“双披萨”团队是指“小到只需要两个披萨就可以喂饱整个团队”，直到今天它仍然是亚马逊的重要组织模式，每个小型自治团队为产品与功能决策负责，从发现应用、应用开发、应用部署。如今，它被称为DevOps开发应用的模式。

这样的创新选择需要胆量和勇气，但效果也很明显，亚马逊从每年部署几十个功能发展到如今的每年部署数百万项功能。比如，Amazon S3是AWS的对象存储服务，在2013年推出的时候只有8个微服务，如今S3包含235+的分布式微服务。

要成功地使用现代应用开发来提高灵活性和创新速度，“企业必须结合自身情况，在架构模型、运营模型、软件交付、安全模型以及数据管理五大方面做出改变”，Aaron Kao强调。

从亚马逊消费业务部数据库完成迁移到AWS，能够更加直观的感受到将臃肿的单一数据库被分解到专有的数据库系统的样子，如关系型数据库、图数据库、文件数据库、键值数据库、内存数据库和数据仓库等。这样的迁移不仅能够满足业务所需的数据库性能和业务需求，而且可以更好地控制预算和成本模型。

将单一应用架构逐步转向微服务的架构模型已经成为企业迈向现代化应用开发的必经之路，容器、无服务器计算、DevOps普及和快速发展无疑加快了这一过程。容器为应用程序打包提供了新的载体；DevOps为软件交付提供了标准化和自动化的流程；无服务器的运营模式也把运行代码的繁重配置和管理工作解脱了出来。

“随着代码库不断加大，添加或是改变单体应用的功能就变得更加复杂，会限制企业对新功能的实现。引入微服务架构，每个团队做一个服务，每个服务执行一个功能，它们之间互相独立运行；企业可以让不同的团队来运营、开发不同的服务，通过一些轻量级的API实现服务、团队之间的沟通。如果扩大规模，只需要对某个服务进行规模化，修改某个微服务的代码，而无需影响到其他代码”，Aaron Kao解释道。

容器是最受欢迎的代码打包选项

微服务架构可加快业务决策，提升创新速度，规模化扩展更容易，同时大大降低应用程序可用性风险。在云上，AWS为用户转向微服务架构提供了丰富的计算选项，容器服务是最受用户欢迎的代码打包选项。

比如，麦当劳通过Amazon ECS构建了云原生微服务架构，在4个月内上线了新的送货上门服务，实现了用不到100毫秒的延迟扩展到每秒两万个订单，而且能够轻松的与全球交付合作伙伴进行集成。

AWS的容器服务覆盖了从镜像、计算引擎到容器编排的三层结构。最底层是弹性的镜像注册表，Amazon ECR可以存储容器镜像文件，而且容器注册表十分易用；

中间层是计算引擎，可以使用Amazon EC2作为启动类型来运行容器，也可以使用AWS Fargate来启动无服务器的运行；

最上层是编排层，在这里AWS为用户提供了灵活的编排机制选择，如果用户不想去关注基础架构，则完全可以使用AWS的容器托管服务，Amazon ECS能够提供与Kubernetes相同的编排服务，Amazon EKS则提供对开源Kubernetes的管理服务。

Amazon ECS和Amazon EKS都是AWS遵循企业对容器，对Kubernetes发展趋势演进需求的产物，在Aaron Kao看来，二者在AWS平台上都是增长非常健康的服务，会坚持二者的同步发展。

“如果用户基于Amazon EC2实例进行应用开发，那么Amazon ECS是最自然的选择。”Aaron Kao说，“Kubernetes已经是容器编排的事实标准，在全球有超过51%的用户使用Amazon EKS。”

是什么原因吸引了众多用户将Kubernetes聚集到AWS之上？“Kubernetes是一个开源的项目，所以云平台的质量、应用的质量是相辅相成的，只有这样才能为你的客户提供好的服务”，Aaron Kao分析道。

首先，Amazon EKS是运行生产级工作负载的平台，将安全与可靠视为首要任务，能够确保客户获得最新的安全补丁；其次，AWS提供原生和上游的Kubernetes体验，与开源的Kubernetes运行完全一样。AWS与社区共同合作，会将代码贡献给社区；第三，Amazon EKS可与AWS的165种服务无缝集成。

为了进一步提升容器打包的效率，AWS Fargate为用户省去了大量的资源配置和管理工作，用户只要决定在容器上使用多少CPU和内存，Fargate负责对计算资源的弹性扩展进行管理。

Aaron Kao透露，目前Fargate还不支持Amazon EKS，但很快就会支持。Amazon EKS很快会在AWS中国（北京）区域、AWS中国（宁夏）区域推出。

随着Kubernetes越来越普及，AWS对其的创新也在不断加快，以适应企业的不同需求。比如提升Amazon EKS的友好度，与更多的AWS服务集成，EKS与AWS IAM身份访问管理集成，让每一个EKS的Pods都可以获得IAM的许可，可以让用户进行细颗粒度的身份和访问管理；对容器在软硬件层面进行“全栈式”创新，硬件Nitro系统对安全性的提升，开源微虚机Firecracker对日志的统一存储与查阅等。在Github上，AWS会全面实时的呈现其容器服务的技术路线图。

“无差别承载性”任务交给AWS

现代应用程序中包含大量活动部件，因为微服务架构的使用，使得组件数量远超出了以往单一应用和数据库的范畴，而且每项服务背后都对应着一套专用数据库和一支不断发布新功能的团队。

AWS将这些活动组件分为两类，一类负责保障业务成功，比如创造独特的用户体验和开发创新产品的组件；一类被称作“无差别承载性”活动组件，这些组件所覆盖的任务对于企业而言需要完成，但本身不能提供任何竞争优势，比如服务器管理、负载均衡和应用安全补丁应用等。

无服务器模式的则可以让企业从繁杂的“无差别承载性”活动组件运营中解放出来，从而更专注于优化保障业务成功和创新产品的组件。AWS在2014年提出了“无服务器”的概念，并推出了AWS Lambda。它是一种事件驱动的无服务器计算应用服务，能够帮助企业在无需配置或管理服务器的前提下运行代码。

企业只需要按被消耗的计算时间付费，能够自动地扩展工作负载的大小。“在Lambda方面我们会持续进行简化，持续进行开发。它支持所有的开发程序，比如流行的IDE工具包。另外它也不断增加功能集成，如集成Lambda应用负载均衡、Lambda SQS等等功能。还支持大量的合规认证，包括ISO, PCI, HIPAA, SOC, GDPR, FedRamp等等。”

作为简化用户构建和打包应用的两种不同方式，Fargate和Lambda有所不同。Fargate进一步简化了容器打包的效率；Lambda只负责打包用户的代码。通过下图，能一窥二者的区别。

目前，有数十万用户在使用AWS Lambda来构建现代化应用。Aaron Kao分享了可口可乐的案例，“可口可乐使用Lambda和STEP函数来更新自动售货机通行证应用，让工程人员能够在几天内快速构建和部署新的功能。”

写在最后：通向构建现代化应用道路没有统一的方式，但“亚马逊模式”的启示和充分利用云服务的优势，让企业能快速的构建满足应用需求的微服务架构，从而将重心放在定义业务逻辑上，来扩展系统，提高敏捷性，加速创新。