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.

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

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:

A high-level overview of the Cloud Foundry ecosystem. More detail can be found at https://cloudfoundry.org/  © 2017 Cloud Foundry, Inc. All Rights Reserved.

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:

A conceptual overview of the Cloud Foundry platform architecture. More detail can be found at https://cloudfoundry.org/application-runtime/  © 2017 Cloud Foundry, Inc. All Rights Reserved.

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:

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

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).

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:

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.

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:

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.