Buildpacks and Containers for Cloud Foundry

 Given the recent enhancements to Stackato (users can now deploy their Docker images directly to Stackato), we thought it was great that our own Phil Whelan was invited onto a panel discussion to talk about buildpacks and containers for Cloud Foundry at this year's Cloud Foundry Summit. Julian Friedman (IBM), Colin Humphreys (CloudCredo), and Andrew Clay Shafer (Pivotal) were also on the panel and it was moderated by Dr Nic Williams (Stark & Wayne). It was no surprise that the discussion around the role of containers and buildpacks was pretty lively given the calibre of panelists--all are extremely knowledgeable about containers and Cloud Foundry internals.

Dr Nic started off the session by exploring the definition of a container. In the case of Docker, there are containers and there are images. The image is actually the portable part, while the container focuses on process. However, the shipping container analogy that is commonly associated with Docker skews the definitions such that the container is seen as also being portable.

Another topic discussed during the session was around the ease of use of containers. Julian Friedman commented on how good the overall Docker user experience was. In some cases, developers may find it easier to push a Docker image rather than using cf push (particularly if they are already building Docker images). However, one of the issues with Docker is that it does require users to assemble the other essential components, such as logging, that's needed for a distributed system. The reality is that the cf push command in Cloud Foundry is a simple command, but there is some set up that's required before you get to that point. While Stackato is based on Cloud Foundry, one of the differences is that we package it up as a Stackato VM instead so the setup time is minimal. Users can deploy an app as quickly as if they were deploying with a container, while having the administrative benefits that a PaaS provides.

Despite being only a half hour, the panelists covered a lot of ground (but probably could have kept going). Some of the great questions raised and issues discussed with respect to containers and buildpacks included:

• Should we be supporting multiple Pods to Cloud Foundry?
• What's the best abstraction for the user?
• What are containers missing or do they give too much power?
• When should you ship a container and when should you ship code?
• What are the issues surrounding layered file systems?
• Is there a way to combine the better ideas of Docker files and those of buildpacks? Should we create more abstractions than what buildpacks are currently supporting?

There are certainly pros and cons with respect to using containers and buildpacks. As Phil noted, both have an opaqueness about them such that you don't necessarily know what the container or buildpack has done. However, both make deploying applications much easier. Regardless of what's used, the panelists felt that it was important to use the tools in the right way. Julian Friedman made a great analogy that summed it up nicely: "Containers make it cheap to do the wrong the thing...:It's like driving a big SUV, what's happened is that we've made gas prices cheaper, but it's still probably best if we get better transport." I think "supplying better transport" is a motivation for those who contribute to the Cloud Foundry project. I hope discussions like this one will continue to push the ecosystem to keep innovating and supplying the abstractions necessary to provide a better user experience.