Amazon switching back to monolith architecture

Amazon's Prime Video team recently switched from a serverless, microservices architecture to a monolith and saved 90% on operating costs while simplifying their system. The team initially designed their solution as a distributed system but hit a hard scaling limit at 5% of the expected load. This highlights the issue with the microservices craze, which in theory offers scalability and flexibility, but in practice, can needlessly complicate a system. The article argues that microservices and serverless architecture are a zombie architecture that refuse to die, and replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in most cases. The monolith software structure provides a simpler and easier-to-manage system, with greater control over data consistency and changes, improved security, and better performance.

Sources:

Even Amazon can’t make sense of serverless or microservices

The 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! But beyo…

Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%

The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.

Prime Video TechMarcin Kolny

In brief:

• The software industry is seeing a shift back towards the monolith software structure, which integrates all components of an application into one system.
• The complexity that comes with microservices and serverless architecture, such as operational overhead and troubleshooting challenges, is one reason for this shift.
• Managing data consistency and latency in a microservices environment can also be difficult, while the monolith structure is simpler to manage and can improve performance.
• Security and compliance are additional challenges with microservices, as each service needs to be secured independently.
• While microservices and serverless architecture may still be appropriate in certain situations, the trend towards the monolith is likely to continue as more companies recognize the benefits that this approach can offer.

So why?

In recent years, the software industry has been abuzz with the use of microservices and serverless architecture. These approaches have been touted as the solution to all the scalability and flexibility challenges that organizations face. However, there seems to be a new trend emerging in the industry, where companies are moving away from microservices and serverless architecture, and opting for monolith software structure instead.

The monolith software structure is the traditional software architecture where all components of an application are integrated into one large, cohesive system. In the past, this approach was widely used, but it fell out of favor with the advent of microservices and serverless architecture. However, it seems that the monolith is making a comeback.

So, why are we seeing this shift back towards the monolith software structure?

The first reason is the complexity that comes with microservices and serverless architecture. While these approaches offer a lot of flexibility, they also bring their own set of challenges. For instance, each microservice or function needs to be deployed, maintained and tested separately. This can be time-consuming and lead to an increase in operational overhead. Furthermore, when things go wrong, troubleshooting can be a nightmare, as each component of the application needs to be examined individually.

The second reason is the difficulty of data consistency and latency management. In a microservices environment, each service is responsible for a specific function. This means that there is a lot of data exchange between services, and this can lead to issues with data consistency and latency. When there are many services involved, managing data consistency and latency becomes even more complicated.

The third reason is security and compliance. In a microservices environment, each service needs to be secured independently, which can be challenging. Furthermore, when there are multiple services involved, it can be difficult to ensure that they are all compliant with relevant regulations and standards.

In contrast, the monolith software structure is simpler and easier to manage. Since all components of an application are integrated into one large system, it is easier to maintain data consistency and ensure that changes are made consistently across the system. This can help to reduce the risk of errors and can also make it easier to maintain security and compliance.

Furthermore, the monolith software structure can also be more efficient in terms of performance. Since all components of the application are running in one process, there is no need for network communication between services. This can help to reduce latency and improve overall performance.

Conclusion

In conclusion, the shift towards monolith software structure is gaining momentum as companies recognize its benefits in terms of simplicity, efficiency, and reliability. While microservices and serverless architecture offer flexibility, they also come with complexity, data consistency and latency management issues, as well as security and compliance challenges. In contrast, the monolith software structure provides a simpler and easier-to-manage system, with greater control over data consistency and changes, improved security, and better performance. While microservices and serverless architecture will continue to be used in certain situations, the trend towards the monolith software structure is set to continue as more companies realize its advantages.

How you can determine if a monolith architecture is suitable for you

As a software engineer, here are the steps you could follow to analyze and understand if a monolith architecture could benefit your company's software:

1. Understand the current pain points: Before making any decision, it's essential to understand the current pain points and challenges faced by your company's software. Identify the areas that need improvement, such as scalability, maintainability, performance, and security.
2. Evaluate the business needs: Understand the business needs of your company and the software's role in achieving them. Evaluate how the monolith architecture can meet those needs compared to other architectures, such as microservices or serverless.
3. Analyze the size and complexity of the software: Monolith architectures work well for smaller applications with simpler architectures. For larger and complex software, microservices or serverless architecture may be a better choice. Analyze the size and complexity of your software to determine if monolith architecture can handle it efficiently.
4. Evaluate the team's expertise: Monolith architectures require less specialized knowledge and skills compared to microservices or serverless architecture. Evaluate the expertise of your team and determine if they have the skills required to manage a distributed system.
5. Consider the cost: The cost of maintaining a distributed system is higher compared to a monolith architecture. Evaluate the cost-benefit of monolith architecture compared to other architectures and determine if it's feasible for your company.
6. Perform a proof-of-concept (POC): A POC can help you test the viability of monolith architecture for your company's software. Develop a small portion of your software using the monolith architecture and evaluate its performance, maintainability, and scalability.

By following these steps, you can determine if a monolith architecture is suitable for your company's software. Remember, the decision should be based on the specific needs and goals of your company, and not just because it's a trend in the industry.