Containers, Docker, Kubernetes, and Serverless are often used when explaining a Microservices architecture. However, focusing on physical deployment is missing the point of Microservices entirely. Microservices (or any size services) are about logical separation and not about physical deployment. Deployment flexibility is a by-product of having well-defined boundaries for services that are autonomous.

YouTube

Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this post.

Microservices

Like many terms in the industry, they often get confused or conflated with other concepts and lose their original meaning. Martin Fowler calls this Semantic Diffusion. I think Microservices falls into that category as I don’t think you would get the same definition from a group of people.

I’ll use the definition from Adrian Cockcroft:

Loosely coupled service oriented architecture with bounded contexts

When it comes to a Bounded Context, which is from Domain-Driven Design

If you have to know too much about surrounding services you don’t have a bounded context.

It’s all about coupling and autonomy. You want to be autonomous and not be coupled to other services. If you have to coordinate with another service for a change your making, then you’re not autonomous. If you’re sharing a database with other services, and make a schema change and need to coordinate with other services so they also make the required change, you aren’t autonomous.

I advocate often for Domain-Driven Design and the concept of boundaries in most of my posts/videos. This is why I like to describe a service as the authority of a set of business capabilities.

Containers/Docker/Kubernetes

The vast majority of the content you’ll find about Microservices, almost always focus on physical deployment and all the technical complexities that come from it. The focus then becomes on Containers, Docker, Kubernetes, or Serverless. But this is missing the point entirely of Microservices.

Microservices is about logical separation, not physical.

A bounded context is a logical boundary. It represents a portion of a subdomain of the larger system.

4+1 Architectural View Model

Somewhere along the rise of Microservices became this idea that a logical boundary is also a single source code repository that is built into a single deployable unit.

For example, that a service had it’s own git repository and would be built into a container image.

Although this is practical in some situations, it doesn’t need to be if you think about logical, development, and physical views separately.

The above diagram is the 4+1 Architectural View Model. It’s used for describing an architecture based on multiple concurrent views.

The logical view represents a bounded context. The Development view represents the source code, repository, what you see in your editor or IDE. The physical view is the topology of deployment.

In most examples of Microservices, they focus as if these are all one unified concept without making any distinctions between them.

In the example above, each Service (Sales, Warehouse, Billing) are all living in their own containers, talking to their own databases and communicating to a message broker. There’s nothing wrong with this. However, you can still have logical separation without physical separation of deployment.

At build time, you could however compose all the different services and run them within the same executable. Their communication is unchanged. They aren’t directly communicating within the same process. They are simply hosted together in the same process.

I’m not advocating one way or the other, but illustrating that logical separation and physical separation are different concerns.

Do Microservices require Containers/Docker/Kubernetes?

No, Microservices are about logical separation, not physical.

Source Code

Developer-level members of my CodeOpinion YouTube channel get access to the full source for the working demo application available in a git repo. Check out the membership for more info.

Additional Related Posts