亚马逊 Prime Video 团队从 serverless 架构迁移到 monolith，为什么他们要这么做?

本篇最早收录于《ExplainThis 全端双周报》第 1 期

这周亚马逊的 Prime Video 团队发表了一篇新的技术文章《Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%》，在文中描述它们如何透过把架构从 serverless 迁移到 monolith 来节省 90% 的成本。这件事在社群中掀起极大的讨论，因为这几年的架构趋势都是往 serverless 靠拢，但是没想到有团队反而选择从 serverless 迁移到 monolith，而且还因此更省成本。

非常推荐大家读一下原文。在读这篇原文时，有几个我们认为值得思考的点。首先，架构方式没有绝对的好与坏，而是有其适用的场景。在文中有提到，该团队最开始选择 serverless 的架构让他们能够非常快速开始专案，因此不能说最开始的架构选择是错的。只是随着系统的使用量增加，该团队意识到原本的架构变得不是最佳的形式，因而决定调整架构。

在真实世界的系统设计，很难真的在一开始就预知未来会发生的事，因此适时回头检视既有架构是否需要被重构，是非常重要的。没有所谓完美的系统设计，只有最符合当下阶段与情境的系统设计，该团队的例子给了一个非常好的示范。

此外，在真实的系统设计中，成本永远是一个重要的考量。而用 serverless 架构代表在分散式的元件之间有更高的资料传输成本，所以该团队的高吞吐量使用情境下，若把这些元件从分散式改到单一进程的 monolith 当中，能大幅降低传输资料的成本。但不是所有团队都会遇到像这个团队在的情境，以及不是系统中的所有元件都有这种特性。因此实际的作法，可能会是有高运算与吞吐需求的子系统，放到 monolith 当中，而其他子系统维持用 serverless 的方式。