-1

I looked into buildpacks a bit, and it seems like nice tool. To me it seems it offers two different things, sort of:

  1. magically turn your code repository into a running container, even if you wouldn't know how to do any of that (Heroku style)
  2. make it more developer friendly to build high quality OCI containers

So it's a quite attractive tool to people / teams who don't know much about building OCI images and benefit from (1) in addition to (2).

For our team this is not the case, we don't need (1). We are somewhat experienced in writing Dockerfiles and writing those does not take much time. So the cost / benefit ratio of adding and learning a new tool is not as good.

So taking Buildpacks into use I think a team that knows how to write Dockerfiles gets benefits

  • better productivity (ignoring learning curve) creating and maintaining images
  • close to optimal layering, so that code changes cause rebuilds of only few layers. Use of multi-stage builds so that runtime containers don't have build tools etc that's not needed
  • at least somewhat minimized image sizes
  • reproducible builds (not sure where we benefit from these)
  • run as non-root user, perhaps some other security best practices too?
  • software bill of materials (not sure how we benefit from these, images are already vuln scanned in registry)
  • can rebase images without rebuilding app (not sure how we benefit from these, we would always rebuild app and run CI tests before releasing)
  • there's a community behind e.g. paketo.io buildpacks, which I assume will monitor and fix vulnerabilities to underlying OS distribution etc

and on the flipside there's these costs

  • added complexity; another non-trivial tool to learn
  • learning curve
  • magical black box; nice when it does what we want, more pain when it does not. Not easy to predict where the magic runs out, before we take it into use in practice
  • probably harder to make ad-hoc modifications to the containers
  • another moving part that can break. What if the buildpacks produce runtime containers that don't follow best practices, are bad quality, or inefficient? I mean, it's likely that they are of better quality than our hand-written Dockerfiles - but not certain

Is this a fair assessment of the pros & cons, for and use case where Dockerfiles is a valid alternative - am I missing something?

Janne Mattila
  • 598
  • 7
  • 20

1 Answers1

1

I think you're on the right track, but let me respond to a few of your points:

at least somewhat minimized image sizes

This depends on the buildpacks and stack you use. The Heroku Buildpacks are not optimized for this at all. The some of the Paketo buildpacks are very much optimized for this.

reproducible builds (not sure where we benefit from these)

Potentially in your cost-to-serve. You'll avoid building hundreds of layers that could have been the same layer and paying for their storage. But this is dependent on buildpacks that take advantage of this feature

added complexity; another non-trivial tool to learn learning curve

It depends which persona you're talking about. The end users get a smaller learning curve. Just run pack build and you don't even need to learn Dockerfile or what containers are. But you need someone to build and maintain your buildpacks. If you're using Paketo or Heroku buildpacks, you kinda get this for free.

Buildpacks let you centralize this cost though. You can have one person or team create buildpack that provides leverage for your entire organization.

another moving part that can break. What if the buildpacks produce runtime containers that don't follow best practices, are bad quality, or inefficient? I mean, it's likely that they are of better quality than our hand-written Dockerfiles - but not certain

I would definitely be more concerned about developers on my team hand crafting their Dockerfile and each one of them getting it wrong in their own special way :)

codefinger
  • 10,088
  • 7
  • 39
  • 51