Transition application code to images with Cloud Native Buildpacks

Much of the conversation in the software industry is around developer experience. From new ways to measure productivity to reducing important but drudge work, organizations are looking to make life more joyful for developers.

One area that’s gaining more attention is the use of buildpacks to create apps for cloud-native environments. Though not a new concept – buildpacks have been around for about 15 years – they can ease the burden on developers by simply taking source code and turning it into fully functional apps.

A quick history, according to Ram Iyengar, chief evangelist at Cloud Foundry: Heroku brought up the concept of creating immutable objects from source code, regardless of programming language or platform, in 2010. Cloud Foundry (the open source project) was working to do much the same thing, but as open source. Pivotal was an early backer and developer of the Cloud Foundry project as a commercial tool, and both projects released a v2 in 2015. But when Pivotal was acquired by VMware in 2019, the Cloud Foundry Foundation was formed to shepherd the project, and that is now under the auspices of the Cloud Native Computing Foundation.

Pivotal’s path was to make containers out of the source code provided, while Heroku’s vision did not include containers. In the cloud native vs. non-cloud native debate, there exists a divide in which everything runs in containers, and where not everything runs in containers. So, Heroku and Pivotal/Cloud Foundry came together to create Cloud Native Buildpacks that would be compatible with the cloud native ecosystem, which, Iyengar said, meant that “it had to be open source, it had to adhere to the OCI specification, and it has to be ready to deploy on Kubernetes and make use of cloud native constructs.” 

The non-Kubernetes version 2 of buildpacks, Iyengar said, will continue to exist for the foreseeable future, while the “newer, shinier version of buildpacks in the one for containers and Kubernetes,” he said.

Heroku went ahead with its closed source commercial implementation – which has since been open-sourced –  while Cloud Foundry Foundation in 2020 created Paketo buildpacks, which is open source and production-ready, Iyengar said.

All about the developer experience

Among the benefits of buildpacks, as we bring the narrative back around, is improving the developer experience. While there are six or seven ways JavaScript developers can get this experience of having tooling give you a functional app from source code, but if you’re not using JavaScript, the tool is basically useless, Iyengar said. Packeto buildpacks enable developers to get the same build experience regardless of the source code language. 

“The kind of homogeneity that’s possible with buildpacks is phenomenal, and that’s really what I mean when I say developer experience,” Iyengar said. “It’s about allowing developers to bring any language or framework and providing them with the homogeneous and complete user interface in order to give them the best-in-class developer experience that is possible.”

Iyengar also pointed out that buildpacks can overcome automation hurdles that exist when using technologies such as Docker. “For a developer or software engineering team to maintain Docker files for local development and production, it can quickly become a big sort of development hell in creating these Docker files and maintaining them,” he said. “Buildpacks relieve users of having to write these meta files and maintain them.”  He explained that with a Docker-based build process, if you want to write a different Docker file for your GitHub actions versus if you’re running them on your pre-production machines, there are different requirements. It’s not the most optimal.” Buildpacks, he said, make the process uniform irrespective of the infrastructure you’re running on. 

The same is true for SBOMs – software bills of materials – and going forward, you’ll be able to choose between x86 images and ARM images and dictate in the build process what kind of image you want and make them all available, Iyengar said. “The focus on automation within the buildpacks community is huge.” Further, he noted, the project makes available production-ready Buildpacks that are also compatible with CI/CD integrations such as CircleCI, Gitlab, Tekton, and others.

Because buildpacks provide transparency into what’s in an image, and what images can and cannot contain, this is where buildpacks and AI cross. “Any AI that is able to read and parse buildpacks metadata can very conveniently look at what policies need to be set, and you can create rules like do not create or push containers to production if they contain a particular version of, say, Go that’s outdated or has a vulnerability,” Iyengar said. “And, if a new vulnerability gets detected, there can be an AI engine that basically turns through all of the buildpack layers and says, ‘these are the layers that are affected, let’s replace them immediately.’ Mitigation, he added, becomes a very trivial operation.

Iyengar stated that the focus within the buildpacks community has been to “plug a lot of gaps that the Docker-based ecosystem has left, but it’s really about knowing what’s inside an image when you’re deploying it.”  Buildpacks, he said, make it easy to attest and create provenance that images need in our modern, security-first cloud native landscape.  Going forward, built-in SBOMs won’t just be a convenience, they’ll be a compliance requirement.

 

The post Transition application code to images with Cloud Native Buildpacks appeared first on SD Times.

Source: Read More