Microservices all the way, or not?

A few years back, 6–7, I’ve heard about the concept of microservices for the first time. My first question was: what’s the difference between a microservice and a service? After that the next question was: how small should a microservice be (aka, how micro is a microservice)? In the end, after a codecamp edition, I’ve started to think about what will be “the new trend”? Everyone will build up microservices, or continue with monoliths? It seems everyone has their own opinion and to be honest, I don’t think it is a good or bad answer to that. (If you thought that after reading this article you’ll know if you should go for a microservice architecture in your new project, or if you should “support” this type of architecture on your next interview then you can stop reading. You won’t get your answer).

As I previously said, everyone has their own opinions:

“Start with monolith and extract microservices” — Tammer Saleh (The entire thing can be found here)

The same opinion can be found here, in an article written by Zhamak Dehghani, but, if you start with a monolith and then extract it into microservices, will you really get a microservices architecture or just a distributed monolith? Is this what you want to achieve?

“Don’t start with a monolith when your goal is a microservices architecture” — Stefan Tilkov (The entire thing can be found here)

This makes more sense if you know that you need a microservices architecture, but, do you know how to handle it? Are you actually sure that you want to pay the price for it?

“If you can’t build a monolith, what makes you think microservices are the answer?” — Simon Brown (The entire thing can be found here)

I think this is the best quote on the subject. If you can’t build a monolith what makes you sure that your “workaround” is a microservice architecture?

As you can see, everyone has their own opinions and this is mine: You shouldn’t build a microservice architecture if you/your team/your organization is not prepared to handle one. It’s much harder to maintain it, to work with it to deploy it and you need a completely different mindset vs in a monolithic architecture. For example, if you don’t know what a correlation id is, or if you have no clue how logging works in such an architecture, don’t know about saga pattern, you shouldn’t try to build your app based on one, because you will get a very hard time and no fun. You will end up with services calling multiple other services which will call other services and you’ll get “spaghetti calls” very hard to debug.

If you still think you want to have one, or think it’s the best thing that happen/was invented, then I want to give you some key points that you should keep in mind since I found them very helpful:

1. Train your teams. Each member should think that any other “thing” that is using the microservice that he is working on, is a client of it. He should document well the “things” that are public for the clients and try to facilitate an easy integration. (P.S. Keep in mind that an average team doesn’t really have the knowledge of how to handle a microservice architecture; after all, first appeared in Netflix. Do you really think your product is as big as theirs?)
2. Trust your teams! One of the main benefits of a microservice architecture is the fact that each team can develop (their) services in any language they feel fit. They should be able to scale them, release their work on them, independently. Since they can work in any language, they will have fun and since they can work in parallel the time to market will be faster.
3. You will get better fault detection and isolation. Basically, your system will be able to recover from a problem that happens in a specific microservice, but for this, you need to have a good logging (and tracing) system and you need to implement circuit breaker pattern and maybe other “tricks” so that if a microservice is down, or has latency, your entire system won’t go down, and the recovery will be made automatically without the intervention of any developer. You can also include a retry mechanism, which can be easily implemented with Polly in .Net. Fail fast is a big thing in such an architecture.
4. S from SOLID or SRP. The microservice should do only one thing. Building a microservice that will be changed for more than one business context, is a bad practice (and even design)
5. Have its database. I know it’s hard and maybe counter-intuitive, but if all your services use the same monolithic database, will in the future become a bottleneck, plus, what will happen when your database will be down? The entire system will go down. Why did you invest in a microservice architecture if such a thing happens? (Even if I’m pretty much against using this anti-pattern, you should go for it, if you still have a dedicated DevOps team for all microservices).
6. Service communication should be loosely coupled. If your services are coupled, you don’t have a microservice architecture. You have a distributed monolith, which is the same as a monolith plus the latency so…it’s bad. Try to use a service bus or even async call directly the other service but try not to become dependent on a response.
7. Each service should have its dedicated infrastructure. If you have 5 microservices on the same machine, and that machine goes down, it’s bad! Each microservice should work in its isolation.
8. Always have good versioning. Your clients should be able to choose when they want to migrate to the next version. You shouldn’t force them to change, because your microservice changed and if you have it breaking changes, to sure all your changes are backwards compatible.
9. CI/CD should be 100% separate. Each service should be able to be built and deployed separately. The team shouldn’t be dependent on another team on the deployment level (or any other level).
10. Your team members should know the difference between orchestration and choreography and use what they need when they need it.
11. You will need A LOT of integration and acceptance tests / consumer-driven contract tests. You will need to be sure your microservice behaves as you expect in almost all situations.

The entire idea of microservices is an old one “modernized”: Divide and conquer. It’s nothing new about this, it’s just the way that it’s implemented. The complexity just moved from code to infrastructure.

You shouldn’t start implementing a microservice architecture if you are searching for a short time benefit, or if you don’t have senior developers and architects in your team. I found it very hard for juniors and mid-level developers to comprehend the complexity of such type of architecture. It’s not impossible, but hard and the price that you will pay it’s too high in my opinion.

I will end this article with a quote from Martin Fowler:

“Microservices introduce eventual consistency issues because of their laudable insistence on decentralized data management. With a monolith, you can update a bunch of things together in a single transaction. Microservices require multiple resources to update, and distributed transactions are frowned on (for good reason). So now, developers need to be aware of consistency issues, and figure out how to detect when things are out of sync before doing anything the code will regret.” (Entire article here)