ACM通信

实践

与沃纳·沃格斯的第二次对话

CACM人员
ACM通讯，2021年3月，第64卷第3期，50-57页
10.1145 / 3434232
评论

当我1998年加入亚马逊时，该公司在美国只有一个网站，只卖书，在5个服务器上运行一个C语言应用程序，一些用于键/值数据的Berkeley db和一个关系数据库。那个数据库被称为“ACB”，代表的是“Amazon.Com Books”，这个名字不能反映我们的雄心范围。在2006年,acmqueue发表了吉姆•格雷(Jim Gray)与亚马逊首席技术官沃纳•沃格尔(Werner Vogels)之间的一段对话，沃格尔在对话中解释称，亚马逊不应仅仅被视为一家在线书店，而应被视为一家科技公司。在这14年里，亚马逊的分布式系统以及用于构建和运营它们的模式的影响力不断增长。在接下来的对话中，Vogel和我特别关注了从单一分布式系统——简单存储服务(S3)——的演变中吸取的教训——它是在2006年那次对话的时候公开推出的。
汤姆Killalea

汤姆KILLALEA:在您2019年12月AWS re:Invent大会上的主题演讲中，您说在2006年3月S3发布时，它是由8个服务组成的，到2019年，它达到了262个服务。当我坐在那里的时候，我想这是一个惊人的数字，而让我震惊的是，很少有人写过一个大规模的、始终在线的服务是如何在很长一段时间内发展的。对于我们的软件从业者社区来说，这将是一个非常有趣的旅程。这是一种前所未见的进化，当然也没有被广泛讨论过。

WERNER VOGELS:我完全同意这是无与伦比的规模。即使在今天，即使现在的互联网服务已经达到了不可思议的规模——我的意思是，例如，看看Zoom(这次采访是在Zoom上进行的)——我认为S3仍然比它领先两到三代。,为什么?因为我们开始得更早;这只是一个时间问题，与此同时，与你的客户有一个严格的反馈循环，不断发展服务。相信我，当我们设计它的时候，当我们建造它的时候，我认为没有人能预料到它的复杂性。我认为我们确实意识到，6个月或1年之后，我们将不会运行相同的架构。

所以，我认为前面的一个原则是不要把自己锁在你的建筑里，因为两到三个数量级的规模，你将不得不重新思考它。我们早期在努力思考什么是可进化的架构时所做的一些事情是革命性的——将来我们可以在此基础上为s3添加功能。我们以前从未这样做过。

即使是亚马逊零售商，我们也有我们想要提供的独特功能，但我们总是非常确定我们想要去哪里。对于S3，以前没有人这样做过，还记得我们在房间里设计它的时候，(AWS杰出工程师)AI Vermeulen在黑板上写了一个数字:我们将在6个月内存储的对象数量。

KILLALEA:我记得这次谈话。

VOGELS:为了安全起见，我们在后面加了两个0。头两个月我们挺过来了。

S3的一些特性是独一无二的。我们在新闻稿中提出了10条分布式系统原则。(见侧边栏，“分布式系统设计原理”)

这是非常独特的，建立一个从根本上健全的服务，这样你就可以在它的基础上发展。我觉得我们自己都有点惊讶。

这八个服务实际上只是获取、放置和管理传入流量的基本部分。最重要的是，S3有很多不同的原则，但是持久性当然比一切都重要。我们通过在三个可用分区上复制向客户承诺的11个9(99.9999999%)是唯一的。我们的大多数客户，如果他们有现成的系统——如果他们幸运的话——可以在同一个数据中心存储两个对象，这就给了他们四个9。如果他们真的很优秀，他们可能有两个数据中心，实际上知道如何在两个数据中心上复制，这给了他们五个9。但就耐用性而言，11 9是无与伦比的。它胜过一切。对于持久性的需求也意味着，例如，8个微服务中的一个将会持续地检查所有对象，所有的crc(循环冗余检查)，现在已经有数万亿的对象了。有一个工作人员不停地在周围检查，以防某个物体有一点腐烂或类似的情况。

我们早期学到的最重要的一件事是——我用过这句话——“一切都失败了，总是如此。”真的，每件事都失败了，总是以意想不到的方式，我从来不知道的方式。位在内存中翻转，是的。你需要保护带有CRC或校验和的个人数据结构，因为你不能再信任其中的数据了。TCP(传输控制协议)被认为是可靠的，而且在比特中没有任何翻转，但事实并非如此。

KILLALEA:以分布式系统原则启动是独特的。14年后，这些信条会有所不同吗?有这样的期望，信条应该是常青的;会有实质性的变化吗?

VOGELS:不是这些;这些是我们在分布式系统中使用的真正基本的概念。这十条原则与S3是分开的，说明这是您想要大规模构建分布式系统的方式。我们刚刚演示了S3是应用这些技能的一个很好的例子。

与此同时，其他一些科技公司也在扩大规模，比如搜索引擎等，通常只有一个任务，比如把搜索做得很好。以零售商亚马逊(Amazon)为例，我们必须做所有的事情:机器人、机器学习、大容量交易处理、坚如磐石的网页交付，你能想到的都有。在亚马逊网站上，计算机科学教科书里的每一项技术都被推向了风口。我们以无与伦比的规模运营，拥有真正伟大的工程师——但他们是务实的工程师——我们在构建S3之前做了一些改变，以回归基本原理，确保我们构建的东西从根本上是健全的，因为我们不知道一年后它会是什么样子。为此，我们需要有一个真正坚实的基础。

KILLALEA:S3成功的关键之一是，在发布之初，它尽可能的简单，提供的仅仅是GetObject和PutObject。在当时，这是相当有争议的，因为这似乎是太简单了。事后看来，您是如何反思这个争议的?从那时起S3是如何发展的?你提到的可发展的体系结构．

VOGELS:List是另一个与Get和Put一起使用的，前缀是List。

KILLALEA:正确的。发行时还能再简单点吗?

VOGELS:它有一点争议，因为当时大多数科技公司都在提供所有的东西，它会附带一本非常厚的书和10个不同的合作伙伴，告诉你如何使用这项技术。我们走上了一条杰夫(贝佐斯)多年前描述的道路工具而不是平台．平台是大型软件平台公司用于服务其技术的老式方式。

如果你想从Win32转到。net，很明显，供应商会告诉你具体的操作方法，而且它会附带所有的东西——不是小的构建模块，而是“你应该这样构建软件”。

在我们开始S3之前不久，我们开始意识到我们正在做的事情可能会从根本上改变软件的构建和服务的使用方式。但我们不知道这将如何演变，所以更重要的是创造小型、灵活的工具，让客户(或者我们自己)可以在其基础上进行开发，而不是在特定的时刻把所有东西都准备好。这并不一定是时间问题;更重要的是，我们确信，无论我们向S3的接口、S3的功能添加什么，都应该由我们的客户驱动——以及下一代客户将如何开始构建他们的系统。

如果你把所有的东西都建在一个大平台上，你就需要使用5年前的技术，因为这就是设计、建造和提供给客户所需的时间。我们希望发展得更快，并与客户建立一个非常快速的反馈周期，客户会问:“2025年你们将如何开发?”

在过去的五到十年里，发展发生了根本的变化。我们需要构建正确的工具来支持在构建软件的方式上急剧变化的速度。有了这些，你就无法预测;你必须和你的客户一起工作，看看他们是如何使用你的工具的——特别是如果这些工具是以前从未建立过的——看看他们能做什么。所以，我们坐下来问，“最小值是多少?”

还有一件事我想指出。亚马逊零售商和AWS在技术上的最大区别之一是，在零售领域，你可以尝试各种各样的东西，如果客户不喜欢，你可以关闭它。在AWS中，你不能这样做。客户会在你的基础上建立他们的业务，你不能因为你不再喜欢某样东西或认为其他东西更好就把它拔掉。

你必须有意识地小心API设计。api是永远。一旦你把API放在那里，也许你可以对它进行版本化，但一旦你这样构建了它，你就不能把它从你的客户那里夺走。在API设计中保持保守和简约可以帮助您构建基本的工具，您可以在这些工具上添加更多的功能，或者合作伙伴可以在其上构建层，或者您可以开始将不同的构建块组合在一起。这就是我们一开始的想法:做到极简主义，这样我们就可以让我们的客户来推动接下来发生的事情，而不是我们坐在后面的房间里思考，“这就是世界应该是什么样子的。”

KILLALEA:定义MVP(最小可行产品)的简约理念现在已经得到了广泛的采用，但S3在发布时将其推向了极致。在早期，有一些关于AWS团队应该首先将哪种持久性服务推向市场的讨论:对象存储、键值存储还是块存储。有一种感觉，最终每个人都会出现，但在一个小团队中有必要的顺序。首先启动S3是有意为之的，例如在2008年8月启动EBS (Elastic Block Store)。你能告诉我们原因吗?

VOGELS:我们从自己构建系统的过程中学到了很多东西，其中键值存储是最关键的。在2004年12月与我们的一个数据库供应商发生“意外”之后，我们决定深入研究一下我们是如何使用存储的，结果发现我们使用的存储中有70%是键值。这些值有的很大，有的很小。其中一个是向Dynamo发展的，小键，表接口，类似的东西，另一个是S3, S3更像一个blob，更大的值存储，有一些不同的属性。

早期S3的一个大赢家是对对象的直接HTTP访问。这对所有人来说都是一个巨大的胜利，因为突然之间，在每个网页，应用，或其他地方，你都可以通过使用HTTP来拉入你的对象。这是前所未闻的。也许一开始我们认为某些东西会更受欢迎，但结果却并非如此——例如，BitTorrent界面。它被使用了吗?是的，它确实被使用了。但是它被大量使用了吗?不。但我们推出了FTP访问，这是人们真正想要的东西。

所以，有时候看起来不是很性感的东西，但这确实是我们的客户习惯使用的。同样，你构建了一个极简的界面，你可以以一种健壮和可靠的方式来构建它，如果你从第一天就开始添加复杂性，这种方式将会困难得多，即使你知道你添加的是客户想要的东西。

有些事情我们在第一天还不知道，但是一个更好的例子是当我们启动DynamoDB时，我们采用了类似的最小化方法。我们在推出的当天就知道，客户已经想要二级指数，但我们决定不推出二级指数。结果是，客户回来后说他们想要IAM(身份和访问管理)——对数据库中单个字段的访问控制——比他们想要的二级索引多得多。我们的方法允许我们重新定位路线图，并找出对我们的客户最重要的事情。在DynamoDB的情况下，结果与我们所想的非常不同。

KILLALEA:我认为这次谈话的大部分内容都是关于可进化性的。当我在re:Invent听你演讲时，我的思想转向了加尔定律:“一个能工作的复杂系统总是由一个能工作的简单系统进化而来的。”一个从零开始设计的复杂系统永远不会工作，也不能通过修补来让它工作。你必须从一个简单的系统开始。”您认为这对S3的发展有何影响?

VOGELS:这就是S3背后的基本思想。我们能建立一个复杂的系统吗?可能。但是如果你建立了一个复杂的系统，那就很难发展和改变，因为你要在一个复杂的系统中做很多长期的决定。如果您在非常简单的界面上做出长期决策，这不会造成太大影响，因为您可以在它们的基础上进行构建。复杂的系统更难进化。

让我给你举个例子。S3添加的服务之一是审计功能—审计对象是否仍然是新鲜的、活跃的、没有被触摸的，或者其他什么。这是我们做审计的第一个版本。然后我们开始开发CloudTrail(2013年11月发布)，它必须集成到S3中。如果您构建了一个包含所有这些内容的复杂系统，或者可能包含5个内容，那么这种集成将是一场噩梦，而且它肯定不会导致您能够适应随着时间的推移而不断发展的设计。

Mai-Lan Tomsen Bukovec (AWS存储副总裁)谈到了持久的文化。例如，在S3中，持久性胜过一切，甚至胜过可用性。想象一下如果服务宕机:您不能丢失对象。你的数据不会消失;也许你需要5分钟才能再次访问它，但你的对象应该一直在那里。Mai-Lan的团队有一种持久的文化，这意味着他们使用诸如TLA+这样的工具来评估他们的代码，看看它的算法是否在做它们应该做的事情。

现在，简单地说，你有一个2000行的算法。你可以用正式的验证工具来评估;5万行，忘了它吧。简单的构建模块让你拥有一种专注于你想做的事情的文化，无论是围绕审计，还是围绕使用TLA+或持久性审查等。我们在S3中所做的所有更改都要经过持久性审查，以确保这些算法实际上不会做任何超出我们希望它们做的事情。

KILLALEA:通过全面的正式验证?

VOGELS:下面是S3上下文中的一个很好的例子。如果您查看libssl，就会发现它的代码行数多得可笑，其中大约有70,000行代码涉及TLS处理。如果您想创建漏洞，请编写数十万行代码。这是我们系统中最易受攻击的接入点之一。

KILLALEA:我知道S2N即将推出一个插件。

VOGELS:是的，所以我们写了S2N，也就是信噪比，一共5000行。通过对这5000行代码的正式验证，可以确切地知道它的功能。现在S3上的所有东西都在S2N上运行，因为我们对这个库更有信心了——不仅因为我们自己构建了它，还因为我们使用了所有这些额外的技术来确保我们可以保护我们的客户。我们的每一次传输都有端到端加密。在如何使用加密存储时，您希望我们创建密钥吗?你想把钥匙带来给我们吗?您是否需要将密钥放入KMS(密钥管理服务)中?或者您想完全管理您的密钥?我很确定我们一开始只有一个，然后顾客们开始说，“但是那个，那个，那个。”你也需要这些。

如果您将其构建为具有小型微服务的可进化架构，您仍然可以允许加密只完成它的工作，然后您可以考虑如何开始添加其他服务来完成其他事情——比如从S3到Glacier的生命周期管理。如果该对象在30天内没有被触摸，将其移动到减容实例存储;如果两个月都没有人碰过它，就自动把它移到冰川。

KILLALEA:您在2010年2月发布了S3对象版本。这如何适应服务的不断发展的期望，客户希望如何使用它，以及所提出的体系结构需求?

VOGELS:这主要是与我们的客户基础反复讨论什么才是最好的界面，真正倾听人们的需求。老实说，与分布式锁管理器相比，不可变性是一个更大的需求，而分布式锁管理器是出了名的难以构建和操作。它需要在不同的合作伙伴之间进行大量的协调，并且失败模式并不总是被很好地理解。

因此，我们决定采用一种更简单的解决方案:对象版本控制，正式名称为S3对象锁。可以对锁定对象做两件事。首先，一旦创建了它，就只能更改它，这在区块链之类的世界中是一个非常有趣的概念。你还可以在它上面设置两个属性:一个是保留期(例如，30天之内不能删除);另一个是LegalHold，它是独立于保留期的，基本上说这个对象不能被删除，直到授权用户明确地对它采取行动。

事实证明，对象版本控制在法规需求的上下文中是极其重要的。您可能需要能够告诉您的医院或监管检查人员，该对象将在未来6个月的实时存储中保存，然后将其移到冷库中，在之后的30年里保存。但是能够向监管机构证明你使用的技术在30年内仍然有效是一个相当大的挑战，因此我们已经在那里建立了所有这些额外的能力。

KILLALEA:传统显式锁定的缺失已经将责任转移给了开发人员，他们需要在代码中解决这个问题，或者使用版本控制。这是一个非常有意的决定。

VOGELS:分布式锁管理器是我们在20世纪80年代和90年代以及21世纪初自动使用的技术之一，它是数据库和类似的东西附带的。您可能一直在使用关系数据库，因为这是您拥有的唯一工具，它与事务一起提供，所以您使用事务，无论您是否需要它们。我们想从不同的角度考虑对象存储，考虑它的需求;事实证明，我们的方法给客户提供了正确的工具来做他们想做的事情，除非他们真的想要锁和解锁，但这不是一件容易扩展的事情，我们的客户很难理解。我们采取了不同的方式，我没有听到很多客户的抱怨。

KILLALEA:S3是在4年前推出的数据湖在2010年末詹姆斯·迪克森的一篇博客文章中首次使用。⁵目前，许多企业数据湖都在使用S3。如果他们知道会发生什么，那么2006 S3团队尝试预测这些数据湖的需求是有益还是分散他们的注意力呢?

VOGELS:一般来说，我们在AWS的早期做了很多事情——与s3无关——但也有一些遗憾。例如，我再也不会，再也不会同时把账户和身份结合在一起了。这是我们在早期所做的;我们并没有考虑到这个系统会如何发展。我们花了很长时间才把这些账户删除掉。account是你开账单的地方;身份是在构建系统时使用的东西。这是两种完全不同的东西，但我们在早期并没有将它们分开;我们只有一个概念。那是一个显而易见的选择，但却是错误的选择。

下面是关于S3的另一个有趣的例子。这可能是我们唯一一次改变定价策略。当我们推出S3时，我们只对数据传输和数据存储收费。事实证明，我们有相当一部分客户储存了他们在eBay上销售的数百万产品的缩略图。没有太多的存储空间，因为这些缩略图真的很小，而且也没有太多的数据传输，但有大量的请求。它让我们了解到，例如，当你设计界面，以及那些你要收费的界面时，你想要收费的是你自己的成本。我们没有预料到的成本之一是请求的数量和请求处理。我们后来将其添加到S3中的支付模型中，但这显然是我们没有预料到的。S3之后的服务已经能够从S3本身吸取教训。

回到数据湖的概念，除了这两件事，我不会做其他任何事情，主要是因为我认为我们已经创建了基本的构建块，因为S3服务的远不止数据湖。就数据湖的概念而言，有一些有趣的部分，我认为S3在这些部分下工作得很好，但是您需要更多的组件来构建一个数据湖。例如，在构建数据湖方面，Glue是一个同样重要的服务，它位于S3旁边，发现您的所有数据，管理您的数据，让您决定谁可以访问哪些数据，以及是否需要从本地数据库中提取数据，或者是否需要从关系数据库中提取数据，以及所有这类事情。

事实证明，如果你真的想建立一个成熟的数据湖，你需要大量的组件。它不仅仅是在S3中存储东西。这就是我们建造湖组的原因。你在AWS和我们的合作伙伴看到的一件事是，现在我们有了这个庞大的工具箱——175种不同的服务——它们一直被当作小的构建模块。这使得它们有时很难使用，因为它们不是真正的解决方案，它们是基本的构建模块。所以，要建立一个数据湖，你需要把所有这些东西放在一起。你现在看到的是，人们正在构建解决方案，给你一个数据湖。

我们必须记住，S3的用途远不止于此，它可能是包含大量视频和音频文件的内容湖，也可能是存储小文件的数据湖，也可能是用于进行基因组学计算的数据湖。我们的一个客户正在测序一亿人类基因组。一个人类基因组是100gb;这只是原始数据，没有其他的东西，所以要发生很多事情。在生命科学领域，文件越来越大。如果我回顾过去，或者看看那些开始收集数据的客户，无论是结构化的还是非结构化的数据，他们中有相当多的人开始弄清楚如何将机器学习应用到他们的数据中。他们还没有真正做到这一点，但他们可能希望将数据存储在那里，并开始使用红移或EMR或kineesis或其他一些工具来做更传统的分析方法。然后他们可能会在一年后做好准备，那时他们已经训练好了工程师，准备将机器学习应用到这些数据集上。

这些数据集变得如此之大——我在这里谈论的是pb字节或数百pb字节的单个数据文件——需求随着时间的推移而变化。当我们设计S3时，它的一个强大的概念是分离计算和存储。你可以存储所有的东西，但是你的计算不需要使用它来扩展，并且在计算方面可以非常灵活。如果存储更多，就不需要更多EC2(弹性计算云)实例。

随着数据集变得越来越大，通过让计算更接近数据进行相对简单的操作，看看S3内部能做什么就变得更有趣了。例如，我们看到客户从他们的S3存储中检索几十甚至几百pb的数据，然后对其进行筛选，可能在他们的分析中使用5%的数据。这是一个很重要的概念，因此我们构建了S3 Select，它基本上在最低级别为您进行筛选，然后只移动您真正想操作的数据。

同样，在我们的环境中发生的其他事情也允许我们扩展S3。在Lambda和无服务器组件中，我们所做的第一件事是在文件到达S3时启动Lambda函数。不需要运行EC2实例，就可以使用自己的功能和功能执行事件驱动触发和扩展S3，这使得它更加强大，因为在那里运行的不仅仅是我们的代码，而是您的代码。这里有一系列的例子，我们在S3的掩护下为你运行一些计算，如果你需要的话。

KILLALEA:就我们的读者可以从这段旅程中学到的经验而言，可扩展性的概念真的是非常关键的。我知道，在S3的案例中，有一些例子是从最基本的内容开始，并从一些非常早期和苛刻的采采者的要求中学习，比如SmugMug的Don MacAskill和当时在Netflix工作的Adrian Cockcroft。有没有其他的例子，客户的要求让你睁开眼睛说:“这很有趣;我没有预料到这一点。”然后这就成为了旅程的关键部分?

VOGELS:还有其他关于大规模大规模数据访问的例子。为了从S3中获得所需的性能，一些客户意识到他们必须对名称进行一些随机化。他们会对数据进行预分区，以获得他们想要的性能，特别是对于非常大容量的访问人员。

我们对S3中分区的发生方式进行了重大修改，现在已经过去三年了，不再需要这个过程了。如果客户自己不进行预分区，我们现在就有机会通过可观察性为他们进行分区。我们观察正在发生的事情，可能会很快地进行重构或重新划分，以便为我们的客户提供正确的性能，而这些客户在过去必须自己弄清楚。

对于我们最早的客户，我们着眼于特定的行为并意识到我们必须为他们解决这个问题。事实上，像Don (MacAskill)这样的人一直非常直言不讳，但也是非常聪明的技术专家。这些开发者清楚地知道他们想要为自己的业务创造什么，我认为我们会因为他们的反馈而茁壮成长。

例如，今天可能是远程医疗，它需要符合HIPAA(健康保险便携和责任法案)和其他监管要求;它需要确定数据是如何存储的等等。我们已经开始在此基础上进行构建，以便我们可以轻松地使用微服务架构来测试审计师是否满足HIPAA或PCI DSS(支付卡行业数据安全标准)或其他实时合规规范。

---

我们想从不同的角度考虑对象存储，考虑它的需求;事实证明，我们的方法为客户提供了正确的工具来做他们想做的事情。

---

例如，Amazon Macie就是这些服务之一。S3中的功能可以检查您的所有数据，发现哪些是个人身份信息、知识产权或其他东西，我们可以使用机器学习来发现这些。为什么?每个顾客都是不同的。这不仅仅是发现他们告诉你他们拥有什么;它发现了数据的访问模式，当我们看到数据访问模式的变化时，这可能表明有坏的参与者进来了。我们可以建立所有这些东西，因为我们有这个微服务架构;否则，这将是一场噩梦。

KILLALEA:在2006年的一次谈话中acmqueue在与Jim Gray的谈话中，您谈到了团队如何“完全负责服务——从确定功能范围到架构、构建和操作。你建立它，你运行它。这让开发人员能够接触到软件的日常操作。”⁶我知道你对那次谈话记忆犹新。直到今天，这篇文章仍然是我们阅读最广泛的文章之一。书中提到的很多概念都有普遍的相关性。

VOGELS:和吉姆的那次谈话很棒。这与AWS无关。它更多的是关于零售，关于实验，确保你的工程师开发面向客户的技术，而不是坐在后面的房间里，把它交给其他人，然后他们再与客户接触。如果你的首要领导原则是以客户为中心，那么你也需要将这一原则运用到你的运营中。我们希望每个人都以客户为中心，为此你需要与客户保持联系。我也认为，我经常开玩笑说，如果你的闹钟在凌晨4点响，你就会更有动力去修复你的系统。但它让我们变得灵活，速度真的很快。

我记得在亚马逊零售的早期，我们有一整年都在关注性能，尤其是99.9%的百分比，我们有一整年都在关注消除单点故障，但后来我们有一整年都在关注效率。最后一个完全失败了，因为它不是一个面向客户的机会。我们的工程师非常善于消除单点故障，因为这对我们的客户有好处，或对性能有好处，并了解我们的客户。变得更高效是由底线驱动的，所有的工程师都说，“是的，但我们可以做所有这些其他的事情，对我们的客户有好处。”

KILLALEA:正确的。这是一个很难领导的项目。

VOGELS:这就是你想要的工程文化。当然，你也不想花太多的钱，但我记得把产品搜索从32位立即变成64位只需要三分之一的容量，但最重要的是，亚马逊的工程师们对什么对我们的客户是重要的进行调整。这又回到了我们的技术运作模式;当然，DevOps在此之前并不存在。所有这些都是在那之后发生的。

可能原因之一就是acmqueue文章之所以受欢迎是因为它是我们第一次讨论这个问题。当我们写那篇关于发电机的论文时，反应是相似的。⁴写这篇文章的动机并不是为了推广亚马逊，而是让工程师们知道，要构建世界上最大的可扩展分布式系统，我们拥有多么棒的环境，而这甚至发生在AWS之前。我和你当时面临的最大挑战之一就是招聘。你不能雇佣工程师，因为“为什么，你们是(咒骂)书店!”作为一个学者，我知道我几乎不会在亚马逊演讲。为什么?“一个数据库和一个Web服务器，能有多难?”

直到我们开始公开谈论这类事情，潮流才开始转变，我们不仅有能力雇佣更多的高级工程师，而且有能力让人们对此感到兴奋:“如果你想做真正大的东西，你就去亚马逊。”我认为现在有了AWS，这就容易多了;每个人都知道。但在那个年代，这要难得多。

KILLALEA:在规范意义上，最初的S3团队是一个单一的敏捷团队，事实上，在整个Amazon采用敏捷时，它是一个相当大的开拓者。

---

随着数据集变得越来越大，通过让计算更接近数据进行相对简单的操作，看看S3内部能做什么就变得更有趣了。

---

VOGELS:是的。

KILLALEA:2006年，您与Jim讨论的“您构建它，您运行它”的理念也应用于S3团队的开发人员。他们都非常熟悉最初的8个服务，并且能够在调试任何问题时进行第一次尝试。随着系统复杂性的增加，对于任何单个工程师来说，都很难有一个完整而准确的系统模型。既然S3不是一个单独的团队，而是一个大的组织，那么工程师如何对整个团队进行推理和建模呢?

VOGELS:一如既往，有技术，有文化，有组织。亚马逊的文化是众所周知的，我们不需要谈论太多的技术，所以一切都是关于组织。想想我们早期在亚马逊所做的事情，围绕着首席工程师创造的文化。这些人跨越多个服务，他们在这方面有更大的观点，他们负责架构的一致性——不是他们告诉其他人要做什么，但至少他们有知识。

如果您在S3中有一个团队负责S3 Select，那就是他们所做的。这就是你想要的。他们可能需要深入了解存储技术，或者其他类似的技术，甚至是存储技术随着时间的推移的演变，因为我们在2006年存储对象的方式和我们现在存储对象的方式是不同的。但我们并没有复制所有东西;你不能因为觉得某些新技术可能更容易使用，就突然开始复制艾字节的数据。你所做的决定也有一定的重要性，尤其是涉及到存储的时候。

首席工程师、杰出工程师——这些角色都是随着时间的推移而演变的。我加入的时候，我们公司还没有杰出的工程师。随着时间的推移，我们开始雇佣更多的高级领导，纯粹是为了成为这些团队，多个团队的顾问，而不是日常的编码工作。您不能期望S3 Select团队对Macie的审计功能有足够的了解，但是您确实需要在您的组织中有一些人可以在此基础上更自由地漫游。

我们去中心化的本质使我们很容易在团队的特定责任区域内快速行动;分权的缺点是协调。现在，突然之间，你需要在协调上投资，因为这些团队小，灵活，敏捷，快速移动，他们没有额外的人来帮助协调。

在过去的亚马逊，我们有一些这样的案例;当Digital(例如Kindle或Amazon Video)想要在订单管道中添加一些东西时，就需要一个实际的交付地址。没有别的办法。他们会走到80个不同的订餐团队面前说:“我们需要改变这个。”订购团队会回答说，他们没有为此做预算。结果之一就是我们允许重复发生。我们允许Digital团队建立他们自己的订单管道以提高执行速度。有优势;否则，我们不会这么做。也有缺点。

共享知识，首席工程师和杰出的工程师帮助实现这一点。但有时人们到wiki上阅读你的旧API，并不知道它是旧API，然后开始通过你认为你已经弃用的旧API敲打你的服务。

信息共享，协调，监督，了解其他的情况以及其他团队的最佳实践，在我们的规模下，这些都成为了挑战，因此你需要改变你的组织，你需要雇佣真正擅长监督的人，我不会说他们有决策控制权，但假设他们是老师。

KILLALEA:平易近人是首席工程师的关键特征。即使初级工程师通过设计评审，知道他们的设计很糟糕，他们仍然应该自信地离开，因为一旦他们相信他们重新设计的设计已经准备好了，他们可以再去找同一位首席工程师。

VOGELS:是的。

KILLALEA:您能否谈一下允许跨团队边界发展的责任划分，在哪里划分边界和适当的范围?

VOGELS:我仍然认为，在这个信息共享的话题上，还有另外两个角度，我们在亚马逊一直做得很好。其一，当然是在AWS之前，让所有人都审查运营指标或业务指标。数据库团队可能会在周二早上聚在一起，回顾他们服务中正在发生的一切，他们会在周三早上出席大型AWS会议，现在我们有175个服务，不是每个服务都出席了，但骰子正在滚动。

KILLALEA:事实上，我相信一个轮子正在旋转。

VOGELS:是的。所以，你需要准备好谈论过去一周的工作成果。其中很重要的一点是，会议室里有资深人士，也有刚刚推出第一项服务的初级人士。在那间屋子里的两个小时里，我学到了很多东西，这可能是我见过的最有价值的东西。对于商务会议也是如此，无论是与会的亚马逊(AWS)首席执行官安迪•雅西，还是亚马逊(Amazon)首席执行官杰夫•贝佐斯，还是亚马逊全球消费者(Amazon Worldwide Consumer)首席执行官杰夫•威尔克;在商业层面还有很多需要学习的地方。S3为什么要删除这么多数据?嗯，事实证明，这个服务于其他人的文件存储服务每个月只删除一次，在此之前，他们标记了所有对象(用于删除)。

你需要知道;你要明白;你需要和房间里的其他人交谈，分享这些知识。这些运营审查和业务审查会议已经成为极有价值的教育工具，大多数高级工程师可以在这里展示如何构建和运行可伸缩的服务。

KILLALEA:对于一个具有不断演进的架构的大规模服务来说，14年是相当长的一段时间。是否有一些通用的经验可以分享给起步较早的服务所有者?在S3从8个服务发展到262个服务的14年历程中，还有什么其他可以让我们的读者受益的经验教训吗?

VOGELS:一如既往，安全是第一位的。否则，你就没有生意可做。无论您构建什么，使用什么架构，都应该从安全性开始。你不可能拥有面向客户的服务，甚至是面向内部的服务，而不把它作为你的首要任务。

最后，我有两个建议。一种是架构良好的框架，我们从客户那里收集了10到15年的关于最佳实践的知识，基本上超过5个支柱。^3.架构良好的框架处理操作、安全性、可靠性、性能和成本。对于每一个支柱，你会得到100个问题，你应该能够回答你自己的问题。例如，“你打算做键旋转吗?”最初，我们的解决方案架构师会为您做这个审查，但对于数百万的客户来说，这并不能真正扩展。我们为我们的用户创造了一个工具，这样他们就可以在控制台上进行操作。不仅如此，他们还可以在多个项目中看到每个项目中可能存在的共同缺陷。如果你没有在其中任何一个做关键的轮换，也许你需要制定一个政策或教育你的工程师。

其次，它更面向开发人员，是Amazon Builders' Library。¹那是一套关于我们如何在亚马逊建立东西的文件。其中最重要的一个是基于细胞的架构:你如何划分你的服务，使爆炸半径尽可能小?你怎么做负荷削减?所有这些我们在零售商亚马逊苦苦挣扎的事情，我们想出了很好的解决方案，我们现在让每个人都可以看到。

KILLALEA:谢谢你沃纳;很高兴能和你聊天。

VOGELS:汤姆，很高兴和你谈话。

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2021 ACM, Inc。

---

没有发现记录