MSA consideration
Before We Start
Let's make sure we're on the same page with terminology
Domain
A unit that logically implements actions and responsibilities (This could either be logic or policy)
I won't make a diagram for this.
Service
A unit that provides data/behavior as a single function (
domain + data)
If it's about a product, it could be named product service.
Application
A unit that combines one or more services and a user interface (
service + user interface)
What is MSA?
It is about breaking your applications into small pieces (services) which do specific jobs that match their domain.
That is why it is called Micro Service Architecture
Should I go for it?
I can't give you an answer.
It's your call.
Just remember this before you adopt MSA.
Martin Fowler said,Don't even consider microservices unless you have a system that's too complex to manage as a monolith.
Bright side
- Can prevent the failure of Service A from propagating to Services B, C, and D.
- Able to implement distributed systems flexibly and consistently
- Free from considerations in adopting HW / SW technologies. (just matching interface will do)
- Reduction in build & test time.
Dark side
- Development complexity and proficiency
- transaction management
- testing (when multiple services are involved)
- maintenance (troubleshooting, monitoring)
Some points I want to talk about MSA
Personally, I think it's all about making boundaries of the domain.
Do Event Storming and determine where things should be.
We'll start from there.
Avoid Too Many Microservices Being Made
I saw an ugly case.
There were so many microservices, there were some services no one knew. Heard the name, but had no idea what it did.
If you consider adopting MSA,
You need to compromise at the point where your team can manage when defining the domain.
Even though the functions it provides don't match its name.
Try not to make a new domain service every time.\ If you already have too many microservices that you can't handle, merge them.
If DB transaction is a viable option, use it
Separating all the databases into pieces and implementing Distributed Transaction could be a stupid approach.
I'm not saying Distributed Transaction such as SAGA, 2PC are not good.
Those are cool stuff, but it's going to take a lot of resources to develop/maintain them.
What I'm trying to say is, DB transaction is what you can almost always rely on.
Filter out domains that can't be changed due to external dependencies
Don't mess with them.
