Why Cloud-Native Buildpacks Should Excite Companies

Good golly gosh, I am so sick of writing a Dockerfile from scratch every time. The truth is that most times I end up copying the one from a previous project and replacing a few pathnames with new values. As an individual, this makes sense. That’s one of the many reasons that I, a person, have an interest in Cloud Native Buildpacks. In fact, some of the same reasons which get me pumped should also get companies pumped.⊕ Cloud Native Buildpacks are software which take in your application source code and produce a ready-to-run OCI container image. Think of them as the natural evolution of the “git push deploys” from PaaS offerings like Heroku, Cloud Foundry, and friends.

Let’s explore them.

So let’s say you work at a medium-sized company which sells widgets. Let’s call it Midstate Diversified Widgets for the sake of completeness. Like many companies, Midstate has a fair bit of “legacy” code but has made moves towards “modernization”. One such move has been to adopt containerization to ease deployments. This has worked wonders for easing their operational workloads while also introducing challenges. One such challenge is that every independently-deployed service requires its own Dockerfile. This means that teams usually maintain several, slightly-different versions of more-or-less-the-same Dockerfile. The slight variations are just enough to cause problems for folks like operations, security, and compliance.

For example:

• Imagine that Midstate Diversified Widgets suffers a service outage on their internal widget catalog service. As a result of difficulties spent troubleshooting the issue, operations wants all container images to contain a copy of their auto-troubleshooting script.

• Let’s also imagine that Midstate’s security group requires all container images to include some sort of file scanner so that it can be exec’d in each container as needed.

• Finally, assume that the compliance team now asks that all container images include a special version file in the image filesystem to ease their audit burden. Note that CNB’s pack tool already produces Software Bill Of Materials (SBOM) files by default.

In each case, the changes and workload all rest with the individual teams. If every team is writing their own Dockerfiles, then every team must change each and every Dockerfile to accommodate each of these requests. After all, this sort of work is best done by the folks most familiar with their products and their products’ technical stacks. This brings us to an interesting question: How can the company’s shared-service teams know if each product team did their part correctly?

One way would be to use a code-scanning tool to analyze each and every Dockerfile before building an image, perhaps as part of a CI/CD pipeline. What’s more, there could be some checks on the images themselves at deployment time.

But there is a better way than hacking things together. That way is Cloud-Native Buildpacks (CNBs). You can read more about CNBs and how they work in their documentation and tutorials. For our purposes, suffice it to say that the CNB model leverages collections of modules, called buildpacks, geared towards configuring an image. Each buildpack can opt-in to participating in an image build based on the source code used as input to a build. For example, a Python buildpack might configure a Python environment if it detects a pyproject.toml file in the project root. Another buildpack might detect a directory of certificates and inject them into the container’s trust store. You can search for specific buildpakcs on the registry as well as check out other collections, like the ever-popular Paketo Project.

In the CNB model, each Midstate Diversified Widgets shared-services team would write and maintain their own buildpack. These could then be included by default in CI/CD pipelines. So the operations team could write and own the buildpack which provides their troubleshooting script while the security team would produce one which injects their file-scanning executable. Still, the compliance team’s buildpack would be able to produce the needed SBOM and write it to a pre-specified path.

From the perspective of the product teams, their focus stays on their products and backlog. This offers them genuine autonomy from “edicts from the higher ups” while also giving shared-services teams the power to take meaningful action.

Cloud-Native Buildpacks offer the chance for consistent build processes, even when accounting for variations in product purpose and technology stacks.

So, take some time and check out buildpacks. Maybe even take the tutorial on how to write your own buildpack. In my mind, it’s really worth it. Especially if you write or maintain a lot of Dockerfiles!

I’m excited about this, and others should be too.

Special thanks to Richard Scheeman and Nicholas Santiago for fast feedback on earlier drafts.

← Back to All Posts