Navigating Cloud Foundry
For all the talk about the cloud, many applications continue to run on traditional servers. Hybrid architectures are sometimes the right option, but if you want to move corporate applications onto the Internet, you don’t want to start from scratch. Cloud Foundry, a platform-as-a-service (PaaS) cloud platform, enables enterprises to move older software to the cloud and build new cloud-centric programs using familiar tools and programming languages.
In buzzword-heavy terms, it delivers continuous integration using a highly scalable and available architecture. In this article, I explain its purpose in more techie language.
According to Pivotal, which offers one of six certified distributions of Cloud Foundry, more than half of Fortune 500 companies currently use the platform. They include six of the 10 largest carmakers, seven of the top 10 banks, and five of the 10 largest insurance companies.
At Cloud Foundry Summit 2017, presenters included Comcast, Allstate, and Ford. Among the platform's biggest supporters is SAP, the poster child for enterprise proprietary software, which is so committed to the project that it launched its own Cloud Foundry PaaS, SAP Cloud Platform.
How it works
If you have developed software for a traditional data center, you already know the existing technology stacks, programming languages, APIs, and so on. You probably have also deployed in-house software using container orchestration tools or virtual machines (VMs) for performance and scalability. Cloud Foundry takes these existing skills and methods and gives you the ability to build cloud-native applications.
Specifically, Cloud Foundry enables programmers to use Java, Ruby, Node.js, .NET Core, Python, PHP, and Go. These languages come ready to run on the cloud in buildpacks that provide the framework and runtime an application needs. It automatically examines programs to determine which dependencies to download and how to configure applications to communicate with the needed services. As a result, developers can forget about infrastructure and focus on building the application.
Cloud Foundry uses GitHub for storage and version-control of source code, buildpacks, documentation, and other code and deployment resources. Developers who use Cloud Foundry can also use GitHub for their own applications, custom configurations, and other resources.
To deploy finished applications, programmers upload the application bits and metadata to their cloud. Those instructions use the Cloud Foundry command line (cf) or plugins from Eclipse, Maven, or Gradle.
Developers also create and bind services. This is done by building a Web Archive (WAR) archive and uploading it with the cf push command. When you run this Cloud Foundry deployment command, the program performs the following tasks:
- Uploads and stores application files
- Examines and stores application metadata
- Creates a “droplet” (the Cloud Foundry unit of execution) for the application
- Selects an appropriate Diego cell to run the droplet
- Starts the application
Diego is Cloud Foundry's container management system and runtime. (For more on container basics, see "When to use containers (and when not to).") Cloud Foundry has its own container implementation. Until recently, that was Warden; these days, Garden is the preferred container format.
You can also use Docker, if you prefer. The main difference between Docker and Warden is how container images are organized:
- Warden works with buildpacks. Warden containers usually have only two layers: a read-only layer with an operating system root file system—say, Ubuntu 16.04—and a non-persistent, read/write layer for the application itself, all its dependencies, and temporary data.
- In contrast, Docker runs operating system images, which are distributed through Docker Hub; a Docker application must have an image.
Garden, the current Cloud Foundry container back end, is very like Warden in functionality, but it was refactored and re-implemented in Go, primarily for performance reasons. Garden supports multiple pluggable back ends, which are software modules responsible for creating containers. Three back ends are available: Linux, Windows, and runC, which is the Open Container Initiative container specification. Using the Garden Linux back end you can run Docker images fetched directly from Docker Hub and your own Docker repository.
Regardless of the container type, Cloud Foundry runs applications on VMs. Cloud Foundry has two kinds of VMs: the component VMs that constitute the platform’s infrastructure, and the host VMs that host applications for the outside world. Diego distributes the hosted application load over all of the host VMs, and keeps it running and balanced through demand surges, outages, or other changes.
In Cloud Foundry, compute and storage resources are delivered to applications as an “on-demand utility,” much the way you pay for electricity. Based on demand, multiple host VMs can (and generally do) run duplicate instances of the same application. Cloud Foundry implements this by distributing the application’s source code to VMs, along with everything needed to compile and run the applications locally. This includes the OS stack that the application runs on, as well as an appropriate buildpack with its languages, libraries, and services.
The Cloud Controller stages an application for delivery to a VM by combining stack, buildpack, and source code into a droplet that the VM can unpack, compile, and run. For simple, stand-alone applications with no dynamic pointers, the droplet can contain a pre-compiled executable instead of source code, language, and libraries.
Cloud Foundry components communicate with one another by posting messages internally. They do so using HTTP and HTTPS protocols, and by sending NATS messages to each other directly. (NATS is a cloud-native messaging system.)
Applications often depend on services such as databases or third-party APIs. To incorporate these services into an application, a developer uses the Cloud Foundry Service Broker, an API that enables the Cloud Controller to list services, provision the services, and allow applications to make calls to them.
Cloud Foundry balances the processing loads over multiple machines while optimizing for efficiency and resilience against point failure. It does this at three levels.
The first of these load balancing functions is BOSH, which creates and deploys VMs and deploys and runs Cloud Foundry on top of a particular cloud. Bosh is an open source tool chain for release engineering, deployment, and lifecycle management of large-scale distributed services. BOSH has its own command line, separate from the cf command line.
Typically, system operators use BOSH as a DevOps tool to manage the underlying infrastructure of the PaaS. To configure the Cloud Foundry deployment for any given application, BOSH follows a manifest document.
The second performance management tool kicks in once Cloud Foundry is running. The Cloud Controller runs the applications and other processes on the cloud’s VMs, balancing demand and managing application lifecycles.
Finally, Gorouter routes incoming traffic from the world to the VMs and sysadmin commands to the Cloud Controller. Implemented in Go as a single process, Gorouter routes packets quickly, with minimal latency.
Reasons to believe
Cloud Foundry adoption has been driven by two major reasons.
First, developers need not worry about infrastructure. Cloud Foundry can run on any cloud, including Google Cloud Platform, IBM Cloud, Microsoft Azure, OpenStack, and vSphere. Developers and IT departments can move applications between clouds or even run applications across multiple clouds at the same time. This makes developers happy and productive, and avoids vendor lock-in (which is music to the ears of CFOs and CEOs).
The second element is enabling developers to use the tools they know. “Cloud Foundry lets developers write in the language of their choosing," says Abby Kearns, Cloud Foundry Foundation executive director. "It puts the controls in the hands of developers so they can self-provision without any roadblocks.”
Another attractive element is the project’s open source roots. Cloud Foundry is an open source PaaS licensed under Apache 2.0. It started as a VMware project led by Mark Lucovsky, Derek Collison, and Vadim Spiva. In 2012, VMware and its parent company, EMC, rolled Cloud Foundry into a new for-profit company called Pivotal. The code was spun off into the Cloud Foundry Foundation in late 2014, encouraging a healthy open ecosystem of users, developers, and providers. And now today, Cloud Foundry Foundation lives at The Linux Foundation.
Open source remains at the heart of the project, and active participation is encouraged. A developer can be trained on Cloud Foundry and given a "fast track" for commit rights, which permit the developer to add functionality to the software without outside approval. If all goes well, developers can obtain commit rights after working in a Cloud Foundry Dojo for six to 12 weeks. By contrast, it takes at least a year to earn commit rights in most open source projects. (As with most open source projects, anybody can submit a pull request.)
Everyone’s jumping on board
Why would a company want to join an open source programming framework for a PaaS cloud? Because Cloud Foundry gives businesses the power to deploy their existing legacy software to the new, cheaper cloud world. It also enables developers to easily create new cloud-native applications. Those are powerful incentives.
Corporate developers are relying heavily on the platform. As John Troyer, a co-host of online tech interview show theCUBE, observed, programmers aren't building one or two applications: “They’re building thousands of applications on Cloud Foundry and moving their whole enterprise over.”
The cloud giants are eager to support these corporate users. Microsoft recently joined the Cloud Foundry Foundation. "That's where the customers are," says Corey Sanders, Microsoft's director of Azure Compute. Google and IBM also support Cloud Foundry on their clouds. Of the cloud powers, only Amazon Web Services (AWS), with its Elastic Beanstalk PaaS, isn't fully behind Cloud Foundry. However, you can run Cloud Foundry on AWS.
Cloud Foundry has more competition than just Elastic Beanstalk. Other competitors for this growing PaaS market include Engine Yard, Red Hat OpenShift, Google Application Engine, and Heroku. In a recent Computerworld article, cloud business consultant Ben Kepes observes that Cloud Foundry "seems to have stolen much of the thunder of PaaS.”
KPMG predicts that "investment in PaaS will almost double its growth rate.” CIOs are adopting cloud computing for strategic development and production platforms. In that effort, KPMG says they are "beginning the process of paying down technical debt and migrating or modernizing their legacy IT estate."
Making the most of PaaS
The end result? Cloud Foundry enables DevOps to establish continuous development for application and IT workflow. It makes it easier for developers to port old applications and create new ones using familiar languages on almost any infrastructure-as-a-service cloud.
Cloud Foundry isn't just about making life great for your developers. According to SAP CTO Björn Goerke, “Ten years ago, we had delivery cycles of every two years. Now, we're a cloud company with quarterly release cycles with patches every two weeks.”
Doing so meant that SAP had to change its business model and encourage its employees to adopt new practices. They used Cloud Foundry to enable this transformation. If you don't want your company to be "eaten by software," you'd be smart to check out Cloud Foundry for yourself.
Cloud Foundry: Lessons for leaders
- Cloud Foundry bridges the gap between legacy applications and cloud-centric services.
- Cloud Foundry is open source and supported by all major cloud vendors. Only AWS isn’t fully behind it; even so, you can still run it if you are on AWS.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.