At Open Source India 2024, Ram Iyengar, Chief Evangelist, Cloud Foundry Foundation, raised a few eyebrows with his cogent arguments about ways to manage and deploy infrastructure. OSFY’s Yashasvini Razdan got some exclusive takes on alternatives for scalable application deployment and management, and the role of Cloud Foundry Foundation in this business….
Q. Could you tell me what is the Cloud Foundry Foundation and how does it support open source development?
A. The Cloud Foundry Foundation is a non-profit that basically exists to provide vendor neutral governance around the Cloud Foundry open source project as well as a lot of projects that surround the Cloud Foundry project within the ecosystem. Cloud Foundry has been an open source project for a little over 10 years now, which is like the Jurassic Age in terms of software and they’ve been a leading proponent of open source alternatives to good projects in the entire commercial ecosystem.
Q. How is the Cloud Foundry Foundation related to the Linux Foundation?
A. The Cloud Foundry Foundation came together around 2015. Originally, it was part of a project at a company called Pivotal, which was spun off from VMware. Over time, Pivotal was reacquired by VMware. During this period, several major companies, like IBM, SUSE, Google, and SAP, adopted Cloud Foundry as their preferred cloud platform. This widespread adoption created a need for a vendor-neutral, independent open source body, leading to the establishment of the Cloud Foundry Foundation.
Fast forward seven or eight years, and the Cloud Foundry community began to shrink, in part due to the emergence of Docker, Kubernetes, and other technologies that attracted developers’ attention. As the community scaled down, there was less need for an independent body, and the foundation transitioned to become a directed fund under the Linux Foundation. Today, it operates as one of many projects within the Linux Foundation.
Q. How big is this community?
A. It’s hard to tell, but there are a little over 20,000 people on our Slack.
Q. What role do these partnerships and collaborations play in Cloud Foundry’s initiative?
A. The members of the Cloud Foundry Foundation provide essential funding to keep the foundation running. Membership fees from these companies support the foundation’s activities, and members contribute in various ways. They nominate representatives to the governing board, participate in the Technical Oversight Committee (TOC), and supply staffing for many projects. They also help fund our events and identify key industry events for us to attend or sponsor.
For instance, at KubeCons around the world, our members assist with staffing support. Indirectly, this participation also serves as a signal of their investment in the project and its active development when they present it to their major clients. This symbiotic relationship is essential for sustaining the project, the foundation, and the community. Our membership ranges from major corporations to smaller companies.
Q. How is the democratic ethos and open source spirit of the foundation maintained with such big companies being members?
A. This is where the Linux Foundation, or the vendor-neutral history of the Cloud Foundry Foundation, plays a prominent role. The foundation operates independently of any vendor influence, prioritising the interests of the open source project above all. We carefully avoid any involvement with vendors’ commercial activities.
Q. What are the benefits this foundation provides to developers? Why should developers be a part of it?
A. Being part of the Cloud Foundry community grants direct access to maintainers, contributors, and members of the governing board or TOC. This setup effectively removes any hierarchy or layers between a developer looking to achieve something within Cloud Foundry and those who can make it happen.
The community is small enough that every developer can have a voice and make an impact, yet large enough to encompass a wide range of individuals working across various open source projects. Ultimately, if a developer seeks an impactful, community-driven open source experience, Cloud Foundry offers a strong foundation to start with.
Q. What projects is the foundation working on?
A. Active development is a key focus of the foundation, with Cloud Foundry at the core—a comprehensive suite of projects rather than a single starting point. One central component is BOSH, or the BOSH Director, which plays a crucial role in managing and deploying infrastructure within Cloud Foundry. The ecosystem also includes various smaller projects essential to its functionality, such as UAA for authentication, and other components dedicated to logging, security, and networking. These individual projects can be utilised independently, but together they form the complete Cloud Foundry installation essential for foundational operations within the platform.
Additionally, there are projects that overlap with other communities. For example, our projects Korifi and Paketo are used heavily by folks in the Kubernetes and Cloud Native communities. These projects are built and maintained to serve users who belong to a community adjacent to ours.
Q. How would you describe the expanse and use of Cloud Foundry geographically?
A. Cloud Foundry is used worldwide, though the exact scale is difficult to pinpoint. There’s a strong presence in North America, a large contingent in Europe, and a substantial community in Bengaluru, as is common with many major technologies.
In India, the State Bank of India leverages Cloud Foundry, while in the UK, the government also relies on it. Governments in Canada, the US (through cloud.gov, a Cloud Foundry-powered PaaS for federal agencies), and South Korea are users. Alongside these governmental applications, many financial institutions and large corporations, like Mercedes-Benz in the EU, are also part of the Cloud Foundry ecosystem.
Q. How do you manage and govern all these contributions?
A. The Cloud Foundry community is organised into working groups led by elected working group leads. These groups report to a Technical Oversight Committee (TOC), which collaborates with the working groups and their leads. Above the TOC is a governing board that provides overall direction.
My team and I provide various services for these groups, such as setting up GitHub accounts, creating AWS and GCP-based pipelines for testing, and ensuring that all required resources are functional. Each working group operates as a self-governing unit within its project, while our role primarily involves support. We also contribute by promoting the open source tool and handling related marketing activities.
Q. How does Cloud Foundry compare with Docker and Kubernetes?
A. Docker and Kubernetes emerged independently, between 2010 and 2020, each tackling similar challenges. Each solution gathered its own community, with some gaining more traction over time, leading to greater adoption. Container technology itself has been available in Linux for a long time, but it wasn’t widely adopted until Docker enhanced the developer experience around it.
Docker packages source code into a container based on the specifications provided, resulting in a container image or an immutable artefact that can be deployed on any compute resource, like a VM. Docker attempted container orchestration with Docker Swarm, which eventually fell out of use as Kubernetes became the preferred orchestrator. Kubernetes offers ways to handle networking and ensure that containers run consistently. It provides the capability to maintain, say, five instances of a container, making sure they’re always available. Though Kubernetes doesn’t necessarily simplify things, it does offer comprehensive container orchestration.
Cloud Foundry also handles source code to immutable artefact conversion using Linux-based containment (LXC). It can manage containers to ensure they’re always available, support multiple instances of applications, and streamline networking, logging, and orchestration within its ecosystem. However, Cloud Foundry has not gained the same popularity as Docker or Kubernetes.
Q. Are there any instances where Cloud Foundry is integrating with Kubernetes or Docker?
A. Yes, for two reasons: first, the popularity of certain projects tends to steer the community in a specific direction. Second, after creating a Docker container, there are numerous deployment options, but if a standard, compliant, and secure deployment path existed, many companies would prefer it.
In isolation, Kubernetes is limited as it provides only a few core functions; to make it genuinely useful, it requires a complete ecosystem, which is what the CNCF (Cloud Native Computing Foundation) ecosystem offers. This includes a build service, deployment tools, CI/CD pipelines, logging, monitoring, and security tools, all of which collectively make Kubernetes functional. Kubernetes deployment complexity also grows with team structures, as managing consistency and updates across clusters can quickly become complicated; using Kubernetes alone can feel cumbersome. Personally, I believe developers aren’t supposed to be wasting their time with Kubernetes.
Cloud Foundry provides a higher-level abstraction over Kubernetes, with constructs like ‘orgs’ and ‘spaces’, mapping them to Kubernetes components, simplifying the experience. Developers can use Cloud Foundry’s own tools or integrate other cloud-native options like Istio or Envoy for networking.
Q. You made a very interesting statement that “developers are wasting their time with Kubernetes.” Could you elaborate?
A. Infrastructure abstractions like Kubernetes are meant to be the “boring” part of the stack eventually. So, when I say developers sometimes waste time, I mean developers don’t always need the trendiest solution but a reliable one, where core challenges are already solved. This lets them focus on what truly matters instead of making the basics of their workloads function.
There’s room for both established and emerging projects in a developer’s toolkit, and developers need to find a middle ground for themselves. Trends come and go, and very few technologies including Cloud Foundry have withstood the Docker and the Kubernetes wave, and beyond. It’s actively developed and continues to serve infrastructure teams who are now focused on optimising AI workflows. Cloud Foundry’s strength lies in its community of infrastructure enthusiasts who seek a platform that provides first-class multi-tenant support over any infrastructure, with a straightforward approach to services, workloads, and networking. It’s designed to handle various workloads, from tomorrow’s AI to today’s cloud-native apps, containers, and beyond.
Developers often focus on a technology until it becomes “boring,” at which point they move on to higher order problems and solution sets. But Cloud Foundry has seen its peak, held huge events, gained a large following, and remains in use at major companies. For example, JPMorgan runs thousands of containers in production with Cloud Foundry, as do some of SAP’s clients.
Q. How does this foundation support scalable application deployment across multiple clouds?
A. Cloud Foundry itself was always designed with the goal of abstracting underlying cloud infrastructure from all the workflows layered above it. Envisioned as a PaaS, Cloud Foundry was created to operate on any hyperscaler or cloud provider you install it on. It is extremely scalable across single or multiple clouds. Cloud Foundry BOSH was inspired by Google’s BORG (often cited as a precursor to Kubernetes).
BOSH was designed as a next-generation BOSH, with ‘S’ following ‘R’ and ‘H’ after ‘G’, symbolising this progression. Cloud Foundry was envisioned to operate at hyperscale, efficiently handling hundreds of thousands of containers. BOSH, or the BOSH Director, serves as a substrate that shields developers from the complexities of the underlying cloud platform.
Q. How is this scalability achieved and how does it impact the setup cost?
A. This scalability is partly because running Cloud Foundry requires a substantial setup—typically 30 to 50 VMs, which enables it to optimise compute resources at scale. It can handle a high volume of applications and deploy numerous workloads and instances as needed. It is cloud-agnostic; it works well across various cloud providers, with versions available for Azure, AWS, Google Cloud, SAP, and formerly IBM and SUSE. This flexibility makes it easy to deploy on your chosen cloud provider through its marketplace offerings.
Q. How does this impact the hardware infrastructure costs?
A. It’s not something that can simply run on a laptop, which does present challenges, but with that scale of resources, Cloud Foundry is highly optimised. For example, Cloud Foundry applies the principle of ‘bin packing’—a feature in Kubernetes designed to optimise compute for container clusters—but it applies this principle to VMs, ensuring efficient use of every VM deployed. It operates on VMs, so you aren’t tied to specific hardware, though VMs do come with associated costs.
Q. How does Cloud Foundry handle DevOps automation?
A. Automation in Cloud Foundry relies on two core aspects: capabilities and features that allow tools to be automated, and the ability to seamlessly move processes from one stage to the next. Cloud Foundry was designed with both in mind, making it essential for many DevOps automation needs. It simplifies common workflows—like building, deploying, scaling, logging, monitoring, and applying security best practices—into a single command.
For instance, if you have your code on your laptop, you can configure a Cloud Foundry (CF) endpoint on a remote cloud provider. By executing cf push <app-name>, Cloud Foundry takes the source code, uploads it to the cloud controller, builds it, attaches necessary services, deploys it to production, and then provides a URL to access the app—all in one step.
Additionally, Cloud Foundry offers various services (e.g., databases, message queues, pub/sub tools like Kafka) through the CF Marketplace, which you can attach with a single command. Instead of creating databases, handling credentials, or manually configuring connections, you can simply use cf bind-service to link these services to your app.
These single-command operations integrate seamlessly with any automation tool, enabling efficient and streamlined workflows for DevOps teams.
Q. What kind of security measures or checks and balances are in place to ensure that the vulnerabilities are properly taken care of?
A. Cloud Foundry takes a multi-pronged approach to managing security within the foundation. We have a Vulnerability Management Working Group that monitors vulnerabilities across all Cloud Foundry projects. While no project is entirely immune to security issues—Cloud Foundry was also affected by incidents like the Log4j vulnerability—the working group provides ongoing oversight to mitigate and resolve issues promptly.
We also have stem cells, which are the OS-level base that supports workloads built on top of the platform. Keeping stem cells secure, low-risk, and up-to-date offers an additional layer of protection, as they provide a stable, secure foundation for all applications deployed within Cloud Foundry. Likewise, the use of Buildpacks within Cloud Foundry makes it easier to patch a large number of containers. The community’s vigilance and contributions are invaluable in maintaining the integrity and functionality of Cloud Foundry.
Q. How do you see the future of the Cloud Foundry project evolving?
A. The foundation is focused on maintaining the current Cloud Foundry on VMs and its existing ecosystem, while also working to extend Cloud Foundry to newer technologies like Kubernetes. Beyond Cloud Foundry, the foundation supports related projects like Buildpacks and the Open Service Broker API, which are relevant across multiple ecosystems. Our goal is to back these projects, nurturing and sustaining the communities around them.
In addition to Cloud Foundry, we engage in various initiatives under the Linux Foundation umbrella. For instance, we integrate best practices from the Open Source Security Foundation and collaborate with the CNCF, adopting beneficial tools and practices, such as Buildpacks, where they fit. By leveraging these synergies within the Linux Foundation, we aim to grow and evolve alongside the broader open source ecosystem.
Q. How has your experience been at Open Source India (OSI) 2024?
A. I really think we should have brought in a sponsorship for this year’s event, but we’ll definitely work on something early enough before next year’s edition. I really loved being part of this huge exhibition of open source tech; there’s a lot more we can do as an open source foundation with the OSI community and take advantage of a lot of the OSI bells and whistles.
