There is a virtuous cycle in expertise that pushes the boundaries of what is being constructed and the way it’s getting used. A brand new expertise improvement emerges and captures the world’s consideration. Individuals begin experimenting and uncover novel purposes, use circumstances, and approaches to maximise the innovation’s potential. These use circumstances generate vital worth, fueling demand for the subsequent iteration of the innovation, and in flip, a brand new wave of innovators create the subsequent technology of use circumstances, driving additional developments.
Containerization has change into the muse of contemporary, cloud-native software program improvement, supporting new use circumstances and approaches to constructing resilient, scalable, and transportable purposes. It additionally holds the keys to the subsequent software program supply innovation, concurrently necessitating the evolution to secure-by-design, continuously-updated software program and serving because the means to get there.
Beneath, I will speak via among the improvements that led to our containerized revolution, in addition to among the traits of cloud-native software program improvement which have led to this inflection level – one which has primed the world to maneuver away from conventional Linux distros and in direction of a brand new method to open supply software program supply.
Iteration has moved us nearer to ubiquity
There have been many inventions which have paved the way in which for safer, performant open supply supply. Within the curiosity of your time and my phrase depend I will name out three specific milestones. Every step, from Linux Containers (LXC) to Docker and in the end the Open Container Initiative (OCI), constructed upon its predecessor, addressing limitations and unlocking new potentialities.
LXC laid the groundwork by harnessing the Linux kernel’s capabilities (specifically cgroups and namespaces), to create light-weight, remoted environments. For the primary time, builders may package deal purposes with their dependencies, providing a level of consistency throughout completely different programs. Nonetheless, LXC’s complexity for customers and its lack of a standardized picture distribution catalog hindered widespread adoption.
Docker emerged as a game-changer, democratizing container expertise. It simplified the method of making, operating, and sharing containers, making them accessible to a broader viewers. Docker’s user-friendly interface and the creation of Docker Hub, a central repository for container pictures, fostered a vibrant ecosystem. This ease of use fueled fast adoption, but additionally raised issues about vendor lock-in and the necessity for interoperability.
Recognizing the potential for fragmentation, the OCI (Open Containers Initiative) stepped in to standardize container codecs and runtimes. By defining open specs, the OCI ensured that containers may very well be constructed and run throughout completely different platforms, fostering a wholesome, aggressive panorama. Tasks like runC and containerd, born from the OCI, supplied a standard basis for container runtimes and enabled better portability and interoperability.
The OCI requirements additionally enabled Kubernetes (one other vendor-neutral normal) to change into a really transportable platform, able to operating on a variety of infrastructure and permitting organizations to orchestrate their purposes persistently throughout completely different cloud suppliers and on-premises environments. This standardization and its related improvements unlocked the total potential of containers, paving the way in which for his or her ubiquitous presence in trendy software program improvement.
[Containerized] software program is consuming the world
The developments in Linux, the fast democratization of containers via Docker, and the standardization of OCI have been all propelled by necessity, with the evolution of cloud-native app use circumstances pushing orchestration and standardization ahead. These cloud-native utility traits additionally spotlight why a general-purpose method to Linux distros now not serves software program builders with essentially the most safe, up to date foundations to develop on:
Microservice-oriented structure: Cloud-native purposes are sometimes constructed as a set of small, impartial companies, with every microservice performing a selected perform. Every of those microservices may be constructed, deployed, and maintained independently, which supplies an amazing quantity of flexibility and resiliency. As a result of every microservice is impartial, software program builders do not require complete software program packages to run a microservice, relying solely on the naked necessities inside a container.
Useful resource-conscious and environment friendly: Cloud-native purposes are constructed to be environment friendly and resource-conscious to attenuate hundreds on infrastructure. This stripped down method naturally aligns properly with containers and an ephemeral deployment technique, with new containers being deployed continually and different workloads being up to date to the most recent code accessible. This cuts down security dangers by making the most of the latest software program packages, fairly than ready for distro patches and backports.
Portability: Cloud-native purposes are designed to be transportable, with constant efficiency and reliability no matter the place the applying is operating. On account of containers standardizing the surroundings, builders can transfer past the age-old “it labored wonderful on my machine” complications of the previous.
The virtuous cycle of innovation driving new use circumstances and in the end new improvements is obvious in terms of containerization and the widespread adoption of cloud-native purposes. Critically, this inflection level of innovation and use case calls for has pushed an unbelievable price of change inside open supply software program — we have reached a degree the place the security, efficiency, and innovation drawbacks of conventional “frozen-in-time” Linux distros outweigh the familiarity and perceived stability of the final technology of software program supply.
So what ought to the subsequent technology of open supply software program supply appear like?
Enter: Chainguard OS
To satisfy trendy security, efficiency, and productiveness expectations, software program builders want the most recent software program within the smallest type designed for his or her use case, with none of the CVEs that result in danger for the enterprise (and an inventory of “fix-its” from the security groups). Making good on these parameters requires extra than simply making over the previous. As an alternative, the subsequent technology of open supply software program supply wants to start out from the supply of safe, up to date software program: the upstream maintainers.
That is why Chainguard constructed this new distroless method, constantly rebuilding software program packages based mostly not on downstream distros however on the upstream sources which are eradicating vulnerabilities and including efficiency enhancements. We name it Chainguard OS.
Chainguard OS serves as the muse for the broad security, effectivity, and productiveness outcomes that Chainguard merchandise ship right this moment, “Chainguarding” a quickly rising catalog of over 1,000 container pictures.
Chainguard OS adheres to 4 key rules to make that doable:
- Steady Integration and Supply: Emphasizes the continual integration, testing, and launch of upstream software program packages, guaranteeing a streamlined and environment friendly improvement pipeline via automation.
- Nano Updates and Rebuilds: Favors continuous incremental updates and rebuilds over main launch upgrades, guaranteeing smoother transitions and minimizing disruptive adjustments.
- Minimal, Hardened, Immutable Artifacts: Strips away pointless vendor bloat from software program artifacts, making sidecar packages and extras optionally available to the consumer whereas enhancing security via hardening measures.
- Delta Minimization: Retains deviations from upstream to a minimal, incorporating additional patches solely when important and solely for so long as needed till a brand new launch is lower from upstream.
Maybe one of the simplest ways to spotlight the worth of Chainguard OS’s rules is to see the influence in Chainguard Photographs.
Within the beneath screenshot (and viewable right here), you may see a side-by-side comparability between an exterior <python:newest> and <cgr.dev/chainguard/python:newest> Chainguard Picture.
Other than the very clear discrepancy within the vulnerability depend, it is price analyzing the dimensions distinction between the 2 container pictures. The Chainguard picture includes simply 6% of the open supply various picture.
Together with the minimized picture dimension, the Chainguard picture was final up to date simply an hour previous to the screengrab, one thing that occurs day by day:
A fast scan of the provenance and SBOM knowledge illustrates the end-to-end integrity and immutability of the artifacts — a form of full diet label that underscores the security and transparency {that a} trendy method to open supply software program supply can present.
Every Chainguard picture stands as a sensible instance of the worth Chainguard OS supplies, providing a stark various to what has come earlier than it. Maybe the best indicator is the suggestions we have acquired from clients, who’ve shared how Chainguard’s container pictures have helped get rid of CVEs, safe their provide chains, obtain and keep compliance, and scale back developer toil, enabling them to re-allocate valuable developer sources.
Our perception is that Chainguard OS’s rules and method may be utilized to a wide range of use circumstances, extending the advantages of constantly rebuilt-from-source software program packages to much more of the open supply ecosystem.
Should you discovered this convenient, make sure you try our whitepaper on this topic or contact our crew to speak to an skilled on Chainguard’s distroless method.
Notice: This text is expertly written and contributed by Dustin Kirkland — VP of Engineering at Chainguard.
