I've see this happen to a number of friends. Most of them have enough saving that they can 'retire', but none of them wanted to retire yet. It often means moving away from friends to implement a lower cost-of-living. Once you are >40, it can be hard to find a job. You are too experienced for mid-level roles, but your core skillset may no longer be relevant. e.g. There are far fewer Win32 developers than 10 years ago, but retraining to be a web developer can be a big challenge. I've also seen people get promoted to a managment level, based on a targetted skillset, where it can be hard to find find a new role.
As a customer of serverless, you do not have to manage any servers, that is provided by the platform. Even with a platform like EKS, the customer is still responsible for selecting instance type, OS/AMI and any OS updates. With serverless, the customer doesn't worry about managing their servers, they just enqueue tasks (function invocations) and let the provider worry about right-sizing instances types, OS updates, etc.
Having worked on both AWS and GCP, my experience was that AWS had a much better organizational grasp on how to price services. They track the predicted revenue/costs compared to the observed, and expect each team to have roadmap projects to improve that ratio over time (or at least to keep the ratio the same as they drive down prices). When I was there, Google has not such process for tracking their costs. Engineering teams had much less understanding of their costs as well. I never worked on Azure, but I heard similar stories there to my experience at GCP; that there was no institutional process for reducing costs.
Building top down process to improve costs to enable price drops is one of Amazon's core strengths. It is core to how they run all their businesses.
S3 explicitly changed their license to allow copying the S3 API. I forget the year, ~2010? I was working an S3 at the time and it was a strongly debated decision.
Google’s initial launch of their cloud storage copied not just the S3 API, but also the error codes.
Some of the cultural issues around avoiding virtual came from hard lessons with v1.0. After shipping v1 they realized that there were a large set of security and compatibility issues with not having framework classes sealed. No-one I worked with really like the idea of sealing all our classes, but the alternative was an insane amount of work. It is just too hard to hide implementation details from subclasses. If you don't hide the details then you can never change the implementation.
I can't say for swift, but there were also real security challenges. It is hard enough to build a secure library, but to also have to guard against malicious subclasses is enough to make even the most customer friendly dev run screaming. My team hit this and it cost us a huge amount of extra work that meant fewer features. vNext we shipped sealed classes and more features and the customers were happier.
Last I checked, Eucalyptus is missing an number of the APIs that customers really use once they are doing more than just hosting a few VMs. Access control, security, VPN... The service providers are actually quite different and any attempt to standardize is just doing to be the least-common-denominator, which is going to be missing a great number of useful features.