The worst thing about microservices is the name
The name Microservice did nothing but harm to the great concept that’s hidden behind it.
Few years back, there was an enormous hype about microservices. People were discussing how small is small enough. The problem is, that was never the point of the idea.
Monolith
Personally, I think, that the best way to start with a new project is to start with a monolith. But not a big-ball-of-mud throw everything everywhere type of monolith. A well designed piece of code, covered with tests. Written in a way, that in a few years, when you will have the needs, you can safely restructure existing code, or even extract it as an external service.
Mind your team-structure
You cannot overcome Conway’s Law. You have to accept it. If you have a small product/development team, working with a big number of sub-systems, will be a pain in the ass, and Developer Experience will be harmed. If your product is developed by multiple teams, sharing a sub-system or having an “orphaned” sub-system is even worse.
Trade-offs
With the distributed architecture, you have to be ready to accept trade-offs, and to explain these trade-offs to the business. It’s almost certain, that you will have to accept eventual consistency. Creating business reports won’t be as easy as when you had all of your data in one database. Life won’t be as easy as it was with the one monolith system. But it may pay off. Depends what you are looking for.
Boundaries
One of the biggest issues, when trying to design a system that’s composed of many cooperating sub-systems, is setting the boundaries. My rule of thumb, is that any sub-system should be treated as an independent company, with which you have to cooperate and negotiate about the external interfaces and data sharing. It may raise some controversy, but if you want to have a stable system, you have to be cautious about all of the connections between the sub-systems. Make them as decoupled as possible. Draw boundaries only where you are pretty sure where they go. You have ecommerce + erp as a monolith? Fine, at first, draw a line between ecommerce and erp. Refactor it. Create a “logical” separation in the codebase, where you can’t just grab anything from another part and throw it into another one. Create some interfaces. Experiment with asynchronous communication. You will learn how it is to live with a boundary in your system. And remember, it’s easier to manage one boundary than to mange 10s of them. When you will learn about the other boundaries, and you will see value in extracting another sub-system, you can perform a further refactor.
Data bounding
It’s related to the boundaries. Even if you have a service that is pretty much separated, at some point you may have to exchange data between them. It’s another thing you have to accept —sharing data synchronously to another system, puts the upstream service in place of handling potentially high traffic. Asynchronous data synchronization gives you eventual consistency. If you don’t want to loose data, you have to implement the outbox pattern, and have another sub-system in your system — some kind of a message broker, like RabbitMQ.
Reasons
Before creating a distributed system, you should ask yourself “Why?”. In my opinion, there are only a few reasons:
- Stability. You want to separate crucial parts of the system from less crucial ones. Blog part of the system is not as important as order-placing, right?
- System diversity / scale. If your system is so diverse, that it has multiple products and product-oritned teams, separation between them can bring a lot.
- Hot paths. There is a part of the system that is improportionally more used and we can benefit from writing it as a separate system — to make it more stable, write it in more performant language, etc.
And to be honest, I don’t see much more beyond it.
As you can see, I didn’t even use the term “Microservice” while explaining my point of view. That’s because I think this term is misleading and creates a lot of confusion, especially with people less experienced in system design.
