Cloud Foundry Explained in 5 Minutes
Cloud Foundry is an open-source platform as a service (PaaS) that enables developers to deploy applications fast and at scale. With its widespread adoption across big organizations, it's important to understand its basic concepts. This blog post provides the fundamental terminology required to have a basic understanding of Cloud Foundry.
What is Cloud Foundry?
Cloud Foundry is an industry standard platform for cloud applications. It is designed to foster fast-cycle innovation by minimizing the time it takes developers to take apps into production. The Cloud Foundry platform itself is highly scalable to safely host sheer amounts of apps, while apps themselves are also very easily scalable on the platform.
Cloud Foundry is even more than just a PaaS platform. The Cloud Foundry Foundation is a nonprofit organization striving to make the open source Cloud Foundry platform the leading application platform for cloud computing worldwide. While commonly by "Cloud Foundry" we refer to the PaaS offering, the Cloud Foundry foundation also maintains the Cloud Foundry Container Runtime (CFCR), which is a Kubernetes offering.
Cloud Foundry High-Level Usage
To deploy an application to Cloud Foundry all we need to do is to push our application source code to the platform. Cloud Foundry's mantra hereby is:
Here is my source code, run it on the cloud for me, I don’t care how.
Cloud Foundry takes the application source code, builds a container around it, and then runs it and makes sure to keep it alive. The application can then connect to services such as databases or message queues, that can be provisioned via a self-service marketplace from within Cloud Foundry.
Organizations and Spaces for Tenancy Management
Cloud Foundry knows two levels of hierarchy for tenancy management: organizations and spaces. A single Cloud Foundry deployment is divided into several organizations, and each organization can contain an arbitrary amount of spaces. Usually, organization and spaces relate to the company, team or project structure, so there could be an organization for a whole project or an organization for a department or team.
A space finally contains the actual applications that run in Cloud Foundry and holds the connections to 3rd party services required by these apps (such as databases). Both, organizations and spaces can have quotas and users with specific roles attached to them.
Routing
Once applications are deployed to a specific organization and space, we need to ensure the application is available and reachable for end users. To do so, Cloud Foundry associates so-called routes to applications. Each application may have an arbitrary number of routes, through which it is available. A route looks as follows:
By default, the app name is used as subdomain, but any name can be chosen as long as it hasn't been taken by another app in another space. Cloud Foundry ensures that all traffic reaching the platform entry point is routed to the correct application.
Buildpacks - Creating Containers from Source Code
When pushing application source code to Cloud Foundry, the platform assembles a container with the help of a language-specific buildpack. Buildpacks can automatically detect the programming languages and frameworks used by the source code and assemble the container using battle-tested configuration and security concepts. Doing so ensures that all containers running on the platform comply with the same set of standards. That also means that to patch all containers with a fix it boils down to updating the respective buildpack and rebuilding all containers based on the new buildpack.
Buildpacks have lots of responsibilities and support for common features used by a certain platform. For example, buildpacks take care of adding frameworks, libraries, or runtimes if necessary (for example a Java Runtime Environment), they can add application performance monitoring tools, or even handle certificates for the application. Check out the Java buildpack for a good example.
Spicing up the Ecosystem with Services
Hardly any application runs without any kind of backing service like a database or message queue. To allow developers to provision required services themselves, Cloud Foundry provides a marketplace of services where developers can view and provision services to their liking. Technically, the marketplace implements the Open Service Broker API which is an API to dynamically provision services.
The services that are provisioned through the marketplace then expose the credentials to the application via the environment variable VCAP_SERVICES.
A lot of frameworks support setting up the connection to external services based on the contents of that variable, such as the Spring Cloud Connectors.
Summary
In this blog post you have learned what Cloud Foundry is and what the platform's central concerns are. We're able to deploy applications by pushing their source code, which is then turned into a container by a buildpack. Then running container is exposed to the outside world through a configurable routing plane. Applications can provision and access third party systems through the marketplace concept with service brokers. If you're interested in seeing how Cloud Foundry can help your enterprise to succeed in adopting cloud technologies, we're more than happy to have a chat.