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
Text updated 27th of June 2021
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.
You’ve probably read that a microservice should follow the Single Responsibility Principle (SRP) – it should do one thing and do it well.
If we align microservices with business capabilities, such as Sales, Shipping, Marketing, Billing, Policy Management,
then the microservices 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 individually 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.
Continue reading “Service vs Components vs Microservices – part 6”
Jeppe Cramon's Software development blog 