Microservices EVERYWHERE

I dare to say this statement is true in almost all the areas of human activity. The same holds true when to use and when not to use microservices. Microservices are a pattern. When do we apply a pattern? When we need a solution to a problem.

The problem is what matters. The need we are trying to accommodate. Quite often I see patterns blindly applied without the actual comprehension of the underlying issue. What is my favorite reason for using microservices?

If I got a nickel every time I hear this, I’d have been a rentier by now. Let me tell you a secret:

In overwhelming majority of cases, there is absolutely ZERO need for any kind of scaling. Nada, null, nothing. It requires awful lot of users accessing our system to force us to scale it. How much data can we keep in a single PostgreSQL database? Well, around 20TB with reasonable response times. How many concurrent requests can we handle on a single machine? Tens of thousands using Spray and Akka.

Of course, it boils down to the context again. What we are doing with the data, the constraints we are facing, etc. However, if we believe we need scaling to handle a few tens of users, we should stop right now and immediately rethink and rework whatever we’re trying to achieve.

You might want to argue — but what if our service fails, scaling helps us there, sure? Well, that’s what resiliency is for. Hot-standby setup is likely going to cover most of the situations we encounter. And I’m not arguing just semantics here.

Now, what is the likelihood of our product ending up on top of ProductHunt? 0.0001%? There is nothing wrong with being optimistic, but let’s keep it real. Instead of spending our time on making the ultra-mega-dynamically-scalable solution, we could have realized more value for our customers or users.

I’ve just saved us a lot of money right there. Getting back to the topic of microservices, there is my second favorite reason to use microservices:

Microservices to save the day, right? Now I’m close to become a billionaire. As the popular saying goes: What is worse than a ball of mud? A distributed ball of mud! Microservices are not going to fix our software development culture. Au contraire, they will complicate our lives immensely in this case. Introducing all the complexities of distributed systems and a state of the art automation into a big mess never goes according to plan.

The true culprit is our wish to untangle the Gordian knot which our codebase started to resemble. Now we need to be honest with ourselves. How did we end up in this mess? Has there been an issue in our process? Did we bite off more than we can chew? Is team acting as a team or bunch of egos? Such an introspection will tell us where to focus the effort when fixing a messed up project. Obviously, using agile and lean practices is a huge win since they incorporate internal feedback mechanisms from the beginning.

So what should we do when we develop software? I suggest following:

…​as needed based on strict KPIs.

When our team agrees on this in the beginning of the project, it naturally leads to better internal design of the monolith — since everyone is expecting bits and pieces will be eventually extracted. What are other advantages of such approach?

Such a process offers plenty of leeway to evolve our product while the focus is still on the business value brought to our customers and users. And the value turns into profit…​ eventually :)