Amazon is abandoning microservices?

While different companies are breaking down monoliths into microservices, some are doing the exact opposite. It would be easy to dismiss it if an unknown company went against the trend, but when we talk about Amazon's experience, ignoring it would be strange. We noticed this case after it was published on the blog of David Heinemeier Hansson, the author of Ruby on Rails. By the way, we interviewed him, and you can find it on our website.

The Amazon Prime Video team decided to completely abandon the microservices architecture and replace it with a monolith. The results were staggering—they managed to save almost 90% of operational costs, and the system became simpler. It sounds surprising because their infrastructure was initially designed as a serverless solution with the aim of independently scaling each component. However, they reached a hard scaling limit in the process, and the cost of the components would have been unreasonably high.

The service they were building consisted of three main components: a media converter, defect analyzers, and a stream orchestrator to manage all this chaos. The first mistake was handing over the orchestration to AWS Step Functions. To work efficiently, it required several state transitions per second for each stream. Soon they hit the account limit and incurred high costs since there is a fee for each transition.

The second problem was even more interesting. Each defect analyzer was implemented as a microservice using AWS Lambda to process frames. These frames were prepared by another microservice, which broke down the video and temporarily uploaded the resulting images to AWS S3 object storage. While everything worked fine, the number of calls to the corresponding S3 bucket was huge and costly.

All of this, combined with the complexity of the system they built, made the engineers realize that in their case, the microservices architecture was redundant and didn't provide any significant advantages. By packaging all the mentioned components into one process, they achieved high speed as data exchange happened in memory. It also allowed them to get rid of the S3 storage as a temporary buffer. Conceptually, the architecture remained the same, but now orchestration was performed for only one instance instead of many.

These significant changes, of course, affected scalability. Previously, each detector worked separately and could be horizontally and vertically scaled. With the new system, horizontal scaling was not possible, and only vertical scaling remained, which is not infinite for each instance. To address this scenario, a solution was devised with service cloning and allocating only the required types of detectors.

According to DHH, in many ways, microservices are zombie architecture that has become toxic. Replacing method calls with network calls and dividing services within a single coordinated team almost always becomes a crazy venture. It's not guaranteed that microservices will solve the client's problem, but they can definitely do harm.