If you think of microservices as a modularization tool - a way to put reusable code in one place and call it from other places - then you are missing the point. Microservices don’t help solve DRY code problems.
Monoliths aren’t merely monolithic in terms of having a monolithic set of addressable functionality; they are also monolithic in terms of how they access resources, how they take dependencies, how they are built, tested and deployed, how they employ scarce hardware, and how they crash.
Microservices help solve problems that linkers fundamentally struggle with. Things like different parts of code wanting to use different versions of a dependency. Things like different parts of the codebase wanting to use different linking strategies.
Adding in network hops is a cost, true. But monoliths have costs too: resource contention; build and deploy times; version locking
Also, not all monolithic architectures are equal. If you’re talking about a monolithic web app with a big RDBMS behind it, that is likely going to have very different problems than a monolithic job-processing app with a big queue-based backend.
Adding to the theme of microservices overhead, I feel like the amount of almost-boilerplate code used to get and set the contents of serialized data in the service interfaces exceeds the code used to actually do useful work even in medium sized services, much less microservices.
It is possible that there are architectures other than ‘monolith’ and ‘microservices’. Component architectures are also a thing. If it doesn’t all deploy in one go, I don’t think it’s a monolith.
It is how a large majority of microservices gets implemented in practice.
What was originally a package, gets its own process and REST endpoint, sorry nowadays it should be gRPC, the network boilerplate gets wrapped in nice function calls, and gets used everywhere just like the original monolith code.
Just like almost no one does REST as it was originality intended, most microservices end up reflecting the monolith with an additional layer of unwanted complexity.
Okay, but if you’re allowed to submit ‘well structured modular componentized librarified monolith’ as an example proving how monoliths aren’t all bad, I’m not going to let you insist on holding up ‘cargo cult grpc mess’ as proof that microservices are terrible. Let’s compare the best both structures have to offer, or consider the worst both enable - but not just compare caricatures.
On the contrary, as the sales speech at conferences is that the mess only happens with monoliths and the only possible salvation is to rewrite the world as microservices.
Good programming practices to refactor monoliths never get touched upon, as otherwise the sale would lose its appeal.
An interview for me turned from going well to disaster because of a single mention I made that I was not a fan of seeing every single project with the microservice lens. That kind of rustled the interviewees who strongly believed that anything not written as microservice today is not worth building.
I thought that was a pretty inoffensive and practical statement I could support with points but who knew that would derail the entire interview.
Monoliths aren’t merely monolithic in terms of having a monolithic set of addressable functionality; they are also monolithic in terms of how they access resources, how they take dependencies, how they are built, tested and deployed, how they employ scarce hardware, and how they crash.
Microservices help solve problems that linkers fundamentally struggle with. Things like different parts of code wanting to use different versions of a dependency. Things like different parts of the codebase wanting to use different linking strategies.
Adding in network hops is a cost, true. But monoliths have costs too: resource contention; build and deploy times; version locking
Also, not all monolithic architectures are equal. If you’re talking about a monolithic web app with a big RDBMS behind it, that is likely going to have very different problems than a monolithic job-processing app with a big queue-based backend.