2018年8月9日，Amazon.com CTO Werner Vogels（沃纳·威格尔）来到了AWS技术峰会北京站上。笔者有机会与Werner Vogels进行了一对一对话，了解了亚马逊网站和AWS的技术思想，以及那些不为人所熟知的故事。

很多人都知道，2006年亚马逊发布了S3存储服务，并发布了Amazon Web Services（即AWS）这个品牌；但可能很多人都不知道，亚马逊早在2002年的时候，就已经发布了AWS服务，当时发布都是电商类相关的网络服务，包括搜索、产品目录和购物车等。2006年相当于重新发布了AWS品牌，但这次发布的S3已经是云服务的范畴，由此拉开了全球公有云的大时代。

而AWS的技术思想，其实是为了解决早年亚马逊网站在扩展方面遇到的技术挑战。早年的亚马逊网站是一个整体的软件包，数据库在后台运行；为了实现整个网站架构的可持续扩展，亚马逊在很早的时候就自创了类似后来的SOA面向服务的架构，而当面向服务的架构中的每一个“服务”也膨胀到巨大规模后，又再次自创了类似后来的微服务架构。可以说，整个亚马逊的技术史，就是永远比其它公司早5-10年遇到新的技术挑战，在解决扩展性问题的过程中，衍生全新的技术架构和体系，而这些新的技术架构和体系后来都应用到了AWS上。

无论对于亚马逊网站还是AWS云业务，都是由一个一个小而自治的团队负责新功能的开发、上下线及运营。对于亚马逊网站来说，快速行动比追求技术连贯性更重要，在亚马逊网站内部也允许技术上的重复或冗余。不过对于AWS业务来说，由于是针对外部用户，因此会保持对外接口的一致性。小型而自治的团队，是整个亚马逊与AWS的技术组织模式。

对于亚马逊网站来说，并没有IT团队与业务团队之分，IT人员与业务人员组成一个一个小型而自治的团队，自行根据用户的需求而做出技术和业务决策。之所以这样，是因为亚马逊认为技术人员必须深入到业务中，才能真正获得业务知识并与业务团队一起快速响应客户需求。这样一个新型的企业组织模式，正是当前的数字化转型过程中，传统企业所期望的敏捷模式。

数字化转型是关于人而非技术。随着以AWS为代表的云计算技术平台的普及，技术的差异化竞争优势正在消失，甚至亚马逊的竞争对手也可以在AWS的平台上，展开与亚马逊的竞争。因此，更为关键的是，如何为客户真正创造独特的能力与价值？

且看Werner Vogels的精彩观点。

问：首先，我想知道为什么你这两年来经常来中国，特别是今年。

Werner Vogels：中国是一个重要的市场，我们在中国推出了第二个区域，这对许多客户来说非常重要。而且我很喜欢去客户所在的地方，我也很喜欢这里，我们的客户在这里，他们是否面临特殊的挑战，这都就是我们要为他们解决的问题。

许多客户都是全球性运营，不仅仅是在中国地区，也在中国以外的地区运营。我们可以帮助这些客户解决支付、合同等问题，也可以帮助解决客户的任何问题。我们通过客户的反馈，来寻找能够帮助到客户的机会。

问：谈到全球运营，您如何看待云计算与数据中心外包之间的关系？

Werner Vogels：需要在两个层面看数据中心外包：一个是许多企业正在使用的传统方式，为客户提供计算能力，为使用的虚拟私有服务器时间而支付费用；另一个层面是为管理服务。我认为计算资源外包与AWS非常相关，很多外包服务的客户向AWS迁移，这是可以互相转换的。而对于管理服务而言，却是完全不同的事情，现在这些客户也正在转向AWS，在AWS那里有更实惠的价格。

在美国有一个很好的例子，这就是RackSpace。RackSpace曾经基本上为客户提供数据中心外包服务，也提供了一定程度的管理服务（managed service）。现在RackSpace是在AWS上运行的好伙伴，他们还有一些外包数据中心，更多的则运行在AWS上。RackSpace业务中，有很重要的一部分是为客户提供管理服务，包括CRM和ERP等。除了RackSpace之外，还有其它的外包数据中心合作伙伴，也在AWS之上建立了管理服务业务。

问：您认为现在客户更需要数据中心外包，还是在AWS之上的托管云服务？

Werner Vogels：这取决于客户本身的成熟程度和技术运营的成熟度。有许多企业将所有IT都外包出去后，很难将这些业务带回企业内部，因为他们已经没有相应的专业知识了，因此他们需要基于AWS的管理服务供应商。如果企业内部具有这些专业的技术知识，那么他们就可以轻松地在AWS之上管理应用程序，而无需管理服务合作伙伴。

数据中心外包与云计算有很大不同。传统的数据中心外包需要非常长期的合同、受限制的环境、没有计算弹性，无论客户是否使用都需要为合同付费，而且虚拟机可能是唯一可行的业务。

问：怎么看SOA面向服务的架构？亚马逊2010年财报中曾提及，SOA是AWS的架构基础。

Werner Vogels：我们在SOA被发明之前就已经开始使用“服务”的方式了，甚至在AWS之前就已经开始了。

对于亚马逊的零售业务，我们在1990年代编写了当时的应用程序，那时的亚马逊软件架构无法进一步扩展。当时的亚马逊网站就是一个巨大无比的应用，数据库运行在后台，而这样架构确实无法再扩展了，必须找到一种新的可扩展的方式，这就是现在称之为“服务”的方法。我们大约在2000年左右发明了这样一种软件编写的方式，赋予一小段代码以逻辑、数据和API接口，必须通过API获取数据、与代码交互，这样就可以将整个电子商务应用切割成更小的构建模块，每个构建模块都可以成为“服务”。

我们在“服务”方面获得了很多经验。随着时间的推移，亚马逊开始添加基础设施服务，包括如何管理计算、如何管理数据库、如何管理存储，这其中的大部分也能成为服务。为什么？因为希望让业务逻辑来负责和管理计算的扩展，而不是由人工来管理。我们把这样的技术和技术思想也应用到了AWS，从头开始构建AWS，这样可以满足最高的安全要求。

对于AWS来说，亚马逊网站也是一个客户，但它对安全的要求则与其他客户完全不同。我们希望确保以最佳方式保护我们的客户，所以我们从头开始构建了AWS的所有软件，但是以“服务”的方式，因为这样可以达到最高水平的竞争力。任何人都可以通过使用这些服务来访问我们的软件或功能。我相信无论在亚马逊内部或AWS，这种软件服务的方式都取得了巨大的成功，在亚马逊内部现有1000多种不同的服务，AWS则提供了125种不同的服务。

在另一方面，我不认为SOA是一种技术，它更像是一种架构原则。当我们在最开始构建了这些服务后，就进入了另一个阶段，因为我们后来发现这些服务变化得非常快、也变得越来越庞大，需要将它们进一步分解成更小的构建模块，现在称之为微服务。如果在那时有类似ECS或Kubernetes这样的容器技术，我们肯定会用，但这些技术在那时还不存在。在亚马逊的身上会持续出现这样的现象，我们遇到挑战可能要比其它公司早5-10年，这是因为整个亚马逊的规模所致。因此，一旦我们构建了AWS，就可以为客户提供别人以前从未构建过的技术。

问：怎么看微服务？AWS与微服务的关系是什么？

Werner Vogels：微服务是一种独立组件，可以进行独立扩展的技术。例如，登录组件是所有页面都要用到独立组件，而地址簿组件只有在支付页面才用到，因此这两个服务有着不同的扩展要求。如果它们都位于同一软件包中，则地址簿服务必须与登录服务进行相同级别的扩展。而通过分解它们，可以允许登录服务随着特定需求而变大或变小，而地址簿服务则可以独立于登录服务而扩展。

这就是我所说的微服务方法，但这与AWS的方式无关。例如AWS提供DynamoDB，你无需关心它到底是如何扩展的。SNS或SQS等服务，用户都不必考虑具体是如何实现的，而只要知道它们可用、可靠、安全、跨多个可用区、性能可预期，就够了。AWS不是微服务，因为客户在使用AWS服务，而微服务是用于开发的。

问：AWS服务最初是在2002年开始的，对吧？在2006年重新发布了AWS。

Werner Vogels：略有不同。在2002年的时候，我们开发了很多流行的零售服务，包括为了帮助商家开设电商门店，就需要产品目录和搜索服务、购物车服务等。当时开发的服务，多是电商相关的服务，主要是与亚马逊电商基础设施对接。这些都纳入了后来的亚马逊合作伙伴计划。当我们在2006年发布S3的时候，觉得还是要延用AWS这个名字。

问：最近听说亚马逊决定在2020年将Oracle从其核心业务中完全去除？

Werner Vogels：我们的很多客户都喜欢在AWS之上使用Oracle，我们可以为客户运行Oracle，这绝对没问题。我无法评论有各种各样关于Oracle的传言，但这个故事可以分享：2004年的时候，我们（亚马逊网站）在一年中最繁忙的一天，发生了重大的扩展事故，这要追溯到Oracle数据库，这个事故让整个电子商务服务宕机了一整天。这时我们开始意识到我们正在以非常不同的规模使用数据库技术，所以我们决定要深入研究是否可以解决这个问题。

我们深入了解了我们是如何使用这些数据库，结果发现70％的操作与关系型数据库无关，都是Key-value查询。例如购物卡，没有人关心购物卡内的内容，也不需要搜索这些内容，而是只需要识别卡，并把这张购物卡交给客户就可以了。从来没有一个诸如“给我所有的含有Harry Portter的购物卡”的查询，这种情况从未发生过。因此我们70％的数据库操作与关系型数据库无关，我们意识到可以自己构建数据库技术，有针对性解决特定问题。

这是DynamoDB的起源，之前被称为Dynamo，是为永续业务而构建的，完全专注于构建可靠的可跨多数据中心的Key-Value数据库。由此，我们缓慢但坚定地逐渐消除了对关系型数据库的依赖，主要是因为我们认为每个特定的现代应用都需要不同类型的数据库存储，包括Key-Value、文档、图或关系。对于我们的许多客户来说，会利用所有这些数据库技术，这就是AWS提供这么多种数据库的原因。而且，我们的许多客户也开始要求或需要比高端关系数据库更好的数据库，而且是云原生的数据库。

为此我们构建了一个真正的云原生数据库Amazon Aurora。要知道，大多数商业关系型数据库都是20世纪90年代的技术，这些关系型数据库的核心架构方面后来并没有更多的发展。另一方面，Aurora是一个完全云原生的数据库，真正利用多个数据中心的所有功能，用户不再需要担心扩缩容问题，Aurora是一个真正的云原生数据库。我们相信，考虑到Aurora的优势，亚马逊最终肯定会继续使用Aurora，并看它能带我们到哪里吧。

问：亚马逊和AWS是如何管理技术团队的？

Werner Vogels：我并不管理任何团队，我不是亚马逊的工程VP（VP of Engineering）。可以分享的是，不论是亚马逊还是AWS，我都不直接负责技术决策，我可以参与评估。技术团队是自治的，他们可以自己做出技术决策，而不需要我的管理。比如DynamoDB可以自己做出技术路线规划，因为他们离用户最近，从用户那直接获得反馈。95％的AWS功能和服务都是客户直接要求的，这比什么都重要。

问：如何确保技术架构的一致性？

Werner Vogels：看一下亚马逊的零售业务，快速行动要比架构连贯性更重要。每个团队都可以采用自己的技术，从而为用户提供最好的服务。这不应该是自上而下的管理，我们不会要求团队采用Java，而是由团队自行决定；如果他们觉得Ruby是更好的选择，那么就可以使用Ruby而不用要求获得批准。

当然，我们希望确保我们的工程师能够获得正确工具以完成任务。但是每一个团队都是自治的，他们可以自己做决定。对于整个亚马逊网站来说，如果一个地方需要用到某种技术，可能在另一个地方也会用到类似的技术，我们允许重复或冗余。因为我们更相信自治和快速行动，而不是自上而下、让团队窒息的控制。

AWS是另一回事。AWS面向的客户与亚马逊电商不同，因此AWS是要求技术架构的一致性，我们希望为AWS客户提供一致的接口，对于API的开发也是这样。除此之外，到底是如何实现这些服务的，这取决于团队自身。

问：对于亚马逊来说，IT团队是自治的小型团队？

Werner Vogels：请记住亚马逊是一家技术公司，它不是零售商，因此亚马逊没有IT部门。IT部门所做的工作涉及电子邮件和其他一些服务，但电子商务领域的运营已深深融入到亚马逊业务中。比如推荐鞋子的技术团队与鞋子业务部门一起工作，技术要与业务团队深深融合。为什么？因为鞋子的推荐引擎与书籍的推荐引擎相比，非常不同。在鞋子推荐中，希望最大限度地减少退货次数，并且希望确保人们的选择与实际需求的尺寸或颜色完全匹配。推荐鞋子是一种非常不同的方法，特别是因为鞋子的尺寸很难选择，如果选择9.5号，也可以试试9号，因为这两个尺寸的鞋子可能都适合。无论如何，亚马逊没有IT部门、没有开发部门，技术团队与实际的鞋子销售员关系密切，因为他们需要非常具体的关于鞋子的业务知识。

问：现在有很多传统公司希望引进亚马逊的方法，他们希望将IT嵌入到业务中，只是不知道怎么做。

Werner Vogels：我们的客户正经历数字化转型的挑战，而数字化转型是关于人而非技术。正如你所提到的，如果外包所有的IT，是不能突然把IT带回到公司内部，因为已经没有相应的专业知识了。或者如果曾经雇用的人都非常保守，只想运行SAP ERP系统，而不想成为一个风险承担者，也不能责怪他们不能在第二天就突然变得非常迅速，应该为数字化转型聘请不同的人。所以我认为许多公司进行数字化转型所面临的最大挑战是人员管理，如何让合适的团队做正确的事情。例如AWS认证培训总是满员，我们已经无法更快速的培训了，而是需要与许多培训公司一起工作，培养更多的培训师，才能培训更多的AWS人员。

我们听到的许多客户都是人员的问题，远超过技术问题。如果使用云，就能更快的行动，但如何做到这一点？如何找到人去落实？我们的许多客户发现这很有挑战性，AWS专业服务开发了一个完整的场景手册，围绕着我们所看到的那些成功公司的实践，比如改变组织结构等。我们试图尽力帮助我们的客户，但这些公司应该雇用合适的人，找到新的组织结构，以便能够快速行动。

问：听说在一开始的时候，亚马逊在一栋楼，AWS在相邻的另一栋楼，方便AWS说服亚马逊使用AWS。

Werner Vogels：这我不知道，他们总是在一栋楼里工作，那些时候还有点混乱。早期的时候，我们研究不同的技术，EC2是一支在南非的AWS团队所开发的，S3是在西雅图开发的。我记得早期设计S3的时候，并未想到它会变成多大，但我们添加了两个零以确保安全。我们在前三个月绘制了蓝图，并且我们很幸运地采用了非常好的软件开发方法。我们知道软件必须随着时间而发展，基本上每上一个新规模的时候，可能就不得不重新架构。我们非常幸运能够提前做出非常好的决定，以确保能够构建我们的系统，并能够随着时间的推移不断发展这个系统，而不让客户受到影响。

问：你能告诉我任何关于AWS早期如何说服亚马逊团队的故事吗？

Werner Vogels：服务需要有选择性，不需要“你应该在AWS上运行”这样自上而下的命令，没有必要。如果技术足够好，能够以更轻松的方式完成工作，那么自然会用它。亚马逊的大部分已经迁移到AWS，为什么？因为它让工程师的生活变得很简单。亚马逊是非常苛刻的客户，实际上亚马逊可能不是最大的客户，但亚马逊对于AWS来说并没有特殊性，任何人从AWS上都能获得同样的技术服务，甚至可以在AWS平台上与亚马逊竞争。

问：经过这些年，能否总结一下AWS成功的秘诀？

Werner Vogels：以客户为中心。当我们启动AWS时，我认为IT的一次重大革命已经发生了，但却采用了一种截然不同的经济模式。在过去，降低成本的唯一方法是与IT提供商签订长期合同。但作为客户，其实从来没有掌握IT，总是技术供应商在负责。当我们开始构建AWS时，不仅希望建立真正伟大的新型可扩展技术，以帮助公司实现互联网规模，还希望成为地球上最以客户为中心的IT提供商。这意味着我们需要从根本上重写经济模式，只需为所使用服务而付费，而无需提前付费。这非常关键，从根本上改写整个IT行业。当我们建立AWS时，我们真的想要一个非常不同的经济模式，实现真正的以客户为中心。

问：说到客户，AWS怎么看大企业？

Werner Vogels：以美国新闻集团为例，这是全球性的大型公司，他们建立了64个数据中心，然后关闭了60个数据中心，将所有转移到AWS；通用电气的60个数据中心转移到AWS。即使是曾经的初创公司，Airbnb使用AWS的规模要比大多数大企业还要多，Uber或Twitter等都在云环境中成长，云对他们来说非常重要。

Slack这样的新互联网规模企业，都是100％在AWS上运行，而它们如果没有AWS的话，甚至无法启动。世界上最大的企业正在使用AWS，包括中国的小米，以及一些年轻的企业如猎豹移动、musical.ly等，所有这些年轻企业以及这些初创企业，我们称之为互联网规模公司，他们就在互联网上成长，他们的用云量远超传统企业。

如果你回到15年前会发现有一篇很好的文章，叫做“IT并不重要”，该文的大意是IT将不再是企业差异化竞争力所在。真正让公司与众不同的，是公司为客户构建独特的能力。因此最好的工程师应该去做与众不同的事情，而不是做每个人都必须做的事情。

版权声明：

凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。