Cloud Foundry Architecture — Removing the OS Barrier with PaaS, Part 4

By Posted in Engineering, Top Post 23 February 2012

I broke the latest post in this series into a double featurette. Part 3.1 dug deeper into the context behind PaaS and Cloud Foundry’s open source software efforts, along with some of the questions that have been posed since Part 1. With Part 3.14159265, I came full circle (pun intended) back to the topic, and collected the top links for putting together a Cloud Foundry environment, getting various platforms to run, and other key pieces of information. (All in one place for easy reference!) In Part 2, I jumped into a hands-on example of setting up Cloud Foundry on Ubuntu Linux, with links to great references on setting up or using the virtual machines available from Cloud or from Iron Foundry to get things going. When I kicked off this series, I covered what PaaS can do for your development environment and how PaaS fits into the big picture.

Now it is time for an architecture discussion. I dug through the code on github for the Cloud Foundry, Iron Foundry, and Uhuru Software effort to gain more familiarity with the architecture. After a fair amount of study, I created this architecture diagram of the pieces.

Client Layer / Plugins
The client layer consists of several tools, plugins and command line capabilities. With the VMC one can easily just “gem install vmc” and be off and running on the client. For many, this will be the extent of work needed to use Cloud Foundry. For the plugins and tools, Eclipse and Visual Studio have had plugins, add ons, and tooling additions available to provide visual interactions via the IDE for deployment, maintenance and other functionalities.

There are many possibilities for client facing applications that ride atop the Cloud Foundry enabled PaaS. Of course, some of these client applications are the PaaS provider interfaces and feature sets themselves. Two companies providing great web enabled, SaaS-style interfaces atop Cloud Foundry PaaS are ActiveState  (Stackato) and AppFog (get the beta). And I’d suspect, (no promises, just saying) more companies will be jumping on the bandwagon with great PaaS capabilities and feature sets this year, such as Tier 3, the Iron Foundry coders.

Cloud Foundry System / Core Architecture
The core of the Cloud Foundry architecture centers around the controller, or as I like to say, “the concept of the controller”. There can be one or multiple of these various core systems in the architecture, as one might assume based on horizontal scalability needs. Around and within the controller, various tools such as Rescue and Stager, enable deployments to specific areas of the infrastructure. The horizontally scalable, self healing, pub/sub functionality is provided by NATS (written by Derek Collison). Between the capabilities of NATS, the controller(s), health monitor(s) and other elements, the entire core architecture and system surrounding it is self-healing. (Better than NCC-1701 Enterprise even!)

Speaking of futuristic and high tech, the cloud controller is built on some serious elements. The cloud controller utilizes Async Rails 3 with Ruby 1.9.2 and fibers plus eventmachine.  Check out Woodchuck for a quick start or read about the 9x performance by  for an idea of what async is about. Mike Perham and Ilya Grigorik also publish great info about these frameworks.

Droplet Execution Engines – Running Services and Applications
Droplet Execution Agents, or DEAs, are the Jedi of the Cloud Foundry stack that sit on the various instances running, to enable applications and services. They are loaded on various nodes (including Windows Server 2008 Core thanks to the OSS Iron Foundry fork) which then execute the applications based on the various frameworks supported. The frameworks can be Ruby on Rails or Sinatra, PHP, .NET, Node.js, and Java just to name a few. The DEAs hold a particular responsibility to executes and responds accordingly when they’re ready to host a particular application stack.

The DEA nodes don’t need to all be the same size either. They can vary. A great example is a set of DEA nodes that will run Node.js applications. These can be super small instances around 256 MB of RAM and a single core, and they’ll scream. Where as a .NET or Java node would work better setup for multi-threading work with a two to four gigs of memory and four or more compute units (cores). This is one of the beauties of the DEAs. They can go to configurations that can be customized and setup specifically for what kind of work the specific nodes are to be setup for.

Keep in mind, that even though an application or applications can run on the server enabled with the DEA, the DEA itself doesn’t really care what framework stack is being executed. What it takes care of is droplets, which is a wrapper around an application that provides HTTP interactions. DEAs are basically a black box with a start and stop. Beautiful architecture, elegant and functional in their simplicity.

The router is a router — pretty simple in that regard. The router within the Cloud Foundry architecture operates as another event machine daemon within the system. The routers are responsible for listening on the bus for new apps coming active in the system or going offline. When updated, the routing table is updated or referred to based on need to determine proper route requests. These requests are then load balanced across routers.

Health Manager
The health manager acts like a medical trauma advisor. It determines ailments to the system by looking into the models or databases that the cloud controllers have access to. The health manager wakes up at a certain interval and verifies that the state of the world is good. If nothing is sick, life continues. If a node is sick, however, the health manager kicks in and works within the system to determine a remedy. It then works with the cloud controller to administer the necessary medicine and fix the ailments.

The services are where MySQL, Redis, SQL Server, or any of many server services can operate. This list is one of the areas where additions are made daily for for more new capabilities.

So that pretty much gives the 80k foot view of the architecture for Cloud Foundry. Let me know if you have any questions, thoughts, or curiosities. In addition, if there are any PaaS topics you’d like to know more about let me know and they’ll magically appear in Part 5 along with unicorns and Transformers.

About the author

Adron Hall is a jovial, proactive, test & code, code & test, get things done well, software architect, engineer, code monkey, coder, and distributed systems advocate. As a coder, Hall plies a polygot language path including C#, Java, JavaScript, and Erlang lately -- as well as Pascal, Basic, Visual Basic, C++, C, COBOL, RPG, CL, and others in the past. He founded with Aaron Gray, Node PDX with Troy Howard, and more startups are in the works. You can read his blog at Composite Code (

Tell us your thoughts Or Send us an internal high five

Talk to @newrelic