Microservice Boundary - A Guide

I conduct several design and architecture reviews every week, and one topic that comes up often is how teams decide to build their features. Will they need to create a new microservice, or can they use an existing service in their current infrastructure? How do you choose?

At Microsoft, I often encourage folks to balance the following principles and seek others' opinions to challenge their assumptions:

Performance: Performance is the?super-feature?of any system. I tend to build performance into the architecture of our products from the ground up. If two services have a chatty interface amongst them, we often consider co-hosting them in the same executable.

Units of deployment: Microservices are typically defined as units of deployment. We build them in a way that each microservice can have an independent deployment pipeline and cadence. When creating a new microservice, we ask ourselves if a new deployment encapsulation is truly warranted.

Unit of scale and placement: microservices, nanoservices, and pods can all be units of scale and placement. Suppose there is a service with exotic characteristics (e.g., it needs expensive GPUs, but the rest of the services don't). In that case, you might want to consider a separate service.

Team independence: It is often necessary to draw code boundaries to help decouple teams, especially teams in different time zones.

Not a code component: A microservice is?not?always one component. Other technologies such as NuGet and npm packages help with componentization and distribution. Component isolation should not be an objective here.

Physical and logical isolation: At times, one might need to separate the logic into more than one microservice for security or resource governance reasons. For instance, it is common to have an API Gateway Service that manages authentication, authorization, throttling, billing, etc. The gateway then proxies the calls to backend services that are not exposed to broader attack surfaces such as the internet.

Dependency management: Suppose that multiple services need access to a given database. If all directly interacted with that database, data migration or changes to its schema can be challenging, because multiple deployment units need to roll out in tandem. Therefore, we often place all operations related to a dependency in a single service. Note that a single service can also manage more than one dependency.

I hope that you can use the above principles?to find an optimal balance for your scenarios.

Pedram