Microservice architecture is a big modern hype promising to solve all your problems, such as make system more modular, move away from the monolith model, improve performance and make the system more scalable. But does it really deliver?

The Good

Splitting the system in a set of Microservices really helps in terms of company structure. Now you can allocate a different team (or even a person) to a completely separate service (independent piece of software), they are free to choose a desired technology and integrate with the rest of the system using cross-platform API. It’s like magic, there are almost no people conflicts, each team is independent and just delivers N times a day.

If you are a big organisation like Netflix it also helps you scale at enormous numbers, as now you know which microservice consumes how many resources, loaded it is, how and when to scale etc.

Another plus comparing to a monolith is that you can choose a better technology to a particular task. As you probably know there is no “one size fits all” framework for all tasks, for instance sometimes it’s much faster to create an http server in node.js, sometimes you need to work with legacy COM objects in C++, and there is complex business logic better handled with Java or C# etc. etc. etc.

The Bad

When looking at the implementers all of the companies are big names like Netflix, Google, Halo etc. They do have an enormous amount of traffic and data and yes, monolith approach just doesn’t work for them. Most of the software projects are small to moderate and hardware is powerful. How small is small? It depends on what you are doing. 99% of software happily fits on one average servers and doesn’t even need to scale out. If you do need to scale your business is successful and you need to rethink what you are doing anyways.

Another thing is over 60% of software projects fail, I won’t go into details why but it’s a know fact. Over architecting something new into a Monolith increases those changes even more.

If you are on an average software project you solution is already a monolith, you just don’t know it. You already have a separate application for a website (one microservice) and backend API (another microservice) and probably some background processing task (another microservice) etc. etc. etc. You can calm down now as you are following the modern trend.

If you don’t have a huge company and large multicultural (in technology sense) team you can’t even start exploring a massively scaled microservice architecture. How many people will actually want to use a different language or skills when they are happy with what they know and successfully delivering current solution?

The Ugly

The worst bits are there is a considerable overhead on keeping Microservices alive. Did you realise that each microservice has it’s own deployment model (one of the benefits shooting back) so you either have to create many deployment scripts and analytics yourself or hire more people to do this? Here comes the configuration and deployment hell, replacing code dependency hell.

You do need to deep your API always backward compatible so other Microservices don’t crash. It’s a lot of work, lot of testing and a huge barrier in code refactoring. You can’t just upgrade something to a new business logic, there are many steps involved in keeping everything backward compatible, deploying in sequence, extreme testing, debugging with logs only you name it.

People conflicts are coming back when parts don’t communicate together as now they start blaming each other if something doesn’t work.

If you are using a new cool technology for one of the Microservices only a few people are comfortable with you risk losing that service when those people leave the company.

There is a huge communication overhead if any services are getting “chatty” as now you’ve replaced in-memory call to an HTTP call over the network, performance wise things may downgrade dramatically unless there are experts understanding things well. There is an overhead on monitoring and watching bottlenecks which don’t exist in a monolith.

In essence every microservice architecture is a cloud monolith.

Conclusion

If you are an average software company don’t jump into modern trends. Follow common sense. If something doesn’t work try to fix existing problems instead of creating new ones.

Most of the “monolith” architectures suffer from performance not due to a barrier of scalability but because of badly written code you should analyse and optimise.

---

To contact me, send an email anytime or leave a comment below.