Cloud Foundry for Developers

Chapter 1. Cloud Foundry Introduction

In this chapter, we introduce Cloud Foundry by providing background on the product itself and some related concepts that may be useful for those unfamiliar with it. We then dive deeper into the details of using Cloud Foundry from the application developers perspective in subsequent chapters.

In this chapter, we will cover the following topics:

Why Cloud Foundry?
What is PaaS?
What is Cloud Foundry?
What is Pivotal Cloud Foundry?

Why Cloud Foundry?

cf push

That's it. That is the essential answer to the question Why Cloud Foundry?, Anti-climatic, right? At least, until you understand the revolutionary leap that application development has taken as a result.

Without cf push, the typical application development cycle is convoluted and complex because often, much of the development activity is consumed by finding a place for your application to live and serve the world securely, reliably, and robustly. There are three problems that have impeded development:

It is difficult to deliver applications that are valuable to you, your organization, and/or the world if you aren’t able to focus on building the application itself. In some large organizations, developers have said that 80% of our efforts are getting infrastructure ready. Imagine a day in which you only have to build your application, not assemble middleware; install application runtimes; or fiddle with an operating system (OS), virtual machine (VM), servers, storage, or networking.
Application developers are not system administrators or system operators, nor should they be compelled to be. If you ask operators to develop code that one would expect from an application developer, most would likely decline. There are boundaries from their perspective. Both disciplines fall under IT, yes. Both are extremely technical roles, requiring deep expertise to be sure. Both do the heavy lifting required to ultimately make an application of some value available to an audience who needs it. However, the Dev versus Ops divide is wide and deep. There are fundamental specializations, concerns, and risks that drive behavior in both roles that creates an obvious and quite natural fracture line to follow when dividing the workload of getting applications up and running in production. Of course, both should work together, share, and learn techniques that are cross-functional and relevant to how to be more efficient and agile in their respective roles, such as continuous integration and continuous deployment (CI/CD). In the end, application developers thrive if they focus on developing applications and solving problems in that very difficult space, without the concerns of being a shadow platform engineer or operator.
It is hard to build a consistent, reliable, secure, and highly available production environment. Much more so by stitching together compute, storage, and network capacity into a cohesive system that meets the demands of modern enterprises and the expectations of application consumers. All the while, providing the rigor and flexibility that enables developers to focus on developing applications with ease. VMware revolutionized the IT world with server virtualization in 1998. They abstracted away the boundaries of physical hardware into pools of virtual servers. This enabled us to make better use of the underlying hardware by distributing and fitting large, complex workloads over the physical boxes.

These are the problems that Cloud Foundry was made to address: ending the eternal battle of the developer's focus on apps versus operating and engineering the platform that those applications are run upon.

Cloud Foundry does this by bringing about enterprise-grade application virtualization. It does this by harnessing and orchestrating a symphony of containers into an elastically scalable distributed system comprising all of the components a given application needs to serve the world. This changes the game much the way VMware did with VMs and server virtualization. Cloud Foundry is a proven application virtualization platform that gives control back to the developer, allowing developers to focus on developing applications, instead of infrastructure operations.

Note

cf push was originally vmc push, which stood for VMware Cloud. Cloud Foundry was conceived at VMware in 2009 and born as an open source project in 2011. The original code for VMC can be found at https://github.com/cloudfoundry-attic/vmc.

What is PaaS?

Platform as a Service (Paas) is one of a number of terms in the taxonomy of cloud computing including Infrastructure as a Service (Iaas) and Software as a Service (Saas).

While, generally, IaaS is server focused and SaaS is user focused, PaaS is developer focused. PaaS enhances developer productivity by enabling application virtualization, so there is a significant reduction in the need for developers to perform the undifferentiated heavy lifting associated with the plumbing that detracts from the actual work on application code and concerns. Often this is called yak shaving. For instance, it may include everything from installing application runtimes, dependencies, app packaging, staging, and deployment, to configuring deeper down the stack into infrastructure concerns such as configuring load balancers, networking, security, provisioning VMs—nearly anything that takes your focus off building a great application.

Note

According to Jeremy H. Brown while at MIT around the year 2000, yak shaving is what you are doing when you're doing some stupid, fiddly little task that bears no obvious relationship to what you're supposed to be working on, but yet a chain of twelve causal relationships links what you're doing to the original meta-task. The term was coined by Carlin Vieri. The original email on the subject can be found at http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gsb2000-02-11.html.

Heroku (https://www.heroku.com) is the name of one of the original trailblazers in PaaS. Available since 2007, Heroku is a cloud platform that enables developers to push applications into a hosted service on the internet. The idea was to focus developers on building applications, not infrastructure. Using insights gained by the Heroku team from operating a large platform with diverse applications running on it, Adam Wiggins and team formed the basis for what are now called cloud-native applications through their original Twelve-Factor App (https://12factor.net) patterns. They were motivated to raise awareness of some systemic problems seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. We will discuss cloud-native apps, and further developments since the original Twelve-Factor App methodology was written, in future chapters. Additionally, Heroku's buildpack model is used for Cloud Foundry and will also be discussed a bit later in the book.

The Cloud Foundry definition of PaaS

In the cloud era, the application platform is delivered as a service, often described as PaaS. PaaS makes it much easier to deploy, run, and scale applications. Some PaaS offerings have limited language and framework support, do not deliver key application services, or restrict deployment to a single cloud. Cloud Foundry is the industry’s open PaaS and provides a choice of clouds, frameworks, and application services.

Who are Pivotal and the Cloud Foundry Foundation?

In April 2013, Dell EMC and VMware formed a new company called Pivotal. Each parent company contributed people, software, products, and collateral that were not core to their own business to this new entity. This included 11 companies that had been acquired by the parent companies at one point or another. Soon after, with further investment from additional companies, such as General Electric, Ford, and Microsoft, Pivotal's mission focused sharply on transforming the way the world makes software.

Cloud Foundry, along with several other notable projects like the Spring Framework for Java (https://spring.io) and RabbitMQ (http://www.rabbitmq.com) for message brokering, were included in the Pivotal origin story.

Soon after its creation, Pivotal, together with other enterprise leaders, sought to create the Cloud Foundry Foundation to ensure the ongoing stewardship of the Cloud Foundry community and its open source software. The foundation was created as an independent non-profit under the Linux Foundation. Since its founding in January 2015, over 70 companies (https://www.cloudfoundry.org/members/) have joined the Cloud Foundry Foundation and continue the mission to drive the global awareness and adoption of the Cloud Foundry open source project, to grow a vibrant community of contributors, and to create coherence in strategy and action across all member companies for the sake of the project.

The Cloud Foundry Foundation exists to:

Establish and sustain Cloud Foundry as the global industry standard PaaS open source technology with a thriving ecosystem
Deliver continuous quality, value, and innovation to users, operators, and providers of Cloud Foundry technology
Provide a vibrant, agile experience for the community’s contributors that delivers the highest quality cloud-native applications and software, at high velocity with global scale

Note

You can find more detail on the Cloud Foundry Foundation and its mission at https://www.cloudfoundry.org/foundation.

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!

Note

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.

Note

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.

Note

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

Note

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.

What is Pivotal Cloud Foundry?

Pivotal Cloud Foundry™ or Pivotal CF™, commonly referred to as PCF, is currently the leading enterprise PaaS powered by Cloud Foundry. Many of the companies that comprise the Fortune 1000 use Pivotal Cloud Foundry internally as a part of their cloud portfolio offering. Using this particular Cloud Foundry distribution, they build their own cloud-native applications and migrate existing applications so that they can leverage many of the benefits of moving to a PaaS. It is because of this deep enterprise penetration and the higher likelihood of encountering Pivotal Cloud Foundry within the confines of business, government, and organizations that we will discuss some of the additional capabilities Pivotal Cloud Foundry provides above the open source Cloud Foundry release.

Pivotal Cloud Foundry delivers an always-available, turnkey experience for scaling and updating PaaS on multi-cloud public, private, or hybrid infrastructures such as VMware vSphere, Amazon Web Services, Google Cloud Platform, Microsoft Azure, and OpenStack.

As a commercial distribution of Cloud Foundry, it provides several significant additional features and a commitment to support the product that organizations are accustomed to from vendors. For instance, Pivotal Cloud Foundry provides extra tools to simplify installation and administration not included in the open source software product.

For instance, should you want to install a Cloud Foundry distribution on your own infrastructure, you would do the following at a high level:

Set up all external dependencies, such as an IaaS account, external load balancers, DNS records, and any additional components.
Create a manifest to deploy a BOSH Director.
Deploy the BOSH Director.
Create a manifest to deploy Cloud Foundry.
Deploy Cloud Foundry.

Source: Deploying Cloud Foundry at http://docs.cloudfoundry.org/deploying/index.html

This is initially a manual process that requires a good deal of BOSH and platform engineering expertise, although any platform engineer worth their salt would typically begin to automate a good deal of this process. However, it can be very difficult to get the distributed configuration of a large system composed of a variety of multiple VMs, network components, compute, IaaS access, storage, DNS, SSL certificates, and so much more described properly within the manifest file you must define, which BOSH then uses to build the Cloud Foundry foundation. Even getting to the starting line requires creating a manifest to deploy a BOSH Director which can be difficult if you are unfamiliar with the inner workings of BOSH; an interesting topic to be sure, but also deep and complex with a steep learning curve and commitment.

Building upon the foundation provided by the open source Cloud Foundry release (https://github.com/cloudfoundry/cf-release), as one might expect, Pivotal Cloud Foundry adds many features atop of the open source version that have been driven and shaped by the needs of enterprise, government, and organizations to simplify the administration and day operations of Cloud Foundry.

Without belaboring the finer details of the differences between the open source and Pivotal distributions of Cloud Foundry, there are a few differences that are worth highlighting.

As mentioned previously, a good deal of expertise in BOSH is a prerequisite to installing the open source version of Cloud Foundry. Pivotal Cloud Foundry provides a simplified web-based UI for installing and managing the installation of Cloud Foundry and various components, such as the CF Application Runtime, and other services such as RabbitMQ, Redis, MySQL, and so forth as simplified service tiles. Ordinarily, each would require their own BOSH installation and manifest creation to deploy in a coherent way – a rather significant challenge if done manually. This UI is called Ops Manager and enables zero-downtime upgrades for the platform and services, along with simplified maintenance and changes to the deployment configurations underpinning the Pivotal Cloud Foundry Foundation.

A second significant difference between the open source and Pivotal versions of Cloud Foundry is developer-centric. Apps Manager is an administrative UI that enables developers to access many of the capabilities of the Cloud Foundry CLI in a more intuitive way. Apps Manager provides a visual way to configure and manage many of the critical features necessary to handle the daily ins and outs of managing your applications for scale, performance, settings, services, logging, and integrations such as autoscaling that are only available with the Pivotal Cloud Foundry distribution.

The Pivotal Cloud Foundry distribution provides additional support for cloud-native applications via much of the NetFlixOSS functionality under the guise of Spring Cloud and Spring Cloud Services (SCS). This provides common pattern implementations that enhance resilience, ease of configuration, and high availability in the applications you design and deploy to Cloud Foundry, including service coordination and discovery, circuit-breaker patterns to prevent downtime, and other patterns that are particularly useful for microservices.

Another notable feature of the Pivotal distribution is the PCF Metrics dashboard, which presents easy access and visualizations of recent application events, metrics, and logging.

Pivotal Cloud Foundry components glossary

Pivotal Cloud Foundry components and what they do include:

Ops Manager: A web interface for installing, configuring, upgrading, and scaling Pivotal CF and Pivotal Services
Apps Manager: A web interface for working with Cloud Foundry and managing orgs, spaces, users, apps, services, routes, and so on
Pivotal Cloud Foundry Metrics: A dashboard monitoring, event and logging component for applications running in PCF
Pivotal Services: Managed services including autoscaling, MySQL, RabbitMQ, Redis, Spring Cloud Services, and so on

Other Cloud Foundry distributions and public providers

In addition to the commercial offering of Pivotal Cloud Foundry, the Cloud Foundry Foundation certifies additional platform providers to ensure consistency in the core Cloud Foundry components to ensure portability. The Cloud Foundry Certified PaaS certification requires certified offerings to actually use the software released by the Foundation’s project teams. For more details on Cloud Foundry Certified Platform Providers, please see https://www.cloudfoundry.org/provider-faq/.

A partial list of provider offerings include:

AppFog from CenturyLink (https://www.ctl.io/appfog/): CenturyLink’s platform based on Cloud Foundry.
Atos Cloud Foundry (https://atos.net/en/solutions/application-cloudenablement-devops): A commercially licensed and managed Pivotal Cloud Foundry.
GE Predix (https://www.predix.io/registration/): An industrial internet offering of Cloud Foundry for IoT (Internet of Things devices) and analytics.
IBM Cloud (https://www.ibm.com/cloud/): IBM’s cloud platform based on Cloud Foundry, which provides access to IBM services, including Watson. Formerly called IBM Bluemix.
Pivotal Web Services (https://run.pivotal.io/): Pivotal’s public Pivotal Cloud Foundry. A fully managed version of Cloud Foundry that runs on a public cloud.
SAP HANACloud Platform (https://cloudplatform.sap.com/capabilities/runtimes-containers/cloud-foundry.html): SAP's HANA cloud platform based on Cloud Foundry, which provides access to SAP services.
Swisscom Developer Portal (https://developer.swisscom.com/): Swisscom’s Application Cloud. A fully managed version of Cloud Foundry offered on a public cloud that stores all of your data in Switzerland.

A comprehensive list of Cloud Foundry Certified Platform Providers and their offerings can be found at https://www.cloudfoundry.org/how-can-i-try-out-cloud-foundry-2016/.