AWS CEO Andy Jassy亲述：AWS如何诞生

亚马逊网络服务( AWS )是一个网络平台，它为Netflix、Slack和NASA等公司提供各种服务。AWS于2006年正式推出，它最初是一套包括存储、数据库和其他产品的服务，允许任何人在不购买服务器等物理硬件的情况下构建互联网应用程序。

现在AWS变成了亚马逊的提款机。2018年全年，AWS营收高达256亿美元，运营利润达到73亿美元，几乎亚马逊公司全部利润都来自AWS业务。

《纽约杂志》intelligencer栏目2018年11月26日刊登了对AWS CEO Andy Jassy的采访。他亲自讲述了AWS诞生的过程，以及早期开展这项业务过程中的经验教训。

AWS CEO Andy Jassy：AWS如何诞生

从2000年到2003年之间，我们都在考虑和筹划，这些后来被称作AWS的事情。

当时，我们增加了很多软件开发工程师，但是开发软件项目所花费的时间却跟以前一样多。

开发团队一直在告诉管理层，如果他们有更多的人手，他们就可以更快地交付产品，但是事实却不是这样。

当时，我是亚马逊CEO杰夫·贝佐斯(Jeff Bezos)的幕僚长（或者办公室主任），于是就跟开发团队的管理层们谈话。

他们对我说：“你认为，这些工程只需要2到3个月就能搞定，但实际上我们2-3个月只能完成存储、数据库或者计算中的其中一项。”

最初，他们觉得自己在为每个项目重新发明轮子（意指做一些重复无用的工作）。

但事实是，这件事情对亚马逊而言很有意义：我们内部很渴望打造出来可靠、可扩展并且高性价比的基础设施服务。即便没有后来的AWS作为独立业务向第三方开放，我们仍然会构建这些服务，因为这可以让公司业务运转得更快。

2003年夏天，我们在贝佐斯家里开了一次会。大家伙一起讨论，亚马逊公司的核心竞争力是什么。当然，我们从最明显的事情开始，比如我们在零售行业很在行。

但当我们更深入地研究的时候，我们意识到，在亚马逊建立消费者业务的8年过程中，我们实际上非常擅长运营基础设施服务，比如计算、存储和数据库。

由于亚马逊的零售业务利润非常低，我们必须非常擅长运行可靠、可伸缩、成本低廉的数据中心，然后以合适的规模和价格运行它们。

在这次讨论中，我们在白板上写了几条核心优势。第一栏，列出了我们为消费者提供的所有服务。第二栏，我们列出了为卖家提供的服务，如何让卖家在亚马逊上销售产品或者提供电子商务技术服务。考虑到我们对基础设施方面的信心，我们增加了第三栏：开发者和企业。

我们问自己：如果你相信有公司会使用这些基础设施服务从头构建应用程序，那么这会不会形成一套互联网操作系统。如果你相信存在一套互联网操作系统，那么它的关键组件会有哪些呢？

2003年夏天讨论这个问题的时候，我们发现还没人为这套互联网操作系统构建核心组件。但是我们认为，我们正好非常擅长这个，可以打造所有的核心组件。因此，我们决定去研究一下，打造一个可以开发科技应用的基础设施平台是不是能成为一项生意。

当时，我们的主要争论是，我们中的一些人说:“这跟我们的其他业务有很大的不同，为什么我们不先建立一个类似存储服务的东西，看看是否有人会使用?”如果有人用，我们可以再考虑建立其他服务。但是AWS团队强烈认为，我们要么构建一个平台，要么就不干这事。

实际上，每个应用程序都需要计算服务器、存储、数据库、消息传递或分析，如果我们希望实现最终目标——让开发人员比以前更快地构建应用程序——那么只提供一个组件并不能解决问题。我们还认为，如果等待市场反馈，那么打造这个平台可能就要推迟上几年时间。

整个辩论发生在持续4个小时的高层会议上，我们不得不仔细审查是否做AWS的提案。最后，大家达成了足够的共识，那就是——如果我们要下注，我们不妨下个大赌注。

我要告诉你们的是，在那次会议上我们决定真正去打造这个平台之后，我们花了两到三年的时间才真正推出了第一个服务。

之后有很多次我们问自己，“人们会从我们这里购买存储空间吗?人们会从我们这里购买计算服务吗?人们会从我们这里购买数据库服务吗?或者我们应该是否应该专注于开发我们知道人们会使用的电子商务技术?”

但我们相信，如果想要在基础设施技术平台领域占领先机，我们必须首先进入这个市场。

人们并没有想到它会来自亚马逊。我想大多数人都会认为，它最可能来自那些老牌的科技公司。

我是少数几个始终坚信要么构建一个平台，要么不构建它的人之一。但是需要承认的是在打造这个平台的前2年，我晚上回到家，妻子问我工作如何时，我的回答是：我花了很多时间听那些非常聪明的人质疑我们是否应该收敛一下野心，我花了很多时间去说服他们要追求更大的机会。她就会接着问我：“你确定能成功吗？”而我会回答：“我不知道，我确实也不确定。”

你在追求一项新事物的时候，并不会所有人都能理解你。但是加入亚马逊之前的创业经历以及在亚马逊的工作经历告诉我，当你尝试做一件新事情的时候，花很多时间去思考它是否会成功，这真得是在浪费精力。我们需要把精力放在我们需要构建的东西上，而不是怀疑它是否会成功。

我们仔细评估了AWS的各种可能性。在亚马逊内部，我们不会为新兴事物设定一定要达到什么指标，因为很难知道人们是否会对这些新鲜事物有反应。

相反，我们会问一系列问题：如果我们成功了，能做大吗？我们还有其他的路径可选吗？今天提供的服务好吗?我们是否有能力在这一领域更有见识?

如果我们喜欢这些问题的所有答案，那么我们就分配一个单独的团队来处理它，这个团队不受其他业务的牵绊。否则的话，如果你用一个已经很忙的团队来执行这项计划，那么这个计划在时间和优先级方面肯定要输给那些前景确定的业务。

我们喜欢这些问题的所有答案。但我们也做了评估，如果我们完全错了，没有人使用AWS，那么损失有多大。我们雇佣了57个人，投入了一些资金，此外还得考虑项目失败没法收回投资的问题。

但是我们确信有很多这样的需求，因为在亚马逊内部，对开发工程师而言这是一个真实存在的问题。如果亚马逊遇到了这个问题，其他人也会遇到，这是理所当然的。即使我们一开始没有做对，我们也可以通过迭代开发来找到有价值的东西。

在亚马逊，我们对大的战略赌注非常关注，我们会不断地坚持，直到发现与客户有共鸣的东西。所以AWS不是一个测试，即使早期没有人使用它，我们也会尽力去做。我们确信有什么东西在那里，我们会在它上面重复几年，直到我们发现一些人们认为有用的东西。

我们在构建AWS业务的过程中学到了很多东西，而且每个月的收获都在增加。最好的教训之一就是拥有正确的人和正确的领导者非常重要。虽然这句话看似平常，但是是否遵照，结果大不同。

另一个教训是，当你很早就知道人选不合适的时候，你总是要花很长来做出改变。这是人性，因为你关心别人，你希望你能改变他们。但大多数时候，当你发现人选不合适之时，你通常要等上6到12个月，有时甚至更长时间，才能做出改变。一定要让有才能的人处在他们最适合成功的位置上。

在AWS发展早期，我经常觉得自己会有问题，或者会发现一些看起来不太正确的东西，但是我害怕问一些愚蠢的问题，所以不敢说出来。后来，在这个过程中，我们发现这确实是个问题，我本可以为团队节省很多时间。

对我来说，不用担心问愚蠢的问题是一个很好的教训。有时候，团队在一起工作的时间太久了，想法常常相同。如果有人问一些跟业务不那么相关的问题——如果有明显的答案，他们会在30秒内得到答案，但有些时候，这些问题可以让你抓住一些团队想不到的东西。