[M_Bakhtiari]

> "the cloud" is, and always has been, antithetical to Unix (Unix being about site autonomy and simple tools working together)

Does the physical hardware being on the actual premises or not really have anything to do with "site autonomy" or the granularity of the toolchains?

In fact, can you even buy any viable physical hardware to run on your site that's not already a virtualised "cloud" with the real host OS firmly in the control of your corporate overlords, e.g. Intel ME and AMD PSP?

[dijit]

I'm going to go against the grain here and say that the cloud is not simply 'server hosting' because, if that was the case we'd still be calling them VPS'.

"The cloud" is a set of APIs for provisioning but also a bunch of managed services that surround your instances, pub/sub, DNS, load balancers, managed SQL. All of this is almost designed to be a vendor lock-in.

However, disregarding the vendor lock-in: How does my OS integrating with AWS's APIs help my on-prem services?

[M_Bakhtiari]

> "The cloud" is a set of APIs for provisioning but also a bunch of managed services that surround your instances, pub/sub, DNS, load balancers, managed SQL. All of this is almost designed to be a vendor lock-in.

A lot of it is, but I strongly disagree that all of it is. Many of these are perfectly interchangeable with the exact same software (FOSS DBMS, web server, load balancer, etc.) running on a competitor's managed service, VPS or on your own premises. As for the services that aren't, I do think the IT architects and managers who agree to use them are absolutely crazy and ought to be fired. If all of them are fired, cloud providers would be forced to provide interoperable provisioning APIs and services or perish.

> However, disregarding the vendor lock-in: How does my OS integrating with AWS's APIs help my on-prem services?

I suppose it doesn't, but why should it? If you think they bloat up your local installation, maybe you can just not install the kernel modules/daemons/libraries in question.