Even Amazon can’t figure out serverless and microservices

The Prime Video team at Amazon published a rather remarkable case study on their decision to abandon their serverless microservice architecture and replace it with a monolith. This move saved them a staggering 90%(!!) in running costs and also simplified the system. What a victory!

But aside from praising their common sense, I think there’s a bigger point here that applies to our entire industry. Here’s what speaks for itself:

“We designed our initial solution as a distributed system using serverless components… In theory, this would allow us to scale each component of the service independently. However, the way we used some of the components resulted in us reaching a hard scaling limit of around 5% of the expected load”.

This really sums up the big microservices craze that has been sweeping the tech industry for a while: THEORETICALLY. Now, finally, the real results of all this theory have been received, and it is clear that in practice, microservices represent perhaps the biggest threat to unnecessarily complicate your system. And serverless only exacerbates the situation.

What makes this story unique is that Amazon was the original example of service-oriented architectures. A much smarter option before the advent of microservices. An organizational template for dealing with intra-corporate tasks on a crazy scale, where API calls trump scheduling coordination meetings.

SOA makes sense on the scale of Amazon. No single team could ever hope to know and understand everything needed to manage such a fleet of supertankers. Getting teams to coordinate their actions using published APIs was a stroke of genius.

But like many good ideas, this pattern became toxic once taken outside of its original context, and caused havoc once it was injected into the internal structures of single application architectures. This is how we got microservices.

In many ways, microservices are a zombie architecture. Another strain of intellectual contagion that simply refuses to die. It’s been eating brains since the dark days of J2EE (remote server beans, anyone??) through nonsense WS-Deathstarand now in the form of microservices and serverless.

But this third wave seems to have finally reached its peak. I wrote an ode to the Majestic Monolith back in 2016. Kelsey Hightower, one of the lead developers of Kubernetes, is great formulated it in 2020:

“We’re going to destroy [монолит] and somehow find the engineering discipline we never had… Now you’ve gone from writing bad code to building bad infrastructure.

Because it brings in a lot of new spending, it brings in a lot of new hires… So a lot of people get addicted to all this abundance of money and marketing, and that’s just the hype that people associate their appointment with, although to be honest, it’s not necessarily solve their problem.”

Bingo. Replacing method calls and module separation with network calls and service separation within a single, consistent team and application is insane in almost all cases.

I’m happy that we fought off the zombie onslaught of this terrible idea for the third time in my memory, but we still need to remain vigilant so that we don’t end up having to do it again. Some bad ideas just refuse to die, no matter how many times you kill them. All you can do is recognize when they rise from the dead again and keep your rhetorical shotgun loaded.