Join our daily and weekly newsletters for the latest updates and exclusive content on industry-leading AI coverage. Learn More
What is a monolith?
The shift towards microservices started gaining momentum in the early 2010s, as tech companies recognized the limitations of monolithic architectures. However, many companies such as Amazon (Prime Video), Invision, Istio and Segment are moving back to monolithic architectures. This article will explore why many organizations fail when transitioning to a microservices architecture.
Created on Canva by the author.
A monolithic architecture is straightforward: The user requests data and all business logic and data reside within a single service. However, monolithic systems face challenges, such as limited scalability, difficulty with deploying updates and a vulnerability to single points of failure.
To address this, many organizations have attempted to transition to a microservices-based architecture to leverage advantages such as abstraction and encapsulation, faster deployment, easier maintenance and closer alignment of each service with team ownership.
Why microservices?
In an ideal microservices architecture, each business domain operates as its own independent service with its own database. This setup offers benefits like better scalability, flexibility and resilience. Consider the diagram below.
Created on Canva by the author.
The reality
However, recent trends show that many companies are moving away from this and sticking to a monolithic architecture. This is because it is difficult to achieve this level of harmony in the real world. The reality often looks like the diagram below.
Created on Canva by the author.
Migrating to a microservice architecture has been known to cause complex interactions between services, circular calls, data integrity issues and, to be honest, it is almost impossible to get rid of the monolith completely. Let’s discuss why some of these issues occur once migrated to the microservices architecture.
Incorrect domain boundaries
In an ideal scenario, a single service should encapsulate one or more complete business domains so that each domain is self-contained within a service. A domain should never be split across multiple services, as this can lead to interdependence between services. The following diagram shows how a single service can contain one or more entire domains to maintain clear boundaries.
Created on Canva by the author.
In complex real-world systems, defining domain boundaries can be challenging, especially when data has traditionally been conceptualized in a specific way. The following diagram shows how real-world systems often look in a microservice architecture when boundaries are not defined in advance or engineers add new services without considering domain boundaries.
