Buildpacks Go Cloud Native
blog.heroku.com
Buildpacks Go Cloud Native
1–10 of 17 posts
Re: Buildpacks Go Cloud Native
#2This is Heroku's post, the HN discussion about the CNCF blog post is at https://news.ycombinator.com/item?id=18131378
Pivotal's post for reference: https://content.pivotal.io/blog/peace-of-mind-for-developers...
Re: Buildpacks Go Cloud Native
#3Aren't they just shell scripts? Last time I looked inside one anyway. Heroku makes a big deal about them, but most Unix people have similar things floating around in ~/bin.
Re: Buildpacks Go Cloud Native
#4Hadn't heard of buildpacks before.
Where do they fit into packaging picture?
How do they compare to (1) VMWare images (2) Docker images (3) Debian packages? And when would you use them instead of one of these.
Re: Buildpacks Go Cloud Native
#5Aren't they just shell scripts? Last time I looked inside one anyway. Heroku makes a big deal about them, but most Unix people have similar things floating around in ~/bin.
> Aren't they just shell scripts?
They can be written in any language. I have personally worked on buildpacks written in bash, golang, ruby, python and I forget what else.
> Heroku makes a big deal about them, but most Unix people have similar things floating around in ~/bin.
I don't know that I agree. Could you elaborate a bit?
Re: Buildpacks Go Cloud Native
#6Hadn't heard of buildpacks before. Where do they fit into packaging picture? How do they compare to (1) VMWare images (2) Docker images (3) Debian packages? And when would you use them instead of one of these.
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.
> (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.
Re: Buildpacks Go Cloud Native
#7Hadn't heard of buildpacks before. Where do they fit into packaging picture? How do they compare to (1) VMWare images (2) Docker images (3) Debian packages? And when would you use them instead of one of these.
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…
> Buildpacks focus on turning sourcecode into a runnable container
So buildpacks are like Debian source packages?
It's a package of my .c files, and the consumer runs $(CC) to compile and run those and It Just Works?
Re: Buildpacks Go Cloud Native
#8Earlier quoted context omitted.
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…
> Buildpacks focus on turning sourcecode into a runnable container So buildpacks are like Debian source packages? It's a package of my .c files, and the consumer runs $(CC) to compile and run those and It Just Works?
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.
Re: Buildpacks Go Cloud Native
#9Aren't they just shell scripts? Last time I looked inside one anyway. Heroku makes a big deal about them, but most Unix people have similar things floating around in ~/bin.
> Aren't they just shell scripts? They can be written in any language. I have personally worked on buildpacks written in bash, golang, ruby, python and I forget what else. > Heroku makes a big deal about them, but most Unix people have similar things floating around in ~/bin. I don't know that I agree. Could you elaborate a bit?
All the ones I've looked at have been shell, as Buildpacks are used to build systems. Python would work too.
They're useful, but they're not an 'invention' or a 'technology' any more than any other bootstrap shell script is.
Re: Buildpacks Go Cloud Native
#10Earlier quoted context omitted.
> Buildpacks focus on turning sourcecode into a runnable container So buildpacks are like Debian source packages? It's a package of my .c files, and the consumer runs $(CC) to compile and run those and It Just Works?
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…
> The source package has to be packaged by someone
Same with buildpack-packager.
But I get the idea. Thanks for explaining!