The Software Industry’s Big Dilemma: Centralized or Decentralized ? Microservices to Monolithic
Last week, there were fierce discussions in the software world to switch from microservices to monolithic architecture. In this article, we will examine what happened last week and examine where the industry is heading.
What happened ?
Everything starts with this article: Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%.
A Prime Video team at Amazon has published a rather remarkable case study on their decision to dump their serverless, microservices architecture and replace it with a monolith instead. This move saved them a staggering 90%(!!) on operating costs, and simplified the system too. What a win!
The initial architecture relied on serverless components such as AWS Step Functions and AWS Lambda. However, this approach led to scaling limits and high costs due to state transitions and the high number of Tier-1 calls to the S3 bucket for video frame storage.
To address these issues, the team decided to rearchitect their infrastructure, moving from a distributed microservices approach to a monolith application. This allowed them to eliminate the need for the S3 bucket as intermediate storage for video frames and implement internal orchestration within a single instance using Amazon EC2 and Amazon ECS.
By moving to a monolith, they reduced their infrastructure costs by over 90% and increased their scaling capabilities to handle thousands of streams. The new approach allowed them to use Amazon EC2 compute saving plans, further driving down costs.
The takeaway from this case study is that microservices and serverless components can work at a high scale, but the decision to use them over a monolith should be made on a case-by-case basis. In Prime Video’s case, moving to a monolith architecture led to significant cost reductions and improved scalability.
The software industry is shaken
With this article, The software industry is totally shaken. Kelsey send tweet series about this article: https://twitter.com/kelseyhightower/status/1654098279116992513
And continues with:
Kelsey highlights the key points from the Amazon Prime Video team’s experience of reducing costs and improving scalability by moving from a serverless, microservices architecture to a monolithic one.
- He emphasizes that the shift isn’t a criticism of AWS Lambda, as it helped the team build the service quickly and enter the market.
- He points out that the overhead and underestimated costs of moving data around in microservices can be a significant issue in real-world scenarios.
- He reminds that a monolithic architecture doesn’t imply a spaghetti codebase; modular code should be written regardless of the deployment model.
The primary message is not about choosing microservices vs. monoliths but rather selecting the right tool for the job based on specific use cases. The choice between microservices and monoliths should be made on a case-by-case basis, considering the specific requirements, costs, and scalability factors of a project. With these tweet series we remembered the posf of Kelsey at 2020:
What DHH Said ?
DHH is Creator of Ruby on Rails, Co-owner & CTO of 37signals (Basecamp & HEY). At 2016, He has published a famous article:
In his article of “The Majestic Monolith”, DHH argues that for small teams without the resources of tech giants like Amazon or Google, embracing a monolithic architecture can lead to more efficient development and maintainable code. He presents Basecamp as a case study, demonstrating how a small team was able to create and maintain a large application across multiple platforms using a monolithic architecture. DHH contends that a majestic monolith, built with intent and pride, can help teams write beautiful, understandable, and succinct code that is easier for individuals to comprehend and modify.
Last week, DHH published 2 new article about this Microservices to Monolithic issues:
He obviously disagree to Microservices idea for decade:
DHH argues that the microservices trend, which works well for large organizations like Amazon, often leads to unnecessary complications in smaller-scale applications. The shift away from microservices and serverless is a positive development, as these approaches often result in bad infrastructure and increased spending without solving the underlying issues. DHH calls for vigilance in recognizing the resurgence of such detrimental ideas in the tech industry and maintaining a rational approach to system architecture;
I’m happy that we beat back the zombie onslaught of that terrible idea for the third time in my living memory, but we still need to stay vigilant that we’ll eventually have to do it again. Some bad ideas simply refuse to die no matter how many times you kill them. All you can do is recognize when they rise from the dead once more, and keep your retorical shotgun locked and loaded.
What “Werner Vogels — The CTO of AWS” said ?
Building evolvable software systems is a strategy, not a religion. And revisiting your architectures with an open mind is a must.
He said there is no one-size-fits-all approach to software architecture, and it’s essential to have an open mind and choose the best solution for each specific situation. He emphasizes the importance of evolvable architectures that can adapt and change over time as the system grows. While event-driven architectures and microservices can offer benefits, sometimes a monolithic architecture may be the most appropriate choice depending on the product, team skillset, and desired customer experience. The article encourages regularly evaluating systems, considering different architectural patterns, and making well-informed decisions to best meet the needs of the project and its stakeholders.
The Code Report — Serverless was a big mistake… says Amazon
In YouTube, Fireship publish a great video about this debate and asking about “Serverless was a big mistake… says Amazon”.
It’s May 6, 2023, and in the Code Report, it’s highlighted that serverless is considered the biggest lie in the history of computers. The term “serverless” is misleading as it still involves using a server, but it’s not owned by the user. Amazon Prime Video recently published a shocking article explaining how they saved 90% on their Amazon Web Services bill by switching from serverless microservices to an old-fashioned monolithic architecture.
Serverless is Dead ? What happened “serverless-first” approach ?
It’s not accurate to say that serverless is dead. Rather, serverless is not a one-size-fits-all solution, and it may not be suitable for every use case or organization. The “serverless-first” approach remains a viable option for certain applications and scenarios, particularly when rapid development and deployment are crucial.
The key benefit of starting with serverless services is that it allows organizations to focus on developing features and functionality without worrying about server management. This can lead to faster time-to-market, as developers can build, test, and deploy applications more quickly. Serverless architectures also offer scalability and cost savings since organizations only pay for the compute resources they actually use. Kelsey also emphasis faster time-to-market with serverless:
However, as demonstrated by the Amazon Prime Video example, serverless might not be the best choice for every situation, and sometimes a monolithic or other architecture may be more efficient and cost-effective. It’s essential for organizations to evaluate their specific needs and requirements when choosing an architectural approach.
“Yan Cui — AWS Serverless Hero” Explain the situation with numbers
Yan Cui, in his series of tweets, emphasizes that the choice of technology in a system should depend on the specific requirements and traffic demands of different parts of the system.
He shares DAZN’s experience, where critical services with high traffic and scaling demands were run on containers due to Lambda’s scaling limits, while other services with lower traffic demands used Lambda and Step Functions. He highlights the benefit of a microservices architecture, which allows each team to choose the appropriate technology based on their needs.
He points out that people should not assume the discussed article covers the entirety of Prime Video’s system. It’s about a specific part of the system, and other parts might still use microservices and serverless components.
Yan emphasizes that starting with a serverless approach to quickly go to market and later pivoting to containers when the costs become too high is a practical way to build and scale a system.
So, Yan Cui underscores the importance of choosing the right technology for different parts of a system based on their specific requirements and stresses the value of a “serverless-first” approach that allows for fast development and scalability adjustments as needed.
What about Scalability ? Vertical scale better then Horizontal Now ? Return back to Vertical Scale Isn’t has limitations ?
Scalability is an essential aspect of any software architecture, and both vertical scaling and horizontal scaling have their advantages and limitations. The choice between the two depends on the specific requirements of an application.
Vertical scaling, also known as scaling up, involves adding more resources to a single server (e.g., increasing CPU, memory, or storage). This approach can provide quick performance improvements, but it has its limitations. At a certain point, adding more resources becomes expensive, and there may be physical or technical constraints on how much a single server can be scaled.
Horizontal scaling, or scaling out, involves adding more servers to distribute the workload. This approach is more commonly associated with serverless and microservices architectures, which can offer better scalability and flexibility compared to monolithic applications. However, as the Amazon Prime Video case study showed, serverless and microservices aren’t always the most cost-effective or efficient solutions for every scenario.
We all learned about the limitations of Vertical scaling and at some point we should shift the architecture to microservices in order to get benefits of horizontally scaling. With this Prime Video team’s article, now we have a big question:
- How did the Monolithic improve the scaling over AWS Lambda functions?
While monolithic applications may seem less scalable than serverless functions, they can still be designed to scale effectively. By using techniques such as caching, load balancing, and database sharding, monolithic applications can achieve improved performance and scalability. Moreover, modern cloud infrastructure can enable monolithic applications to scale both vertically and horizontally, depending on the specific use case and requirements.
But we still can say that serverless functions has great scalability. Here you can see Yan explained it:
In summary, both monolithic and serverless architectures can be scalable, and the choice between vertical and horizontal scaling depends on the application’s specific needs. It’s essential to consider the trade-offs and evaluate which approach best suits the system being developed.
Cycling Hype of Software Architecture Patterns: Monolithic to Microservices
Software architecture hypes, such as the one around microservices, often stem from the continuous search for improved solutions to address the challenges of software development and maintenance. As new technologies and approaches emerge, they can quickly gain popularity and become the latest trend. However, these hypes often create cycles of shifting between different architectural approaches as the industry tries to determine the best practices for various situations.
The microservices hype emerged as a reaction to the perceived limitations of monolithic architectures. Microservices promised increased scalability, flexibility, and faster development by breaking down large applications into smaller, independent services. However, microservices also come with their own set of challenges, such as increased complexity, higher operational costs, and the need for robust communication and coordination between services.
Over the years, the IT industry has gone through several cycles of centralizing and decentralizing architectural decisions. Centralized architectures typically involve monolithic applications or a small number of large services that handle various tasks, whereas decentralized architectures like microservices promote a more distributed approach with many small, independent services.
What is Next Big Thing in Software Industry ? Industry deserves a new Hype Buzzyword Architecture: Megaservices ? Macroservices ?
If microservices is not hot anymore, the software industry requires a new hype buzzword architecture style, even it could be an existing architecture for decades, we need a new naming. Here you can find DHH recommendation:
What about Serverless Monolithic ?
Here you can see that Kelsey go one more step and offers that if we follow Modular Monolithic Architecture and build on Serverless and fully managed components, this would be prefect architecture most of software projects.
The key takeaway is that there is no one-size-fits-all solution for software architecture. It’s essential for developers and architects to critically evaluate the trade-offs and requirements of each project and make well-informed decisions about the most suitable architecture. The cycle between centralization and decentralization is likely to continue, as the industry learns from its experiences and adapts to new technologies and challenges.
What’s Next ?
- Microservices Killer: Modular Monolithic Architecture
- Macro-services to Nano-services: Evolution of Software Architecture
- Microservices Architecture: Problems and Solutions with Pattern and Principles
Step by Step Design Architectures w/ Course
I have just published a new course — Design Microservices Architecture with Patterns & Principles.
In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.
