4cdd353fa4
Provide an interpretation of the OpenStack mission statement with respect to cloud applications and COE/PaaS layers to guide projects in aligning their priorities with the direction of the broader community. Change-Id: I99be9bffe4c269037634cf1883f604a233b9672d
5.6 KiB
2017-03-17 OpenStack and Cloud Applications
The OpenStack Mission
OpenStack's mission is:
To produce a ubiquitous Open Source Cloud Computing platform that is easy to use, simple to implement, interoperable between deployments, works well at all scales, and meets the needs of users and operators of both public and private clouds.
Implications for Cloud Applications
Proprietary APIs lock users in to a single vendor and thus expose them to possible rent-seeking. We develop OpenStack because we believe this should not be the price of entry to cloud computing. Our goal is to provide a viable alternative Open Source cloud API and implementation so that users can select, and switch, vendors (including moving between public and private clouds) based on the value they provide instead of being hostage to a proprietary API.
Even Open Source APIs create lock-in, of course, but not vendor lock-in. Every user who is locked in to an OpenStack API is a user we have saved from being locked in to a single proprietary vendor. This is OpenStack's highest purpose. (Conversely, every user who is locked in to a single OpenStack vendor due to non-interoperability of solutions represents a failure of our mission.)
Therefore, excellent support for cloud-aware applications -- that is, applications that access the cloud's APIs directly -- is imperative if OpenStack is to fulfill its mission. There are many existing applications that are self-contained (that is, they could run on any server or VPS) and it is important that they run well in OpenStack clouds. However, this cannot be a substitute for OpenStack's support of cloud-aware applications. Only if developers of cloud-aware applications see OpenStack as a competitive platform on which to build new cloud-aware applications can we help them to avoid proprietary lock-in.
Many factors contribute to making a platform attractive to developers, but robust security is the sine qua non for that large proportion of applications that are network-facing. OpenStack therefore requires an application-centric (not just user-centric) authentication and authorization model. It must give fine-grained control to the application developer (not administrator) to delegate, in perpetuity until revoked, minimal privileges to access OpenStack APIs to the parts of the application that need them.1 Application developers can also benefit from the broad range of cloud services that are already, or in the future will become, part of OpenStack. These services can help them to, for example, reduce development effort, centralize scarce operational skillsets in their organization, scale at finer levels of granularity, share expensive resources efficiently, provide reliability guarantees cheaply by amortizing the cost over multiple applications, help the application to manage its own infrastructure, or obtain from the cloud information that it needs to do so. Many OpenStack services offer more than one of those benefits. Some of those services themselves comprise cloud-aware applications running on the virtual compute infrastructure.
We recognise that some cloud-aware application developers may work with additional layers of abstraction on top of OpenStack's virtual compute infrastructure, such as that provided by a Container Orchestration Engine (COE) or Platform as a Service (PaaS). In such cases, we may regard the COE or PaaS as part of the application layer from OpenStack's perspective. OpenStack can add considerable value to these layers by allowing them to become cloud-aware themselves or to be supplemented by cloud-aware management services.
Furthermore, we anticipate that many applications of the future will be heterogeneous in their infrastructure needs: parts of an application may be implemented running directly on the virtual compute infrastructure, other parts in shared multi-tenant cloud services, and still others on top of a third-party COE or PaaS layer. For this reason, we will seek to partner and integrate with Open Source COE and PaaS projects to ensure that their workloads also have seamless access to the full range of OpenStack cloud services and to other application components deployed directly on the virtual compute infrastructure.
We invite all OpenStack projects to review their development priorities for alignment with the most critical aspects of our mission: to provide a secure, simple, scalable, interoperable set of services to the applications that depend on OpenStack APIs.
Footnotes
For instance, the first steps toward this might be to eliminate write access to the whole project for every user in the default policy; establish a Keystone domain, or method of provisioning domains, in which to create application user accounts that is consistent between clouds; and provide a secure method to provision, rotate, and deliver credentials to the application. Obviously the exact technical solutions will be determined through the usual open design process.↩︎