CloudStack's Chip Childers

The CloudStack cloud solution has been around for several years and offers a formidable collections of services. CloudStack graduated from the Apache incubator to become a top-level Apache project earlier this year. What better time to check in with CloudStack VP Chip Childers on the state of the project and the path ahead?

Chip served as release manager for the CloudStack 4.0.0 and 4.1.0 releases. He is a principal engineer in the Cloud Engineering organization at SunGard Availability Services, where he is responsible for the overall architecture of SunGard's CloudStack-based service offerings. He also serves on the board of the Distributed Management Task Force (DMTF) and has several patents pending in the areas of infrastructure automation and orchestration system design. He is the maintainer of several open source projects dedicated to helping cloud operators understand their Apache CloudStack deployments through better visualizations and capacity planning simulation.

ADMIN: OpenStack seems to get more headline space, but CloudStack is also an open source cloud solution with similar goals. What distinguishes CloudStack from OpenStack and the other cloud alternatives? What makes CloudStack different?

C. Childers: There are a myriad of differences. The big differences are:

• Apache CloudStack is written in Java, while OpenStack is written in Python.
• Apache CloudStack is a bit older than OpenStack -- first being developed around 2008.
• Apache CloudStack is a single project that orchestrates compute, network services, and storage, while OpenStack has a bit wider scope as a foundation, and is actually a collection of projects that one can pick and choose, to assemble into a cloud platform.

Both have good communities, both are licensed under the ASLv2, both are housed at open source foundations.

We believe that the Apache CloudStack community's focus on making it easy to operate, coupled with a strong focus on enabling the spectrum of workload styles from "virtualization plus" to "cloud native," is a key differentiator for the project.

ADMIN: What are some scenarios or configurations where CloudStack shines? What would be an ideal situation for using CloudStack?

C. Childers: If I had to pick one, I'd say Apache CloudStack shines with multiple types of workloads. The reality is that most companies have many different workloads; most of them aren't really cloud workloads that can tolerate failure, keep many node members stateless, and keep moving on. Apache CloudStack's multiple hypervisor support, multiple network models, and support of enterprise virtualization features like VMware DRS means you can deal with those varied workloads all within the same management environment.

ADMIN: CloudStack is ready for action now, and a lot of people are using it, yet we all know that development never ends. A new version of the CloudMonkey management utility just arrived. What's new with CloudMonkey, and are there other recent CloudStack features that you find particularly exciting?

C. Childers: Yes, we have hundreds of production installations of the Apache CloudStack code right now, with more coming online all the time.
The CloudMonkey CLI tool has actually been around for about a year now, and appears to be growing in popularity with CloudStack operators and consumers of CloudStack clouds.  This release was the first independent release of that code, separated from the core Apache CloudStack release now.
If I had to pick one thing to highlight about the CloudMonkey, it would be the multi-version support of the tool.  Previously CloudMonkey and CloudStack were tightly coupled, but with Apache CloudMonkey 5.0.0, the CLI can actually query the API endpoint of the target cloud and automatically discover the capabilities of that environment.

Apache CloudStack 4.2 and will be out by the time you read this. This is a major feature release for the CloudStack community, and has been in the works for about 6 months now.  There are a ton of interesting features, from the ability to use a message bus for data/event collection and tracking, to greatly broadened VMware feature support, to the ever increasing number of SDN technology plugins shipping with the project.

I'm looking forward to 4.3. I just looked at a patch for integrating Juniper's OpenContrail with CloudStack, and other feature proposals are starting to hit the mailing lists now.  4.3 should be another big feature release for us.

ADMIN: The whole concept of the cloud is changing even as we design tools for it. Right now, a lot of interest surrounds these gigantic data centers, with dense systems, supporting hundreds or even thousands of  virtual machines. Is CloudStack ready for this high-volume, heavy-use environment? If so, what CloudStack features make it particularly well adapted?

C. Childers: The reality is that Apache CloudStack has been running in such environments since 2009. The largest deployment that I personally know is more than 40,000 physical nodes under a single plane of management in two zones (Availability Zones in AWS parlance). Each of those 40,000 physical nodes is a hypervisor, with virtual machines running atop them.

Given that example scale, we believe Apache CloudStack is ready to grow with our users. We've recently added the concept of regions to the software as well, which will allow for the aggregation of multiple CloudStack management domains into even larger-scale, distributed across the world.

ADMIN: The CloudStack project has had several ownership changes in recent  years. What's life like as an Apache Foundation project? How are decisions made? How do you settle disagreements? How does the current management structure differ from being part of a big company like Citrix?

C. Childers: The Apache Software Foundation is a great place for the CloudStack community. Since the donation of the code by Citrix, the developer and user community has continued to grow rapidly. People trust the ASF and the "Apache Way" to help guide community behavior in projects like this, and our experience as a community agrees with that trust.

The community is all about individuals collaborating on the shared project, be they developers sponsored by a commercial organization, users of the software adding new features, or even friendly members of the broader ASF community helping us with project tooling.

Decisions are made by consensus, and of course, we've created bylaws for the project to help us resolve issues and move forward through any potential conflicts.  That being said, the community has been remarkably unified in it's direction and execution.

ADMIN: What's up ahead for CloudStack? Where are the challenges? How do you see CloudStack growing and evolving over the next five years?

C. Childers: We expect to continue to see the rate of installations grow, and we are excited about the opportunities that presents: more technologies to integrate with, improving the functionality of the core orchestration to support more and more workload scenarios, and achieving even larger scale with the system.