Microservices The Hard Part
Today microservices are a red-hot architecture, and everyone wants to use them. It is cool, but some issues happen only on the fly, and people rarely speak about them. Today we will see some of these issues.
Intro
If you are starting to surf the wave of scalability, DevOps, and this kind of stuff, then you probably do not know that microservices come with some issues that can drive you crazy.
There are some aspects of microservices that few people are talking about, and we only face it when we already have lots of services running. Here I will write a bit about three of them.
Hard to debug
When one monolithic is broken up into microservices, emerge new connections and flows that never were there before. If some bug happens on the surface, it can be chaotic to find the real issue.
If you don’t use a support system to trace requests like New Relic, AWS X-Ray, Data Dog, or another tool. It will be hard to find the root cause inside services’ communication.
Can be slow
When we have many services changing information between each other, it is easy for everything to become slow. One application that stops scaling well is enough to make all the system works worst.
We need to take a lot of care when we draw this kind of architecture, to don’t give too many responsibilities to a single service. We need to pay attention when using message brokers and let go of the HTTP way.
One can crash all
Working with many services, we need to take a lot of care to divide responsibilities, to not build bottlenecks where a single one can break them all. For example, if you have a service just for authentication, then every other service needs to call the authentication before each action to certify that this request is valid. Then you could have a bottleneck at this point. Maybe you could solve this in another way. Sometimes are better to have a lib than a service in cases like that.
Conclusion
Of course, microservices are great, furthermore, it is the way to aim for the dreamed scalability, but everything has trade-offs. I choose to bring here some bad points because everybody talks about the better ones. I don’t need to make it too.
Before implementing microservice architecture in your company, consider reading about event-driven architectures. Also, make sure you know about systems that can help you analyze and debug the production environments in distributed applications. Finally, avoid services that can become a bottleneck.
It’s not about to demotivate you.
It’s about showing avoidable mistakes.
Best regards,
Robson Andrade
Cloud Solutions Specialist
