Five facts you may not know about Cloud Foundry

Five facts you may not know about Cloud Foundry

Demystifying persistent misconceptions about the open source

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

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

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

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

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

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

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

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

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

Figure 3. 250,000 containers

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

Cloud Foundry works with any language and

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

Figure 4. Cloud Foundry core design points
(cloud, framework/language, service – agnostics)

Cloud Foundry core                     design points

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

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.

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

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

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.

Downloadable resources



via IBM developerWorks : Cloud computing

October 3, 2017 at 01:09PM