What Makes a Good Microservice Boundary?
Before the team from MusicCorp tears off into the distance, creating service after service in an attempt to deliver eight-track tapes to all and sundry, let’s put the brakes on and talk a bit about the most important underlying idea we need to keep in mind. We want our microservices to be able to be changed, deployed, and their functionality released to our users in an independent fashion. The ability to change one microservice in isolation from another is vital. So what things do we need to bear in mind when we think about how we draw the boundaries around them?
In essence, microservices are just another form of modular decomposition, albeit one that has network-based interaction between the models and all the associated challenges that brings. Luckily, this means we can rely on a lot of prior art in the space of modular software and structured programming to help guide us in terms of working how to define our boundaries. With that in mind, let’s look more deeply at three key concepts which we touched on briefly and which are vital to grasp when it comes to working out what makes for a good microservice boundary – information hiding, cohesion, and coupling.
One of the foremost succinct definitions I’ve heard for describing cohesion is this: “the code that changes together, stays together.” For our purposes, this is often a reasonably good definition. As we’ve already discussed, we’re optimizing our microservice architecture around simple making changes in business functionality—so we would like the functionality grouped in such how that we will make changes in as few places as possible.
We want related behavior to take a seat together, and unrelated behavior to take a seat elsewhere. Why? Well, if we would like to vary behavior, we would like to be ready to change it in one place, and release that change as soon as possible. If we’ve to vary that behavior in many different places, we’ll need to release many different services (perhaps at an equivalent time) to deliver that change. Making changes in many different places is slower, and deploying many services directly is risky—both of which we would like to avoid.
So we would like to seek out boundaries within our problem domain that help make sure that related behavior is in one place, which communicate with other boundaries as loosely as possible. If the related functionality is spread across the system, we are saying that cohesion is weak – whereas for our microservice architectures we’re aiming for strong cohesion.
When services are loosely coupled, a change to at least one service shouldn’t require a change to a different . the entire point of a microservice is having the ability to form a change to at least one service and deploy it, without having to vary the other a part of the system. this is often really quite important.
What kind of things cause tight coupling? A classic mistake is to select an integration style that tightly binds one service to a different , causing changes inside the service to need a change to consumers.
A loosely coupled service knows as little because it must about the services with which it collaborates. This also means we probably want to limit the amount of various sorts of calls from one service to a different , because beyond the potential performance problem, chatty communication can cause tight coupling.
Coupling though comes in many forms, and I’ve seen variety of misunderstandings about the character of coupling because it pertains to a service-based architecture. thereupon in mind, i feel it’s important that we explore this subject in additional detail, something we’ll do shortly.