Why You Should Use Buildpacks Over Docker

Docker is the obvious choice for building containers, but there is a catch: writing optimized and secure Dockerfiles and managing a library of them at scale can be a real challenge. In this article, I will explain why you may want to use Cloud Native Buildpacks instead of Docker.

Common Issue Using Docker

When a company begins using Docker, it typically starts with a simple Dockerfile. However, as more projects require Dockerfiles, the following problematic situation often comes up:

• Developers tasked with containerizing their applications lack the knowledge, time, or motivation to write a new Dockerfile. As a result, they copy and paste a Dockerfile from another project.
• Any bad practices or security vulnerabilities in the copied Dockerfile are propagated.
• The copied Dockerfile might be optimized for a specific stack, leading to poor performance in the new context.

This scenario repeats each time a new application needs to be containerized. While this might be manageable for a few applications, it becomes a significant issue when dealing with hundreds. That can lead to serious technical debt and security vulnerabilities.

What Do Buildpacks Have To Offer?

Consistent Experience

In the era of platform engineering – where process standardization is crucial – microservice-oriented infrastructure must accommodate a wide variety of stacks. Buildpacks provide a standardized approach to creating container images using one command to containerize any application. That command – pack– is all that's needed (no need to write a Dockerfile or other configuration file).

Eliminate Dependency Management

Concerns about dependency management are eliminated. Buildpacks automatically detect, download, and install the necessary dependencies, libraries, frameworks, and runtime environments.

Reusability

A key benefit is the availability of production-ready buildpacks maintained by the community. Experts – from companies like Google, Heroku, Broadcom/VMware, etc. – manage these buildpack images to ensure your container images are optimized and explicitly secured for each stack.

Misconceptions With Buildpacks

When buildpacks were first created about a decade ago, users complained about several limitations. But most of those are long gone, so let me bust those myths.

Myth 1: Limited to a Few Programming Languages

Buildpacks supports all modern programming languages. Providers like Google, Heroku, and the open-source Paketo Buildpacks project support a wide range of languages, including Java, Node.js, .NET Core, Go, Python, PHP, Ruby, and Rust.

Myth 2: Limited Customization

“There are limitations, but they are by design”, says Cloud Foundry maintainer Tim Downey. Buildpack “limitations” will protect you from bad practices such as running your container as root or running arbitrary Shell commands. And if you need a workaround, there is always a clean way to do it.  For example, if you need to install a package that is not listed in your application dependencies (such as installing some OS utility), you can cleanly do this using the apt buildpack.

Myth 3: Vendor Lock-In

Buildpacks output OCI images like Docker, ensuring maximum compatibility with any hosting platform or on your infra. And if a buildpack vendor-specific optimizations do not work for you, you can easily switch to another provider, such as the open-source Paketo Buildpacks, which are free of vendor dependency.

Myth 4: Dependency Management Issues

Dependency management is simplified with Buildpacks. They automatically track and manage dependencies, offering a robust approach for complex applications with strong security requirements. Buildpacks can even generate a Software Bill of Materials (SBOM) for your container images with the same command used to build an image.

Myth 5: Unoptimized Images

Buildpacks are designed with best practices to build faster and smaller images. They also offer advanced features, such as the rebase functionality, which allows rebuilding any part of an image without needing to be rebuilt entirely, which is not available in Docker-based images/workflows.

Don’t Waste Your Time Writing Dockerfiles: Use Buildpacks

Writing a Dockerfile is the right way to go if you have a small infrastructure or a solo developer, but for any company with a large enough infrastructure, you should seriously consider trying Cloud Native Buildpacks. The learning curve is super easy and will save you a lot of work in the long run.