Making Microservices Just the Right Size
Building cloud-native applications involves building an application as a series of microservices. The idea being that individual microservices are self-contained slices of an application that can be designed, built and operated independently of the rest of the application. This allows large and complex applications to be managed in bite-sized pieces, where each piece is built and operated by a single development team.
But microservices come in a wide variety of sizes from tiny, super-specialized microservices to services big and complex enough to form their own monolithic applications.
It’s difficult to determine the right size for the services you need to build your organization’s apps and meet your business goals.
Services Vary In Size
Historically, services tended to be rather large and could form “mini applications” on their own. In fact, even a massive monolithic application can be, to some extent, a service for other systems. Many early software-as-a-service (SaaS) systems were built as large monoliths—often a simple Ruby on Rails stack—yet, to their customers, they were simply a single “service” in their distributed application.
With the advent of cloud-native architectures, however, there has been a drive to make services smaller and simpler. The idea is that smaller services are easier to understand and easier to manage, debug and update. They can be owned and maintained by a smaller team. Since the architecture of an individual service is much simpler, they are easier to understand. Simpler services mean fewer bugs and lower likelihood of problems during upgrades.
In theory, the smaller you make the service, the easier they are to manage. So goes the hypothesis.
There is a fundamental issue, though, with this “smaller is better” approach, in practice. The smaller you make your services, the more services you need to build an application with a given set of features and capabilities. The more services you have, the more complex the interconnection is between them and the more complex the overall system architecture.
By attempting to make smaller and simpler services, applications have become more complex. The smaller service size is a great benefit to the individual development team that owns that service, but the complex interconnection between services has made the overall system architecture more involved.
We’ve essentially moved the complexity uphill. Rather than individual developers dealing with complexity at the code level, system architects deal with the complexity at the system level.
The Goldilocks Size
Thus, services that are too large are difficult to build and understand at scale. Services that are too small simply move the complexity up to the system level.
The goal, therefore, is to find the right size.
It’s like the story of Goldilocks and the Three Bears; finding the right size for your services is challenging, and often involves trial and error. It’s easy to build them too big or too small. Finding the Goldilocks size can be challenging.
How do you find the Goldilocks size for your microservices? The answer depends a lot on your organization and your application. The right size depends on your answers to some key questions:
- What is the maturity of your individual development teams? The greater the maturity of your development teams, the larger and more complex the services they can maintain. The lower the development teams’ maturity, the smaller you want your services to be. If your teams are inexperienced, you’ll be better off giving them smaller services to own.
- What is the maturity of your service infrastructure? As a cloud-native application, you understand the value of having a mature infrastructure for operating your services. Container-based services managed by an orchestration system such as Kubernetes are the norm. But the more mature your service infrastructure, the more services you can effectively handle. The more services you can handle, the smaller you can make your services, easing the cognitive load of your development teams.
- What is the maturity of your application architecture team? More services mean more interactions between services and a more complex overall application architecture. This puts a greater cognitive load on your application architecture team and requires more knowledge, experience and maturity to manage.
- What does your application require? The ideal service size often depends on where natural service boundaries exist in the desired application functionality and the requirements for specific services. Additionally, some service specifications require extremely high reliability and are best served by a simpler architecture. The ideal size for your services depends a lot on what the application requirements are.
Smaller services are great for less mature development teams, but larger services are better for an overall less complex application architecture. Understanding the maturity and experience of your various teams is required to understand the right tradeoff on service sizes.
Additionally, since smaller services tend to be less complex, they tend to have fewer issues. Yet, complex interactions between more services can negatively impact overall system availability.
Understanding these tradeoffs—and tuning your system based on your application’s requirements and the capabilities and maturity of your available teams—is a key responsibility of your chief architect in a modern, cloud-native application.
