What is Cloud Foundry?

Cloud Foundry is a platform for developing and running cloud-native applications. It is a polyglot platform that allows you to deploy a myriad of applications written in many different computer languages — Java, Python, Node.js, Ruby, Go, .NET languages, and many more. Simply use the best language for the task at hand with the freedom of knowing that Cloud Foundry supports it.

Cloud Foundry is IaaS agnostic and open source. It abstracts away the underlying IaaS whether you run on VMware vSphere, Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, OpenStack, or others. This means that true application portability is possible regardless of the infrastructure choices and it enables a consistent multi-cloud strategy — public, private, or hybrid.

Cloud Foundry application development requires software engineers to understand how to build and deploy cloud-ready applications. However, there is a little secret: your applications do not have to be fully cloud-native, Twelve-Factor applications to run on Cloud Foundry. Often existing applications will run just fine on Cloud Foundry with a few minor changes — if you know some simple recipes!

The easiest way to see if an application needs some changes to run on Cloud Foundry is simply to cf push the app. See what, if any, errors may arise. Then make corrections as needed, then cf push again. Iterate on that process until the app is running in Cloud Foundry. It is often surprising how little effort it takes to get an app to run on Cloud Foundry. And, in many cases, it is the middleware-specific customizations of the app code that are intended to integrate or launch the app on a given app server like WebLogic or WebSphere where some points of friction commonly are found in practice -- more so than the actual application functional code.

Cloud Foundry provides a highly available, scalable, and secure platform to deploy your application. And with autoscaling, your application can scale-out to accommodate surges in traffic and then scale-in once traffic subsides — automatically!

Here is a guide to Cloud Foundry at a glance:

Initial release in 2011
An open cloud-native platform (PaaS)
Fast and easy to build, test, deploy, and scale apps
Works with any language or framework
Available as open source, commercial distributions, or hosted offerings
Open source with an Apache license, hosted on GitHub
Developers use the cf command-line utility to interact with a CF deployment
The cf CLI (Command-Line Interpreter) is pre-built for Windows, Mac, and Linux
The cf supports any language or framework through buildpacks

As a developer, Cloud Foundry does the following:

Enables you to focus on building applications
Moves you out of the VM provisioning game
Allows you to recreate an application's runtime environment continuously
Deploys and scales an application in seconds
Externalizes and injects environment-specific dependencies
Has an API that enhances release management productivity
Uses containers to isolate apps and create application virtualization
Manages your application’s entire life cycle

The Cloud Foundry project code can be found at:

Cloud Foundry architecture

The Cloud Foundry architecture abstracts away many of the complexities of day-to-day application development to provide a rich and robust environment for deployment. Cloud Foundry handles many of the operational and infrastructural demands behind the scenes in a unified and consistent way so that Cloud Foundry operators and engineers can manage and maintain the platform without downtime in most cases, enabling rolling, zero-downtime upgrades, and patches to the platform without developers noticing anything going down. Scaling Cloud Foundry by adding more infrastructure is baked into the platform to enable growth over time as demand increases.

The Cloud Foundry platform is composed of a set of horizontally-scalable, distributed services. It includes tooling which automates and orchestrates the underlying infrastructure, providing an abstraction layer over IaaS platforms.

Cloud Foundry is very robust. It uses what can nominally be called Weak AI because of its narrow focus on maintaining a self-healing feedback loop under the hood via its release engineering and management tooling, called BOSH. For instance, when a virtual machine in Cloud Foundry is misbehaving, it is taken out of service and replaced quickly. This enables failure detection and recovery at any level: application, container, VM, or the entire Cloud Foundry Foundation when configured for high availability (HA).

Perhaps the most unusual aspect of Cloud Foundry, from a platform engineer's perspective, is that it is infrastructure agnostic, meaning that an operator can run Cloud Foundry on a variety of IaaSes such as VMware vSphere, Amazon Web Services, Google Cloud Platform, Microsoft Azure, OpenStack, bare-metal servers, and others. This is as revolutionary as the concept of the write once, run anywhere dream of application portability that application developers sought with the slogan created by Sun Microsystems to illustrate the cross-platform benefits of the Java language. Cloud Foundry does this by using an abstraction, called a Cloud Provider Interface (CPI), that translates a common set of infrastructure build commands into an IaaS-specific translation using an open source project called Fog (http://fog.io). Fog enables Cloud Foundry to avoid vendor lock-in, which constrains you to a single IaaS. Interestingly, many IaaS providers are adding support to Fog directly, such as the Google Compute Platform. As they do, Cloud Foundry enjoys this rich inheritance that will enable it to run on an ever-growing list of cloud providers as they become available and supported.

Weak AI versus Strong AI: Weak AI is non-sentient artificial intelligence that focuses on one narrow task, whereas Strong AI is a machine with the ability to apply intelligence to any problem, rather than just one specific problem. Most currently existing systems considered under the umbrella of artificial intelligence are weak AI at most.

The capabilities and the operational aspects of Cloud Foundry are truly remarkable, if not revolutionary, from a system operator's and platform engineering perspective.

BOSH is one of the most interesting components of the Cloud Foundry ecosystem. Although it sits firmly in the domain of the platform engineer, since it automates and directs the deployment of the Cloud Foundry components themselves, it is used to deploy and maintain a Cloud Foundry Foundation (installation). BOSH is an open source tool chain for release engineering, deployment, and life cycle management of large-scale distributed systems. If you are interested in looking at the operational side of Cloud Foundry, you can find out more about BOSH at https://bosh.io and find the open source code for it at https://github.com/cloudfoundry/bosh.

The Cloud Foundry platform provides key elements such as routing, container management, logging, and metrics, as well as application configuration, service catalog, and messaging built-in.

Cloud Foundry is a polyglot platform, in that you are free to use any programming language of your choosing to develop your application for deployment. It has built-in support for Java, .NET Core, Python, Ruby, Go, Node.js, and PHP and it can support more by adding a variety of buildpacks that contain everything needed for application runtimes in additional languages. Most buildpacks are open source and community-driven. They can be found at https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Buildpacks#community-created.

A simplified overview of the Cloud Foundry ecosystem:

Additionally, there are Command Line Interpreter (CLI) and Integrated Development Environment (IDE) integrations for popular development tools such as Eclipse, Visual Studio, IntelliJ IDEA, and VS Code, among others.

What about connecting your application to services such as databases, message brokers, object stores, and so on? Most applications have dependencies on these types of externalities. Cloud Foundry addresses this necessity elegantly, providing several ways to address these capabilities, of course. We will discuss this in detail in future chapters.

A simplified overview of the Cloud Foundry platform architecture:

The preceding figure shows the stack of infrastructure and BOSH that Cloud Foundry platform engineers use to install, manage, and maintain Cloud Foundry. There is the Cloud Foundry Application Runtime ™ (previously known as Elastic Runtime) inside the big box outline that is comprised of the various components. From the developer's perspective, this is Cloud Foundry. But from the holistic, systems view, it is but one part, albeit a very, very important part. The CF Application Runtime is exactly as the name implies:

The elastically scalable application runtime environment that stitches together the compendium of components needed to stretch across the underlying infrastructure resources to create and manage pools of compute, memory, datastore, blobstore, and networks to support the app-centric view of the world we call application virtualization. This includes all the orchestration, networking, containerization, management and control systems you might imagine are needed to pull together such a complex ballet of dynamic technology.

Primarily, these fall into the following categories:

Routing
Authentication
Application life cycle management
Application execution
Platform services
Messaging, metrics, and logging
All of these are unified behind the Cloud Controller API, which enables RESTful integration with the CF Application Runtime through the Cloud Foundry CLI (a.k.a. the cf CLI) and other commercial user interfaces (UI) such as Pivotal Cloud Foundry's Application Manager web-based UI

We will unbox these in more detail in future chapters. Further information may be found at https://www.cloudfoundry.org/platform/.

Cloud Foundry security

Cloud Foundry enables a future-forward, cloud-based re-evaluation of long-held security fundamentals and assumptions because of the way its BOSH component works behind the scenes. This is an exciting time to rethink and reframe security in proactive ways that were not imaginable even a few years ago without the automation and feedback loops BOSH gives us. BOSH is constantly tearing down VMs that are no longer in good state or performing as expected, and recreating them on the fly. BOSH is always eliminating a plague that all infrastructure that is not fully automated will eventually encounter: configuration drift.

BOSH is always running on a feedback loop, validating the state of real-world infrastructure with the expected configuration. If there is drift, BOSH eliminates that bad apple and promptly replaces it with one that meets the exact specification of the configuration. This is a process called repaving. Repaving constantly ensures that we have smoothly paved underlying infrastructure that meets the needs of our Cloud Foundry Foundation and our applications. BOSH does this seamlessly behind the scenes with zero downtime to your application (provided you have at least two application instances running).

Configuration drift occurs naturally in data center environments when changes to software and hardware are made ad hoc and are not recorded or tracked in a comprehensive and systematic fashion. Often people, as varied as operators or developers, will log directly into a server or VM and make changes that will cause something to work with the tuned configuration of a server, but not work elsewhere if that change is not present. Often, that place is a production environment and the issue is not discovered until something has gone awry. Configuration drift is analogous to the insidiously phrased excuse of It works on my machine. This plagues developers who have fundamental, unaccounted for variations in their system configurations that enables a application to run only on their machine. We would probably hear that phrase less if we then immediately rack that particular machine into the data center and run it in production each time it is heard.

Because of this, a new way of thinking about security posture has become commonplace with the advent of the three Rs of security: repair, repave, and rotate.

These principles were first articulated by Justin Smith, a thought leader at Pivotal, in a presentation titled Cloud Native Security: Repair, Repave, Rotate in 2016, which can be found at https://www.infoq.com/presentations/cloud-native-security.

Justin defines cloud-native enterprise security as:

Repair: Repair vulnerable software as soon as updates are available.
Repave: Repave servers and applications from a known good state. Do this often.
Rotate: Rotate user credentials frequently, so they are only useful for short periods of time. Minimizing the attack vector of time.

Cloud Foundry manages some of these for you already. And, it is improving rapidly as the three Rs have become a key element for the Cloud Foundry community to drive the cloud-based security posture story forward.

Cloud Foundry containers

Just as Cloud Foundry is changing the way of thinking about a proactive, modern, agile, and adaptable security posture that is constantly repairing, repaving, and rotating at the operational levels of the Cloud Foundry components, so too has the thinking about provisioning, scaling, and capacity management changed to reflect the dynamic and adaptable way in which Cloud Foundry enables containers to work.

In the past, at least in most enterprises, if you wanted infrastructure you would likely need to work your way through the circles of provisioning hell. Often the process looks something like this:

Request a server or VM to be provisioned or purchased.
Wait until that server or VM was provisioned.
In the meantime, you need to get to work building the app. So either,
1. Find a box you can temporarily run under your desk as your app sandbox.
2. Or, break out the credit card and provision some compute from a public cloud provider as a stopgap.
3. Or, leverage some version of shadow IT that your organization turns a blind eye toward while the normal IT process runs the official gauntlet
Get the server racked in the data center or the VM spun up.
Get access and credentials to ssh and log in to the box.
Discover issues with the configuration.
Request remediation of the issues by the operations team.
Once everything is in order, install and configure your application runtime environment and middleware.
Finally, after week, months, or years, deploy your application to deliver the business or mission value it promised.
Find out that you are under-provisioned to handle demand -- then quickly start the process over again to get more capacity and compute to keep the app online and available as it grows.
Learn your lesson and always order way more capacity than you think you'll need, just in case, because it takes too long to bring more online once you're in production.

The last step is very common in large organizations with lots of processes and red tape. And, often as a result of protecting the scarce resources of servers racked in the data center and watts guzzled by those additional servers, organizations wind up vastly over-provisioned, meaning that they have more capacity taking up square footage in the data center than they need. In some organizations where this has been measured, the over-provisioning can be well over 40%. That is to say that over 40% of the racked servers can be un-racked and taken offline with no effect on the ability of the organization to provide a good home from which applications can serve their users.

This would be an entirely avoidable situation if it were not for the hard climb and time required by developers and operators to get through the process and red tape. The psychology that takes over is one of having long-lived pets. Because of the tremendous effort required to get these servers or VMs, developers in this situation always ask for more than they think will meet their immediate needs. They become attached and even if some of these servers have nothing on them yet, they defend them and protect them from reclamation, and rightfully so.

In large organizations, perhaps the hardest part of application development is getting into production. It is not unexpected in organizations of scale to wait a whole month, driving through road blocks step by step, until the production infrastructure is provisioned and has a dial tone to then finally deploy your application to the world. Cloud Foundry shortcuts that on the infrastructure side, but often there is still some much-needed improvement on the process red tape.

Part of the solution is to get rid of the servers as pets worldview that feeds this behavior. Containers are a good answer to this challenge. This is because they can be treated as disposable things that can be re-spun very quickly to enable our applications to scale-out automatically when demand is high and then scale-in once that demand dissipates, thus, always right-sizing our compute capacity and energy consumption to what we actually need at the time, and, eliminating the fear and headaches that one must always run through the thicket of ticket jungles to get more capacity when we need it.

What are containers?

Containers are ubiquitous in the cloud discussion. A good definition comes from Amazon Web Services (AWS):

Containers are a method of operating system virtualization that allow you to run an application and its dependencies in resource-isolated processes. Containers allow you to easily package an application's code, configurations, and dependencies into easy to use building blocks that deliver environmental consistency, operational efficiency, developer productivity, and version control. Containers can help ensure that applications deploy quickly, reliably, and consistently regardless of deployment environment.

Source: AWS, What are containers? (https://aws.amazon.com/containers/)

Containers are great, but orchestrating and managing rolling security patches and upgrades without downtime is a very hard problem in most scenarios, leaving our applications open to vulnerabilities and exposing us to risks we may be unwilling to take.

Cloud Foundry makes containers work better by orchestrating them automatically. It does all of the difficult things that containers need to keep them updated, patched, happy, and healthy -- and, all with zero downtime. There are few other container-based PaaSes that can do this well in an enterprise or mission-critical setting at the current time.

Cloud Foundry containers are standards-based. The specification comes from the Open Container Initiative (OCI) (https://www.opencontainers.org). The OCI is a consortium of highly-visible organizations like Docker, Dell Technologies, Microsoft, IBM, Google, Red Hat, etc. that serve as the keeper of the flame for the runC library that Cloud Foundry uses as its primary container runtime library for Linux-based nodes. Commitment to this container interoperability standard by a wide variety of players enables Cloud Foundry to do interesting things to leverage the standard and expand the capability of the platform. For instance, Cloud Foundry can run Docker images from Docker repositories, such as Docker Hub. For more information, see https://github.com/opencontainers/runc.

This enables Cloud Foundry to run everything on Linux and Windows (any .NET core and most .NET classic) applications, to loading and running pre-baked Docker images with specific app runtimes and configurations.