There’s a virtuous cycle in technology that pushes the boundaries of what’s being built and how it’s being used. A new technology development emerges and captures the world’s attention. People start experimenting and discover novel applications, use cases, and approaches to maximize the innovation’s potential. These use cases generate significant value, fueling demand for the next iteration of the innovation, and in turn, a new wave of innovators create the next generation of use cases, driving further advancements.
Containerization has become the foundation of modern, cloud-native software development, supporting new use cases and approaches to building resilient, scalable, and portable applications. It also holds the keys to the next software delivery innovation, simultaneously necessitating the evolution to secure-by-design, continuously-updated software and serving as the means to get there.
Below, I’ll talk through some of the innovations that led to our containerized revolution, as well as some of the traits of cloud-native software development that have led to this inflection point – one that has primed the world to move away from traditional Linux distros and towards a new approach to open source software delivery.
Iteration has moved us closer to ubiquity
There have been many innovations that have paved the way for more secure, performant open source delivery. In the interest of your time and my word count I’ll call out three particular milestones. Each step, from Linux Containers (LXC) to Docker and ultimately the Open Container Initiative (OCI), built upon its predecessor, addressing limitations and unlocking new possibilities.
LXC laid the groundwork by harnessing the Linux kernel’s capabilities (namely cgroups and namespaces), to create lightweight, isolated environments. For the first time, developers could package applications with their dependencies, offering a degree of consistency across different systems. However, LXC’s complexity for users and its lack of a standardized image distribution catalog hindered widespread adoption.
Docker emerged as a game-changer, democratizing container technology. It simplified the process of creating, running, and sharing containers, making them accessible to a broader audience. Docker’s user-friendly interface and the creation of Docker Hub, a central repository for container images, fostered a vibrant ecosystem. This ease of use fueled rapid adoption, but also raised concerns about vendor lock-in and the need for interoperability.
Recognizing the potential for fragmentation, the OCI (Open Containers Initiative) stepped in to standardize container formats and runtimes. By defining open specifications, the OCI ensured that containers could be built and run across different platforms, fostering a healthy, competitive landscape. Projects like runC and containerd, born from the OCI, provided a common foundation for container runtimes and enabled greater portability and interoperability.
The OCI standards also enabled Kubernetes (another vendor-neutral standard) to become a truly portable platform, capable of running on a wide range of infrastructure and allowing organizations to orchestrate their applications consistently across different cloud providers and on-premises environments. This standardization and its associated innovations unlocked the full potential of containers, paving the way for their ubiquitous presence in modern software development.
[Containerized] software is eating the world
The advancements in Linux, the rapid democratization of containers through Docker, and the standardization of OCI were all propelled by necessity, with the evolution of cloud-native app use cases pushing orchestration and standardization forward. Those cloud-native application characteristics also highlight why a general-purpose approach to Linux distros no longer serves software developers with the most secure, updated foundations to develop on:
Microservice-oriented architecture: Cloud-native applications are typically built as a collection of small, independent services, with each microservice performing a specific function. Each of these microservices can be built, deployed, and maintained independently, which provides a tremendous amount of flexibility and resiliency. Because each microservice is independent, software builders don’t require comprehensive software packages to run a microservice, relying only on the bare essentials within a container.
Resource-conscious and efficient: Cloud-native applications are built to be efficient and resource-conscious to minimize loads on infrastructure. This stripped down approach naturally aligns well with containers and an ephemeral deployment strategy, with new containers being deployed constantly and other workloads being updated to the latest code available. This cuts down security risks by taking advantage of the newest software packages, rather than waiting for distro patches and backports.
Portability: Cloud-native applications are designed to be portable, with consistent performance and reliability regardless of where the application is running. As a result of containers standardizing the environment, developers can move beyond the age-old “it worked fine on my machine” headaches of the past.
The virtuous cycle of innovation driving new use cases and ultimately new innovations is clear when it comes to containerization and the widespread adoption of cloud-native applications. Critically, this inflection point of innovation and use case demands has driven an incredible rate of change within open source software — we’ve reached a point where the security, performance, and innovation drawbacks of traditional “frozen-in-time” Linux distros outweigh the familiarity and perceived stability of the last generation of software delivery.
So what should the next generation of open source software delivery look like?
Enter: Chainguard OS
To meet modern security, performance, and productivity expectations, software builders need the latest software in the smallest form designed for their use case, without any of the CVEs that lead to risk for the business (and a list of “fix-its” from the security teams). Making good on those parameters requires more than just making over the past. Instead, the next generation of open source software delivery needs to start from the source of secure, updated software: the upstream maintainers.
That’s why Chainguard built this new distroless approach, continuously rebuilding software packages based not on downstream distros but on the upstream sources that are removing vulnerabilities and adding performance improvements. We call it Chainguard OS.
Chainguard OS serves as the foundation for the broad security, efficiency, and productivity outcomes that Chainguard products deliver today, “Chainguarding” a rapidly growing catalog of over 1,000 container images.
Chainguard OS adheres to four key principles to make that possible:
- Continuous Integration and Delivery: Emphasizes the continuous integration, testing, and release of upstream software packages, ensuring a streamlined and efficient development pipeline through automation.
- Nano Updates and Rebuilds: Favors non-stop incremental updates and rebuilds over major release upgrades, ensuring smoother transitions and minimizing disruptive changes.
- Minimal, Hardened, Immutable Artifacts: Strips away unnecessary vendor bloat from software artifacts, making sidecar packages and extras optional to the user while enhancing security through hardening measures.
- Delta Minimization: Keeps deviations from upstream to a minimum, incorporating extra patches only when essential and only for as long as necessary until a new release is cut from upstream.
Perhaps the best way to highlight the value of Chainguard OS’s principles is to see the impact in Chainguard Images.
In the below screenshot (and viewable here), you can see a side-by-side comparison between an external and Chainguard Image.
Aside from the very clear discrepancy in the vulnerability count, it’s worth examining the size difference between the two container images. The Chainguard image comprises just 6% of the open source alternative image.
Along with the minimized image size, the Chainguard image was last updated just an hour prior to the screengrab, something that happens daily:
A quick scan of the provenance and SBOM data illustrates the end-to-end integrity and immutability of the artifacts — a kind of complete nutrition label that underscores the security and transparency that a modern approach to open source software delivery can provide.
Each Chainguard image stands as a practical example of the value Chainguard OS provides, offering a stark alternative to what has come before it. Perhaps the greatest indicator is the feedback we’ve received from customers, who have shared how Chainguard’s container images have helped eliminate CVEs, secure their supply chains, achieve and maintain compliance, and reduce developer toil, enabling them to re-allocate precious developer resources.
Our belief is that Chainguard OS’s principles and approach can be applied to a variety of use cases, extending the benefits of continuously rebuilt-from-source software packages to even more of the open source ecosystem.
If you found this useful, be sure to check out our whitepaper on this subject or contact our team to talk to an expert on Chainguard’s distroless approach.
Note: This article is expertly written and contributed by Dustin Kirkland — VP of Engineering at Chainguard.
About The Author
Original post here
