Sure, so all those things should be owned by a team rather than an individual. But that makes the whole "When a container/vm would run out of memory, we all didn't have to scramble to figure out who broke something. The person who owned the code for that service dealt with it. If a service started kicking out errors nobody but the owner had to be distracted." kind of pointless; the whole team should know about the service and be aware of any recent changes to it, and everyone should be able to debug it.
> I disagree that external services are hard to interface to. They are hard to work with when they are buggy, but if they hit the specs, they generally are not an issue.
Well of course programming is easy as long as there are no bugs! But the most important and hardest part of programming is debugging, and every time you hit a service boundary you have to figure out which side of it the bug lies on; that ends up being a significant amount of work. Practically speaking you need to implement a stub version of the service for testing with, monitoring that can confirm whether that service is up and running, maybe some kind of tracing/replay that lets you track specific problematic requests... and that's even more work for internal services, for something like S3 at least some of the bits and pieces for doing that have been built already.
> Because of the loose coupling, things were very extensible and easy to modify.
Absolutely, but you don't need a network boundary to achieve that. (I mean, maybe you do in Python because it has no visibility rules/enforcement and incredibly poor dependency management, but that's not a general problem).
> You conveniently left out "or branch".
Different commits on the same branch can be just as different as different branches. You can't have it both ways, either you keep all your services in lockstep which means you have to restart everything to fix a bug, or you have to worry about different services being on different versions. (Actually, since you normally can't restart a group of microservices atomically, you have to worry about version compatibility even if you try to always deploy new versions of everything together, IME).
> Listen, I am not trying to sell anything, I don't care what you think. I am just sharing my teams experience. It was overwhelmingly positive using services to build a complex system with real revenue from Fortune 100 customers for almost a decade.
Your post sounds like a salesperson/cultist with the "not a single engineer that ever voiced a concern over how things worked" emphasis. I've worked in multiple microservice-oriented environments including those that claimed success for microservices, and they've all either had the same problems I'm talking about, or actually not been talking about microservices but rather reasonably sized services (i.e. having teams - groups of ~10 people who worked together and had standups together - maintain one or two services each).