- 1. Cloud Foundry has always used containers
- 2. Cloud Foundry works on more than 10 IaaSes (same code, different cloud)
- 3. Cloud Foundry scales to hundreds of thousands of applications
- 4. Cloud Foundry works with any language and framework
- 5. Cloud Foundry is extensible
- Downloadable resources
- Related topics
Five facts you may not know about Cloud Foundry
Demystifying persistent misconceptions about the open source platform-as-a-service
As the usage of cloud technology matures, companies have found the need to move up the stack to get value. In particular Platform-as-a-Service (PaaS) has provided a one-stop, complete operating system for the cloud.
Enterprises that use PaaS solutions like Cloud Foundry (CF) don’t have to worry about the details of how to manage cloud resources to run their apps. The platform takes care of that for them. All they have to focus on is their application code and access to a catalog of services. The platform does the rest: scaling, healing, HA/DR, and so on.
“With constant innovation, early platforms like Cloud Foundry can continue to maintain their leadership in this space. However, it’s also important to keep up with the innovation and excitement that come with newer approaches to solving the challenge of orchestrating containers, such as Docker Swarm and Kubernetes.”
While platforms such as CF have enjoyed considerable successes in recent years, they have also had their detractors. Specifically, by forcing a view of the cloud world (apps, services, org, users, and so on) these platforms can put certain limits on the kind of applications you can deploy.
For instance, CF is not well suited to deploying a service such as a database. In CF, this is done using BOSH (a multi-cloud scalable release engineering tool) directly and deploying onto an Infrastructure as a Service (IaaS) using VMs or container clusters running on the VMs. These kinds of limitations have led to the rise of alternative platforms like Kubernetes and Docker Swarm, which give developers complete freedom by allowing them to directly manage clusters of containers and run their applications on them.
Alternative platforms to CF are a welcome addition, as they encourage innovation in all sides. However, there are a number of myths or misconceptions about the CF cloud operating system that are worth dispelling. This article explores five things you may not know about CF.
We are not highlighting these issues to fully compare or contrast CF with other platforms, but rather to make sure that the misconceptions are rectified and facts are exposed. We hope to illuminate the current CF architecture and design points such that enterprise users trying to use a PaaS can make the best decisions possible.
Cloud Foundry has always used containers
As interest in containers has reached a fever pitch with the advent of Docker and Kubernetes, it's important for us to understand how CF relates to these technologies. First, CF like many other PaaS environments uses containers. This has been true from the very start, and predates all the current container orchestration platforms. If you think about what containers do, you understand why containers have always been central to CF.
Containers are a means of isolation in UNIX/Linux systems. Using various kernel features, you can run applications in so-called containers in Linux such that they will have their own isolated view of system resources, as well as limits on resource usage.
CF has made use of containers from the very start. With recent releases, the container layer in CF (Garden runC) has even been upgraded to contribute and conform to emerging industry standards in container technologies by adopting the CNCF-led runC standard. So every time you run a CF application, you are running it inside a runC container.
What CF adds that is unique is the management of these containers, plus it hides the complexity from end users. The Diego runtime in CF is an efficient scheduler for containers. The goal (in part) is to maximize utilization of the underlying virtual machines that CF is being instantiated on.
Why would you need a scheduler like this? Because resources in an IaaS are offered in discreet capacity. For example, you can create VMs with 10 GB of memory with 64 CPUS and 10 GB Ethernet networks. When you install CF on VMs like this, you may end up with 4 VMs that are dedicated to running the end users’ applications. Part of the job of the CF Diego scheduler is to determine how and where you should place applications, and what portion of the available resources you should assign to any one application. The scheduler tries to do this in a way that maximizes usage and allows the largest number of apps to run efficiently within the limitations of your environment.
Specifically, the Diego scheduler allocates user application instances in a way that they stay available. It also recovers and re-provisions applications when they fail or are upgraded. Diego exploits the fact that all CF apps are stateless (so they can always be safely moved to another host as long as at least one instance stays running); this enables Diego to provide resilience, health management, and efficient placement for user applications while remaining somewhat simple at its core. This differentiates Diego from other, more general schedulers.
Cloud Foundry works on more than 10 IaaSes (same code, different cloud)
When CF was initially released, it worked on a few clouds (such as VMware and AWS) and that was enough to satisfy early multi-cloud users. In time, as the first version of BOSH emerged and matured, other clouds were also added—mainly VSphere, VCloud, and OpenStack. BOSH supported a clear Cloud Provider Interface (CPI), but adding new CPIs could be difficult because these various CPIs were embedded in the BOSH director code.
Figure 1. CPIs are cloud agnostic
In 2015, the BOSH team started rectifying this situation by cleaning up and externalizing CPIs in the BOSH director code base. CPIs are now packaged as BOSH releases, and can be deployed and updated separately from the director. Also, the CPIs can now be in any language and use whatever technology is required to target the cloud they are designed for.
Once all of the existing CPIs were converted into their own repos and a separate CPI team was created, it was time for the CF community to take notice. As a consequence of this new extensible mechanism, many more clouds and even container platforms could be used to deploy CF. These included SoftLayer, Azure, and GCP, as well as Docker and Kubernetes, to name just a few.
Figure 2. Available CPIs
With more than 15 different CPIs available, including a bare-metal SSH CPI and a multi-CPI that allows you to target more than one cloud, CF is easily the most cross-platform PaaS in existence.
Cloud Foundry scales to hundreds of thousands of applications
As Cloud Foundry has matured, one of the biggest challenges it has faced is scalability. Companies like IBM, SAP, Pivotal, and GE have betted on the CF code base as a core element of their public cloud strategy for application services. Multiple parts of the platform were rewritten in Golang, and the addition of more modern distributed systems technology with Diego provided a more modern and stable runtime for CF. But did this also provide a more scalable environment?
The Diego team spent the better part of 2016 fine tuning the runtime so that it could achieve linear scaling characteristics. By revisiting and refining various component choices and running scaling experiments, they were able to provision 1,250 Diego cells, each corresponding to a base VM for running applications, and scaling the platform to run 250,000 containers.
Figure 3. 250,000 containers
Given the one-to-one mapping between an application instance and a container, Diego scalability tests showed the possibility for CF to manage 250,000 applications while keeping them routable and responsive throughout the entire scalability test. And that does not account for the fact that CF currently runs in live production environments with hundreds of thousands of apps.
We don't actually know the limits of CF scaling, since it's so costly to run such large experiments and the Diego team did not try to push the limits to reach a breaking point. So in theory, CF could scale to 500,000 or even a million applications. More details on how the scalability test was performed can be found in "250k Containers In Production: A Real Test For The Real World."
Cloud Foundry works with any language and framework
From the very start, CF was designed to work with any language and framework. This design point has been maintained such that now languages and frameworks supported in CF are not only widely available, but they are also customizable. Java support is one good example as there are many approaches to running Java applications; whether you want to use the OpenJDK or the IBM Liberty Java VM, there is a supported Java buildpack.
Figure 4. Cloud Foundry core design points (cloud, framework/language, service - agnostics)
And it’s not just well-established languages and framework that get to play well in the CF ecosystem. It’s also new and esoteric languages. For instance, as soon as Apple released its Swift language OSS in December 2015, CF buildpacks for Swift started showing up. Today, at least two versions are available through the community.
Furthermore, buildpacks have maintained compatibility with Heroku such that those released by that community are usable in a CF installation. Additionally, the CF community has innovated in buildpacks by exploring support for multi-buildpacks for applications that need more than one runtime, as well as private buildpacks for when you need to fork a language’s runtime or a framework to solve an esoteric issue with your application that cannot be solved through other means.
Cloud Foundry is extensible
Cloud Foundry has been criticized for lacking extensibility and extension points. While the platform is completely open and thus could, in theory, be modified by anyone who submits a Github PR, there was no way to extend the platform in a systematic fashion—meaning, a way to allow exploratory works to be viewed by all and created by all, on all parts of the platform. In other words, how could you allow innovation with the spirit of the "let a thousand flowers bloom" strategy?
To solve this issue, in late 2016 the project management council (PMC), which controls the direction of the platform, decided to divide all the projects that constitute CF intro three sub-PMCs: Runtime, BOSH, and Extensions. The mission of the new Extensions PMC was to encourage extensions to the platform, and put some structure into the evolution of these extensions while allowing the community to explore all kinds of fruitful or not-so-fruitful options.
After the first six months of organizing and retrofitting existing projects that fit as extensions and considering new projects, CF now has an established extension process and means for anyone in the community to extend the platform. These extensions include APIs, tools, CPIs, connectors to other platforms, buildpacks, services, and more.
As the community continues to add more extensions, some will disappear and some will graduate to become core. Regardless, the primary goal is to ensure that the platform remains open and vibrant, and that anyone in the community can extend the platform with their next brilliant idea.
Platform as a Service will continue to evolve. With constant innovation, early platforms like Cloud Foundry can continue to maintain their leadership in this space. However, it’s also important to keep up with the innovation and excitement that come with newer approaches to solving the challenges of orchestrating containers, such as Docker Swarm and Kubernetes.
In many ways, container orchestration is not a zero-sum game and we expect that many platforms can succeed as the problem space that these platforms are trying to solve includes all of IT applications and service management.
In this article, we've highlighted five important facts (some well known and some not) that can help enterprise IT managers make the right decision when they need to choose between CF and other PaaS environments.
- IBM Cloud Foundry resources
- 250k Containers In Production: A Real Test For The Real World
- BOSH: a multi-cloud scalable release engineering tool
- Other articles by Michael Maximilien