vali_111 - Fotolia
Is a Cloud Foundry deployment right for you?
Enterprise PaaS needs have grown from streamlining app deployment to the ability to use the hosting infrastructure of their choice -- which has put Cloud Foundry in the spotlight.
Large enterprises continue to be attracted to Cloud Foundry as IT teams look simplify app deployments in cloud environments.
More users are building more Cloud Foundry deployments as organizations adopt multi-cloud strategies and seek to avoid vendor lock-in, according to the latest user survey. Cloud Foundry provides great flexibility in choosing which infrastructure to use -- a feature that many competing PaaS offerings, such as Heroku, lack.
Even if you use a commercial version of Cloud Foundry, migrating to a different host infrastructure is not too difficult because the core tools and configurations remain the same.
Cloud Foundry options
Cloud Foundry is designed to streamline the process of building, testing, deploying and managing cloud-based applications. Similar to other platform services, it automates the processes required to load, start and manage cloud applications.
To begin, enterprises need to choose between an open source and commercial version of Cloud Foundry. With the first option, IT teams set up their own infrastructure -- either on premises or on an IaaS platform -- then deploy the open source version of Cloud Foundry. The second option would be to use a commercial PaaS platform based on Cloud Foundry, such as Pivotal Software Cloud Foundry and IBM Cloud Foundry.
The commercial versions of Cloud Foundry appeal to IT teams because they are fully hosted, which eliminates the need to set up, manage and pay separately for host infrastructure. They also provide professional support services.
Get started
Developers and IT teams must first deploy Cloud Foundry to their cloud. It can run on all of the major public clouds as well as private clouds such as OpenStack. The command-line tool -- called cf -- then pushes applications to their Cloud Foundry deployment.
From there, Cloud Foundry does most of the heavy lifting required to get the application up and running. It uses reference frameworks -- called buildpacks --- to determine how to compile and launch the application. It also automatically load balances the application by pooling the right amount of resources from the host cloud to meet demand for the application, even as demand fluctuates.
Although Cloud Foundry does most of this work by default, admins can use the cf tool to control behavior manually if desired.
Each application that runs on a Cloud Foundry environment is hosted inside its own container, which provides isolation. This can save system resources compared to VMs, which are heavier by their nature.
Currently, Cloud Foundry uses a runtime called Garden to create and manage container environments. It uses the Diego system to schedule and manage the containers themselves.
Compare frameworks
Organizations evaluating PaaS options today often ask how Cloud Foundry compares to other modern application-deployment frameworks, such as Kubernetes or OpenShift.
First, Kubernetes itself is not a PaaS. It's an orchestration tool that manages applications that run inside containers. Kubernetes does not provide the application testing, build and management features of Cloud Foundry. However, IT teams can combine Kubernetes with other tools to create a complete PaaS. For example, OpenShift is a PaaS that uses Docker containers and Kubernetes to run application.
Cloud Foundry users also have the option of CF Container Runtime, which incorporates Kubernetes into their environments for container orchestration. In general, CF Container Runtime is a better choice if the applications you plan to deploy to Cloud Foundry are packaged as containers from the start because this option gives you more granular deployment control.
At a high level, the feature sets of Cloud Foundry and OpenShift are broadly similar. Each one automates cloud-based application deployment and management. Both PaaS offerings are also open source, with commercial implementations available for each one.
However, there are three core differences between Cloud Foundry and OpenShift:
- Community. Cloud Foundry development is overseen by a nonprofit organization, the Cloud Foundry Foundation. OpenShift is tied closely to Red Hat, which is now part of IBM. As previously stated, many of the OpenShift components are actually independent open source projects.
- Tools. Some of Cloud Foundry's internal tooling, namely its BOSH automation framework, is unique to Cloud Foundry. In contrast, OpenShift is composed almost entirely of third-party open source tools, such as Kubernetes and Puppet.
- Runtime. Cloud Foundry uses the Garden container runtime, while OpenShift uses Docker containers and Docker files. The latter two are more likely to be familiar to a typical developer today, because they are widely used in many other contexts; Garden is more obscure and used primarily with Cloud Foundry.
Familiarity is a key factor when choosing between PaaS offerings. OpenShift may be the better choice if your team is well versed in Docker and Puppet. If your staff will be learning their PaaS tools from scratch, they will find it no harder to get started with Cloud Foundry than with OpenShift.
Organizations should also consider whether they would rather enmesh themselves in the Docker and Kubernetes ecosystem on which OpenShift relies, or dive into the Cloud Foundry world, which has fewer entanglements with other projects.
