Microservices vs. Monoliths: A Balanced Perspective

With the rapid evolution of the software development landscape, different architectural styles have emerged, each with its own pros and cons. From the early days of monolithic systems, to three-tier architectures, service-oriented architectures (SOA), and now microservices, each pattern has its unique strengths that have made them successful in their time. Recently, there's been a buzz around microservices being 'dead' and monoliths making a comeback. However, as a seasoned software architect, I believe that it's not about one approach being superior to the other, but rather about selecting the architecture that best fits the needs of the project and the team.

?

A good software architecture is the backbone of any successful software system. It facilitates system understanding, decision making, and fosters a sense of shared understanding among the team. A well-designed architecture should bring clarity to functional domains and promote separation of concerns, leading to a better code structure and organization. Such an architecture allows architects and developers to rapidly adopt to changed requirements and update software solutions without breaking them.

?

Yet, it's essential to understand that software architecture and a deployment model or runtime architecture, while related, do not necessarily depend on each other. The distinction is crucial: software architecture is more of a blueprint that helps define internal organization and interaction of software elements, while the deployment model dictates how the software is delivered and run.

?

This distinction brings us to an interesting perspective: you can design your software internally like a microservice and run it like a monolith. This approach is not a new concept; it's often referred to as "modular monoliths." It combines the best of both worlds: the internal flexibility and organization of microservices with the simplicity of a monolithic deployment.

?

In a modular monolith, the codebase is divided into modules or components, each encapsulating a specific business or functional domain, similar to microservices. These modules can be developed, tested, and updated independently, increasing the speed of development and reducing the risk of changes affecting the entire system. However, unlike microservices, all the modules live within the same process and are deployed as a single unit, removing the complexities of distributed systems, such as network latency and data consistency issues.

?

Take, for instance, the recent case of Prime Video's video quality analysis system. They transitioned from a microservice-based architecture to a monolithic one to address their specific challenges, such as high costs and scaling bottlenecks. They moved all components into a single process, reducing data transfer costs and simplifying the orchestration logic. The result was a 90% reduction in infrastructure costs and an increase in scaling capabilities. However, the architecture retained the functional divisions of a microservice design, highlighting the potential of a modular monolith approach.

?

In terms of security, the transition to a monolithic architecture means that all data exchanges can take place within the confines of a single process, reducing exposure to potential external threats. The fewer interfaces and reduced surface area make it easier to manage and secure, reducing the risk of data leaks between services.

?

It's important to note that the security of a monolithic application can also be a double-edged sword. While the reduced number of interfaces can minimize exposure, if a security flaw does exist in the system, it could potentially provide access to a larger portion of the system than in a distributed architecture, where services are more isolated. Security measures, such as regular code reviews, penetration testing, and adherence to security best practices, are crucial in any architecture type, be it microservices or a monolithic design.

?

In conclusion, the claim that "microservices are dead, and monoliths live" is an oversimplification. The debate isn't about choosing sides but understanding that different architectural styles serve different purposes. As software architects, our goal should be to adopt an architecture that best serves the needs of our project, whether it's a microservice, monolith, or a hybrid approach like the modular monolith. The key lies in making informed decisions, considering the unique requirements of the project, the team's capabilities, and the potential trade-offs of each approach.

This article has been published in German IT DIRECTOR 6/2023:

www.it-zoom.de/it-director/e/ein-zweischneidiges-schwert-32894