Amazon 的 Prime Video 团队发布了一个相当出色的案例研究，说明他们决定放弃无服务器的微服务架构，并用单体取而代之。此举为他们节省了惊人的 90%(!!) 运营成本，并简化了系统。真是一场胜利！
但除了庆祝他们的明智之外，我认为这里有一个更重要的观点适用于我们整个行业。这是有说服力的一点：
”我们将最初的解决方案设计为使用无服务器组件的分布式系统……理论上，这将使我们能够独立扩展每个服务组件。但是，我们使用某些组件的方式导致我们达到了大约 5% 的硬扩展限制的预期负载。”
这确实总结了一段时间以来席卷科技行业的微服务热潮：理论上。现在，所有这些理论的真实结果终于出现了，很明显，在实践中，微服务可能是最大的警示：因为它不必要地使您的系统复杂化。无服务器只会让情况变得更糟。
这个故事的独特之处在于，亚马逊是面向服务架构SOA的原始典型代表。在微服务之前更合理。当 API 调用超过安排协调会议时，用于处理疯狂规模的公司内部通信的组织模式。
SOA 在 Amazon 的规模上非常有意义。没有任何一个团队能够希望知道或理解驾驶这样一支超级油轮舰队所需的一切。
通过已发布的 API 让团队协调是一种天才之举。
但是，与许多好的想法一样，这种模式一旦在其原始环境之外被采用，就会变得有毒，一旦被推入单一应用程序架构的内部，就会造成严重破坏。这就是我们获得微服务的方式。
在许多方面，微服务是一种僵尸架构。
有些坏主意不管你杀多少次都不肯死。
本文作者DAVID HEINEMEIER HANSSON：Ruby on Rails的创造者
网友评论：
1、微服务和无服务器组件是可以大规模工作的工具，但是否要在整体上使用它们必须视具体情况而定
2、我一直将此称为“过早解耦”：在没有透彻了解问题领域的情况下进行技术解耦，本质上导致本应具有内聚性的代码变得复杂。
3、Amazon 的 Prime Video 团队管理的是大规模实时帧处理。我不认为这反映了绝大多数工作负载。
这是一个特殊的服务，我认为是不能与大多数项目比较。在亚马逊他们这种情况下，处理视频和在服务之间移动大量数据可能不是扩展的方式，但这并不意味着面向服务的体系结构无效
4、解决方案应该在我们试图解决的问题的背景下进行评估。DHH这篇文章并不是说无服务器是坏的，它谈论的是是关于-对特定领域的深入理解可以帮助为给定的业务问题确定更合适的技术解决方案
5、无服务器可以提高生产力。让你的代码成为一个可以通过各种触发器（push to queue、cron、http调用、step函数）执行的简单函数，可以说让你少担心一些基础设施（这是微服务的一个大问题）
6、Rails社区一次又一次地做出的决定显示出了良好的判断力，这让人感到温暖
7、这取决于你的团队和产品的规模。在一个庞大系统中只有一个开发团队是不可扩展的。并发更改和冲突的数量将影响可靠性。微服务迫使团队彼此解耦。
banq：微服务与单体的判断选择取决于观察者的角度，如果你能靠一个团队搞定所有功能，那么单体就很好，如同使用RoR那样，习惯了RoR的人都有喜欢掌控全局 追求高确定性的倾向；否则，承认你自己和你团队能力有限，把自己从上帝至高位置放下来，做好几个微服务功能就已经很了不起了。