Recently, Amazon Prime Video published a surprising article revealing how they saved 90% on their Amazon Web Services bill by transitioning from serverless microservices to a traditional monolith architecture. This is great news for Amazon as it will result in cost savings. However, it’s also bad news as Amazon Web Services (AWS) loses a valuable revenue source. The article has sent shockwaves through the tech industry. Here at ZEN, we are sceptical about changing all your microservices architecture back to big monoliths, but we do see an interesting feature of monoliths that has been ‘thrown out with the bathwater’

I appreciate Amazon's transparency in sharing this information. They have been pioneers in serverless microservices with Lambda functions. Nowadays, numerous platforms like Netlify offer serverless services, which are essentially reselling AWS services behind the scenes. However, not everyone is sold on serverless. David Heinemeier Hansson (DHH), the creator of Ruby on Rails and Basecamp, has been advocating for majestic monoliths for the past decade. His company even moved away from the cloud after spending over three million dollars in one year, choosing to run their own servers.

The difference between a microservice and a monolithic architecture is evident at Prime Video. They required a tool to analyze audio content, including issues like video freezing and corruption. To achieve this, they used multiple serverless functions called Step Functions, which are similar to Lambda functions, to handle different responsibilities. The process involved an initial entry point triggering another service for file conversion, multiple detectors utilizing machine learning to analyze the video, and a final function to aggregate the results and store them. However, passing data between services incurred overhead due to serialization, deserialization, and network communication.

Their service needed to run a video stream multiple times per second, leading to account limits and bottlenecks. Uploading files to Amazon S3 storage temporarily resulted in high costs for accessing these files in the storage buckets. Recognizing that the distributed architecture caused these bottlenecks, they made a bold decision to re-architect to a monolith. Instead of running decoupled distributed services, they consolidated everything into a single container. Although scaling is now limited to vertical scaling only, meaning larger servers for more work. This approach to scaling for amazon prime video eliminated unnecessary communication and network usage, resulting in a 90% cost reduction. Considering the scale of their product, this translates to millions of dollars saved.

Decentralization and centralization are perpetual and dynamic forces in various systems, including computing and governance. They are constantly in motion, adapting to the needs and challenges of different contexts. However, it is crucial to acknowledge the fallacies of distributed computing that have persisted since the 1980s and are unlikely to change. These fallacies include 1) The assumption that the network is reliable when in reality, network failures and latency issues can occur; 2) The belief that network latency is zero, whereas in practice, delays are inherent due to distance, congestion, and other factors; and 3) The misconception that bandwidth is infinite, despite the limitations imposed by physical infrastructure and competing demands. Recognizing these fallacies is essential to navigate the complexities of distributed systems effectively and to making informed decisions about decentralization and centralization based on realistic expectations.

I have my doubts about how applicable this switch is to all microservices environments. It may be comparable to saying:

It is unlikely that the statement praises the remarkable achievement of the Prime Video team in designing their service to adapt to a changing environment, which has garnered widespread attention in their blog post. Instead, it emphasizes their decision to revert to a monolithic architecture rather than highlighting their ability to revert in the first place.

To all the critics, I urge you to examine your own architectures and determine whether you have the capability to change them without your users noticing completely and if you feel confident enough to share your experience through a blog post. Ultimately, cloud architecture involves trade-offs rather than definitive solutions.