A mature service mesh will let privileged users get inside containers to attach profilers and debuggers, manually as needed or systematically through performance monitoring tools, in situ or with temporary exclusion from the load balancer pool. It's also sometimes necessary to correlate issues with host-level metrics to understand weirder bottlenecks and tail latency issues.
> it rarely happens
The credible threat of it happening keeps prices low enough to make it unnecessary.
As far as vendor lock in, in general not just with respect to the cloud, there are so many path dependencies and the risk of disruption versus the reward is so rarely worth it, it hardly ever happens.
How much would Oracle or Microsoft have to raise their prices on their database products for instance to make it worthwhile for a large enterprise company to move away from them to an open source alternative?
I agree with the general sentiment that optimizing for extreme portability does not make sense- but there is a balance that needs to be struck. Designing your apps to be relatively SQL agnostic, or at least isolating those dependencies, makes a lot of sense.
What about all of the programs that you used that depended on Oracle specific drivers. Even in a perfect world where everything was using standard SQL, would the regression testing and migrations be something you would want to tackle as a CTO? Would you be willing to take the reputational risks of something going wrong?
Two broad use cases for serverless -- event based triggers and APIs. With event based triggers you're already locked in by the events you're subscribing to and as far as API's, at least with AWS, if you're using proxy integration, you can use your standard Node/Express, C#/WebAPI, Python/Flask, etc. framework. You add a few lines of code for the lambda proxy but you can use the same code without any changes with your standard web servers.
With AWS, you also have "serverless Docker" with Fargate and you use standard Docker containers.
Production debugging? The same issues and solutions with any micro-service implementation. The solution usually being a common logging infrastructure.
On a broader scale, "vendor lock in" is severely overrated. Despite all of the "repository patterns that will let us hypothetically move our million dollar Oracle implementation to MySql", it rarely happens and often you end up with sub optimal and more expensive/harder to maintain solutions by not going all in on your vendor's of choice solution.