Microservices Are NOT The Solution To Your Problems

Last Update: 01.02.2018. By Jens in Developers Life | Learning

Microservices are not the holy grail of software development as many devs and managers see them. They don’t solve all your problems at once, not even the tech ones. Yet, they follow a fad blindly again. Yesterday it was Agile and SOA, today it’s still microservices and cloud. Instead of solutions, many find themselves facing new problems; worse problems.

I am not saying microservices are bad. They can be a good solution if you are actually facing the problem they try to solve, and your company is ready to deal with the consequences. Yes, like any architecture or pattern they have implications. You should carefully analyze those specific to your context. It must work with your dev team(s), the product and the company culture.

From a manager point of view, it looks great. This big old rectangle the devs call monolith is causing all the troubles they are facing in their product development. It seems like the perfect solution to split them up into small services. All problems now magically disappear, and all are happy again.


This level of abstraction is hiding too many significant implications. Implications management does not understand, and devs are not good at explaining implications caused by tech to a non-techie. Besides, often devs just enjoy the ride of learning something new and hip instead of solving business problems with proven stacks.

Yeah, I’ve been guilty of that myself. We all have.

I’ve seen it recently with a client again. They are intelligent people. Yet, they followed the fad blindly and wasted months of dev time. Management loved the microservice rectangles, their devs had no experience with it, but they loved it too. They implemented it for two of their apps until they hit the roadblock, which was in their case the deployment. Guess what, their software is usually installed on-premise on a single host with tiny memory limits.

Great fit, right?

They even have enough customers who lag behind with 10 years old versions. Versions they still support. With one single code base for an app. That’s not a good fit for a pattern with the goal “speed of change”.

I don’t blame them.

It’s always the same.

People following a fad blindly because they believe or where told by a consultant, it is the solution for them.

Ignoring or skipping the due-diligence phase for their particular case.

Forgetting that the big consultancies always push those fads because they make huge money with it. By blaming the old and praising the new.

No, monoliths are not per se evil. And microservices are not the Holy Grail.

When should I NOT use microservices?

First, we need to keep in mind that the only goal of microservices is “speed of change”. Anything else comes second, if at all.

Second, it is a distributed system with a focus on small business oriented services. It comes with all disadvantages of distributed systems, like complexity, network latency, network failures, performance, etc., yet, multiplied by an unknown factor. Instead of a dozen systems, we might get hundreds.

If you do not need the “speed of change” at all, do not use them. Selling software for on-premise installation? Don’t use it. Consider it only, when you host it yourself like a Saas, or it’s powering your company.

Do your due-diligence of the implications. Don’t use it, when running only small apps or your dev team has a size of 3. You can still be fast without the complexity of microservices involved. Can’t handle a more traditional distributed system with your company, then don’t bother with microservices.

Do you have the experience with the pattern? Can you hire the experienced people? No? Don’t use it.

Talk with your management and explain them the consequences in business terms. All boils down to costs and investments. If the hosting bill doubles or triples, they will think twice about if the really need “speed of change” over anything else. Oh, we need to hire new people. We don’t have money for that. Next sign you are on the wrong path.

Return on investment (ROI) is the key here. A business invests money, time, people, resources, to gain something back, primary more money.

That’s business.

Without it, the company goes bankrupt, and the employees join the force of the workless.

As devs, we often forget those things. We think about code, code quality, code smell, design pattern, the latest hip framework and all that shit to an extreme of worshipping a tech god.

Only the tech is necessary, everything else is bullshit; management, marketing, sales and the other are just a bunch of morons who have no clue at all, are lazy, evil, whatever.

Forgetting, that without the business all the code does not matter. And running a business is more than just code.

It is our job as devs to create systems to solve the needs of the business. Part of that duty is choosing a good solution for the particular situations we are facing.

There is no right, perfect solution for anything.

So, do your due-diligence phase and choose a way that is beneficial for the company and not your curiosity.

If the result is a current fad, be it, go with it. I am not holding you back.

Otherwise stay out of it.

Like mom always told, “if all your friends jump off of a bridge, do you jump too?”.

Want content like this in your inbox each workday irregularly? No BS, spam or tricks... just useful content:

I understand and agree to the privacy policy