At Platform9, we have witnessed first-hand how the rapid growth of public cloud usage among developers has led enterprises to embrace the promise of development agility by setting up their own private cloud infrastructure. This, in turn, has fostered a growing need for the ability to work seamlessly across both public and private clouds, without giving up the benefits of either. The long-held promise of such a hybrid cloud computing environment has always been predicated on the presence of a consistent interface to deploy cloud-native apps across both public and private clouds. While the specific use-cases of interest may differ, this basic requirement is at the core of most of them e.g. auto-bursting, cost control and single management pane among others.
OpenStack – A Hybrid Abstraction Layer
Once we boil down the first order problem to one of creating such an interface, which approaches exist today to address this? Most existing solutions rely on creating a new API layer that then subsumes the public and private cloud beneath it. This has the advantage of providing a fresh take on what such an interface should look like, and the freedom-of-implementation that comes with it. However, the main concern with such an approach is that it comes at the cost of existing tools, integrations and workflows that have been developed for both the public and private clouds. Ironically enough, this ends up sacrificing the best of both of these worlds for the lowest common denominator, resulting in a solution that’s much smaller than the sum of its parts.
Fortunately, there already exists a mature, open, community-driven, extensible cloud interface that a lot of tools like packer, vagrant, fog integrate with – OpenStack! Why create a completely new API set for users to have to learn, and tools to re-integrate with, instead of uniting behind an existing one? This is the rationale we used when leveraging the extensibility of OpenStack to develop a set of AWS-specific plugins for various OpenStack services including Nova, Glance, Cinder and Neutron. The true power of OpenStack is reflected in the strength of its community; we’d like to call out the initial work done here by ThoughtWorks to provide a basic Nova driver that we learned from, and built upon. In keeping with the openness of the OpenStack community, we are also happy to announce that all of these plugins will be made available as open-source contributions for everyone to use, and extend. Check out the project repository on github.
Putting it all together
We have built support for the following OpenStack constructs to communicate with corresponding AWS resources:
- Nova – A new Nova driver that allows for EC2 instance creation within AWS and all the typical operations like power on / off, suspend / resume, along with snapshotting to an AMI
- Glance – A Glance store driver that recognizes an AWS URL schema, enabling use of AMIs as OpenStack Glance images
- Cinder – Support for EBS volumes as Cinder resources
- Neutron – A new ML2 mechanism driver to allow for creation of floating IPs, routers and private subnets, with security groups coming soon
Putting together the combination of drivers above, we now have the same OpenStack API layer available for users to work with AWS resources as well. This enables administrators to utilize existing investments in their OpenStack cloud to also manage how AWS resources are being consumed within the enterprise. For instance, they can now use single sign-on (SSO) integrations within OpenStack to manage identity-based access to both public and private clouds from a single place. Similarly, they can use the multi-tenancy capabilities within OpenStack to partition resource usage among users consistently across either cloud. Building on common abstractions, the same Heat template or Murano application can be used to deploy workloads across both clouds. This opens up a myriad of other such possibilities where OpenStack integrations and investments can be leveraged to apply to public clouds as well.
But what about existing investments on the AWS side? Thanks to the OpenStack workload discovery feature by Platform9, AWS objects – instances and images – are automatically ingested into this control plane as well.
Going even further, users can build Murano or Heat templates to deploy applications across KVM, VMware, AWS today and other clouds like Azure and GCE in the future, using the same consistent underlying constructs. As a result, users now truly have a single pane of glass from which to not only view and manage workloads across clouds, but also continue to exploit the best that all of those worlds have to offer.
Watch this space for more information on the next set of hybrid features we will be building. Reach out to us if you have comments / suggestions, and your hybrid use-cases of interest – we’d love to hear from you!
Latest posts by Amrish Kapoor (see all)
- The unforgiving cycle of cloud infrastructure costs (and the CAP theorem that drives them) - April 23, 2019
- 6 Key Insights from OpenStack Summit Vancouver - May 24, 2018
- Platform9 Brings SaaS and Serverless to Kubecon Europe - April 30, 2018