Microservice Proliferation: Too Many Microservices – DZone

Microservices architecture promotes the development of applications, as suites of small, independent, loosely coupled services. Because of its numerous advantages (e.g., scalability, reliability, faster development cycles, easier maintenance of individual services, etc., detailed in this article), it has gained significant traction in the software industry lately and organizations are building their applications following microservices architecture. However, it comes with a few pitfalls as well.

Recently while working on a use case at work, I observed the other side of microservices architecture, i.e., microservices proliferation. This article is an attempt to detail the pitfalls associated with the excessive creation of microservices (microservices proliferation), offering insights on their causes, implications, and potential strategies for mitigation.

What Is Microservices Proliferation?

Microservices proliferation refers to the uncontrolled, unregulated, and, to an extent, undesirable increase in the number of microservices within an application framework/ecosystem. This is often a result of a lack of architectural plan and governance, architectural oversight, unclear definitions and boundaries of service, and a few non-technical reasons like organizational boundaries, etc. Microservices proliferation can lead to architectural complexities, inefficiency and performance degradation, operational and maintenance challenges, duplication of features, and a maze of service calls leading to further degradation in performance and potential negative customer impact. Let’s discuss a few of these pitfalls and their potential mitigation below.

Common Pitfalls

Increased Architectural Complexity

As the number of microservices in an ecosystem increases, the more complex the services ecosystem (and its architecture) becomes. This leads to further complexity and challenges in design, development, deployments, feature launches, and maintenance of the whole ecosystem.

Implications

1. Services could become too dependent on or too coupled with other services, thereby suggesting an unnecessary artificial infrastructural divide in the services. This also leads to difficulties in truly understanding the system architecture and making any changes to it.
2. With every increase in moving parts in a system (services in an architecture), the operational burden to maintain the system increases. Every microservice requires its own maintenance and management of infrastructure, metrics, and alarming, and thus adds up an operational burden on the on-call and the team.

Potential Mitigation Strategies

1. Define clear definitions and boundaries of the services. Ensure they are cohesive and functionally bounded. Remember, we don’t need to build a new service for every new mapping, every new config, or every new entity a system will have. 
2. Regularly review and audit architecture. Deprecate the services that aren’t needed. Collapse or merge duplicate services to simplify the architecture.

Increased Feature Release Complexity

Since microservices proliferation adds more moving parts (aka services), a feature release could require changes in a relatively higher number of services. This complicates the feature release process as a feature now would require deployments in multiple services. This thus adds up the risk of failures in the feature release process as a failure in deployment in just one service could derail the whole feature release process and could potentially lead to other implications as well (data integrity, system integrity, etc.).

Implications

1. Increased complexity and efforts required in coordinating deployments across services, thereby increasing operational overhead.
2. Complicated rollback process especially if services are interdependent on each other, leading to further increase in operational overhead.
3. A longer release plan and rollback plan could lead to the system being in a transitionary state for longer, leading to inconsistent behavior and thus inconsistent customer experience.

Potential Mitigation Strategies

1. Follow CI/CD principles in all services pipelines to automate the deployment process and safely deploy changes across pipelines, ensuring consistent and reliable releases. 
2. Use feature flags when multiple services are involved for a feature release to decouple the launch of features from deployments and to cleanly control the launch of a new feature across services involved in it.

Performance Degradation

Microservices proliferation could lead to performance degradation of the whole system, primarily because of a request requiring to go through multiple hops, thereby incurring additional network latency.

Implications

1. The first implication is higher latencies to serve a customer request, primarily because of a request requiring interactions between multiple systems.
2. One service with resource contention or unoptimized implementation (or infrastructure) can impact the whole services ecosystem.
3. Lastly, this could imply more infrastructure costs and relatively less performance benefits considering the cost of maintaining the system.

Potential Mitigation Strategies

1. Implement a service mesh to optimize communication between services and to reduce latencies. This, however, adds another component to the architecture and makes it more complex. 
2. Cache where necessary to reduce the overhead and latencies because of network calls.
3. Regularly load-test the services and optimize the bottlenecks in the services.

Duplication

As new services are created, so is the risk of duplicate and redundant features and code, thereby leading to wasteful utilization of resources.

Implications

1. Duplicate services lead to higher maintenance costs, thereby leading to inefficiencies in the system.
2. Customers of the services could get confused about which service to use, thereby leading to further inefficiencies and errors in the system.

Potential Mitigation Strategies

1. Promote the culture of reuse within the organization. Encourage teams to reuse or extend existing services rather than creating new ones, whenever possible. 
2. Maintain a service catalog detailing crisp definitions, responsibilities, and supported functionalities of each service. Regularly review and audit this within the team.

Increased Testing Complexity

As the number of microservices grows, so does the complexity of end-to-end testing of a feature. Maintaining data and system integrity becomes increasingly complex with the number of microservices in a system.

Implications

1. Coordinating and executing test cases across multiple services can become a logistical nightmare, thereby leading to incomplete testing and thus undetected issues.
2. A higher effort is required in testing individual services as it will require a complex mocking setup, which may not accurately represent real-world scenarios.
3. Higher effort is required in end-end testing of the whole ecosystem of services thereby requiring higher investment and cost for safely launching a new feature.

Potential Mitigation Strategies

1. Implement automated testing frameworks, which can simulate complex interactions between multiple services. 
2. Perform phased testing, starting from testing individual services first and then end-end testing of the whole ecosystem, relying on interfaces of the services involved.

Increased Opportunity Cost and Suboptimal Utilization of Resources

As the number of microservices grows, so does the cost of maintaining the services, the cost to develop any new feature, and the cost of infrastructure of these services. It also adds an opportunity cost since the resources spent in maintaining these services or building over top of these services could be utilized in solving other problems.

Implications

1. Higher developmental, maintenance, and infrastructure costs
2. Higher opportunity cost
3. Wasteful utilization of resources as the team keeps on spinning in maintaining the existing services rather than possibly investing resources in solving other problems

Potential Mitigation Strategies

1. Promote the culture of reuse or extension. Only build new services when necessary.
2. Regularly review the end-end architecture and build experimentation to discover bottlenecks. Merge or deprecate services to simplify architecture and thus improve resource utilization.

Conclusion

Microservices proliferation is real and presents significant challenges that can undermine the benefits of microservices architecture, thereby leading to increased complexity, performance degradation, suboptimal utilization of resources, and missed opportunities to solve other problems. By recognizing these pitfalls and implementing strategic and effective mitigations, teams can navigate the complexities of microservices proliferation, thereby ensuring they harness the true benefits of this architectural pattern.