This article explains the
architecture of Cloud Foundry, a cloud virtualization platform that is gaining
popularity.
So what is a cloud virtualization platform?
It is a layer of software that sits between the software application that you
write, and the cloud platform. Cloud virtualization 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
virtualization allows us to avoid precisely this situation. Examples of cloud
virtualization 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 license. 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
architecture of cloud foundry
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.
Figure
1: Layer diagram showing cloud virtualization platform (PaaS)
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 have 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.
Figure
2: The core components of the Cloud Foundry kernel
Cloud virtualization 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!
