I suppose another option is to run everything in Virtual Machines, then you could run them to any cloud provider you like (or even run your own servers).
What's the reasoning for that requirement, though?
I understand the fear of vendor lock-in, but if AWS decide to put their prices up tomorrow, it's non-trivial to just move everything to Azure (for example). Sure, you have some container images which are portable in theory.. but it's still a large undertaking.
I'd be interested to know if anybody has built with 'cloud agnostic' in mind, and actually needed to migrate to another provider.
A reasonable requirement which leads to "run everything in VMs" is the need to support on-premise deployments. Often data-security and compliance requirements can be handled most reasonably (or at all) by allowing the enterprise client to pick where to deploy a single-tenant copy of the service. For this, I think the most reasonable approach is to only require VMs and do all the configuration yourself (preferably in some scripted / automated manner).
Of course, in this case, (unless you install a private cloud), you forgo all the convenience and advantages of a cloud infrastructure (so one can argue that this wouldn't really count as 'cloud agnostic'), but since such on-premise deployments should only be required by big enterprise clients, they should have deep enough pockets to pay for it.
What's the reasoning for that requirement, though?
I understand the fear of vendor lock-in, but if AWS decide to put their prices up tomorrow, it's non-trivial to just move everything to Azure (for example). Sure, you have some container images which are portable in theory.. but it's still a large undertaking.
I'd be interested to know if anybody has built with 'cloud agnostic' in mind, and actually needed to migrate to another provider.