I agree, if you don't have junior developers (or worse outsourced developers), it is easier to maintain a well constructed monolith that has separate, focused modules, and clear boundaries between the modules. Microservices help contain the damage of bad programmer skills.
I guess my point wasn't that damage containment was a perk. I view it instead as a lack of support- either cultural or structural- from the more experienced developers.
Microservice / faas may help mask it, but you're still stuck with a lot of bad code... Only now, there's less oversight and / or accountability.
Yes but the biggest issue with maintaining "bad code" is it's brittle. You make a change one place and it breaks something else down stream. With a microservice, the invariants are well known and the boundaries are clear. It's easy to know whether you are introducing a breaking change and just create a new version at a different endpoint.
You're not wrong, but I think missing my point. This is how we end up with a hackathon golang microservice saving a company 50k a month when a simple correction to poorly written code would have done the same thing.
Granted, I only skimmed bits of that article, so I'm not sure those were the exact details, but it makes for a nice analogy.
- the code is awful, because lambdas were an excuse to keep bad developers in their own playpens (aka juniors and those who don't learn)
- the code is just fine, and would be easier to maintain if most of the lambdas were combined back into one or more "monoliths"