3 ms·

> " a platform joining up cloud-hosting services from dozens of companies, allowing business to move their data freely" This is practically dead before it's cr

> " a platform joining up cloud-hosting services from dozens of companies, allowing business to move their data freely" This is practically dead before it's created. The other platforms (AWS, GCP etc.) are hyperscale due to their useful integrated nature of building blocks. You're not going to get that with a bunch of random vendors. It's hard enough as it is for a large company to create a somewhat homogenous environment, and existing projects that are supposed to be multi-vendor like OpenStack (and CloudStack) are just not on par. Say you have a few vendors, one runs VMWare, one runs Hyper-V, and you need a workload with scalable counts of CPUs, and the datacenter of the VMWare guys is full and you now need to use some of the CPUs in the other datacenter. Are you going to have a single API (and perhaps console) where you say: I want a machine with specs X, image Y and parameters Z to do that and have the lower layers resolve it? Probably not.

tgsovlerkhgsel 6y ago
> Are you going to have a single API (and perhaps console) where you say: I want a machine with specs X, image Y and parameters Z to do that and have the lower layers resolve it? Probably not. Why not? Isn't Kubernetes already most of the way there? (I have only played with it very briefly, but it looks like it should solve this. The workload is most likely a container anyways, mostly resolving the "image" issue, so the key parameters are CPU, storage and RAM. Ignoring dependencies between containers (e.g. you probably want your web app server and database to be colocated), for the simplest implementation, couldn't you simply create a Kubernetes cluster covering VMs from all providers? It seems like an orchestrator that places your jobs is part of what the project tries to develop, according to https://www.heise.de/news/Bundeswirtschaftsminister-Gaia-X-als-weltweiter-Goldstandard-fuer-Cloud-Dienste-4774826.html https://www.heise.de/news/Bundeswirtschaftsminister-Gaia-X-a...
- oneplane 6y ago
  Not: because you would either lose platform-specific functionality between whatever hypervisor the different vendors happen to use, or you would get multiple APIs. I'm sure attempts other than libvirt exist, but nobody has really succeeded. It's all either Xen, KVM, or VMWare so far, and a little bit of Hyper-V, and none of them are compatible.

tgsovlerkhgsel 6y ago

> Are you going to have a single API (and perhaps console) where you say: I want a machine with specs X, image Y and parameters Z to do that and have the lower layers resolve it? Probably not. Why not? Isn't Kubernetes already most of the way there? (I have only played with it very briefly, but it looks like it should solve this. The workload is most likely a container anyways, mostly resolving the "image" issue, so the key parameters are CPU, storage and RAM. Ignoring dependencies between containers (e.g. you probably want your web app server and database to be colocated), for the simplest implementation, couldn't you simply create a Kubernetes cluster covering VMs from all providers? It seems like an orchestrator that places your jobs is part of what the project tries to develop, according to https://www.heise.de/news/Bundeswirtschaftsminister-Gaia-X-als-weltweiter-Goldstandard-fuer-Cloud-Dienste-4774826.html https://www.heise.de/news/Bundeswirtschaftsminister-Gaia-X-a...

oneplane 6y ago
Not: because you would either lose platform-specific functionality between whatever hypervisor the different vendors happen to use, or you would get multiple APIs. I'm sure attempts other than libvirt exist, but nobody has really succeeded. It's all either Xen, KVM, or VMWare so far, and a little bit of Hyper-V, and none of them are compatible.