父母严格教我在年糕店买年糕的日子已经一去不复返了，我以前在书店买书。我从小就在亚马逊上买东西，我敢肯定没有没有听过 AWS 这个词的无知工程师。
基于这样的想法，在线书店如何创建 AWS 等云服务的故事，成为其基础的 Bezos 规则以及之后的过程很有趣。1.而且我认为核心部分会类似于 Azure 服务的核心。这就是故事2.
我有点迷茫，包括结论，但我会给出一次。 （如果你不这样做，你可能会永远拥有它。）所以，请享受这篇文章，认为它可能会在不久的将来进行重大修改。
从贝佐斯定律到 AWS
Steve Yegge 先生，2002 年左右在亚马逊工作。 2011 年的一天，他感叹亚马逊的微观管理，或者更确切地说是其首席执行官杰夫·贝索斯。3，我在想与谷歌的区别。为什么谷歌不能拥有这个平台，而亚马逊可以创建 AWS？推动这一点的是 2002 年左右发布的贝索斯规则。影响似乎非同寻常。
规章制度如下。它经常在其他页面上被介绍，你可能会觉得你已经被介绍了所有东西。顺便说一句，翻译使用了DeepL。
粗略地说，策略是通过 API 做所有事情，但不要犹豫使用任何手段。
- 今后所有团队都将通过服务接口公开他们的数据和功能。
- 团队必须通过这些接口相互通信。
- 不允许其他形式的进程间通信：不允许直接链接，不允许直接读取另一个团队的数据存储，不允许共享内存模型，不允许任何后门。网络。（不允许其他进程间通信。不允许直接链接，不直接读取其他团队的数据存储，没有共享内存模型，没有后门。唯一允许的通信是通过网络。服务接口调用。）
- 他们使用什么技术并不重要。HTTP、Corba、Pubsub、自定义协议——没关系。Bezos 不在乎。Pubsub、自定义协议等。Bezos 不在乎。
)- 所有服务接口，无一例外，必须从头开始设计为可外部化。也就是说，团队必须计划和设计能够将接口暴露给外部世界的开发人员。没有例外。所有服务接口，无一例外，必须从头开始设计为可外部化的，即计划和设计，以便接口可以暴露给外部开发人员。没有例外。）
- 任何不这样做的人都将被解雇。4
- 谢谢您；祝您有美好的一天！5
尽管这封信四处传播，亚马逊内部还是被迫经历了快速的组织变革。里面的人似乎非常非常艰难（我想要人力资源部门的营销数据！即使在这种情况下，我也不必通过电子邮件发送询问。
比如部门间通信API的维护有缺陷，同事的简单查询就变成了DOS攻击，调试别人的代码就变得困难了（还有其他的事情）。就我目前的理解能传达的就这些了，如果你想了解更多，请看原文：史蒂夫的谷歌平台咆哮）。
由于坚持这一点（或者更确切地说，被我们的员工卡住了），亚马逊已经从一个单纯的在线书店变成了一个基于 SOA（面向服务的架构）的组织，结果，它导致了 AWS平台...因此，它所依据的贝索斯定律声名鹊起。
事实上，与当时的其他服务相比，通过 API 操作它似乎是开创性的。
是的，我听说过 Azure，它是松耦合的
当我听说 AWS 时，我想到了松散耦合的概念。
在我们前几天参加的一次活动中，当我们谈到云服务（包括 Azure）的核心是什么时，这个词就出现了。老实说，这是一个我直到那时才知道的概念，但在思考云架构时，它似乎是一个重要的概念。
当我发布它时，我认为它是最新的设计已经过时了！技术发展的速度如此之快，以至于可能会发生这样的悲剧。这就是为什么我们必须从一开始就做到这一点，以便它可以松散耦合并用新部件替换。
我还没有亲眼目睹这种松散耦合的威力，但我希望听到这样的关于 AWS 和 Shibayan 先生的事情，会让我养成用这种想法做事的习惯。我想
我想写一个工程师，但我本来是对组织发展感兴趣的，所以偶尔会写这样的文章。请原谅我。↩
我们公司强烈推荐 Azure，因此 AWS 毫不在意。就个人而言，如果我不知道两者，我认为我无法看到 Azure 的优点。↩
这就像贝索斯是史蒂夫乔布斯，没有时尚和设计感。他们的共同点是他们的管理方法和他们的智慧。 (https://gist.github.com/chitchcock/1281611)↩
根据史蒂夫的说法，这似乎是一种保镖，以确保它真的很彻底。前游骑兵队、前拳击手、前沃尔玛首席信息官瑞克！ (https://gist.github.com/chitchcock/1281611)↩
据史蒂夫说，这是个笑话！我敢肯定贝佐斯不会想到这一点。贝佐斯一定是继承了京都风格、英伦风格，还有这里的幽默风趣（https://gist.github.com/chitchcock/1281611)↩
原创声明：本文系作者授权爱码网发表，未经许可，不得转载;
原文地址：https://www.likecs.com/show-308627808.html