Last week I attended the OpenStack Silicon Valley conference to give myself a crash-course in all-things OpenStack and private cloud. Having recently come from the public cloud world of AWS and Platform-as-a-Service (PaaS) to land in the middle of CI/Continuous Delivery solutions at CloudBees, I needed to understand OpenStack both as a technology and community then tie it all back to our evolving deployment automation solution. Simple, right? Actually, it was. The event featured interesting and informative panels and talks by leaders in the OpenStack field. I started with minimal prior knowledge of OpenStack, and walked away at the end of the day with a solid level of understanding around the core technology, community, tools, and big players in the OpenStack game. Mission accomplished! I was really amazed at the OpenStack movement as a whole, but what struck me most was the feeling of a powerful connection between OpenStack and DevOps. It makes perfect sense that OpenStack is one of the de-facto technologies in the DevOps tool kit for building private clouds. OpenStack is open source and relatively inexpensive to get going with, extremely powerful and feature-rich, and comes with a passionate (DevOps) community behind it that are constantly releasing new modules and functionality. As very evident at the conference, OpenStack is a tool for the people, by the people. And this got me pretty darn excited. CloudBees is all about making DevOps team members happier/more productive. As part of our CloudBees Flow Continuous Delivery (CD) platform, we’re building out a provisioning and deployment automation solution that integrates with both private and public clouds. While this functionality exists today within our ElectricCommander platform, we are always working on enhancing our integrations throughout the CD lifecycle. First private cloud target? You guessed it, OpenStack. Think of it like this: DevOps creates reusable PaaS-like configurations (‘environment templates’) describing infrastructure and middleware for dynamic OpenStack cloud resources. During a typical CD process, say QA is ready to deploy the latest application build for testing and all they need is an environment. By providing deeper integration with OpenStack for CloudBees Flow users, it will be easy to select the appropriate environment template within the UI, click to provision it, wait a few minutes for the environment to come up, then watch as the application deploys automatically to it. It’s a beautiful thing. Allowing Dev / QA teams to be more self-sufficient when orchestrating deployments in an automated CD pipeline makes everyone happy. DevOps spends less time worrying about availability of server environments, and Dev / QA teams have access to best-practice, standardized resources right when they need them. The CD pipeline flows that much better and everybody wins.
Another cool use-case for DevOps teams is centered around pre-emptive provisioning of dynamic environments within OpenStack. Let’s say you don’t have a build ready to be deployed, but you want to spin up a pool of resources for some other use in your CD flow. Yes, there are tools like Heat templates that DevOps teams can use to perform this exact operation and rather than recreating those wheels we plan to tie them into CloudBees Flow to make your overall CD workflow more repeatable and predictable. Like the strong connection between DevOps and OpenStack evident at last week’s conference, CloudBees is working hard to push the boundaries of Continuous Delivery to make CloudBees Flow a pillar in the DevOps world. And as our deployment automation solution continues to evolve, we’ll continue to enhance our integration with an increasing number of commonly used cloud-oriented tools and platforms such as AWS and VMware clouds, configuration management tools like Chef and Puppet, and much more. Stay tuned!
In the mean time, you may want to check out our OpenStack plugin for ElectricCommander and watch the webinar to learn how Huawei is using it for building a Self-service Dev/Test OpenStack Cloud.