I think the framing of "monoliths vs. microservices", with the implication that you must either have a mountain of a codebase or a beach of grains of code-sand, is not helpful. Good modularity means that different levels of tradeoffs can be made without huge effort.
True, that's why I titled the article "Modular Monolith and Microservices: Modularity is what truly matters". Modularity is crucial here - you can mix it up on multiple levels; having a single modular monolith, a few bigger services that have many modules inside each or finally, microservices where you treat each service itself as a module.
Modularization is what's primary here and gives you flexibility; not having one vs multiple units of deployment
> microservices where you treat each service itself as a module.
Microservices is where you treat each team of people as their own independent business unit. It models services found in the macro economy and applies the same patterns in the micro economy of a single organization. Hence the name.
The clearest and probably simplest technical road to achieving that is to have each team limit exposure to their work to what can be provided over a network, which is I guess how that connotation was established. But theoretically you could offer microservices with, for example, a shared library or even a source repository instead.
Microservices was originally envisioned to literally create the smallest possible service you could, with canonical Netflix use cases being literally only one or two endpoints per microservice.
Which is great I guess for FAANGs. But makes no sense for just about anyone else.
> Microservices was originally envisioned to literally create the smallest possible service you could
"Micro web services" was coined at one time, back when Netflix was still in the DVD business, to refer to what you seem to be speaking about — multiple HTTP servers with narrow functional scope speaking REST (or similar) that coordinate to build something bigger in a Unix-style fashion.
"Microservices" emerged when a bunch of people at a tech conference discovered that they were all working in similar ways. Due to Conway's Law that does also mean converging on similar technical approaches, sure, but because of Conway's Law we know that team dynamics comes first. "Microservices" wasn't envisioned — it was a label given to an observation.
Microservices came about because Netflix and soon some other FAANGS found they were so big that it made sense to make single-function "micro"-services. They literally chose to massively duplicate functionality across services because their scale was so big it made sense for them.
This is great for FAANG-scale companies.
It makes little sense for most other companies, and in fact incurs all of the overhead you would expect - overly complex architecture, an explosion of failure points, a direct elongation of latency as microservices chain calls to each other, chicken-and-egg circular references among services, and all of the mental and physical work to maintain those dozens (or hundreds, or thousands!) of services.
The funny thing to me is people point to monoliths and say "see, problem waiting to happen, and it will be so hard to undo it later!". But I see microservices, and usually the reality is "We have problems right now due to this architecture, and making it sane basically means throwing most or all of it away".
In reality, unraveling monoliths is not as hard as many people have made out, while reasoning about microservices is much harder than advertised.
Tooling in particular makes this a very hard nut to crack. Particularly in the statically typed world, there are great tools to verify large code bases.
The tooling for verifying entire architectures - like a huge set of microservices - is way behind. Of course this lack of tooling impacts everyone, but it makes microservices even harder to bear in the real world.
Forget about convenient refactoring, and a thousand other things....
Nah. You've made up a fun story, but "microservices" is already recognized as being in the lexicon in 2011, while Netflix didn't start talking about said system until 2012.
> This is great for FAANG-scale companies.
Certainly. FAANG-scale employees need separation. There are so many that there isn't enough time in the day for the teams to stay in close communication. You'd spend 24 hours a day just in meetings coordinating everyone. Thus microservices says instead of meetings, cut off direct communication, publish a public API with documentation, and let others figure it out — just like how services from other companies are sold.
If you are small company you don't have that problem. Just talk to the people you work with. It is much more efficient at normal scale.
