# 与 Werner Vogels 的对话 > 原文：[https://jotengine.com/scriptions/mc0d0gqhg0or8vkpt8s4ga](https://jotengine.com/scriptions/mc0d0gqhg0or8vkpt8s4ga) > Kyle Corbitt: 这是我真正的荣幸。 我们今天和医生在一起。 沃纳·沃格斯。 他是亚马逊的首席技术官，当然他有很多令人兴奋的经历。 所以我们今天要和他谈谈他在亚马逊的经历，他在初创公司的经历，以及许多与我们很多人相关的技术话题。 所以谢谢大家，让我们为博士放弃吧。 沃格斯。 > Werner Vogels: 谢谢您。 > Kyle Corbitt: 可以。 当然，我们今天要谈论的是亚马逊，以及你在那里的角色。 但我想从一些背景开始。 在你开始亚马逊之前，你能告诉我们你的职业生涯吗？是什么让你达到这一点的？ > Werner Vogels: 我们有多少时间？在我加入亚马逊之前我是个学者。 我在康奈尔大学做了十年的研究科学家，建立了大规模的分布式系统。 就像在美国和学术界一样，你也会被激励去做创业者。 所以我们在旁边做了两个初创公司，其中一个在我加入他们时就已经存在了。 他们被卖给了一家叫做 Stratus 的公司。 我不知道有没有人记得。 那是在你的时代之前。 而另一家公司却失败了。 我们都有经验，这很好。 有点。 所以在那之前…我不是一个典型的计算机科学家。 直到 28 岁我才真正决定回学校。 我以前在医院工作过，放射治疗。 荷兰癌症研究所对癌症患者进行放射治疗。 有一刻我意识到我真的很讨厌这些人在我身边死去。 我决定去做一件没有人参与的事。 计算机科学似乎真的是一件好事。 现在是 80 年代中期。 所以计算机科学现在已经不复存在了。 但事实证明我有一个... > Kyle Corbitt: 那时没有人类。 > Werner Vogels: 你这么说，是的。 原来我有一个礼物送给它。 我事先不知道。 从那里我开始研究，因为那些是我真正感兴趣的东西。 我获得了博士学位，在葡萄牙的一个研究机构工作了几年，然后我被邀请到康奈尔大学。 然后在某个时刻……我当时在康奈尔大学的时候也做了些什么，事实上，我要么咨询像惠普这样的大公司，要么咨询这个世界上[听不清]的公司。 也经常进行会谈。 所以有一刻，亚马逊邀请我来谈谈我正在研究的一些材料。 我想，真的吗？真的，我得走了吗？这是什么？这是一家书店。 你知道，网络冲浪和数据库，有多困难？然而，一眼厨房，我意识到这是一个巨大的技术操作。 它不是一家零售商，它是一家技术公司，经营规模我以前从未见过，绝对不是我咨询过的其他公司。 从分布式系统研究的角度来看，他们面临的挑战是惊人的。 他们给我提供工作时，我不需要很认真地考虑。 > Kyle Corbitt: 哇，太不可思议了。 这很有趣。 你觉得这是一种改变吗？像今天一样，有趣的分布式系统问题是大公司，也许在学术界出现之前？或者，这就是你事业的发展方向？ > Werner Vogels: 不，我认为情况仍然如此。 我认为大多数分布式研究人员已经意识到这些非常大的公司需要以何种规模运营。 甚至不是这些大公司。 如果你想一想，任何一家成功的互联网公司，或者仅仅是数字公司，都需要以无与伦比的规模运营。 2004 年当我加入亚马逊时，你们中的许多人，如果你想成功的话，将很容易以亚马逊 2004 年的规模运营。 但是没有你真正可以依靠的工作。 没有你必须依赖的基础设施。 所以，在基本上保持云和其他技术给你的东西的光照方面做了很多努力。 亚马逊在 2004 年仅仅通过实际操作就达到了一定的规模。 这并不是说有一本书，或者说你可以阅读如何建立一个可扩展的组织或者一个可扩展的公司，不是的。 因此，在我看来，亚马逊在技术的使用、技术的发展以及运营规模上都比曲线提前了 5 到 10 年。 尤其是如果你想成为一个快速发展的公司。 你不可能喜欢传统的企业，因为他们都面临着创新者的困境，而且很多事情一旦成功，在某一时刻会变得非常缓慢。 如何建立一个需要继续快速发展的公司是一个完全不同的故事。 你可能在权衡生意。 例如，创造技术债务或允许重复发生或类似的事情，这在传统企业中是不可能的，因为效率是他们的主要目标。 在亚马逊，移动速度快，创新速度快，并且有很长的实验管道，这是最重要的事情。 所以你愿意让重复发生，你允许创造技术债务，只要你知道你必须偿还它。 因此，在传统的 MBA 书籍中，你找不到很多亚马逊愿意做的权衡。 大多数情况下，亚马逊必须自己发展。 无论是技术还是流程，还是业务流程。 当然，有了杰夫·贝索斯的掌舵，你就有了一个真正的远见卓识者，真正了解下一个现代世界的面貌或应该是什么样的人。 > Kyle Corbitt: 谢谢。 所以在你加入亚马逊几年后，你被任命为首席技术官。 > Werner Vogels: 实际上是六个月。 > Kyle Corbitt: 哦，真的吗？ > Werner Vogels: 有人问你，你想当首席技术官吗？你想，“他明年不会问，是吗？“[听不清]，他现在还在公司，顺便说一句，他真的想成为一名开发商，他们一直在寻找[听不清]的替代者。 正如我之前所说，有时候你会有一些你不知道的礼物，直到你开始做它们。 我想我是在 9 月加入的，我想我是在 1 月成为首席技术官的。 > Kyle Corbitt: 真的。 所以告诉我亚马逊的情况，然后在我们今天之前，这个角色已经转变成了什么。 > Werner Vogels: 亚马逊的其中一件事，是雇佣我的原因之一，实际上还有我的一些……我带来了，事实上，是吗？我带了五个我以前的学生，当我到那里的时候，真的是要在我们想要的方法中插入更多的学术严谨。 亚马逊已经在规模上变得很好了，但挑战是我们想要做更多的数量级。 在课程中，我们从数量级增长开始。 你必须重新审视你所做的一切，无论是你的过程，还是你的技术。 要真正站稳脚跟，做下一件事，或者达到即将到来的几级增长，我们需要在我们的思想中插入更为严谨的方式。 例如，这是围绕性能的。 你如何测量？我们需要什么样的基础设施来进行测量？如果你想成为一个真正的数据驱动的公司，做出数据驱动的决定，首先你需要拥有数据，但你也需要有一个文化，围绕你如何衡量？你如何解释这些测量？我的意思是，中等延迟，比如说，离你的网页一点二秒的时间，对你的客户什么都不说。 它只是说 50%的客户的体验更差。 你需要知道情况有多糟。 然后从一个工程……例如，99%或 99.9%在这些情况下更重要。 然后，你如何创建一个控制了 99%的工程学科，这样你就可以真正地开始引入它，如果这是你想要做的话？然后能够将其与业务决策联系起来。 例如，常见的知识是，如果提高了网页的延迟，转换就会增加。 问题是，你愿意花多少钱来推动这种转变？你需要有更多的能力，你需要做更多的工程。 你什么时候才能获得控制权所必须的投资收益递减呢？ 所以整整一年，我们都在关注绩效和衡量，诸如此类的事情，当我加入时，已经有一些进展。 我们花了整整一年的时间专注于单一的失败点。 真的，我认为 2004 年我们的可靠性相当好。 周围有规则，所以我们必须使用[SEA]数据中心。 您必须在这些 SEA 数据中心上复制您所做的任何操作，这样就可以丢失一个数据中心。 客户不应受到影响。 因此，您可能会失去两个数据中心，客户可能会受到延迟方面的影响，但不会受到功能方面的影响。 所有这些规则都在那里，我认为我们非常擅长，直到有一刻我们决定，那么为什么不从这些数据中心中的一个拔出插头呢？看看会发生什么？我们第一次这样做并不是为了给大家一个惊喜。 不，我们提醒大家这是我们要做的。 我们不是真的要拔掉插头。 我的意思是，你拉网络，基本上，所以数据中心被隔离。 事实证明，所有这些东西在纸上看起来都很好，但实际上并没有那么好。 尽管第一次这样做时，很多手动过程仍然存在，手动数据库故障转移，诸如此类的事情。 这都是预演。 所以一整年都在关注这个问题。 当你做第三或第四个游戏时，我们称之为游戏日，你实际上达到了一个点，这些事情变得非常自动化，你实际上可以在没有人为干预的情况下完成它们。 当我们第一次这么做的时候，最大的惊喜是……然后你让另一个数据中心重新上线。 然后突然，数据中心必须与其他数据中心同步。 伙计，那是个噩梦。 这是一个没有人想到的情况。 但在你做这些事情之前，你是不知道的。 尤其是这个比例。 然后我们在效率上做了一年，我们做了一些其他的事情。 首席技术官的主要职责是推动真正的大项目，并思考未来我们需要什么样的技术才能作为一个企业建立稳固的基础？或者在亚马逊的例子中，我们已经开发出了哪些其他类型的独特技术，我们也许能够将它们转化为业务？然后事情会在某一时刻发生变化，因为在 21 世纪初，我们在目录中放置了一个 API。 那在当时很流行。 你只要在某个东西上添加一个 API，看看会发生什么创新。 事实证明，很多大公司都在建设中。 所以我们可以访问目录、搜索、购物车，我认为还有一个功能。 不管怎样，很多新的电子商务公司都是根据亚马逊的目录建立的。 他们会做比较购物，并有美妙的新的统计研究所来丰富整个网站，真正伟大的东西正在建设。 但一旦其中一家公司取得成功，他们都开始在执行过程中结巴。 他们都需要得到投资，而不是因为他们需要通过业务运营来运营，他们都需要开始购买硬件。 他们需要雇佣 IT 人员。 所有这些投资实质上都是美国硬件行业的间接资金。 所有这些公司都很难做到这一点。 他们很难获得投资，他们很难获得硬件，因为您可能会订购 50 台服务器。 这不像开车去好市多，把它们放在你的购物车里。 然后雇佣 IT 人员和类似的人。 因此，最初在亚马逊目录上取得成功的大多数公司都失败了。 他们并没有失败，因为他们没有好的想法，他们失败了，因为他们不能准备好他们的 IT 设备，或者没有钱来真正做到这一点。 我认为，随着 AWS 和云技术的发展，一个变化就是你得到的投资不再大量流向硬件公司。 它涉及到雇佣更多与你的公司相关的人，并实际更好地构建你的产品。 然后我们变成……我们开始自动焊接，我们可以稍后再谈。 但是当你成为一个技术供应商，你作为 CTO 的角色就会改变。 我写过一篇关于这个的博文。 在我看来，CTO 有四种不同的类型。 首先，问任何大公司。 每一家大公司，首席技术官的角色都会有所不同。 但我认为有四大类。 一个是企业，他们通常是基础设施经理。 他们向 CIO 汇报，管理大量基础设施。 还有第二个角色，我认为是，你在年轻企业中经常看到的，那里的首席技术官是技术联合创始人，一个有技术远见的人。 我确实认为这个角色是危险的，因为有太多其他的东西，从[听不清]工程团队和类似的事情来说，实际上都落入了这个桶中。 CTO 可能不一定擅长，但我们稍后再谈。 还有一个大思想家的角色。 这正是你推动创新的地方。 如果你看看像 AT&T 和朗讯等公司，他们都有 CTO，或者有一个 CTO 办公室，在那里真正建立下一代技术或实验。 然后是面向外部的技术专家的角色。 如果你是其他公司的技术提供商，那么管理人员就有一个角色，可以与客户在深层次的技术层面上进行互动，以了解他们是如何使用我的产品的？在客户中寻找更深层、更大的模式。 他们还有什么更大的痛点？不仅有我们的技术，而且一般来说。 你知道，我经常开玩笑地说，所以我们是做疼痛管理的，AWS。 是的，那么，客户还有什么样的痛苦，他们必须努力去做那些实际上对他们想要构建的产品没有贡献的事情呢？这一方面有助于客户理解事物，有点像是整个云概念的福音传道者，我们可以肯定地说，10 年前比现在重要得多。 但是，最重要的是，把客户的反馈带回公司，开始思考你需要做什么新的功能或产品，或者我们需要改变什么样的流程，以确保我们更好地为客户服务。 这是一个更加以客户为中心的职位，而不是以技术为中心的职位。 > Kyle Corbitt: 伟大的。 我很好奇，你刚才说的，特别是在早期，有很多任务，比如你所说的游戏日，以确保基础设施的规模。 我很好奇，你是否注意到在亚马逊成长的过程中，工程文化发展得如此之快，你是否发现了一些关于如何发展工程文化并保持其快速发展的技巧或诀窍？保持有效？ > Werner Vogels: 好吧，考虑到亚马逊实际上是我的第一份真正的工作，很长一段时间以来，我一直认为世界其他地方和亚马逊一样。 不是。 亚马逊有一种非常独特的文化，我认为这对快速发展的公司非常有效。 至少让你的团队尽可能独立。 从组织中删除尽可能多的层次结构和结构。 在我看来，等级制度完全不自然。 我的意思是，你需要有某种形式的层次结构，可能是为了报告或者类似的事情，或者为了一些管理部分。 但是如果你看自然，有一只头猴和所有其他的猴子。 没有猴子中尉。 是啊？不。 我的意思是，你可能有很多这样的群体，都有头猴。 它的伸缩性非常好。 我的意思是，如果你观察蚂蚁和自然界的所有模式，如果你能够建立一个自组织的组织，这基本上意味着你雇佣了那些真正想要独立的人。 不想成为追随者。 它实际上想要拥有产品的一部分，并且真正拥有它。 我认为当你是一个年轻的企业时，这一点非常重要。 你不需要追随者的地方。 你不需要编码员。 你需要那些想要拥有你想要的东西的人。 我想，看看这个。 亚马逊有一种我们称之为领导原则的东西。 其中有 14 个，基本上，这就是文化。 所以这就是客户的执着、所有权、深度挖掘，所以其中有 14 个。 看看他们。 如果你在你最喜欢的搜索引擎中输入它们，你会找到它们，并对它们进行深入的解释。 但这确实推动了亚马逊文化的发展。 当我们雇佣一个面试官的时候，比如说我们请了一个面试官，通过电话面试和类似的事情，你可能真的知道他或她是否是一个优秀的工程师。 你的面试都是关于文化的。 真的，你的文化真的很适合吗？因为在文化环境方面，没有比糟糕的雇佣更糟糕的了。 因为这会极大地扰乱你的小团队。 所以在亚马逊，我们非常相信非常小的团队。 所以 10 到 12 个人。 因为有 10 到 12 个人，每个人都知道你在做什么。 我的意思是，顺便说一句，如果你想洗个澡，如果你想早上和 25 个人一起站在走廊里，那就行不通了。 你真正关注的是小团队，确保他们对他们需要做的事情拥有强大的所有权。 作为一个独立思考的建筑团队，想要掌控自己的命运，我认为这很重要。 我认为其中一个挑战是当你在一个年轻的企业成长时，我的意思是，一个首席技术官的角色最初可能是他做一切与技术有关的事情。 基本上，你考虑技术，但也管理团队。 现在，我认为管理团队是完全不同的纪律。 现在，我所说的工程副总裁和首席技术官之间有一个很大的区别。 工程副总裁每天早上醒来都会想：“我有绝对最好的团队吗？我的团队是否处于交付所需内容的最佳位置？“这是一个人。 真正的想法是确保你的工程师处于正确的位置来交付他们需要交付的技术和产品。 CTO 考虑技术。 我们是否在构建正确的技术？我们有合适的工具吗？我们有这些东西吗？在我看来，这是一项与工程副总裁截然不同的工作。 你们认识迈克尔·洛普吗，我认为他是著名的博客写手。 如果你是一名经理，如果你考虑管理，从技术管理的角度考虑，他可能是最著名的温和派作家，他真正思考的是如何使团队有效？但他不是首席技术官。 他是工程副总裁。 我认为这真的体现了（听不清）关于它的书。 看看他的东西。 迈克尔·洛普。 兰兹在休息，我想是博客。 所以真的要看看这些东西。 > Kyle Corbitt: Great. 所以你之前提到过，在亚马逊的早期，你让那些公司与你整合，他们因为基础设施的原因而失败了。 这就是 AWS 的由来吗？或者告诉我，AWS 的想法是怎么发生的？这是如何在内部流行的？ > Werner Vogels: 所以在内部，亚马逊[听不清]。 他们现在也在运行 AWS。 在这样的独立团队中或多或少是有组织的，这些团队中的大多数看起来也像初创公司。 或者他们完全控制自己的目的地。 相信我，书籍推荐引擎和鞋子推荐引擎有很大的不同。 他们有不同的团队，他们有不同的目标，他们有自己的创新议程，都是由团队自己制定的。 所以我们经历了很多建筑上的变化。 90 年代末，亚马逊的目标是快速发展。 为了达到这一点，他们基本上违反了各种体系结构原则。 这意味着它最终成为了某种整体，在后端有一个庞大的数据库基础设施，非常脆弱，从体系结构的角度来看基本上无法再增长。 但要记住，以前没人做过这件事，所以他们不能被指责。 不像你违反了教科书。 没有教科书。 于是亚马逊转向了所谓的面向服务的体系结构。 那也不是当时存在的词。 因此，切掉整块的碎片，将您操作的数据集合在一起，在上面放置一个 API，然后拥有一个网络基础设施，您可以称之为这些，我们称之为服务。 基本上，这需要 2 到 3 年才能完成。 主要是因为再次出现了，关于如何运行服务没有历史记录？所以，基本上，但我们所做的，是把钟摆一直摆到另一端。 在这个使用整体的数据库中，整个数据库集是一个共享资源，基本上是一个约束，因为共享资源会使您的移动速度变慢。 我们看到，改变架构的一个原因是我们看到工程师的效率正在下降。 基本上，部署速度变慢了。 新的功能变得越来越慢，所有这些事情。 为什么呢？因为后端数据库由一组 DBA 管理，所以数据库管理员。 DBA 小组。 要进行任何模式更改，您必须仔细检查它们。 这些人负责这些数据库。 所以他们是保守的，你可以想象，因为网站的可靠性依赖于他们。 所有这些都意味着我们的效率和创新真的在下降。 进入到这个新的体系结构中，我们创造了所有独立的东西。 他们将拥有自己的数据存储。 不再有集中的数据存储。 不再有一个集中的数据存储，不再有单一的（听不清）集中资源，诸如此类。 哦，太好了。 除此之外，我们在那里犯了一些错误。 好吧，两年，三年后，我们把这些碎片都刻了下来。 巨石已经基本消失了，所有的服务。 原来有一个旁白。 我们犯了一个错误。 我们有三个非常大的数据集。 客户的物品，那是目录和订单。 我们基本上把对特定数据操作的所有代码都当作一个服务。 两年之内，它就和那块巨石一样大。 我们必须分解成更小的功能构建块。 例如，如果您谈论项目主服务，那么客户主服务基本上由 10 个不同的较小服务组成。 每一个都有自己独特的扩展性和可靠性，能力。 例如，在那里有一个登录服务，基本上是在每个网页上调用的。 但在同一个软件中，通讯录服务也在运行。 只有在退房时才需要。 但整个事情需要按登录服务器的规模进行扩展，因为这是一个需要更大规模的服务器。 因此，将其分解成不同的构建块，每个构建块都有其独特的伸缩性和可靠性，也许还有安全性要求，这使得我们进入了现在被称为微服务体系结构的领域。 向前走，所有这些团队，他们都很小，他们拥有自己的一部分，然后我们看到这些团队的效率再次下降。 因为现在每一个服务都变成了…需要扩展。 他们都需要做同样的事情。 它们都需要管理负载平衡、硬件和数据库。 现在，每个团队都负责实际复制三个不同数据中心的数据库。 所以，实际上，所有这些团队，你看到这些团队和网络基础设施之间的交流在增加。 所有这些新的票都被创造出来了，所有的工作都完成了。 但他们不是在创新。 他们不想让实验管道继续运转。 还有一个危险信号，我意识到所有的球队都在做同样的事情。 因为我们把钟摆扔到了一边，现在你必须管理自己的数据库。 将实际的数据库放到共享服务平台中，删除存储，删除其中的网络，例如，还创建了一个环境，其中服务器不再是服务器，而是虚拟的，您可以实际管理它们。 我认为在硬件配置方面，我们当时确实做得很好。 作为一名工程师，您将进入一个门户，您将填写您需要的内容。 您还需要 10 台这样大小的 Linux 服务器，一两个小时后您就可以拥有它们了。 如果你能想象到在年底，临近感恩节的时候，尖峰是感恩节的四倍。 所以团队需要更多的硬件。 如果你在一月份去和他们谈谈，告诉他们“你为什么不释放任何能力？”“。 “哦，你知道，如果三月份有项目要进行的话。”然后我们想，为什么不坚持下去呢？显然，仅仅一个小时就能获得生产能力并不能很好地激励人们再次发布产品。 我们首先需要去移动，在那里你可以把工程师们带出循环。 而且，我们可以有业务规则来决定有多少容量应用于某个事物。 服务器需要虚拟化，它们需要获得一个 API，诸如此类。 我们在内部为自己建造这些东西。 看看这些在外部失败的公司，他们的规模看起来是……但我们自己解决了这个问题。 然后开始考虑说这些技术中的一些，或者不是技术本身，而是考虑我们如何为内部构建它们，然后在外部重建它们。 我们在 2006 年春季推出的第一款产品是 AmazonS3Simple Storage Service。 我们称之为互联网存储。 实际上，在早期，我认为这将是针对我现在所说的互联网规模的公司。 我不喜欢用“初创公司”这个词，因为我认为有许多其他类型的企业最终需要互联网规模。 这就是我们所追求的。 存储成为第一个，我们在那年秋天推出了 EC2。 我们内部使用的移动设备和接口，突然计算能力变成了可编程的。 在几个月内，企业发现这对他们来说也太划算了，从那以后我们就知道了。 > Kyle Corbitt: 我很好奇，我的意思是，在你开发这个产品的时候，在它发布之前，亚马逊有没有感觉到……我的意思是，它现在是世界上的主导产品。 这改变了开发商在大公司和小公司的工作方式。 你真的有这样的信念吗，这将改变风景？或者它只是一种迭代，每年都有更多的人使用它，它只是慢慢地成长为今天的样子？ > Werner Vogels: 我认为，我们曾经的事情之一，我不会说是措手不及，是它增长的有多快。 那是肯定的。 我们知道它会非常大吗？是的，那是我们下的赌注。 在亚马逊，有两种类型的创新正在发生。 其中之一就是每个团队自己负责下一年的创新路线图。 团队自己做。 如果他们为鞋子设置推荐引擎，作为减少退货数量的度量标准。 你能推荐吗？现在，如果这个华伦天奴 9 号非常适合你，如果你想买这个吉米·乔，也许买 8.5。 这似乎很愚蠢，但做退货是一种税，这是一种客户不友好的事情。 所以你能做的越多。 这些人负责为来年绘制路线图。 如何获得新的数据源，如何以不同的方式与客户接触。 这是他们自己做的。 没有自上而下的事情，你应该这样做。 所以这是创新的一个层面。 另一个层次是需要大量资本投资的层次。 这显然是美国焊接学会所属的特殊类别。 像 Kindle、AmazonPrime，所有这些都是我们进行大量资本投资所需要的。 然后亚马逊留下了一条规则，如果你这样做，如果它会成功，它需要以对亚马逊资产负债表有重大影响的方式成功。 这不是说我们对另一个感兴趣，比如说，听起来[听不清]，而是另一个 5000 万美元的机会，如果你进行这项资本投资，你需要寻找真正巨大的机会。 我们知道，如果自动焊接系统能够成功，它将是巨大的成功。 以我们从未见过的方式。 我们知道，如果一切顺利的话，我们必须开发出许多新的工艺、技术和技术。 现在，我记得在开发 S3 的时候，我们在板上写了一个数字，我们想，“哦，六个月之内，我们可能……让我们为存储引擎中的这个数量的对象构建这个数字。”然后，为了检查它，我们在它后面放了两个数量级。 比如，好吧。 在头三个月里就成功了。 哦。 现在突然发现，我们早期从技术的角度做出的一些决定是非常明智的。 我们知道，随着每一个数量级的增长，您可能需要重新审视您的体系结构。 你需要建立一个软件，需要能够随着时间的推移而发展。 例如，以存储引擎为例。 如果您转到软件内部的下一个版本，就不能只复制其他存储磁盘上的大量千兆字节来完成这项工作，不。 您必须同时使用多个体系结构，多个版本，所有这些东西。 幸运的是，从 amazon.com 学到了很多经验，我们实际上已经在那里采取了正确的步骤。 但在这个意义上，随着时间的推移，也有一些挑战。 但我也认为，就像其他公司一样，不仅有你必须扩展的技术。 我想在 AWS 的早期，我相信我们说过“我们不需要任何销售人员”。 这东西会自己卖的。 这都是自助服务。”事实证明，情况并非如此。 事实证明，您需要解决方案架构，您需要技术客户经理，您需要客户支持。 你需要在你的产品周围建立所有这些与技术本身无关的东西。 但是，没有这一点，你就不能成为一家成功的公司。 > Kyle Corbitt: 实际上，我是在采访之前看的，我在看 AWS 目录页。 还有，我不知道，我认为这就像是 130 个服务，而且这个数字可能会改变，到我们结束这次谈话的时候。 我很好奇，作为一个组织，你如何决定……你如何决定建立一个新的东西？这是一个自上而下的过程吗？它只是一个独立的团队吗？那是什么样的新产品？ > Werner Vogels: 这两种方法都有效。 我们希望我们所有的团队都能与我们的客户保持密切联系。 我们提供的大约 95%的功能和服务是为了响应客户的直接请求。 这是一次大规模的涌入，当然是我们建立的最早的服务，你几乎可以想到它们应该是什么。 我的意思是，什么是基本的 IT 基础设施、存储、计算、数据库、网络、安全。 我的意思是，你不需要客户来告诉你。 我们知道这些是我们需要建造的基本部件。 但很快，客户就提出了各种其他要求。 我的意思是，如果我从根本上看，AWS 真正擅长的是规模、性能、安全性、可靠性和管理成本。 这些不是外部的产品，而是每个服务中的核心功能。 然后客户来找我们说：“好吧，你知道，你不能为我们运行分析吗？“这是早期的时代，所以关于分析的一切，关于 IUT 的一切，关于移动开发的一切，关于现在的区块链的一切，以及客户实际上想要使用但不想管理自己的所有其他技术。 基本上帮助他们建立正确的特性或工具是很重要的。 当我们推出新产品、新服务时，我们也有很强的文化氛围，我们将以最小的功能集推出它们。 你可以称之为 MVP。 但这是其他人建立业务所需要的技术。 你不能真的发射出薄片状的东西，它必须是坚如磐石的。 因此，我们推出的东西坚如磐石，但功能集最少，然后与您的客户在其他功能应该是什么。 现在，一般来说，我们不知道其他特性是什么。 例如，当我们启动 dynamodb 时，我们真的知道客户想要二级[ndcs]。 我们没有和他们一起发射，但很明显这就是他们想要的。 我们主要使用最小的功能集来启动，因为这些服务有时是以前没有人使用过的，也没有人构建过的。 我们需要观察你的客户，他们将如何使用你的产品。 因为你事先不知道。 事实上，他们可能会以任何可能的方式使用它，除了你打算使用的方式。 这是很好的，因为如果它不是与所有东西和厨房水槽一起发布的，那么你可以关注你的客户是如何使用你的产品的，然后慢慢地开始以他们新的现代开发方式工作的方式迭代和添加新的功能和服务。 当我们启动 lambda 时，它是我们的无服务器环境，所以基本上您只需编写代码，将其转储到 S3 中，而不需要考虑服务器和其他任何东西。 你不需要考虑空闲时间。 你只需要为你使用的东西付钱，像那样的东西。 环境很好。 以前没人这么做过。 那么，发展将如何改变呢？它周围的其他支撑结构是什么？最初，我们将它作为一个事件驱动的环境发布。 所以，一个新文件到达 S3，它会触发一些代码。 一条新消息到达，它会触发一些代码，API 网关。 像这样的事情。 但事实证明，一些公司，实际上立即跳上与服务器少一些是一些最大的企业。 为什么？因为你不需要管理任何事情，如果没有执行，你也不需要支付。 我的意思是，如果你运行一整批 SE2 实例，不管你是否使用它们，你都要为它们付费。 在这种情况下，您只会被收取执行费用。 它改变了开发发生的方式。 你不会像我之前说的那样，在服务器周围启动所有东西和厨房水槽，你会看到你的客户是如何使用它的。 他们很快就开始以[听不清]X 射线作为调试环境进行迭代。 提供步骤功能以构建更复杂的应用程序。 而且，还有很多事情要做，主要是因为你可以观察你的客户是如何使用你的产品的。 例如，在 dynamodb 中，我们知道辅助索引。 结果表明，客户希望利用项目级别的访问管理。 对他们来说比二级国家数据中心更重要。 基本上，客户重新订购了我们的路线图。 然后我们开始提供对他们最重要的东西。 我认为这是很重要的一部分。 但是，同样，即使它看起来像一个 MVP，我们不能把它当作 MVP，因为人们将在它的基础上建立他们的业务，他们将依赖它。 因此，它周围有一个非常不同的文化结构。 去年有 1400 项新功能和服务？随着团队数量的增加，这当然也会加速。 我们在 AWS 中使用相同的结构。 海王星团队。 图形数据库应该与他们最重要的客户保持联系，或者说是最苛刻的客户。 了解他们的需求。 每个团队都有自己的客户群和客户群，并且都是围绕路线图构建的。 你得到的服务越多，你得到的路线图就越多。 但是，这确实是一个快速移动的环境，人们构建软件的方式也发生了巨大的变化。 如果我们能够为我们的客户决定他们应该如何开发软件，那么您可能已经按照五年前或十年前的方式开发了软件。 因为这就是你的结构。 相反，我们需要在 2020 年或 2025 年开始开发我们希望如何开发软件的软件。 这就是我们的想法。 你不能通过为客户做决定来做到这一点。 你需要与他们密切合作，让他们驱动你的创新引擎。 > Kyle Corbitt: 大约十年前，你写了一篇名为“向后工作”的博客文章。 你还记得我说的那个吗？ > Werner Vogels: 是啊。 > Kyle Corbitt: 我很好奇。 你能描述一下你放在那个职位上的产品开发流程吗？然后告诉我你学到了什么，亚马逊是否仍然使用这种结构。 > Werner Vogels: 我们无处不在。 协议从客户那里向后工作。 亚马逊，我们非常注重开发那些对你的客户真正重要的东西，即使我们是一家技术公司，我认为如果你是一家重型技术公司，大量的工程设计，工程师也有负责的风险。 如果他们负责，你不一定要制造产品，你要制造技术。 对我们来说，两者有很大的区别。 我认为，让 AWS 成功的原因是我们关注的是产品。 意思是，我们想为我们的客户做什么？更像是，哦，这是一个非常酷的存储系统，它位于我们从未建过的地下。 或者我们如何在 dynamodb 中处理全局表？所以我们正在建造所有这些令人惊叹的技术，但这并不是驱动它的原因。 这就是你想要为你的客户建立的。 你想解决什么问题？为了他们。 我们要确保这一点，无论是在 AWS，还是在[听不清]，还是在门罗公园开设一个新办公室。 我们使用一个叫做向后工作的过程。 我们为什么要这样做？所以你要做的第一件事就是写一份新闻稿。 这不是一个新闻发布会。 这是你为自己写的一份新闻稿，你用非常清晰和简单的术语丰富地描述了你将要构建的东西。 然后你写一份文件，上面有 20 个最常见的问题。 然后你必须用非常清楚和简单的术语来回答这些问题。 有时，特别是在更复杂的情况下，我们会迭代前两个文档，可能 10 到 15 次。 直到完全清楚你将要建造什么。 不超过这个。 然后，您编写 UX 文档，基本上我的客户将如何使用它？或者与客户的互动将是什么？第四个文档是用户手册、术语表和其他一些术语的一部分，类似的东西。 最后，您将看到一组四个文档，它们精确地描述了您将要做的事情。 亚马逊河流域的统治是这样的，你的账单不会超过这个。 因为，作为工程师，我也是一个工程师，你有这样的倾向……任何能让你轻松构建第二个版本的东西，你[听不清]都可以把它放在第一个版本中。 这不是一个选择。 它真的专注于构建那个，而且只关注那个。 它为我们提供了一个非常强大的结构，围绕着如何思考客户、如何感受产品，以及更多关于技术的内容。 这是您要构建的产品。 现在，我们需要什么样的技术？有一个非常强大的产品在思考这个问题。 它与我们拥有的另一个过程结合在一起。 亚马逊会议……我们暂停使用幻灯片。 没有 PowerPoint，没有主题演讲，什么都不像。 为什么？因为在会议上，我认为幻灯片是致命的。 一半的房间将在他们的电话上，另一半已经在第二张幻灯片上抱怨他们不明白你在说什么。 很明显，因为你还没有看到整个演示。 我们在亚马逊经营着所谓的六台寻呼机。 这是一个六页的文件，一个你必须写的叙述。 在会议的前 30 分钟，我们将一直默读这份文件。 有时候，读完一半，你会像“伙计们，回到画板上”。 别在这里浪费时间。”为什么？因为这是非常重要的，因为如果你没有清晰的头脑，就很难写出一份清晰的文件。 写一个故事是非常困难的。 这可能是，经常会有一个协作的努力。 你会写，你会给你的一些同事反馈，你把它放在你的抽屉里。 一周后，你再次拿起它，修改它，直到你认为你真正清楚地描述它是一个特性，还是一个产品，或者一个活动，或者一个你想涉足的新业务。 在看了这六页 30 分钟后，房间里的每个人都在同一页上。 顺便说一下，没有双关语。 或者你想说的双关语。 所以不，在那之后你会得到非常高质量的讨论，因为每个人都知道我们在说什么。 现在，这个过程的一部分通常是这样的，然后在这六个页面上有一个附录，它是 pr 和 faq，您将重复这些内容。 我们有一个非常独特的文化。 > Kyle Corbitt: 五年前，虚拟化还是一个相当新的概念，很多公司都在转向虚拟化。 今天，一切都在集装箱化，很多大客户都转向了 lambda，转向了完全没有服务器的平台。 你认为五年后发展将走向何方？我们将如何构建我们的应用程序？ > Werner Vogels: 如果我有这个水晶球……我会有点……我想我确实看到不少公司跳过了集装箱的步骤。 越来越多。 我想这堆东西中的一部分我认为是什么让容器变得流行，有一件事是每个人都想进入一个更加微服务的环境，我认为容器技术的地图非常好。 我们可以在您拥有的单个组件中轻松地进行上下扩展。 我认为这与微服务的想法非常吻合。 我认为大多数真正进入那个阶段的人通常都是从整体阶段出来的，把整体分解成那些容器。 人们从零开始，越来越多地围绕无服务器环境进行开发。 你甚至可以考虑，在美国焊接协会，两个集装箱产品。 一个是 ecs，这是一个容器服务，它围绕着 docker 和 docker 的功能和类似的东西。 以及对所有数据库服务的深度集成，然后在服务下面管理[听不清]eks。 我们就是这样开始的。 集装箱的问题，尤其是在我们交付 Fargate 之前，我将在一分钟内讨论它，基本上它几乎把你带回到云前的日子。 突然，您需要在多个可用性区域上管理多个容器。 几乎有很多东西需要将它们映射到虚拟机上。 因为这些东西不是由它们自己控制的。 您仍然需要管理下面的整个虚拟机环境。 尽管容器是一个很好的开发抽象，但是客户需要做很多工作来运行这些容器。 所以其中的一部分将得到处理，因为它是一个托管服务。 但我们也交付了一种叫做法盖特的东西。 Fargate 基本上取消了底层虚拟机的所有管理。 所以，基本上，只要写一个容器，把它放进去，它就会运行。 Kind of. 那是你想去的地方。 现在，我认为每次你需要做一些与构建产品或运行产品毫无关系的事情时，以最有效的方式，那就是浪费精力。 我们继续研究如何才能将越来越多的痛点去掉？因为你知道，没人关心谁在运行容器。 没有人关心下面的虚拟机。 这只是你必须付的税。 我认为我们正在培养，特别是我认为[听不清]群体中的交互作用确实将许多东西反馈到主流[听不清]开放源代码环境中。 尤其是在安全之类的事情上。 五年来我们是如何做不同的事情的……哦，这就是问题所在。 是的，我认为有更多的无服务器开发，因为我认为我们已经看到了一个巨大的进步。 我认为我们将看到越来越多的工具和支持平台和基础设施，围绕着构建更复杂的无服务器环境的能力。 我认为与其他服务更好地集成，这绝对是我们将看到的。 但我想换个地方。 我想五年后我们要做的一件事是，每个人都将把安全作为他们的首要工作。 无论你是首席执行官，还是首席技术官，无论你是工程师，我们都需要变得有安全意识，我们都需要成为安全工程师。 我想如果你看过过去的四五年，我的意思是没有一个星期没有大规模的数据泄露。 是啊？很尴尬。 我认为，作为技术专家和数字商务领袖，我们应该感到尴尬。 但我们不是。 愤怒在哪里？我们几乎可以接受这是我们的一部分……事实并非如此。 你知道的？如果不保护你的客户，你就没有生意。 我认为这可能是一个年轻的创业公司，10 年前或者 5 年前你没有想到的。 在哪里，我认为每个人都需要开始思考，哦，这是我从我的客户那里收集的数据，我如何保护我的客户？你可能会说，“哦，谁对沃纳在这里租这辆自行车感兴趣？“好吧，你知道，这个数据集加上你可能从其他地方得到的两个其他[听不清]数据集可能对……我认为我们都需要变得非常有安全意识，确保我们能够继续保护我们的客户。 我认为作为年轻的企业，实际上开始丢失客户的数据是很尴尬的。 它会影响到你周围的每个人。 不仅仅是作为客户，它还将反映在其他年轻企业上。 我认为，如果你从客户那里收集数据，如果你有消费者数据，你就有责任保证数据的安全。 你知道，还有一些工具。 这里有加密功能，并为您提供了许多不同的工具，所有这些工具都可以帮助您实现这一点。 但是，你必须牢记这是你的首要工作。 当然，你们都在想“是的，但我们不知道。 我们正在建立这项新服务。 我们正在建立这种新的消费服务。 我们不认为……不，我认为唯一的办法是，如果你真的在不考虑安全的情况下建立新的业务，那么很难将其改造成新的业务。 你会做一个噩梦，比方说，当你成功了，你成长了，你需要改进安全性的两年，三年之后？你会陷入困境。 这也意味着你的开发过程，因为这就是你所要求的，需要改变。 安全性需要成为您的默认部分，例如，持续集成和持续部署管道。 它需要触发事件。 每当你在构建某个东西，并且有人向它添加了一个新的开放源码库时，应该会有人发出警报来检查我们为什么要添加这个库？我们为什么要这样做？我们是从安全的角度来看这个的吗？您的开发管道本身需要是安全的，整个部分需要发出各种警报，安全性需要成为您的首要关注点。 它周围有很多自动化工具。 因此，您可以使用 AmazonInspector 测试各种漏洞，但如果您进行持续集成和持续部署，尤其是在您[听不清]或医疗保健领域。 你要遵守各种规章制度。 你怎么知道你刚刚写的这五行新代码没有违反你的 HIPAA？或者，你仍然遵守金融监管机构对你的任何要求。 我们有各种各样的自动化工具可以持续地为您测试这个，但是您确实需要这样做。 它需要在你的脑海里。 因此，开发，特别是如果它继续部署，就会从我们过去接近安全的方式发生根本性的变化。 现在，我真诚地相信，从安全的角度来看，持续部署实际上更好。 因为在过去，你会写 50000 行代码，安全团队会进来，审查它，祝福它，他们不知道自己在做什么。 愿上帝保佑，50000 行代码，你不知道。 你可以部署它。 更改五行代码？你可以用自动化的过程、自动推理和类似的东西来测试，你实际上正在构建正确的东西。 我认为这是安全方面的巨大进步，我们需要牢记安全。 我希望在五年的时间里，我们不一定都是安全工程师，但我们都非常有安全意识，保护我们的客户将是我们的首要问题。 它在亚马逊。 无论是智力资本还是金融资本，它都将永远是我们的第一投资领域。 如果不保护你的客户，你就没有生意。 > Kyle Corbitt: 除了对安全性不够认真之外，您看到的初创公司在使用 AWS 时是否还有其他常见的错误或错误？ > Werner Vogels: 嗯，首先，我认为有一个技术上的。 我们有相当多的人是第一次使用 AWS，但他们已经有了经验，比如说，构建服务和使用传统的数据中心。 使用 AWS 作为数据中心会使您失去信心。 我认为，是的，它有一些优势，你有一些弹性和你可以利用的东西，但是如果你不使用更高级别的服务，围绕安全，围绕数据分析，围绕移动，所有这些，我们为了大量的高可用性而剥夺了大量的开发。RD，举个例子。 你输了。 如果你只是把它当作一个只有一些虚拟机、数据库和存储的数据中心，那么你的主要生产力的提高就不是从这里来的。 一些，但不是主要的。 其次，更重要的是元级别，你必须弄清楚你是什么样的公司。 我认为有两个不同的公司，两种不同的风格。 其中之一就是你追求高增长，获得大快速类的东西。 尽可能快地获得尽可能多的客户，不必考虑太多的收入，花很多投资者的钱，真正迅速变大，成功，然后可能被收购。 因为这就是人们投资你的原因。 这使得你对 AWS 的使用和你对云的使用非常不同，如果你是……我们非常支持这一点。 因为你不必为获得容量或服务担心太多。 就在那里。 它也有一个清晰的成本图，这是不同的。 或者，如果你想成为一个可持续发展的公司。 基本上，我想建立这家公司，但 30 年后仍在营业。 不一定只关注收购，而只是建立业务。 我想如果你们按照信号 V。 噪音，来自大本营，DHH 和其他人，还有杰森（听不见），他们谈论了很多关于他们想如何继续经营的事情。 他们还想在 10 年，20 年后继续做这个生意。 他们是怎么做到的？这就需要不同的体系结构，它需要更多的成本控制，它需要成本和客户获取之间的明确关联，所以 AWS 也支持这一点，但它需要您构建非常不同的体系结构。 因为你想要更多的控制成本和规模，而不是另一个你不太关心成本，但你更关心我们能不能快速改变，这样我们就能解决客户的问题，因为我们需要快速发展。 杰夫经常区分雇佣军和传教士。 雇佣兵是创业公司的创始人，他们是为了钱。 传教士是为了热爱这个产品而来的。 我想做这个产品。 或者我想做这个生意。 你支持两者，它们都是有效的。 他们都是创业的有效途径。 只是技术支持和你为这些不同群体建立的技术是非常不同的。 所以，弄清楚你是谁。 > Kyle Corbitt: 好吧，非常感谢。 这太棒了，我们学到了很多。 各位，非常感谢 Dr. Werner Vogels.