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-in: “You can check out anytime you like, but you can never leave!” Once you write your application using a particular cloud vendor’s API, it will be very difficult 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 is:
- Supported on many cloud platforms: Amazon, Rackspace, OpenStack, Ubuntu, etc.
- Supports many programming languages and frameworks: Java, Scala, Ruby, Spring, Rails, Grails, etc.
- Supports many back-end services: RabbitMQ, MySQL, PostgreSQL, MongoDB, Redis, etc.
The history of Cloud Foundry
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 tool: 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 on the Cloud Controller to take corrective actions. To find 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 droplet) on the DEA, after the latter confirms its readiness 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!
