The toxicity of Microservices, and how to recover from this madness

As a leading technologist and some one with strong public opinions, David Heinemeier Hansson (or DHH) is no stranger to causing a kerfuffle in the interwebs. The last time this happened was around this screed in defense of working from an office.

This time it's about the 'microservices' fad. Amazon published a wonderful case study on how they scaled up Prime Video infrastructure and saved about 90% of their costs. The folks at Amazon Primve Video admitted openly, what was all along whispered in the corridors of several tech driven companies - microservices can deliver the promised goods only in contexts which makes sense for their implementation, which can pretty much be applied for any concept of technology architecture. In Amazon's own words:

We designed our initial solution as a distributed system using serverless components (for example, AWS Step Functions or AWS Lambda), which was a good choice for building the service quickly. In theory, this would allow us to scale each service component independently. However, the way we used some components caused us to hit a hard scaling limit at around 5% of the expected load. Also, the overall cost of all the building blocks was too high to accept the solution at a large scale.

Here's DHH piling on this admission from Amazon:

...it's clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse.

What makes this story unique is that Amazon was the original poster child for service-oriented architectures. The far more reasonable prior to microservices. An organizational pattern for dealing with intra-company communication at crazy scale when API calls beat scheduling coordination meetings.

Reading Amazon's case study and DHH's post took me back to my own experiences of how serverless distributed systems were force fitted into several products I had worked on - for a variety of reasons (I have heard words thrown around like 'this promotes headless architecutre', and 'we can lift and shift from AWS to Azure' and 'this isn't the 2000s' and much more nonsense). Microservices (and much of distributed architecutre) are yet another example of 'the next big thing' catching the attention of consultants, which drove a lot of money followed by a lot of hiring ultimately resulting in a lot of decisions going this way (neatly summed up by Kelsey Hightower here).