Meeting Chip Childers of the Cloud Foundry Foundation

This post was originally published on ActiveState’s blog. View the archived original.

A few months ago the Cloud Foundry Foundation was officially launched and now has a small dedicated team of people who are focused on getting the Foundation to where it needs to be. Chip Childers, Technology Chief of Staff, is focused on the Cloud Foundry ecosystem and is currently on a road trip to meet with the various members of the community. During his recent trip to Vancouver, Canada, he met with ActiveState and I had a chance to sit down and ask him a few questions.

Chip has been working closely with Sam Ramji, whom you may have seen in a recent ActiveState fireside chat. While Sam, who is CEO of the Foundation, is focused on the business side to things, Chip is focused on the contribution process and the technology.

Chip has been in the industry since the late 90s, starting out in interactive marketing and web development before moving on to building large applications for hosting providers. He was working at SunGard Availability Services, a large service provider, at the time they decided to go with CloudStack. This was also the time at which CloudStack was becoming an Apache Software Foundation project. Chip took the position as the first Chair of the Apache CloudStack PMC (Project Management Committee) and served his full term of one year.

Chip’s focus in the CloudStack project was to get users engaged. He saw this as critical to the long term health of the project. His personal philosophy is to focus his energy on the key things that need to be done, which is generally not the most attractive work. With CloudStack he saw supporting the community as one of these key things.

Chip was contacted by Jim Zemlin, from the Linux Foundation, when Jim was building the team for the Cloud Foundry Foundation. He was interviewed by Sam Ramji and also observed the first Cloud Foundry Foundation board meeting as part of his interview. Chip said Sam is a great person and that Sam’s high level of excitement for the Cloud Foundry project drew him in. He also thought that this seemed like a fascinating problem. How to create a Foundation and how to take a project from the agile model employed at Pivotal to an industry collaboration based on that same model of paired development. He said this is first time this has been done within an open-source software foundation.

Not all software projects are governed in the same way. Chip described a scale between closed-source proprietary software and full consensus-based open source development. The sweet-spot for Cloud Foundry is somewhere in the middle, where the collective good of the foundation’s members and the broader ecosystem benefit from a project based on opinionated views of where things need to go.

When comparing what Chip did with Apache CloudStack with his work at the Cloud Foundry Foundation, Chip clarified they are very different. CloudStack was just a project, but now he is dealing with a foundation which encompasses a collection of projects that collectively form a greater system. The ASF is a charitable organization, whereas the Foundation is not. The Cloud Foundry Foundation’s role is to support the economic growth of Cloud Foundry and the collective interests of its members. Therefore Chip will be spending a lot of time with contributing members and also with members who hope to contribute.

Chip describes Cloud Foundry as a platform for cloud native applications where staple services are segregated out. Specifically, Twelve-Factor Applications. He clarified that “PaaS” is just a feature of Cloud Foundry and this is the role of the elastic runtime. Cloud Foundry as a whole is made up of the elastic runtime, stateful services and BOSH. These three core areas (stateless, stateful and platform operations) of Cloud Foundry are where the Foundation will focus to drive development, collaboration and adoption.

Chip hopes to take advantage of opportunities to work with vendors, such as database vendors, who can build services that work with Cloud Foundry. Vendors may deploy their services using BOSH. They might even create Loggregator or CLI plugins.

One area that fascinates Chip is the next generation of ISV architecture. Software vendors are finding that targeting their platform to run on Cloud Foundry is a great way to deploy their software, if the customer is already running the platform. This gives the platform operations team a consistent experience across bespoke and purchased applications, while the ISVs get the benefit of a known deployment target designed for their latest cloud native application architectures. In the future, Chip hopes to see a big ISV marketplace with enterprises migrating to cloud native applications. He hopes to see a lot of choice in the market.

Cloud Foundry is a set of projects that can be stacked together to form a cloud native application platform, but can also be utilized in other ways. The recent Lattice project is an example of this, which is much lighter single-tenant platform for deploying Docker images that combines the Router, Loggregator and Diego. We’re seeing other deployment mechanisms, such as Terraform being used to deploy the open-source Cloud Foundry. Stackato uses a different mechanism as well.

I asked Chip about his thoughts on using 3rd party technology with Cloud Foundry, which seems to be the route OpenShift is now taking with its re-imagining of its platform on top of Kubernetes and Docker. He said that we have to be careful about injecting dependencies that a large ecosystem will then depend on, but also ensure that we don’t fall into the “Not Invented Here” trap. Right now, etcd is an embedded dependency and Consul is being utilized by Diego. The various teams at Pivotal have hit issues with both of these, as with any software, he said. Other dependencies can be injected as plugins, such as in log aggregation.

Chip said supporting developer choice is important. For instance, the choice to deploy just code or a Docker image. Internally we should support different container formats and the various ways they are downloaded, as well as types of buildpacks.

One thing I find very useful is the CAB (Cloud Foundry Advisory Board) calls. Chip said these will continue as they are a very useful feedback mechanism. Even the name will remain, since it’s still used for “user advisory”. There will be no voting, though, as that will be the responsibility of the project leads, PMCs and the PMC Council.

You can meet Chip at this year’s Cloud Foundry Summit in Santa Clara, which is occurring 11th-12th May.