Monolith to Microservices
For over four decades, humanity has been dedicated to the creation of software applications and products. In the early days, there was a lack of clear guidance on how to design well-structured software. However, as time progressed, pioneers like Martin Fowler introduced techniques that steered the entire community towards a specific design pattern.
Transitioning from Monolith
In the past, it was a common practice to develop software that tightly coupled and bundled all its components, running on a single server. This approach soon revealed its limitations, highlighting the need to address issues related to coupling and packaging. Monolithic applications, while simple and easier to maintain, were primarily suited for a relatively small user base, typically numbering in the thousands. As the internet expanded exponentially, the demand for more robustly designed software became evident.
The above paragraph illustrates one of the prevailing design patterns used in building monolithic applications. However, it immediately exposes a set of inherent problems such as the absence of proper separation, single points of failure, and more. These issues become particularly pronounced when the system needs to serve millions of users.
Towards Microservices
Individuals who recognized the need for better software architecture embarked on a journey of exploration and experimentation. Service-oriented architecture (SOA) briefly held sway, incorporating an Enterprise Service Bus (ESB) that acted as an intermediary for transferring messages among applications. However, it soon became clear that SOA was an expensive proposition, especially for startups with limited resources.
Enter Peter Rodgers, who introduced the concept of “Microservices” around 2005. True to its name, this approach involved breaking down a monolithic application into multiple smaller applications, each residing in its isolated environment, unaware of the existence of others yet functioning as a cohesive unit. This concept gave rise to the idea of layering, which is explained in more detail in this blog.
The diagram above demonstrates the concept of layering, where different segments of an application, such as the business layer, data layer, and API layer, are logically grouped into separate units, promoting better separation and easier maintenance.
As the concept of layering evolved, notable figures like Martin Fowler contributed to its development. For more insights, you can refer to this post on microservices by Martin Fowler.
Microservices Architecture
In the diagram, you can observe a simple e-commerce application design. Instead of a monolithic product handling user authentication, order processing, and payment, these functions are split into three distinct mini applications, each with its own database and operating independently. These are our microservices, usually running on separate servers. They utilize messaging-based communication methods like RabbitMQ or Kafka to keep the system informed about the status of their ongoing tasks. This approach effectively eliminates the issues of high coupling, and single points of failure, and enhances fault tolerance compared to monolithic systems.
The “Not So Good” Part
As we delve into layering and microservices, the overall system’s complexity increases, leading to extended debugging sessions and careful consideration when introducing changes to an existing microservice application.
In Conclusion
Microservices, while a powerful approach to modern software development, may not be a one-size-fits-all solution. A community suggestion would be to stick with a monolithic architecture for systems serving a few hundred or thousand users. Conversely, it is wise to opt for microservices when the system requires fault tolerance, high scalability, and real-time capabilities.
