The Architecture of Cloud Foundry

This article explains the architecture of Cloud Foundry, a cloud virtualisation platform that is gaining popularity.

So what is a cloud virtualisation platform? It is a layer of software that sits between the software application that you write, and the cloud platform. Cloud virtualisation platforms help us avoid the ‘Hotel California’ problem of vendor lock-inW “You can check out anytime you like, but you can never leave!” Once you write your application using D SDUWLFuODU FORuG vHQGRU’V AP,, LW wLOO EH vHUy GLIfiFuOW for you to move to another platform, which is, essentially what vendor lock-in is all about. Cloud virtualisation allows us to avoid precisely this situation. Examples of cloud virtualisation platforms are Google App Engine and SalesForce Heroku. The Cloud Foundry platform, available at cloudfoundry.org, is Apache 2.0-licensed, which is a very friendly open source licence. So if you’re interested in knowing what else sets Cloud Foundry apart, it isW Supported on many cloud platformsW Amazon, Rackspace, OpenStack, rbuntu, etc. Supports many programming languages and frameworksW Java, Scala, Ruby, Spring, Rails, Grails, etc. Supports many back-end servicesW RabbitMQ, MySQL, PostgreSQL, MongoDB, Redis, etc.

VMware developed Cloud Foundry and contributed it to the open source community. Being open source is expected to increase the acceptability of the platform and make it widely accessible. It is located at www.cloudfoundry. org. The source code can be obtained from http:// github. com/cloudfoundry. Note that the cloudfoundry.org site is different from http://www.cloudfoundry.com/, which is where VMware provides a hosted and commercially supported version of Cloud Foundry.

Architecture

Let’s look at the major components of the Cloud Foundry platform, which are written in Ruby, and run as daemons.

The Cloud Controller

This component of the architecture orchestrates all other components. It also stores information about the status of other components in the architecture, the users, the deployed applications and available services. It exposes a REST interface for accepting requests from the Cloud Foundry

command line toolW the VMC client. The Cloud Controller is the external interface used by development and management tools of Cloud Foundry. It also binds external services like RabbitMQ and MongoDB to the deployed applications.

The Health Manager

It monitors the health of the deployed applications and other Cloud Foundry components. It can only monitor, so it depends RQ WhH CORuG CRQWUROOHU WR WDNH FRUUHFWLvH DFWLRQV. TR fiQG out about the health of an application, it compares the current state of a deployed application with the expected state. The expected state of an application that has been running for some time is derived from its initial state. The expected state of an application is available in the Cloud Controller’s DB.

The Droplet Execution Agent (DEA)

This is the component responsible for running all applications. Each application in Cloud Foundry is run as a droplet. A droplet is created by wrapping an application with meta-data like the input port number, the starting mechanism and the stopping mechanism. This wrapping is actually done by another component of Cloud Foundry called the Stager. The Cloud Controller drops (deploys) a new application (the GURSOHW) RQ WhH D(A, DIWHU WhH ODWWHU FRQfiUPV LWV UHDGLQHVV to handle the new application. The DEA is the container that executes the new application. It also handles scaling the applications, when the load increases, by launching new instances of the application. Because DEAs run the applications, in a Cloud Foundry set-up, they are the most numerous. Each DEA also monitors the application that it is running, and generates alerts in case of a change of state.

The router

The router, as the name implies, takes an incoming request, and forwards it to the appropriate DEA. It also distributes the load among DEAs, like a load balancer. Like a hardware router, the Cloud Foundry router maintains a routing table, which is referred to before making routing decisions. There will be many routers in a Cloud Foundry set-up, to handle requests. The routers themselves are load-balanced using a traditional load balancer. If an application that the router sent a request to has failed, the router retries the request with another instance of the same application. The routing table is updated in real time, based on the status of the DEAs.

Messaging

The messaging component is used by all other components in the architecture for communications. It is designed to be highly available and reliable. It uses asynchronous messaging semantics for high scalability. This publish/subscribe messaging is used only for internal communications, and is called NATS. For messaging between applications, Cloud Foundry supports RabbitMQ.

Services

There are a set of Cloud Foundry components that enable us to connect with external services like messaging and data storage. These are the Service Abstraction Components, shown in Figure 2. They are often referred to as Services in the documentation on Cloud Foundry. Examples of external services are RabbitMQ, MySQL, mongoDB and Redis. The actual services run outside the scope of cloud foundry. To interface with them, the system uses the Service Gateway and the Service Provisioning Agent. There is one Service Provisioning Agent for each external service. The Service Gateway is the interface for the Cloud Controller to provision external services and to track the status of those services.

Cloud virtualisation platforms are becoming very popular, since they reduce the risk of cloud vendor lock-in. We have seen the core components of Cloud Foundry and their functions. Being open source, with wide vendor support, there is a good chance that one of your next cloud projects will use Cloud Foundry. So have fun exploring the cloud>