Why monoliths are returning with a vengeance and why microservices may be done.
Join our daily and weekly emails to receive the latest updates on AI. Learn More
The move towards microservices gained momentum in early 2010, as tech companies began to recognize the limitations of monolithic architectural designs. Many companies, including Amazon (Prime Video), Invision and Segment, are returning to monolithic architectural models. This article will explore why many organizations fail when transitioning to a microservices architecture.
What is a monolith?
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.
Created on Canva by the author.
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 configuration offers advantages such as better scalability and flexibility. 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. It is hard to achieve such harmony in real life. In reality, the world often looks something like this diagram. Created on Canva by author.
Let’s discuss why some of these issues occur once migrated to the microservices architecture. 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. It is not a good idea to split a domain across multiple services as this could lead to an interdependence of 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.
Defining domain boundaries in complex real-world system can be difficult, especially if data is conceptualized traditionally in a certain 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.
Created on Canva by the author.
If domains are not well-defined, the dependency on other services increases, which leads to multiple issues:
Circular dependencies or excessive calls: When services are interdependent, they require frequent data exchanges.
Data integrity issues: A single domain split across services causes deeply coupled data to be split across multiple services.
Vague team ownership: Multiple teams may need to collaborate on overlapping domains, leading to inefficiencies and confusion.
- Deeply coupled data and functionality
- In a monolithic architecture, clients often skip designated interfaces and access the database directly because enforcing encapsulation is hard in a single codebase. Developers may take shortcuts if the interfaces seem unclear or complicated. When moving to a Microservices Architecture, each client must be updated to use the new service APIs. However, because clients are so tied to the monolith’s business logic, this requires refactoring their logic during the migration.
- Untangling these dependencies without breaking existing functionality takes time. Due to the complexity of the work, some client updates can be delayed. This leaves clients using the monolith’s database even after migration. Engineers can avoid this by creating new data models within a new service, but keeping existing models in the original monolith. When models are deeply linked, this leads to data and functions split between services, causing multiple inter-service calls and data integrity issues.
Data migration
Data migration is one of the most complex and risky elements of moving to microservices. Transferring all relevant data accurately and completely to the new microservices is crucial. Data migration can be a complex process, and many migrations fail at this point. However, successful data migration is essential to reaping the benefits of microservices. Common challenges include:
Data integrity and consistency: Errors during migration can lead to data loss or inconsistencies.
Data volume: Transferring large amounts of data can be resource-heavy and time-consuming.
Downtime and business continuity: Data migration can require downtime, potentially disrupting business operations. A smooth transition with minimal user impact is crucial.
Testing and validation: Rigorous testing is needed to ensure migrated data is accurate, complete, and performs well in the new service.
- Conclusion
- The microservices architecture may look appealing, but transitioning from a monolith is challenging. The inability to fully utilize the benefits of microservices in the real world is why many companies are returning to a monolithic approach. The inability to utilize the full benefits of microservices in the real world is why many companies are returning to a monolithic approach.
- Supriya Lal is the group tech lead for the commerce platform organization at Yelp.
- DataDecisionMakers
Welcome to the VentureBeat community!
DataDecisionMakers is where experts, including the technical people doing data work, can share data-related insights and innovation.
If you want to read about cutting-edge ideas and up-to-date information, best practices, and the future of data and data tech, join us at DataDecisionMakers.
You might even consider contributing an article of your own!
Read More From DataDecisionMakers
