On Amazon Prime Video’s move to a monolith
Last week an article about how Amazon Prime lowered their monthly AWS costs by 90% by shifting part of their system called VQA (Video Quality Analysis) away from a server-less micro-service architecture to a monolith server.
I want to warn my readers about reading too much into it regarding cloud costs. Please don’t take this article as proof that servers are cheaper and serverless is not. This conversation is not about cloud vs. on-premise; the broader message is that micro-service architectures are costly and overcomplicated.
There is nothing fundamentally wrong with a monolith, and a well-architected monolith with well-structured code with separation of concerns serves its purpose quite well. If Amazon Prime’s experience proves anything, it is that when the granularity of services is too fine, complexity and costs skyrocket.
As an architect, I need to worry about many things: the application needs to work, it needs to scale, and developers need to be productive. When left to their own devices, developers gravitate towards monoliths for a straightforward reason: they can run the entire application stack in their development environment and, most importantly, step through it in a debugger end-to-end. A monolithic repository (aka monorepo) can answer all architectural concerns, starting with developer productivity and to deployment and scalability.
Most importantly, just because someone from Amazon (or Apple, or Facebook, or Google, or Microsoft) said they do things a certain way, it does not mean you should drop everything and do things the same way. My number one rule of software architecture is “Don’t shakespearize!”.
I’ve written on this subject over the years. Here are my other ruminations on micro-service architectures:
- Best (for me) practices for building a micro-service architeceture
- Why you should question the “database per service” pattern
- A monolithic repository vs. a monolith