Thoughts On Microservices
You have a problem. You: Ah! I know! I use a distributed system. Now you still have a problem, but you no longer know where.
As somebody who accidentally became a distributed systems “expert”, I am begging you with tears in my eyes never to use a distributed system unless there is absolutely no other way.
P.S. Same goes for microservices.
What is the danger? For me, the answer comes from this quote from a guest on Greater than Code:
Microservices are an organizational pattern.
And this quote from Arlo Belshee:
Assume that a company is a data-processing system that transforms market information into insights and actions. Now, how should we scale it?
A. We could try to maintain transactional consistency and scale up.
B. Or we could try to maintain eventual consistency and scale out.
C. Or we could completely separate the problems such that we don’t have to maintain any consistency, and then fully multi-process.
Know when each is appropriate.
Combined with Conway’s Law:
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
The microservice test
If you’ve split your monolith service into multiple smaller services, do you have microservices or do you have a monolith distributed across multiple computers?
- If I want to deploy a change to one service, I have to deploy all the services at once. Same with roll-back.
- The people working on one service must consult with people working on another service before making changes.
- One service writes data to a some repository; another service reads it from that repository.
- An outage in one service means another service no longer works.
- When service
Foowants to switch from depending on service
Barto depending on some similar service
- The owners of
Barwill get bent out of shape.
Bar2means reworking a lot of code in
Foobecause it was built with
- The owners of
Finding these good divisions between services is the same problem as separating responsibilities between modules, or between classes, or between teams. It’s about coupling and cohesion. Organizations that can’t do this in one context can’t do it the other contexts, either.