> Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure.
At the prices AWS charges this was never a requirement even before virtualization became a thing, much less API-driven cloud environments until you reached such a scale it simply didn't matter. I owned a fully managed dedicated server provider in the late 90's/00's where the customers never even logged into their machines - we handled all that for them and provided what essentially were an early primitive form of infrastructure APIs - FTP, HTTP, SMTP, etc. Certainly complexity has increased, but there are many models between consuming MySQL as a vendor lock-in service, vs. running MySQL on bare metal machines you hand built and racked in your own datacenter.
There are far more options than to use the AWS/GCE/etc. "SaaS" offerings that are company specific. I completely agree standing up infrastructure via code is almost a requirement for many businesses these days - I would (and I'm very biased here - I work for a small infrastructure provider) much prefer to see a slightly larger premium being put on solutions that don't promote lock-in. I'm also old and cranky, so seeing things like "resizing jpegs as a service" still makes me think the industry has lost it's collective sanity :)
I think my concern is not that you require a set of functional APIs to stand up basic infrastructure - this is certainly very reasonable. For me it's more the direction of the "outspoken self-described leaders" in the industry seems to be towards consuming more application-specific infrastructure services that come with them huge lock-in costs, as well as long-term opex once you hit any form of scale.
I'm working on a quote now that is taking a $200k/mo AWS bill down to a $18k/mo co-location bill, where we handle absolutely all networking, hardware, or other "bare metal" related issues for them - they just have us stand up a k8 cluster for them, and we handle the underlying things like monitoring for hardware failure. While certainly not perfect nor as seamless or easy as AWS they largely get similar means to consume their infrastructure, and pay a tenth of the cost. All without hiring any ops folks to deal with servers. However they get to spend 6 months unwinding all the amazon-specific code they now currently rely on, so it's not an easy sell as that cost (both in real dollars as well as opportunity cost) is far more than the savings they will see on this deal through it's lifetime.
They are making this move as they see their current lock-in as a long-term strategic risk for the company. Especially as they look at the constant march of increases to opex as AWS bills increase.
These are of course my own opinions only :)