Separation considered harmful
By: Tomasz Smykowski
Tags: Ngrx, Front End Development, Programming, Web Development, React

2. Microservices

When we will move forward, data reach at last to the frontend code. A place where separation takes its toll on many ways.

Lately a popular subparadigm of separation was born. It is called microservices. Aside from the literature about that approach, it is understood differently from person to person.

Microservices, micromanagement both fall into the same category. In theory, microservices are great because you can separate domains, and set different teams to work on different projects. Everything is separate so it works awesome.

The problem with the usage of microservices is however, that people don’t know when to split a service into microservices. Just like no one really knows where is the line between micromanagement and management.

But in both cases everyone can learn it is a wrong deduction process result in most cases. But what is wrong with microservices?

Creating microservices generates a lots of overheat. Every microservices needs to maintain its own dependencies that are mostly duplicates. They need to duplicate a lots of boiler plate. Not to mention that design, style, common code has to be in some way shared between them.

Not only these reasons, but also other cause microservices maintaince to be very expensive. So when they should be used? There are two things that can balance out the cost of splitting project into these. First is when the project is really huge. I mean — huge. People doesn’t know what it means. So let’s use an example: when you build an operating system. Or a bank software. Than, building microservices can be helpful.

Another requirement is that you can clearly separate microservices. They are totally different things. They don’t share more than 1% of common stuff.

Now, we don’t write operating systems or bank software every day don’t we? So using microservices won’t balance the cost.

Above of what I wrote before, it is not only that microservices are for huge systems. Where “micro” really means gigantic piece of software. Because I believe some people know about it. But still decide to use microservices to prepare the code for the future. Will it become an operating system or a bank software? I hope it will, because of it is not set up as a year long milestone, it is a premature optimization. One of the worst kind of mistake that can be done.

As long as you read it it may seem like I wrote: microservices are great but for larger projects.

But the greatness itself is also a matter of debate. Are they really? In a standard process of applying solutions there has to be a problem, analysis, conclusions, and a solution.

It is great to thing about what problem we solve rather than pick up every solution available. So what problem constitutes implementing microservices?

Among others a trouble with maintaining codebase can be heard. During my 20y dev practice I have seen it sometimes. And almost always the problem was one: the code was a mess.

The quality of code, refactoring real tests, proper layers, programming to language, not on a language, engineering the process, and so on. If it comes to improving code quality and maintaince process there is a lots of proven ways that work. Ways that were practically applied to hundreds of thousands of projects with success.

But not even one of such method tells that person should take garbage cans and place them in multiple rooms to solve the problem of a mess. All the person does, is separates a mess with some more messy wires.

Clearly microservices are one of the greatest examples how separation paradigm can be harmful. It is a bad solution to badly stated diagnosis (if even!)

Before considering microservices an analysis has to be made. Proper ways of handling problem is to choose solutions and apply them. Not the other way around. It’s like with micromanagement. If you feel the need to do it, it does not mean your employees work wrong. It means there are other problems to solve and micromanagement won’t help but make it worse.