Cloud Foundry Buildpacks or Dockerfiles

I often hear questions about what are these buildpacks that cloud foundry uses. And then frequently, why use a buildpack when Dockerfiles are commonplace?

The most common answer alludes to a topic that is most commonly phrased as a ‘separation of concerns’. Unfortunately, these discussions tend towards an odd combination of the academic and the ethereal when trying to explain the concept. In other words, folk don’t really digest the simple point that buildpacks facilitate.

The separation of concerns is real. And it has value. For fun, let’s look at it from an enterprise workflow perspective. We can examine this from both an application development viewpoint as well as that for application deployment.

First, the Dockerfile approach. To produce Dockerfiles a developer can sit at their desk and build everything needed for the Dockerfile. There is great power in this, but great responsibility too. The following diagram depicts the stack the developer controls.

The important point here is the developer takes on the whole responsibility to define the full container stack. Note, this approach is specifically more complicated if you are interested in maintaining consistency across an enterprise.

If we look at the buildpack approach, it enhances developer efficiency by allowing developers to focus on the application alone.

With buildpacks, you separate the process into specific layers that can be controlled by different roles. A snippet from the cloud foundry docs (https://docs.cloudfoundry.org/buildpacks/)

“Buildpacks provide framework and runtime support for apps. Buildpacks typically examine your apps to determine what dependencies to download and how to configure the apps to communicate with bound services.”

Developers that I talk to like the idea that with a buildpack, there is the concept of App :: Buildpack :: System at each level and that this facilitates supporting three distinct roles that have separate concerns. The roles:

1. End application developer (App)
2. Cloud Foundry admin (various admin controls which includes control over buildpacks)
3. Cluster manager (System, stemcell and stack)

With this in mind, let’s look at what happens when something within the container needs to be updated, maybe due to a security update to a language library.

For the Dockerfile approach, the developer needs to get involved. The container image needs to be rebuilt. All of the assets that were used to build the image need to be re-used with updates applied. And if the updates affect multiple container images across numbers of developers, then they all of these developers need to update their images and have them redeployed.

With buildpacks, the workflow is very different.

The operator or CF admin in this case can apply the ‘lib’ updates to the build process in the platform. This allows the platform to rebuild and redeploy all of the affected containers from this single update. And this happens without having to sidetrack development. This ability to allow development to handle the application code while separating out the activities that operations can handle is at the root of the term ‘separation of concerns’.

It is also worth noting that if the example was an OS image that needed an update, it would use the same process receiving the same efficiencies.

For a world that is focused on cloud native applications which promise the ability to isolate changes in the name of efficiency, the buildpack approach with its concept or separation of concerns fits right into today’s modern application development model.

Ultimately the buildpack approach provides some great benefits. It facilitates consistent best practice implementations across the enterprise as well as offering solid time savings for your developers.