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.

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 6 – Service vs Components vs Microservices

Text updated the 27th of June 2021

First of all, sorry to those who’ve been waiting for part 5. My schedule has been too busy to find focused time to write part 5 before now 😳 .

In part 4 we looked at building our services around functional areas or business capabilities/bounded-contexts.

We discussed that the business data and logic pertaining to a business capability must be encapsulated inside a service to ensure single source of truth for the data.

This also means that other services aren’t allowed to own the same data that another service owns because we want to avoid multi master services.

Since we want our service to be autonomous, i.e. the service should able to make a decision without having to communicate synchronously with other services, we also looked how to avoid 2 way communication (RPC, REST, GraphQL or Request/Response) between services.

The options we looked at were Composite UI’s and Data duplication over Events.

We also briefly discussed a 3rd option that involved a different view on services, where they’re not autonomous and services instead expose intentional interfaces and coordinate updates/reads between several System of Records (SoR) that them selves are autonomous. I believe that organizations with many large legacy systems (and most likely multi master Systems of Records) should look into the possibilities of the 3rd option, as I believe it may create less friction than trying to develop new autonomous services that are well aligned with business capabilities.

In part 5 I will continue discussing SOA and Microservices in the light of autonomous services.

Business Capabilities and Services

In part 4 I suggested building our services around functional areas or business capabilities/bounded-contexts.
I would like to tighten up that statement and rephrase to:

We should align our services with business capabilities.

Continue reading “Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 5” →

Jeppe Cramon's Software development blog

Service vs Components vs Microservices – part 6

What does it mean that a service is a logical boundary?

Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 5

Business Capabilities and Services