亚马逊Prime Video团队的一项案例研究引起了开发者社区的惊讶和娱乐，因为它坦率地评估了通过从微服务架构转向单体架构来节省成本，并避免使用昂贵的服务，如AWS Step Functions和Lambda无服务器函数。
该要求是创建一个监控工具，以识别“每个客户观看的流”中的质量问题，因此需要高度可扩展，因为“有数千个并发流”。团队最初使用由AWS Step Functions编排的分布式组件创建了一个解决方案，这是一种基于状态机和任务的无服务器编排服务。然而，结果表明Step Functions是一个瓶颈。
“我们的服务为每秒的流执行多个状态转换，因此我们很快就达到了帐户限制。此外，AWS Step Functions会按状态转换收取用户费用，”该论文称。还有一个“成本问题”，即对用于临时存储捕获的视频帧的S3存储桶的“高数量的一级调用”。
“我们意识到，在我们特定的用例中，分布式方法并没有带来很多好处，因此我们将所有组件打包到一个单独的进程中，”该论文继续说道，消除了对S3的需求。“我们还实现了编排，以控制单个实例内的组件。”现在，该解决方案在EC2（弹性计算云）和ECS（弹性容器服务）上运行，具有“轻量级编排层以分发客户请求”。
该论文得出结论：“微服务和无服务器组件是在高规模下工作的工具，但是否使用它们来代替单体架构必须根据具体情况进行决策。将我们的服务转移到单体架构中，将我们的基础设施成本降低了90%以上。它还增加了我们的扩展能力。”还提到通过EC2节省计划来降低成本，这表明即使是AWS内部客户也按照与我们其他人类似的模型计费。
“我有点惊讶这篇文章存在，”Hacker News上的一条评论说。在其他地方，AWS经常宣传微服务和无服务器架构作为“现代化”应用程序的最佳方式。例如，在可靠性方面，AWS“良好架构框架”建议：
“使用面向服务的架构（SOA）或微服务架构构建高度可扩展和可靠的工作负载。面向服务的架构（SOA）是通过服务接口使软件组件可重用的实践。微服务架构进一步使组件更小、更简单。”
在这份“AWS指导性指南”文件中，用于现代化.NET应用程序，该公司引用了微服务的好处，包括更快的创新、高可用性和可靠性、增加的敏捷性和按需可扩展性、现代化的CI/CD（持续集成和部署）管道以及强大的模块边界；尽管它也引用了“操作复杂性”作为一个缺点。
然而，这篇新论文似乎证实了开发人员的一些怀疑。其中一个是AWS推荐的解决方案可能不是最具成本效益的，因为它们总是涉及使用多个昂贵的服务。
另一个怀疑是，微服务与单体应用程序的优点经常被夸大了。Ruby on Rails的创造者、云服务使用减少的倡导者David Heinemeier Hansson在评论亚马逊案例研究时说，这“真的总结了一段时间内席卷技术行业的微服务热潮：在理论上。现在所有这些理论的实际结果终于出现了，很明显，在实践中，微服务可能是不必要地复杂化系统的最大警报。而无服务器只会让情况变得更糟。”根据Hansson的说法，“在几乎所有情况下，用网络调用和服务分区替换方法调用和模块分离，而这些都在一个连贯的团队和应用程序中，是一种疯狂的做法。”
2020年，顾问和书籍作者Sam Newman在一次开发者会议上表示，“微服务不应该是默认选择”，并在对The Register的评论中向软件架构师提供了建议，“你做了一些价值链分析吗？你看过瓶颈在哪里吗？你尝试过模块化吗？微服务应该是最后的选择。”
Newman今天在Twitter上指出AWS的论文：“这篇文章实际上更多地讲述了函数与长时间运行的虚拟机之间的定价模型，而不是其他任何事情。尽管如此，这仍然是一个完全合理的架构驱动因素，但由于这个案例研究的经验教训可能具有更狭窄的适用范围。”他补充说，“人们不公开谈论撤回他们进入微服务领域的原因是，有些人可能认为‘他们错了’。当情况发生变化时改变你的想法是完全理智的。”
这篇论文对AWS来说不一定是坏消息。一方面，它与云巨头通常认为的最佳实践相悖；另一方面，它是一个清新而诚实的观察如何通过简化架构降低成本的案例研究，同时也是一个愿意改变方向的案例研究。与许多推广性的案例研究不同，这个案例研究看起来对AWS的客户真正有用。
