3 ms·

> if I can build an app that runs "unmodified" on any OpenStack-based infrastructure, that has a possibility to save me potential time and money from having to

> if I can build an app that runs "unmodified" on any OpenStack-based infrastructure, that has a possibility to save me potential time and money from having to port apps to/from/between AWS, Azure, Google Cloud, et al (assuming of course that it enough clouds actually adopt). OpenStack is at the same layer as AWS, GCP or Azure. It's not an abstraction over them -- that's a PaaS. I'm not sure OpenStack was ever seriously intended to work at that level. I work on a platform, Cloud Foundry, which provides the kind of portability you're talking about. Red Hat have OpenShift, which is another such platform. Disclosure: I work on Cloud Foundry on behalf of Pivotal.

WorldMaker 10y ago
> I'm not sure OpenStack was ever seriously intended to work at that level. There was a hint at some possibility that it might, especially in some of the hype circles early on. It is of course unfair to blame OpenStack for never actually fulfilling that dream, when that was not its intention per se, but that is part of why today people continue to compare what OpenStack promised versus what containers delivered.
derefr 10y ago
It doesn't have to be an abstraction; it could have been an API standard for IaaS providers, with OpenStack itself serving as a reference implementation of said API. No higher-level concepts like containers; just saying things like "the VM lifecycle controllers in AWS, Google Cloud, Azure, DO, Linode, Rackspace, some random company's private cloud, etc., should all 'speak Nova', so that any Nova client can control VM lifecycles on any of them." Such providers could expose extra features with their own proprietary APIs (think e.g. the features exposed to the Gmail users through the web-app vs. through IMAP) but the standard protocol would at least be there for everything. Not that asking AWS+GCP+Azure to commoditize themselves in such a way makes much economic sense, but that's the proposition.
- jacques_chester 10y ago
  It'd be nice, but I don't think they will. Cloud Foundry gets around this by using BOSH for deployment; it essentially creates the kind of layer you're describing.

WorldMaker 10y ago

> I'm not sure OpenStack was ever seriously intended to work at that level. There was a hint at some possibility that it might, especially in some of the hype circles early on. It is of course unfair to blame OpenStack for never actually fulfilling that dream, when that was not its intention per se, but that is part of why today people continue to compare what OpenStack promised versus what containers delivered.

derefr 10y ago

It doesn't have to be an abstraction; it could have been an API standard for IaaS providers, with OpenStack itself serving as a reference implementation of said API. No higher-level concepts like containers; just saying things like "the VM lifecycle controllers in AWS, Google Cloud, Azure, DO, Linode, Rackspace, some random company's private cloud, etc., should all 'speak Nova', so that any Nova client can control VM lifecycles on any of them." Such providers could expose extra features with their own proprietary APIs (think e.g. the features exposed to the Gmail users through the web-app vs. through IMAP) but the standard protocol would at least be there for everything. Not that asking AWS+GCP+Azure to commoditize themselves in such a way makes much economic sense, but that's the proposition.

jacques_chester 10y ago
It'd be nice, but I don't think they will. Cloud Foundry gets around this by using BOSH for deployment; it essentially creates the kind of layer you're describing.