Part 1 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 2 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 3 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 4 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 5 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
As I explained in Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 5, to me a service is a logical boundary that is the technical responsible for a given business capability.
This means that the service owns all data, logic and UI for this capability everywhere it is used.
What does it mean that a service is a logical boundary?
As explained in Philippe Kruchten’s 4+1 view of software architecture, we should not automatically force the logical view to be the same as the physical implementation or for that matter the deployment view.
This often means that a service isn’t a single implementation or deployment artifact.
Examples of business capabilities are: Sales, Shipping, Marketing, Billing, Policy Management, etc.
These capabilities are pretty broad in their scope. You’ve probably read that a microservice should follow the Single Responsibility Principle (SRP) – it should do one thing and do it well.
But if a microservice should cover an entire business capability it would most like be fairly big, which goes against many of the qualities we like about microservices, such as:
- Small (easy to comprehend)
- Replaceable (discard the old and write a new in 2 weeks)
- Upgradable (upgrade just the parts you want without interrupting other parts)
- Fast startup/shutdown
- Individually deployable
A large service is still individual deployable, but from a scaling point it’s typically all or nothing: either you scale the entire deployable unit or you don’t.
What if it is only certain use-cases that needed scaling? This is often harder with too big a deployable unit (what some people refer to a monolith) due to individual components inside the unit being too tightly coupled, like a tangled ball of yarn.
As explained in part 5 splitting services along business capabilities (or in DDD terms Bounded Contexts) has many advantages, such a Business/IT alignment, encapsulation and loose coupling.
It can serve us well to look at the smaller responsibilities of a given business capability. A given capability is normally responsible for handling several commands/events (and thereby use-cases).
We can with benefit breakdown the business capability in to smaller parts or components.
[infobox color=”#f7f7f7″ textcolor=”#0a0a0a” icon=”info-circle”]The smallest responsibility for a component inside a service, is the handling of a single message/use-case (remember communication between services is rarely RPC, but rather asynchronous one way messaging) – i.e. either a Command or an Event.[/infobox]
When we have decomposed a service into smaller implementation components, then there is no logic or behavior remaining outside of these components.
This effectively makes the service a logical container/boundary. The only artifact other than components, a service has is its external schema (the commands, events, datatypes, etc. it exposes).
Are the components inside the logical service then microservices?
They can be!
One of the qualities that many people care about, when discussing microservices, is that they own their own data (i.e. have their own database schema/model), which can give us the ultimate degree of autonomy for microservices (as long as they don’t perform RPC/REST against other microservices).
But as you know there is at least 50 shades of grey and the same goes for shades of Autonomy.
The components inside a service boundary can share endpoints, resources, processes and other artefacts in many combinations. Here are some of the most likely:
| Endpoint | Process* | Database | Storage |
| Shared | Shared | Shared | Shared |
| Own | Shared | Shared | Shared |
| Own | Shared | Own | Shared |
| Own | Own | Shared | Shared |
| Own | Own | Own | Shared |
| Own | Own | Own | Own |
* Process includes: co-deployed inside the same runtime (e.g. JVM), co-deployed in same OS instance, in the same Docker image, on the same physical hardware, etc.
Let’s be pragmatic
Going for full microservices every time is too dogmatic in my opinion.
We need to be pragmatic and case by case determine what solution solves the use-case best, where best involves time to market, price, changeability, scalability, future direction, etc. There isn’t such a thing as a cookie cutter solution, sorry 😉
How should we split?
Should we split into component per message, should we split into components per aggregate or should we split into components for functional area inside the service (e.g. having two separate implementation lines of e.g. Order handling – one for VIP customers and one for regular customers)?
My rule of thumb is that we should strive to make our components autonomous, i.e. they shouldn’t need to request data or call logical from other services/components using RPC/REST/… (i.e. using two way communication).
We should strive for them to interact only using Events.
We can perform RPC, e.g. for queries or *Commands, between components within the same Service boundary, but in this case we should consider co-locating/co-deploying them into the same process and use local calls instead of remote network calls.
In the next blog post I will show how we have chosen to organize our services/components/microservices/gateways/applications as code artefacts.
Update 31st January 2016 (thanks to Trond Hjorteland for pointing out that the original text indicated that sending commands entitled using one-way communication)
* Note: There’s some debate about whether Commands strictly involve two way communication (sync or async) or if they can be used with one way communication (e.g. with events to clarify if they succeeded or not). My view is that commands should be dealt with using two way communication, since you typically want to know if the processing of the command succeeded. For certain cases you may be fine with not knowing this (or you believe that the likelihood of the command failing is very low), in which case Commands could dealt with using one-way communication. A good question to ask in such a situation: are the messages really exchanged commands or are they in fact events? – in which case one-way communication is the right way to exchange the message
Hi Jeppe,
Great post as always. I’m glad that you post talk about autonomy because I was hoping you could share your opinion on who authentication and authorization should be implemented in a micro service architecture.
From a DDD perspective, I believe Identity & Access should be its own bounded context and hence should be implemented as its own micro service. How should this data be shared between services?
In a monolith when a user is authenticated a session is created on the server and you probably store the user id in it. However, if different commands are sent to different services, how do you check if the user is authenticated or not?