From 4cdd353fa46502fa90c3eaff675271622ccfb5ad Mon Sep 17 00:00:00 2001 From: Zane Bitter <zbitter@redhat.com> Date: Thu, 16 Mar 2017 20:40:33 -0400 Subject: [PATCH] Resolution on OpenStack's mission for cloud applications 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 --- .../20170317-cloud-applications-mission.rst | 99 +++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 resolutions/20170317-cloud-applications-mission.rst diff --git a/resolutions/20170317-cloud-applications-mission.rst b/resolutions/20170317-cloud-applications-mission.rst new file mode 100644 index 000000000..80803c497 --- /dev/null +++ b/resolutions/20170317-cloud-applications-mission.rst @@ -0,0 +1,99 @@ +============================================= + 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.\ [#]_ +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. + +.. _rent-seeking: https://en.wikipedia.org/wiki/Rent-seeking +.. _lock-in: https://en.wikipedia.org/wiki/Vendor_lock-in +.. _and implementation: https://governance.openstack.org/tc/reference/principles.html#openstack-primarily-produces-software +.. _VPS: https://en.wikipedia.org/wiki/Virtual_private_server + +.. rubric:: 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. + +.. _eliminate write access: https://review.openstack.org/#q,Ib4cc7141d900881a7dc20842eb5d68eb90521fdd,n,z +.. _provision, rotate, and deliver credentials: https://review.openstack.org/#q,I86a994ca94e2d6a2a4e3753ffab107afc38d3dec,n,z