Have you been reading about the massive confusion regarding container runtimes and compatibility that has been simmering for months, and finally erupted last week? For Pivotal customers, this may be interesting news to keep an eye on, but it’s irrelevant to their success with delivering software. Why? Pivotal Cloud Foundry customers get to focus solely on apps, knowing that they are running atop the most mature, resilient, and dependable container-centric platform in the world. The infrastructure that your application depends on should be stable and reliable—dare I say, boring!—so that you can spend all your time delivering innovative cloud apps.
The Cloud Foundry Foundation and all of Pivotal’s customers have been operating from the ‘infrastructure should be boring’ principle from the beginning of the project. Even back then, we knew that containers played a necessary role in modern infrastructure. Containers have been part of Cloud Foundry since 2011, long before technology like Docker came about. Pivotal first launched a commercial Cloud Foundry product in 2013, and we’ve been running containers in production ever since.
Our customers run innovative, mission-critical business systems on Pivotal Cloud Foundry, and require not only cutting-edge technology, but stability. This fact fundamentally influences our choices and how we introduce technology into the platform.
Let’s look at our journey in search of boring, cloud-scale container technology.
- 2010/2011—At VMware during the incubation of the project, Cloud Foundry used Linux isolation features such as chroot processes with temporary system users. We were without all of the cgroups and namespaces available today. We knew at the time that improved isolation was required!
- 2011/2012 —Cloud Foundry tried using lxc and learned that more tooling was needed for fine grain controls and insight into lower level Linux isolation configuration options. So, we built the 1st version of what is now called Garden because nothing existed in 2011 that met our demands for stability and multi-tenancy. What is Garden? It’s a platform-agnostic API for container creation and management, with pluggable support for different platforms and runtimes. During this time period, the API was used for Linux containers.
- 2013—Docker released as open source, and a newfound interest in containers emerged. While interesting, Docker was optimized for development environments and wasn’t suitable for production-grade, multi-tenant workloads. For instance, shutting down the Docker daemon stopped all containers, and it wasn’t originally optimized for long-running environments.
- 2015—Garden proven reliable at large scale with many of the largest companies in the world. Its extensible model allowed Cloud Foundry and Pivotal to offer Linux and Windows 2012R2 containers, along with support for Docker images. Cloud Foundry was, and still is, the only platform that supports containerized workloads for both Linux and Windows in production.
- 2015—The Open Container Initiative (OCI) is formed with Pivotal as a founding member as industry leaders come together to create consensus on a container runtime specification. runC was proposed and accepted as the standard, and had a lightweight scope that gave Pivotal room to add value on top.
- 2015/16—Thanks to Garden’s extensibility model and in collaboration with IBM engineers in the Cloud Foundry Foundation, Pivotal creates Garden runC. Building with runC enables us to share the core container runtime that creates containers with the large and growing Docker ecosystem. Compatibility, FTW! Using runC also enables CF to optimize for our opinions around daemon processes, container lifecycle including health checks and container networking that come from years of operating containers in production with mission critical workloads. We continue to maintain and run on top of Garden because we have experienced the value of having a clean, stable, orchestrator-first API in front of our container execution engine. Garden’s API allows our orchestration engine, Diego, to run unchanged even while we switch out the underlying containerization technology (from our own solution to runC) and even across multiple OSes (Linux, Windows). Diego is an incredibly powerful, mature, boring engine that operates at exceptional scale!
- 2016—We believe that responsible software companies run their product as a service before putting it in the hands of customers. Pivotal Web Services, a hosted version of Pivotal Cloud Foundry, now uses Garden runC in production. As of today, 100% of the tens of thousands of containers in PWS use runC. After running runC as-a-Service for several months we plan on introducing it in a future release of PCF Elastic Runtime for customers to deploy on any host they choose.
- 2016—Pivotal created an innovative continuous integration tool called Concourse that is open-source and freely available. We’ve adopted Garden runC for a Docker image runtime within this opinionated CI.
We’re happy that OCI is continuing to look at ways to standardize essential parts of the container ecosystem and publicly sharing the scope of the project so we can enable a large ecosystem of container tools that have interoperability and stability.
Infrastructure shouldn’t be “exciting”; it should just work. If you’re building apps that matter, deploy to a platform that puts the attention on developer productivity, not exposed infrastructure primitives. Deploy to a platform that makes its best-in-class container runtime reliable, boring, and invisible. Deploy to Pivotal Cloud Foundry.
About the Author
Follow on Twitter More Content by Richard Seroter
