The Setup

Of the last 5 projects that I have been in, 4 of them had microservices. And my estimation is that we were hurting our development speed because of it.

Of all the projects that I have ever worked in, there was one that had a monolith, and I thought they would benefit from having a transition into microservices. I have worked on a company that went straight in for microservices and it worked very well. I did work on a company that was trying to break their system and move to microservices, for some good reasons. For a while I worked on a company in which the CTO and the architect had some different views, and was brought to help to transition to microservices … but the architect convinced me there was no need (my phase of microservices everywhere ended thanks to him). And every other company where I have seen microservices, there was no good justification to have them.

And as I was thinking about writing something about it a post called You want modules, not microservices came out (lovely read)

Microservices are good … in a context

Last year someone told me “Microservices is the best architecture”. Without caveats. And I just couldn’t disagree more.

I do like microservices, they solve certain problems that you acquire at size. But if you don’t have that size, their cons are a massive drag in the process of creating a product on good time.

The biggest characteristic of microservices is that there is a trade-off simplifying codebases at the cost of operational complexity.

When we are talking about operational complexity that includes deployments, logs, monitoring, even performance optimization. All of it is more complicated. You require additional tools, additional time, additional cost.

But even the development process can at times be more complicated. Changing a business flow involves multiple systems. Redoing your domains becomes more difficult.

You don’t need them

If the development team is 4, 6, even 10 people, you are making your life far more complicated trying to use microservices, without reaping the benefits.

If your application is going to have 10000 signed users … there is no need for scalability (and even so … vertical scalability is so much cheaper in a lot of scenarios)

If your system is going to process 10 requests a day, you could run it from the laptop that was forgotten in the cabinet drawer.

If you are creating a completely new system, is more important to get the system out than to have the ultra-duper-horizontally-scalable-fully-independent-architecture.

Only employ microservices when you are hitting the issues that they set to fix. Until then YAGNI.

Options

You could follow the great advice from Matt Belcher on this post.

Or you can list to Sam Newman, microservices evangelist or something extraordinaire, who recommends (in general) not to start with Microservices