Have you heard the news? Amazon Prime Video has migrated away from microservices to a monolith! Surely if Amazon engineering is eschewing microservices and serverless architectures, we all should do the same and return to the bygone utopia that is the monolith.
But is that what really happened? To be sure, the article lays out some pretty bold statements that, when taken out of context, paint a not-so-rosy picture for microservice and serverless architectures. The most impactful statement is perhaps this one on cost savings and scalability:
Moving our service to a monolith reduced our infrastructure cost by over 90%. It also increased our scaling capabilities.
Even the sub-headline of the article reinforces this narrative:
The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.
Predictably, this set off a torrent of hot-takes and click-bait articles railing against microservices and serverless architectures. …Even the title of this article is admittedly click-baity, but with all the best tongue-in-cheek intentions.
Many thoughtful technologist saw these reactions for what they were and took to Twitter with their own takes. My colleague Darren Shepherd of course did not disappoint:
Kelsey Hightower, as usual, had great insights:
And the always excellent Jaana Dogan shared her insights from her time at AWS, in reaction to speculation that the team in question must have been forced to use Lambda on their first pass:
Not surprisingly, Adrian Cockcroft gives an insightful analysis of how this article should be interpreted holistically. His assessment is that this team “got it right,” by rapidly building the first iteration of their service using a serverless architecture and refactoring when cost and scale became a tangible problem. He also points out that a lot of the negative reaction to microservices is due to the fact they were oversold by vendors looking for a simple marketing message to sell Kubernetes and cloud native technologies.
Of particular interest to me is that the end result of the re-architecture is actually not a monolith at all, but rather a set of services that scale along different lines that originally envisioned. Now, the team is leveraging ECS to basically shard out their detector services, which can then be scaled vertically rather than horizontally.
Another important takeaway for me is that this is not about Prime Video as a whole, but rather one service and one team (the Video Quality Analysis service/team) within a much larger set of services that make up the Prime Video product. I’m speculating a little here, but if we zoom out, I suspect we’ll see that Prime Video very clearly has a service oriented architecture, with the boundaries of those services aligning with the teams owning them. When an organization architects its services to align with team boundaries, the true power of microservices is realized and this article is a great example of that. The VQA team fully owns this service and was able to completely rearchitect it while the rest of product team happily continued on with minimal impact. That is the holy grail of large engineering teams!
I’d like to close by giving huge props to the Prime Video engineering team for sharing their journey and insights. There’s a lot to be learned here and much to think about.