Microservices have revolutionized how projects are scaled. They have helped developers manage gigantic applications. Even though the concept of Microservices has been around since last century, it started gaining traction only recently in last decade with the revolution in Cloud storage. Today, there is a plethora of companies providing cloud services. The cloud was found to be easy to maintain and scale. Then came Docker and everyone lost their minds with containerization. No matter what you are working with, everyone wants to use microservices and host them on cloud.
Let me clarify that I am not against microservices architecture in general, what I am pointing out is using microservices architecture blindly just because someone else is using it or just because it is the norm now. So, hear me out, before you start getting your hands dirty with code to create microservices, make sure you are familiar with the following things:
1. They consume a lot of RAM overall, like a lot:
The reason microservices consume more aggregated memory is that they need to spin up the whole JVM, in case you use java, and the container with OS, if you have containerized your project. If you are using a cloud, then this alone will make you bleed money and the bills will bring you to tears.
2. Synchronization:
To make things work synchronously is a pain with microservices. It’s true that you could design a system in a way that could reduce the delay as much as possible but the CAP theorem(consistency, availability, and partition tolerance) will always win in the end.
Dealing with synchronization will keep making the system complex. No matter what you do, if you have a message queue, it will be a pain to synchronize these services.
3. Setting contracts:
When two microservices need to talk, there needs to be a way to set up a contract between them. Many a times you will need DTOs to establish contract to make sure the exact same datatype is shared among services. Keeping the same DTOs in multiple microservices will just increment the number of compiled classes overall. Basically, a violation of the DRY(don’t repeat yourself) principle.
4. Separation of concerns at Database levels:
If you follow the principle of separation of concern at a functional level in microservices, then with each microservice that is separated on the basis of functionality, there is a need to have a separate database. Even if we leave the cost of acquiring database licenses aside, there are still many technical challenges of mapping fields from one microservice with another. In the case of a single database having multiple tables, this could be easily achieved by joining these tables.
5. Local Development:
Forget about the good old way of spinning a project on your local machine, adding a feature, and pushing it to git; with microservices, one needs to invest money in hardware and will have to purchase multiple servers to run them on each because running all on one will not be possible as you computer will easily heat up and curse you for such atrocity.
6. Security:
The more the number of microservices, the less secure it is because every microservice will need to be checked and secured. In order to share data among microservices, one will need to set up some kind of token-granting mechanism to make sure only the right access and authority go through. Whereas, with a monolithic architecture, this needs to be done just once when the first call is made to access the service. So, one will need to invest in a good Ticket/Token granting mechanism. Remember, with more microservices, comes more expense of securing each of them.
So, if you really have a use case where you need to do horizontal scaling of your system, be my guest and use microservices architecture. If you are working towards solving very complex functionality that requires a lot of people and teams, then for sure microservices pattern is a great thing to use, but don’t do it just because some Tom, Dick, and Harry is doing it.
Hope you have a great day. Happy Coding :)
Want more like this?
Subscribe and I’ll send the next post straight to your inbox.