Cloud Foundry Architect
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, 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.
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.
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!