Are microservices bad?

One of the most recurring argument on the web about DevOps, is microservices and how useful those are.

But.. Microservices are good!

It only depends how many they are and how much time you plan to allocate maintaining them. We had about ten microservices. Each one doing something very specific.

A good application, in my opinion, is for large business where you have different IT departments, also maybe with different knowledges. You can afford to have a server in Java and another in NodeJS, for example.

Maintaining microservices

In a team where you have many developers, you will be easily able to solve bugs and upgrade modules when security patch are released.

If your company has only a few developers, microservices are very bad. The time you put gluing pieces together is too much and the result is a slow process in delivery your software.

HA

You have to think about this. Clustering many services needs more hardware resources and obviously, not for free. I will write a specific post about this.

Reality

You may not have many developers. If is this the case, there is no need to split the code into many pieces. Separating concerns is good but excessive fragmentation easily become the bad.

Sometimes you have to patch a dozen of microservices just because a new security fix for a package you use on every single service, came out. This is very time consuming and time is money, full stop.

We had a dozen of microservices in production. Patched them many times. Spent a lot of time in maintenance.

Discovering how many services we had, was a very «funny» and expensive task. As an addition, each developer wrote the code in the best way in that moment was good to, but that way was not good for the the rest of the services, leaved unmaintained for months, becoming the ugly service-no-one-want-to-put-his/her-hands-on just because the framework used was not funny anymore.

If you like, read this article to better understand how it feels writing Javascript. https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.rgiji2j7d)

We, some months ago

Here’s a list of services we had in production, each with a different NodeJS version, each with a different framework, many without framework, just code put together:

• login
• signup
• portal
• portal-legacy (for some old partner, ruby made)
• dashboard (ruby made)
• radius-to-our-services connector
• proximity framework
• statistics calculator

We, now: a monolithic core

The right solution for us, was to put all services together. As a result, we now have a unique entry point for our services doing all we need. It’s easy to fix bugs, just because the framework is one, well known and documented. Understood how it works, you can easily put your hands in every single part of it.

As a result of many months of refactoring, we now have a super-tested core, with many modules, each of those, is using the same paradigm and this is good.

Conclusion

Microservices are not as bad as you think but can easily drive you in hell, so be careful and think twice before splitting your codebase.