Because microservices may end when monoliths return with a vengeance

The shift towards microservices began to gain momentum in the early 2010s, as technology companies recognized the limitations of monolithic architectures. However, many companies like Amazon (Prime Video), Invision, Istio and Segment they are returning to monolithic architectures. This article will explore why many organizations fail when transitioning to a microservices architecture.

What is a monolith?

A monolithic architecture is simple: the user requests data, and all business logic and data resides within a single service. However, monolithic systems face challenges, such as limited scalability, difficulties with update distribution, and others vulnerability to single points of failure.

To solve this problem, many organizations have attempted to move to a microservices-based architecture to take advantage of benefits such as abstraction and encapsulation, faster deployment, easier maintenance, and closer alignment of each service with the team ownership.

Why microservices?

In an ideal microservices architectureeach business domain operates as its own independent service with its own database. This configuration offers advantages such as better scalability, flexibility and resilience. Consider the diagram below.

The reality

However, recent trends show that many companies are moving away from this approach and are sticking to a monolithic approach architecture. This is because it is difficult to achieve this level of harmony in the real world. Reality often looks like the following diagram.

Migrating to a microservices architecture is known to cause complex interactions between services, circular calls, data integrity issues, and to be honest, it is almost impossible to completely eliminate the monolith. Let’s talk about why some of these issues occur once you migrate to 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 between multiple services, as this can lead to interdependency between services. The following diagram shows how a single service can contain one or more entire domains to maintain clear boundaries.

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 what real-world systems often look like in a microservice architecture when boundaries are not defined in advance or engineers add new services without considering domain boundaries.

If domains are not well defined, the dependency on other services increases, which leads to multiple problems:

• 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 across overlapping domains, leading to inefficiencies and confusion.

Data and functionality deeply coupled

In a monolithic architecture, clients often skip designated interfaces and access the database directly because applying encapsulation is difficult in a single code base. This can lead developers to take shortcuts, especially if interfaces are unclear or seem complicated. Over time, this creates a network of clients tightly connected to specific database tables and business logic.

When you move to a microservices architectureeach client must be updated to work with the new service APIs. However, because customers are so tied to the monolith’s business logic, this requires refactoring their logic during migration.

Untangling these dependencies without breaking existing functionality takes time. Some client upgrades are often delayed due to the complexity of the job, leaving some clients continuing to use the Monolith database after migration. To avoid this, engineers can create new data models in a new service but keep existing models in the monolith. When models are deeply linked, this leads to splitting of data and functions 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 the move to microservices. It is essential to accurately and completely transfer all relevant data to the new microservices. Many migrations stop at this stage due to complexity, but successful data migration is critical to realizing 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 take a lot of time and resources.
• Downtime and business continuity: Data migration can require downtime, potentially disrupting business operations. A smooth transition with minimal user impact is key.
• Testing and validation: Rigorous testing is required to ensure that the migrated data is accurate, complete, and works well in the new service.

Conclusion

Microservices architecture may seem appealing, but transitioning from a monolith is challenging. Many companies find themselves stuck in an in-between state, which increases system complexity causing data integrity issues, circular dependencies, and unclear team ownership. The inability to leverage the full benefits of microservices in the real world is why many companies are returning to a monolithic approach.

Supriya Lal is the group technical manager for organizing the trading platform at Yelp.