Why microservices might be finished as monoliths return with a vengeance

The move to microservices started gaining momentum in the early 2010s as technology companies recognized the limitations of monolithic architectures. However, many companies such as: Amazon (Prime Video), Invision, Istio, and Segment We are moving back to monolithic architecture. This article explores why many organizations fail to migrate to a microservices architecture.

What is a monolith?

Monolithic architecture is easy. When a user requests data, all business logic and data resides within a single service. However, monolithic systems face challenges such as limited scalability, difficulty deploying updates, and vulnerability to single points of failure.

To address this, many organizations are choosing microservices-based I’ve been trying to move towards architecture.

Why microservices?

In an ideal microservices architecture, each business domain operates as its own independent service with its own database. This configuration has benefits such as increased scalability, flexibility, and resiliency. Consider the diagram below.

reality

However, recent trends show that many companies are moving away from this and sticking with monolithic architectures. This level of harmony is difficult to achieve in the real world. In reality, things often look like the diagram below.

Moving to a microservices architecture is known to introduce complex interactions between services, circular calls, data integrity issues, and let’s be honest, it’s nearly impossible to get rid of the monolith completely. Learn why some of these issues arise when you move to a microservices architecture.

Bad domain boundaries

In an ideal scenario, a single service should encapsulate one or more complete business domains, with each domain self-contained within the service. Avoid splitting your domain into multiple services, as this can create interdependencies between services. The following diagram shows how a single service can include one or more entire domains and maintain clear boundaries.

In complex real-world systems, domain boundaries can be difficult to define, especially when data has traditionally been conceptualized in a particular way. The following diagram shows how real-world systems often look in a microservices architecture when boundaries are not predefined or when engineers add new services without considering domain boundaries. It shows.

If your domain is not clearly defined, you will become more dependent on other services, leading to multiple issues, including:

• Circular dependencies or excessive calls: When services are interdependent, they require frequent data exchange.
• Data integrity issues: When a single domain is split between services, deeply coupled data is split across multiple services.
• Ambiguous team ownership: Multiple teams may need to collaborate on overlapping domains, creating inefficiency and confusion.

Tight coupling of data and functionality

In monolithic architectures, it is difficult to enforce encapsulation in a single codebase, so clients often skip the specified interface and access the database directly. This can lead developers to opt for shortcuts, especially if the interface seems unclear or complex. Over time, this creates a web of clients tightly connected to specific database tables and business logic.

If you move to a microservices architecture, you will need to update each client to work with the new service API. However, the client is tightly tied to the monolith’s business logic, so you will need to refactor the logic during migration.

Resolving these dependencies without breaking existing functionality takes time. Updates for some clients are often delayed due to the complexity of the work, and some clients remain using the monolith database after migration. To avoid this, engineers may create new data models in new services and keep existing models within the monolith. When models are deeply linked, data and functionality is split between services, resulting in multiple cross-service calls and data integrity issues.

data migration

Data migration is one of the most complex and risky aspects of migrating to microservices. It is important to transfer all relevant data accurately and completely to the new microservice. Many migrations stop at this stage due to complexity, but successful data migration is key to realizing the benefits of microservices. Common challenges include:

• Data integrity and consistency: Errors during migration can result in data loss or inconsistency.
• Data volume: Transferring large amounts of data can be resource-intensive and time-consuming.
• Downtime and Business Continuity: Data migration requires downtime and can disrupt business operations. A smooth transition with minimal impact to users is important.
• Testing and validation: Rigorous testing is required to ensure that the migrated data is accurate, complete, and functions properly with the new service.

conclusion

Microservices architectures may seem appealing, but moving away from a monolith is difficult. Many companies are stuck in limbo, increasing system complexity, leading to data integrity issues, circular dependencies, and unclear team ownership. Many companies are reverting to a monolithic approach because the benefits of microservices cannot be fully exploited in the real world.

Supriya Lal is the Group Technology Officer for the Commerce Platforms organization. Yelp.