In a microservices app, how many microservices are too many?

Why microservices?

Microservices architectures have become popular over the past several years because they make complex applications more agile and easier to manage. Microservices are similar to service-oriented architecture (SOA), which was popular in the 2000s. But microservices are different from SOA in key ways. Microservices apps tend to include more services, and each service is usually more lightweight than under the SOA model.

The advent of container platforms, especially Docker, has helped to drive the popularity of microservices. Application containers make it easier to deploy microservices by running each service inside a different set of containers. This provides an easy way of isolating processes for each service, as well as scaling services individually as demand changes rather than having to scale the entire app.

Migrating to microservices

In most cases, if you want to migrate to microservices, you have two options:

• Refactor an existing monolithic application so that it runs as a set of microservices. Refactoring means modifying the codebase without rewriting it entirely.

• Rebuild your application from scratch according to a microservices architecture.

Either way, you need to decide how many microservices to include.

How many microservices do you actually need? That’s the big question. There is no hard and fast rule for determining how many microservices an app should include. The answer will vary from app to app and organization to organization, of course. To determine which number is right for you, keep the following considerations in mind as you plan your app migration.

Balance agility with complexity

Your main goal when deciding how many microservices are enough is to strike the right balance between agility and complexity.

If you implement too few microservices, your application will not gain much agility because it will still be composed of large, nearly monolithic parts.

If you have too many microservices, you'll end up with more moving parts in your environment than you need. This makes management, monitoring and security more difficult.

So, as you draft a new architecture for your microservices app, think about whether the number of services you plan to include will deliver the agility you need while still being manageable for your admin team.

Review existing code and processes when refactoring

If you're refactoring your app, try to align each microservice with a distinct part of your codebase, if possible.

This is easy to do if your code was written to be modular or if your application already runs as a set of different processes. In these cases, you can take each major component of the monolith and run it as a microservice without having to rewrite too much code.

This is harder to do if your app is so hopelessly monolithic that there is no logical way to break down its code or processes into microservices. If that’s the case, you're probably better off rebuilding than refactoring the app, especially in application modernization and digital transformation projects.

Keep your organizational hierarchy in mind

Make sure that each microservice is associated with a DevOps development and management team within your organization. This doesn't mean there has to be one team per microservice. A single team can handle multiple microservices.

The goal here is simply to make sure that you don't include microservices in your architecture that become "orphans" because no one is available to develop or support them -- or, worse, microservices that end up being managed by multiple teams at the same time, leading to communication and organizational problems.

Resource consumption

It can be helpful to think in terms of which types of resources different parts of your application need and how many they need.

Your environment will be more agile if each microservice needs to access only one type of resource, such as compute, storage or networking. Microservices that need multiple resources are harder to manage and likelier to crash.

In addition, your app will be able to scale best and remain as cost-efficient as possible if the parts of it that demand the highest volume of resources run as their own microservices. This is because you can increase resource allotment to these microservices whenever needed without allocating more resources to other microservices that don’t need them.

Microservices that need multiple resources are harder to manage and likelier to crash.

For example, if your app allows users to upload photos and then resize them, this functionality should be mapped to three different microservices:

• One is a web front end that allows users to upload a photo, which is a lightweight task that requires a moderate amount of compute resources.
• Another is a storage microservice that takes an uploaded or resized image and stores it in a database. This task requires storage but very little compute.
• The third is a service that does image resizing, which is highly compute-intensive.

Don't forget security

Security considerations can be an important part of how you decide what becomes a distinct microservice.

One goal as you plan your architecture is to make attack vectors for each microservice as small as possible. For that reason, make sure you don't mix together public-facing functionality and internal services within a single microservice. If you do, you are unnecessarily exposing the internal services to a greater risk of attack because services that are not public-facing are less likely to be attacked in most cases.

Keep in mind, too, that one benefit of microservices is that they help to mitigate the impact of breaches. If attackers compromise one microservice, they won't necessarily be able to compromise the rest of your app. Use this to your advantage by making sure that the highest-risk services (meaning those likeliest to be compromised, such as web services) within your application run as distinct microservices.

Likewise, use different microservices to run the parts of your app that are the most important to secure. For example, if you have a storage service that accesses customer data protected by regulatory policies, running that service as a distinct microservice will help to keep it more secure in the event that attackers compromise other parts of your app.

This could be a reason to break your app’s storage functionality down into multiple microservices. Some will handle highly sensitive data, while others will work with less sensitive types of information.

Making the microservices app decision

Deciding exactly how many microservices your app should have is a question only you can answer. There's no easy solution.

But by weighing issues like the way your code base is organized, your app's resource consumption, the way you define roles and teams within your organization and security considerations, you can determine how many microservices are right for you.

When you do, you strike the ideal balance between agility and complexity.