Why not microservice ?

We had a pretty heated discussion on #devkini group recently on the pros and cons of microservice architecture. In fact, every time this topic come up, it always resulted in never ending debate, to the point of other "religious" war in the tech circle such as Linux vs Windows, Vim vs Emacs etc.

So I'll try to summarize all the pros and cons here so that I don't have to type it again whenever this topic come back into discussion.

Firstly, what exactly is microservice ? I'll take Martin Fowler's words for this:-

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

As a disclaimer, I'm not a proponent of microservice but I'll try to not become too bias against microservice in this write up. Among my arguments against microservice is that not all organization of software engineering team actually ready to adopt microservice. Here's what I wrote in #devkini group recently:-

if you have dedicated team to maintain service A, and another team for service B, then go for microservice. But if you just a few devs already full at hand, then fwiw, go monolith.

moving over to microservice is still possible at certain point, but to go back into monolith once you regret, almost impossible.

Why would you go into microservice ? Wouldn't it be more appropriate to see the business nature, and app usage before going into that ? Here is another question from one of our member and the answer from the proponent of microservice:-

Minimization of work. Unix tools philosophy. Horizontal scaling. Containerization. Function as service. All of that.

And to that answer, I replied:-

it will end up in lot more work. You must have automation in place first before jumping into microservice. If your microservice can't (isn't) be decribed in docker-compose.yml (or anything similar) yet, forget about jumping to microservice. Otherwise you'll be spending whole day trying to setup new dev environment to fix small bug that might be creeping in between of all the services.

For these argument, Sean Kelly in his Microservice, please don't article expand it:-

While on the tin it might seem simpler to have a smaller team focused on one small piece of the puzzle, ultimately this can often lead to many other problems that dwarf the gains you might see from a having a smaller problem space to tackle.

The biggest is simply that to do anything, you have to run an ever-increasing number of services to make even the smallest of changes. This means you have to invest time and effort into building and maintaining a simple way for engineers to run everything locally. Things like Docker can make this easier, but someone still needs to maintain these as things change.

People also confuse modularity or decoupling with distribution. If you just want to achieve modularity or reduce couping in your application, you don't have to introduce network boundary to achieve that. Adam Drake in his Enough with microservices wrote:-

Don’t confuse decoupling with distribution. You can achieve decoupling by having a monolith, composed of well-defined modules, with well-defined interfaces, and you should. You don’t need to distribute your application as separate services in order to benefit from the decoupling you get by having modules with clear interfaces.

Dan Haywood in his In Defense of Monolith article expand this topic further:-

In a sense, both a modular monolith and a microservices architecture are similar in that they are both modular at design time. Where they differ is that the former is monolithic at deployment time while microservices take this modularity all the way through to deployment also.

And this difference has big implications. To help decide which architecture to go for, it’s worth asking the question: “what is it you are trying to optimise for?” Two of the most important considerations are shown in figure 2. If your domain is (relatively) simple but you need to achieve “internet-scale” volumes, then a microservices architecture may well suit.

But you must be confident enough in the domain to decide up-front the responsibilities and interfaces of each microservice. If your domain is complex and the expected volumes are bounded (e.g. for use just within an enterprise) then a modular monolith makes more sense. A monolith will let you more easily refactor the responsibilities of the modules as your understanding of the domain deepens over time.

And for the tricky high complexity/high volume quadrant, I would argue that it’s wrong to optimize for scalability first. Instead, build a modular monolith to tackle the domain complexity, then refactor to a microservices architecture as and when higher volumes are achieved. This approach also lets you defer the higher implementation costs of a microservices architecture until such time that your volumes (and presumably revenue) justify the business case to spend the extra money. It also lets you adopt a hybrid approach if you wanted: mostly a monolith, with microservices extracted only as and when it makes sense.

Shopify realized at one point, microservices architecture is hampering developers productivity and going back to monolith.

https://segment.com/blog/goodbye-microservices/

https://medium.com/@Alibaba_Cloud/conways-law-a-theoretical-basis-for-the-microservice-architecture-c666f7fcc66a