Heroku pushes Buildpacks under cloud native umbrella

buildpack

Cloud native Buildpacks are the newest addition to the CNCF sandbox, seven years after the original version of the project was started at application platform provider Heroku.

In 2012 the company published the Buildpack API, which has since been adopted by organisations like Pivotal, Cloud Foundry, and GitLab. Since all of those developed their APIs independently, isolated ecosystems grew up. Moving Buildpacks under the umbrella of the cloud native computing foundation, whick is also responsible for the fostering of projects such as Kubernetes and Prometheus, should standardise the programming interface for all platforms and is supposed to open the project for anyone working with containers.

Buildpacks were initially created to enable support for multiple programming languages on the Heroku platform. Their cloud native counterparts now turn source code into Docker images, which is meant to facilitate runtime customisation and app portability. If you’re thinking that sounds a bit like a Dockerfile, you wouldn’t be wrong. In a blog entry, Heroku likes to point out though, that compared to those, buildpacks are what they call “app aware”, which means they automatically provide security updates, know your app’s build tools and install the runtimes and frameworks you use.

In a first step, a script determines if a given buildpack is suitable for the source code at hand. If the result is positive, a build script prepares the code for production – for example by installing dependencies and preparing static assets. By putting certain dependencies or artifacts into OCI image layers, buildpacks are able to structure layers for clean separation of concerns.

How does this whole thing work anyway?

To enter a project into the sandbox, it needs at least two sponsors from the CNCF technical oversight committee, as well as presentation to the TOC community meeting, adherence to the CNCF IP policy and a prominent display of its status on the project page. To pass on to the so-called incubating stage and eventually become a graduated project, at least two thirds of the TOC have to vote in favour of entering incubation. Other requirements are a “healthy number of committers” as well as evidence that the project is used successfully in production by at least three adequate, independent end users

The CNCF’s aims are the growth and evolution of cloud native technologies, free of partisan influence. It works on promoting the underlying tech and making it more accessible and reliable. The sandbox was introduced as a way to facilitate alignment with existing projects, encourage public visibility and remove obstacles to adoption and contribution.

Amongst the projects sharing sandbox stage at the moment are the Serverless events specification CloudEvents, identity management projects SPIFFE and SPIRE, the open policy agent, as well as the Harbor registry. Projects in incubating stage include OpenTracing, containerd, the proxy Envoy, and Jaeger, which is another tracing tool.