The Complexity of Scaling a Microservices Architecture
Microservices architectures offer many clear benefits, but they also create challenges.
Chief among those challenges is scaling. Effectively scaling a microservices application requires a completely different approach from monolithic scaling, where you usually rely simply on a load balancer and copies of the application (or what Chris Richardson refers to as “the X axis of scalability.”)
This is an important subject, because although scalability for microservices might seem simple enough to understand, in practice it is hard to master. Basic rules and principles for scaling microservices that make sense in the abstract don’t always work well in real-world environments where you are handling millions of requests per hour.
This article discusses some of the initial challenges that your team should take into account when scaling a microservices architecture from an abstract perspective. It also identifies various tools that may be useful for addressing the challenges.
Challenge 1: Handling Microservices Complexity
Complexity is hard to define, but the general concept is associated with many components and parts that interact in timeframes to become a system. Complex systems are a subject of research in many prestigious institutions, and a microservices architecture is a perfect case of a complex system. It not only means a shift in technology, but also the way that components are connected, the way that they communicate, and how people collaborate to keep everything running.
A useful technique for handling a complex environment like a microservice-oriented solution is to visualize it as a network. Network analysis gives you tools, metrics and ways to understand the structural properties and key nodes (microservices, components and agents) in your schema — and how to protect them from an unexpected failure to achieve resilience or stability. Many research papers [1], [2] and books provide a basic understanding of network analysis. In addition, tools such as Kubernetes, Swarm and Mesos, among others, will help you to put together the infrastructure to develop and deploy a complete solution.
Challenge 2: Where’s Waldo in Your Microservices Architecture?
As small, self-contained units of defined tasks that work together through Application Program Interfaces (APIs), microservices can explode in large numbers across your architecture, from dozens to hundreds — or even higher orders of magnitude. Adding more microservices implies adding more complexity to your solution, and you have to be sure that new microservices can scale together with your existing microservices. A rogue (dependency) microservice can bring your whole solution down!
Microservices discovery and registry tools, such as Eureka from Netflix, allow decentralized management of the services available (like a Domain Name Server). Eureka is a service registry for “resilient, mid-tier load balancing and failover” that lets services auto-register and discover other services. It also provides mechanisms to distribute loads across the instances of those services.
Challenge 3: Tracing Microservices Problems
Logging is a vital part of every software solution, but in a microservices architecture, tracing a problem among all of the components in your environment can quickly become a nightmare. Meeting the microservices monitoring challenge requires capabilities such as mapping requests to microservice topologies, or the instrumentation of a centralized endpoint that collects the information from other services. It’s also important to be able to establish a baseline of normal activity within the dynamic environment, to understand dependencies between services within the context of monitoring and to correlate events within one layer of the infrastructure (such as the host server) with other layers (such as application services.)
Challenge 4: Microservices Communication
Communication is a big challenge in the realm of microservices. Creating clear contracts of operation and defining responsibilities are two common tasks for architects and developers. Both completed projects must be in a language that illustrates the capabilities of each service — and in many cases, contextual elements or dependencies on other microservices.
When your solution scales to hundreds of microservices, a clear understanding of the features and requirements of each is crucial for survival. Swagger and API Blueprint are two examples of tools that can be useful for clarifying the way that microservices should work.
Challenge 5: Building Microservices Expertise
A team that learns from crisis builds knowledge that can be used for the future. Toward this end, automation and repeatability are two main characteristics of a mature process for managing microservices. To learn from past events, tools like Zookeeper can come in handy for storing configurations of the tools involved in your operation.
Conclusion
Great architectures imply great challenges. Be aware of the compromises when you select a model to solve a problem. Whatever the model, the issues range from complexity to clear communication and monitoring. Microservices are useful and highly scalable if you prepare yourself and your team to tackle the issues with the appropriate tools. Be prepared—Many more challenges are visible from other perspectives (operative, development and testing, and more).
To learn more about monitoring microservices, get the free eBook: Container Monitoring & Management.
References and Further Reading
- Watts, D. & H. Strogatz, S. (1998). Collective Dynamics of Small World Networks. Nature. Vol. 393. 440-2. 10.1038/30918.
- Laurent, G., Saramäki, J., & Márton, K. (2015). From calls to communities: a model for time-varying social networks. The European Physical Journal B. 88.10.1140/epjb/e2015-60481-x.