The power of Cloud Foundry shines when it comes to deploy microservice architectures and also when it comes to establish a DevOps culture .

The biggest advantage is a leaner deployment process because application developers doesn’t need to talk to an operation department anymore . Furthermore an easy deployment process allows to build continuous delivery/deployment pipelines to completely automate the deployment step.

Using Cloud Foundry (or a PaaS in general) developers are able to deploy and operate applications by themselves without knowing how to setup a webserver, a database, a load balancer, etc.

Excursus: An application is considered as stateless if the application doesn’t save something to the disk nor into the RAM what is required to process future workloads. All data must be stored in a backing service (a database). The benefit of stateless application is the possibility to run multiple instances of an application in order to distribute workload and increase availability.

Cloud Foundry is an open application Platform as a Service (PaaS) developed under an open source license. In other words, Cloud Foundry is a system to easily deploy, operate and scale stateless applications which are written in any programming language or framework.

Deploy and Scale Applications

Feature Interfaces: HTTP/CLI

Cloud Foundry provides a REST API to deploy, operate and scale applications. The Cloud Foundry command line interface (CF CLI) is used by the application developers to send instructions to this API.

To deploy an application, the developer first has to specify to which Cloud Foundry the CF CLI should talk to. Once the "target" is configured the CF CLI asks the developer to authorize with his email and password.

/my-web-application $ cf api https://api.eu-gb.bluemix.net

/my-web-application $ cf login



Email>

In a third step the developer changes the current working directory to the directory where the application source code is and executes the “cf push” command.

The push command causes the CF CLI to upload each file and subdirectory within the current working directory to Cloud Foundry.

Cloud Foundry then tries to detect in which programming language and framework the application is written and then it builds an executable application out of the uploaded application sources. This means Cloud Foundry installs the runtime, the required libraries/frameworks, etc.

In case the developer uploads an application which is not supported by the given Cloud Foundry installation, the developer can specify an URL to an arbitrary buildpack.

A buildpack is a set of shell scripts to transform the uploaded application sources to an executable application. In Cloud Foundry terminology the uploaded application source code is called “app package”. The executable application was build with a buildpack is called “droplet”. The process to build a droplet out of an app package is called “staging”.

Once Cloud Foundry has build the droplet, it will start the requested amount of application instances and route traffic to these instances.

Scaling an application to a specific number of application instances can be done with only one CLI command. Cloud Foundry then will start new application instances using the already available droplet. Decreasing the amount of running instances is also possible with one CLI command.

Scaling applications vertically is as simple as adding new instances. Vertical scaling means that running application instances receives more or fewer resources (memory and disk).

Stream Application Logs

Feature Interfaces: Websocket/CLI

Usually applications generate log messages which are helpful to the developers but since the application instances run on different server collecting those log messages is not straightforward.

Cloud Foundry provides a CLI command to stream and sort the log messages from each application instance to the developer’s terminal. Further the developer can specify a syslog endpoint for each application where the log messages are stored persistently.

To allow Cloud Foundry to handle the application log messages like described the application must write its log message to stdout/stderr.

Show Application Utilization

Feature Interfaces: HTTP/CLI

In order to decide whether it is necessary to scale an application, Cloud Foundry provides an overview how much resources (RAM, disk, CPU) are used by each application instance at the moment.

Restart failing Application Instances (Health Management)

Feature Interfaces: none

Once an application instance crashed for any reason (e.g. out of memory) Cloud Foundry will restart the crashed instance.

Provide a Service Marketplace

Feature Interfaces: HTTP/CLI

As stateless applications often requires additional backing services to persistently store some data (e.g. PostgreSQL, MySQL, MongoDB, RabbitMQ, Redis, etc.), Cloud Foundry provides a marketplace where third party systems can register such a service offering.

To bring a service into the Cloud Foundry marketplace the provider of this service must provide a simple REST API to manage instances and credentials to the services. In Cloud Foundry terminology this API is called “Service Broker API”.

Service instances can be created by choosing a service type (e.g. MongoDB) and a service plan. A service plan describes the dimension of the service instance e.g. a MongoDB with 50 GB storage, 8 GB memory and 4 CPUs.

Once a service instance has been created it can be bound to one or multiple applications running in Cloud Foundry. This means the bound applications can read credentials to the service instance from the environment variables. These credentials usually include a hostname, a port, a username and a password but this depends on the service type.

Manage multiple Tenants (Multitenancy)

Feature Interfaces: HTTP/CLI

Cloud Foundry is able to handle applications of multiple customers so that only authorized developers can update applications.

This means customer X can’t stop or perform other actions with the applications of customer Y. To realize that Cloud Foundry uses a role based authorization system.