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.
Should I switch?
So, the takeaway might be that if you're using microservices, it's worth considering consolidating them into a monolith, right? Well, not so fast. In this case, the optimization was evident. Netflix serves as an example. In 2008, they experienced a massive failure with their monolithic architecture, prompting them to break it into hundreds of microservices for independent scaling and fault tolerance. While it may be more complex and expensive, the consequences of a Netflix outage far outweigh those for small businesses.
Fallacies of distributed computing
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:
"David Guetta moves from EDM to playing a grand piano." Microservices represent an architectural style, just as EDM represents a music style. Monoliths are an architectural approach similar to a grand piano. Moreover, the intention behind this statement seems to suggest that the Prime Video team is retracting their previous stance and admitting that the monolithic architecture would have been a better choice from the beginning.
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.
We’re confident we can supercharge your software operation. Our unique products and services will delight you.