We all know what containers are, right? Of course, right. They've been around for decades, but Docker made containers so easy to use they've reshaped how we run and deploy complex applications. But, as useful as they are, you can't use them by hand to easily install complex programs. For that, we need a different take on automating program deployment: Cloud Native Buildpacks.
A Buildpack is made up of a container platform, containerized middleware, open-source components, language support, and common services. Among the languages supported by Buildpacks are Java, .NET on Windows (Hosted Web Core), .NET Core, Node.js, Go, PHP, Python, and Ruby.
By "complex," what we're talking about is day-2 program operations These are not, as people sometimes mistake, simply a program that stays up and running for two days. No, really, it's not!
Day-2 programs are -- unlike containers that are usually spun up and down multiple times a day -- meant to keep running until they're replaced by another long-term program. Typically, these are the programs behind business processes, mission-critical applications, or IT infrastructure services. A Linux, Apache, MySQL, PHP/Perl/Python (LAMP) stack application, which needs to be kept running 24x7, for instance, is a day-2 program.
You can, of course, run a LAMP stack application by manually setting it up in a set of interrelated containers piecemeal. But, that's slow, tedious, and can lead to mistakes.
With the Buildpack approach, when you deploy an application, the Buildback program pulls together all the frameworks and runtime support you need to automatically generate, containerize, and run your application. It does this by "reading" your code and downloading the dependencies you need to run it. The Buildpack also configures your apps required network services.
A Buildpack's contents are typically kept up to date by their creators. So, for example, a developer doesn't need to worry about whether the latest and most secure libraries are available for your programs. They're already baked into the Buildpack. This means, as VMware, a big Buildpack supporter, puts it, "You don't have to think about dependencies, middleware, or runtime components -- the platform does it for you."
There are many advantages to the Buildpack approach. These include:
- Reducing the operational burden on developers, while supporting enterprise operators who manage apps at scale.
- Ensure that apps meet security and compliance requirements without developer intervention.
- Provide automated delivery of both operating-system-level and application-level dependency upgrades.
- Rely on compatibility guarantees to safely apply patches without rebuilding artifacts and without unintentionally changing application behavior.
Heroku, one of the first Platform as a Service (PaaS) clouds, came up with this idea in 2011. Since, then, it's been adopted by other PaaS and related platforms including Cloud Foundry, GitLab, Knative, and Deis.
While Cloud Buildpacks started before cloud-native development techniques took off in programming circles, Buildpacks are now incorporating cloud-native techniques. Pivotal and Heroku started the Cloud Native Buildpacks project in January 2018. It has since transitioned to the Cloud Native Computing Foundation (CNCF) as part of the Cloud Native Sandbox.
This project aims to unify the buildpack ecosystems with a well-defined platform-to-buildpack contract, The Cloud Native Buildpacks embrace modern container standards, such as the OCI Image format, cross-repository blob mounting, and image layer "rebasing" on Docker API v2 registries.
What all this means for those of you who aren't programmers is Buildpacks can make it much easier, safer, and faster to develop cloud applications. VMware claims, with its Buildpack take, Tanzu, companies will see a 400% faster release velocity, 80% faster security patching, and a 60% reduction in infrastructure costs.
That's impressive. If Cloud Buildpacks live up to their promise, they'll end up being as influential as containers.