Cloud Foundry

Cloud Foundry is a free software “platform as a service” (PaaS) tool (there are also commercial derivates). It occupies the same space as OpenShift (also free software), Heroku (proprietary), Google App Engine (proprietary), and others.

Cloud Foundry is concerned with taking an application that is written in a certain way, providing predefined services that the application requires to run (such as a MySQL database, a RabbitMQ message bus), and starting one or more instances of the application on top of a base operating system, with a load balancer at the front.

Cloud Foundry sits at a level above “infrastructure as a service” tools, which are concerned with provisioning virtual CPUs, RAM, disks and networks. CloudFoundry can manage several infrastructure-as-a-service platforms including OpenStack and Amazon Web Services.[1]

The Cloud Foundry project has developed its own deployment and orchestration tool named BOSH (after originally using the Chef configuration management tool). In order to integrate Cloud Foundry in Baserock we need to consider how BOSH interacts with Baserock.

[1]. Note this distinction only makes sense at a high level. When you dig down it begins to fall apart.

Getting started with CloudFoundry

This may be a bit of a dumping ground for now.

• http://docs.cloudfoundry.org/deploying/
• cf-lite: marked as under development, and only supports deploying to Amazon Web Services
• cf_nise_installer
• CloudRocker: allows running apps independently of Cloud Foundry, using Docker and Vagrant rather than BOSH to deploy them from the same metadata

List of places that Cloud Foundry compiles software

One of the strength of Baserock is that it encourages mirroring all of the source code you need in one place (Trove), and keeping all the build instructions for it in one place, using the standard Baserock definitions format.

It seems that Cloud Foundry is not at all rigorous about this sort of thing. There are x86_64 binaries committed to Git repos, which suggests that porting it to other architectures would be very difficult. There are lots of shell scripts which download source code from the internet and compile it, which means it is vulnerable if any of the servers hosting the code it uses are taken down or compromised. It also makes it tricky to gather all of the code together in order to audit it, debug it or improve it.

Incomplete list of the different places that source code is fetched and compiled, or externally built binaries are used, in a Cloud Foundry deployment:

• BOSH stem cell
• BOSH releases (Cloud Foundry services)
• RubyGems used by BOSH tooling
• buildpacks
• ...

The applications deployed to Cloud Foundry aren't included in this list as they are not part of the infrastructure.