Micro service systems are just huge sprawling code bases with more glue code. Calling something over a network instead of via a local function call is still calling something.
For years one of my favorite experiences (amusing given your username) was being on calls for incidents where they get the dev on for X thing and an exec goes "I thought we got rid of that" and a bunch of people sheepishly explain it wasn't really retired... it was repurposed as an API. I especially loved it when the "retirement" of the broken thing was the execs big achievement. (The comedic nuance often being the thing could have been retired for real, but they demanded a timeline that necessitated the "fake" retirement)
It still happens but it's not a favorite experience anymore. It's just a source of loathing for MBA culture.
Another way to look at it is - why force the agent to grapple with the whole code base when they can rapidly standup many single purpose services instead?
A large code base with modules with clear interfaces accomplishes most of this and is more efficient. Often vastly more efficient. Compare the cost of a function call or an in process message queue with a network API call over http.
Cloud providers make more money the more they can get people to use inefficient designs with more moving parts to rack up more charges. Bonus if it also locks you into managed services. Double bonus if those are proprietary. Complexity benefits cloud hosts.
Microservices, like all patterns, sometimes make sense. Like all patterns they often get overused.
Yep all true. Im not really arguing a point so much as thinking out loud - I guess the core idea I'm chewing on is whether LLM assisted development is enough of a paradigm shift that things that were formerly bad ideas become good ideas - but perhaps this particular line of thought (microservices) is the wrong one.
