Many companies would be better off however using cloud services since the "lockin" still costs them less than the overhead of running xyz service them self. Lock-in is only important if you have a cheaper way to run something, not if you're hiding costs in IT salaries for operations. :)
> Lock-in is only important if you have a cheaper way to run something
False. Lock-in is a business risk, and anyone who thinks it isn't is kidding themselves.
If you are dependent on a single vendor for a non-standardised service, you are also at risk if the vendor goes out of business, if the vendor decides to raise prices significantly, if the vendor decides to discontinue that service, or even if the vendor decides to change the mode of operation for that service.
You are also beholden to that vendor's internal procedures, and tech decisions, which aren't always in your best interests. You may remember last September when there was a fucking massive AWS outage, where customers couldn't access the console, EC2 instances wouldn't spin up, etc. The fault for all of that, was a network disruption which caused DynamoDB to flip it's shit and make "the worlds biggest cloud provider" into the worlds biggest brick shitting machine.
They've probably made changes so that type of error is less likely in future, but that doesn't matter because you don't get to make that decision if you're a single vendor customer on AWS. Whatever choices they make, they make for you.
> hiding costs in IT salaries for operations
Here's a pro-tip for you: use of AWS/Azure/Google Cloud/etc doesn't absolve you of the need for operations staff. If you think your single nodejs developer is equally skilled and has enough time to setup and maintain your infrastructure just because it's dynamic and has a browser interface, I have a great investment offer for you, in magic beans futures.
All of this is accurate. Also on the infrastructure deployment and maintenance side, virtualization already vacated the need for any ordinary organization to spend time worrying about infrastructure. You just rent colo and slap hypervisors in.
There are still organizations messing around with overly complex internal server systems because they have bad admins or are heavy in technical debt, but these are no longer the rule.
For most clients I work with (who often have this "oh but shouldn't we use AWS, they're the best right?" attitude) even a few rented VPS (i.e. on shared hardware) is sufficient.
I'm a big fan of the way some providers like Rimu allow more control, which helps with scaling up - by default most customers just use one or more Xen VM's on shared physical hosts, but you have the option to rent dedicated hardware (either existing stock, or custom orders), and then you can run one or more VMs - without noisy neighbour concerns.
The "single vm on a host" seems weird to most people at first, until you realise that it allows you to migrate the VM between physical hosts.
Sure, the new hotness is servers-as-cattle and we should just provision a new instance, but that doesn't always work for smaller outfits.
