A phrase that has been making the rounds recently is “Composable OpenStack”. It’s a very seductive phrase; it suggests a buffet-like experience with OpenStack that can satisfy any appetite, while at the very same time promising nothing. This makes it easy for sales people to use, as the definition can be modified based on the audience. Yet what does it actually mean? Well, it really depends on who you are, and what you want out of a cloud.
If you are a Megacorp, the term is almost synonymous with “Hybrid Cloud”, a term used frequently in the marketing and sales material of my employer, HPE. In this case, it addresses organizations whose computing resources are spread across multiple cloud providers. A shipping system may live in a data center adjacent to UPS’s servers, the billing system is on an internal cloud for compliance and auditing, while individual supply-chain management components are distributed across regional data centers across the world (via AWS, or Rackspace, or whatever is most cost-effective in the region).
Composing clouds, in this case, means consolidating the management functions (scaling, alerts, security policy, etc), no matter where that component happens to be located.
The Cloud Provider
In this case, we’re talking about an organization (be it an internal IT department or a company like Rackspace) which is offering cloud services to their customers. Here, composability speaks more to the services offered via that cloud. For example:
- You may have your own authentication system instead of Keystone
- You may have your own Bare Metal provisioning system.
- You may, or may not, want to provide Big Data services to some, but not other customers.
This means building the core services of an OpenStack cloud, and either selectively layering on additional services, or replacing those for which you have an internal implementation.
The Application Company
Many companies (Etsy comes to mind) have computing needs that are very well defined. They offer some service with a specific set of requirements, and their cloud is designed for this use case. For example, an organization which offers WordPress containers may only require Bare Metal (Ironic), Container Management (Magnum), Image storage (Glance), and Authorization services (Keystone). Everything else is superfluous, and increases both maintenance and resource requirements.
These companies must be able to choose only those components of OpenStack that are required to meet their business objectives. From a practical standpoint, it means that each service in OpenStack must be able run independently. While many of the services in OpenStack’s integrated release are still tightly coupled, there has been a movement (championed by swift, ironic, and glance) that are peeling this apart.
The Application Developer
Ant the most atomic end of the spectrum, we have the needs of those who are actively developing an application, are using cloud resources to do so, however whose technical requirements are in sufficient flux that a specifically designed cloud is probably not an option. They may be customers of Cloud Providers, however the important distinction is that these individuals are not operators. They think of their work in terms of functioning components, not hosts and networks.
Try to understand the mindset: Describe an application, and its components, rather than a cloud. This application may require a web server, a database, some kind of a file storage mechanism, and a way to expose all these things to the customer in a way that will scale. An operator would look at this and automatically decompose it into services such as Load balancing, IP assignment, DNS, and more. An application developer would rather let someone else worry about those details.
To provide a ‘Composable OpenStack’ to this customer, it means making application components as easy to provision as possible. Details such as MySQL read only slaves, optimizing our load balancer, or subnet DNS, are assumed to be handled for us.