Buildpacks focus on turning sourcecode into a runnable container. Essentially you just throw code at it and It Just Works.
I think the Onsi Haiku is still the best description:
Here is my source code.
Run it on the cloud for me.
I do not care how.
Heroku invented this, it's been picked up by lots of other groups (including for Cloud Foundry -- I've worked on buildpacks for Pivotal in that regard).
> (1) VMWare images (2) Docker images
You have to build these yourselves. The boundary is your CI system, Dockerfile etc -- which you have to maintain. Buildpacks provide a curated, managed, easily upgraded system that does this for you.
> (3) Debian packages?
These are, in some sense, on the far side of where Buildpacks sit. But also slightly different. A debian package is intended to land in a pluripotent environment, possibly under direct human supervision. A Buildpack is meant to build completely self-contained runnable images, starting from sourcecode.
Not quite. The source package has to be packaged by someone, then dpkg knows what to do with it.
A Buildpack instead takes source as it is. You use Maven? The relevant buildpacks recognise pom.xml and know what to do. Bundler? Ruby buildpack sees the Gemfile and takes responsibility. And so on.
I as a developer can send the same sourcecode I have in my git repo or on my local filesystem, with no additional effort to prep it. The buildpack does all the work.
Putting it another way: it makes sense to create a debian source package buildpack. There are apt buildpacks in the wild, I expect they'll be revisited.
It's a script. It might use packages, it might not. It builds a box with whatever runtime is necessary to run your app. It's not a new technology. The resultant image could be a container or any other kind of imaging format.
Here's the node one. It's a shell script. It sets up node. You probably already had it before you knew what a build pack was:
I've worked on Buildpacks fulltime twice now for Pivotal.
I've seen things you people wouldn't believe. Package systems on fire off the shoulder of Orion. I watched C-compilers glitter in the dark near the obscure Nokogiri-interacting-with-stray-environment-variables-if-you're-using-a-slightly-too-old-SQLite-and-the-symlink-is-broken-due-to-an-upstream-bug-that-wasn't-fixed-because-nobody-realised-this-would-happen gate.
But unlike the shell script, these moments will not be lost in time like rain. They will be shipped reliably, repeatably into production by two professional organisations prepared to assign more than a dozen engineers, watch hundreds of upstream dependencies, invest in millions of dollars of automation, test against thousands of distinct applications with tens of thousands of running containers serving billions of requests per day across multiple customers in multiple countries.
I invite you to maintain a nodejs buildpack yourself. Prove us all wrong.
I think the Onsi Haiku is still the best description:
Heroku invented this, it's been picked up by lots of other groups (including for Cloud Foundry -- I've worked on buildpacks for Pivotal in that regard).> (1) VMWare images (2) Docker images
You have to build these yourselves. The boundary is your CI system, Dockerfile etc -- which you have to maintain. Buildpacks provide a curated, managed, easily upgraded system that does this for you.
> (3) Debian packages?
These are, in some sense, on the far side of where Buildpacks sit. But also slightly different. A debian package is intended to land in a pluripotent environment, possibly under direct human supervision. A Buildpack is meant to build completely self-contained runnable images, starting from sourcecode.