Article by Jason English in DZone for Cloud Foundry Foundation
Twenty years ago, software was eating the world. Then around a decade ago, containers started eating software, heralded by the arrival of open source OCI standards.
Suddenly, developers were able to package an application artifact in a container—sometimes all by themselves. And each container image could technically run anywhere—especially in cloud infrastructure. No more needing to buy VM licenses, looking for rackspace and spare servers, and no more contacting the IT Ops department to request provisioning.
Unfortunately, the continuing journey of deploying containers throughout all enterprise IT estates hasn’t been all smooth sailing. Dev teams are confronted with an ever-increasing array of options for building and configuring multiple container images to support unique application requirements, and different underlying flavors of commercial and open-source platforms.
Even if a developer becomes an expert in docker build, and the team has enough daily time to keep track of changes across all components and dependencies, they are likely to see functional and security gaps appearing within their expanding container fleet.
Fortunately, we are seeing a bright spot in the evolution of Cloud Native Buildpacks, an open source implementation project pioneered at Heroku and adopted early at Pivotal, which is now under the wing of the CNCF.
Paketo Buildpacks is an open source implementation of Cloud Native Buildpacks currently owned by the Cloud Foundry Foundation. Paketo automatically compiles and encapsulates developer application code into containers. Here’s how this latest iteration of buildpacks supports several important developer preferences and development team initiatives.
Open source interoperability
Modern developers appreciate the ability to build on open source technology whenever they can, but it’s not always that simple to decide between open source solutions when vendors and end user companies have already made architectural decisions and set standards. Even in an open-source-first shop, many aspects of the environment will be vendor-supported and offer opinionated stacks for specific delivery platforms.
Developers love to utilize buildpacks because they allow them to focus on coding business logic, rather than the infinite combinations of deployment details. Dealing with both source and deployment variability is where Paketo differentiates itself from previous containerization approaches.
So, it doesn’t matter whether a developer codes in Java, Go, nodeJS or Python, Paketo can compile ready-to-run containers. And, it doesn’t matter which cloud IaaS resource or on-prem server it runs on.
“I think we’re seeing a lot more developers who have a custom platform with custom stacks, but they keep coming back to Paketo Buildpacks because they can actually plug them into a modular system,” said Forest Eckhardt, contributor and maintainer to the Paketo project. “I think that adoption is going well, a lot of the adopters that we see are DevOps or Operations leaders who are trying to deliver applications for their clients and external teams.”
Platform engineering with policy
Platform engineering practices give developers shared, self-service resources and environments for development work, reducing setup costs and time, and encouraging code, component, and configuration reuse.
These common platform engineering environments can be offered up within a self-service internal portal or an external partner development portal, sometimes accompanied by support from a platform team that curates and reviews all elements in the platform.
If the shared team space has too many random uploads, developers will not be able to distinguish the relative utility or safety of various unvalidated container definitions and packages. Proper governance means giving developers the ability to build to spec—without having to slog through huge policy checklists.
Buildpacks take much of the effort and risk out of the ‘last mile’ of platform engineering. Developers can simply bring their code, and Paketo Buildpacks detects the language, gathers dependencies, and builds a valid container image that fits within the chosen methodology and policies of the organization.
DevOps-speed automation
In addition to empowering developers with self-service resources, automating everything as much as possible is another core tenet of the DevOps movement.
DevOps is usually represented as a continuous infinity loop, where each change the team promotes in the design/development/build/deploy lifecycle should be executed by automated processes, including production monitoring and feedback to drive the next software delivery cycle.
Any manual intervention in the lifecycle should be looked at as the next potential constraint to be addressed. If developers are spending time setting up Dockerfiles and validating containers, that’s less time spent creating new functionality or debugging critical issues.
Software supply chain assurance
Developers want to move fast, so they turn to existing code and infrastructure examples that are working for peers. Heaps of downloadable packages and source code snippets are ready to go on npm and StackOverflow and DockerHub – many with millions of downloads and lots of upvotes and review stars.
The advent of such public development resources and git-style repositories offers immense value for the software industry as a whole, but by nature it also provides an ideal entry point for software supply chain (or SSC) attacks. Bad actors can insert malware and irresponsible ones can leave behind vulnerabilities. Scanning an application once exploits are baked in can be difficult.
It’s about time the software industry started taking a page from other discrete industries like high-tech manufacturing and pharmaceuticals that rely on tight governance of their supply chains to maximize customer value with reduced risk. For instance, an automotive brand would want to know the provenance of every part that goes into a car they manufacture, a complete bill-of-materials (or BOM) including both its supplier history and its source material composition.
Paketo Buildpacks automatically generates an SBOM (software bill-of-materials) during each build process, attached to the image, so there’s no need to rely on external scanning tools. The SBOM documents information about every component in the packaged application, for instance, that it was written with Go version 1.22.3, even though that original code was compiled.
The Intellyx Take
Various forms of system encapsulation routines have been around for years, well before Docker appeared. Hey, containers even existed on mainframes. But there’s something distinct about this current wave of containerization for a cloud native world.
Paketo Buildpacks provide application delivery teams with total flexibility in selecting their platforms and open source components of choice, with automation and reproducibility. Developers can successfully build the same app, the same way, thousands of times in a row, even if underlying components are updated.
That’s why so many major development shops are moving toward modern buildpacks, and removing the black box around containerization—no matter what deployment platform and methodology they espouse.
This BrainBlog ran in DZone, read it there: https://dzone.com/articles/paketo-buildpacks-aligning-container-images
©2024 Intellyx B.V. Intellyx is editorially responsible for this document. At the time of writing, Cloud Foundry Foundation is an Intellyx customer. No AI bots were used to write this content. Image source: Adobe Express AI.
