Cloud Foundry Blog

Static.com Adds Hadoop Support for Cloud Foundry

Posted on May 20, 2013 by Jake Farrell

In this guest post, Jake Farrell, CTO for Static.com, explains how the major shift in the hosting industry towards platforms for high developer productivity and data-centric applications led them to build their Platform as a Service using Cloud Foundry with Hadoop support.

Test Static.com for Cloud
Foundry Core Compatibility here.

The hosting industry is undergoing a dramatic transformation due to increasing demand for self-service cloud based capabilities. To greet this shift, Static.com, a subsidiary of Catalog.com, is leveraging 19 years of hosting experience, and adopting Cloud Foundry as the foundation for its Platform as a Service (PaaS). This move demonstrates the company’s commitment to providing modern, easily-installed and managed cloud-based solutions to hosting companies and enterprises.

To address the demand for self-service cloud hosting, Static has designed the Static Cloud Manager, a robust yet easy-to-use interface. Static’s Cloud Manager leverages Cloud Foundry to allow end users and enterprises to configure, deploy and scale applications and services in seconds. Additionally, Static has expanded on Cloud Foundry’s core platform and developed a growing catalog of OSS applications, frameworks and services for end users to choose from.

With this growing array of options comes a greater need for insight into application metrics and usage patterns. Static has integrated Apache Hadoop with Cloud Foundry as one of the first steps in what it sees as the cloud’s next major offering: Analytics as a Service (AaaS). Thanks to the power and flexibility of Cloud Foundry, these robust new offerings are rapidly evolving the cloud.

Static adds Apache Hadoop to Cloud Foundry

As PaaS and Infrastructure as a Service (IaaS) become the new hosting standard, having the ability to gain insight into usage and the performance of sites and cloud-based applications is essential. Static believes that the AaaS offering will allow users to make educated decisions about their sites and applications based on usage patterns. The first step to achieving this is to be able to store and crunch large amounts of big data into usable metrics, and Apache Hadoop fits this need perfectly.

Adding services like Apache Hadoop to Cloud Foundry allows Static’s users to easily add cost-effective big data solutions to address custom application needs. Adding Apache Hadoop as a pluggable service inside Cloud Foundry is the first step to automating AaaS to any site or application within the PaaS, enabling customizable metrics and immediate insight into usage patterns.

The Shift in Hosting

Traditional hosting offers minimal choices to the user, forcing them into shared pools where sites and applications are not guaranteed any dedicated resources. Shared hosting has worked for many users and hosting companies, but Static has seen an increase in demand from users who are switching to Virtual Private Servers (VPS) solely for the ability to have a dedicated set of resources and the freedom to choose what they run. This use case places the burden on the user to install, setup and administer the entire process, from start to finish.

Static’s goal was to rethink this approach and to allow for users to have the ability to choose:

• An expanding applications list ready to be installed with one click
• All the latest languages and version to choose from
• Latest frameworks ready to be use
• Full control over memory limits
• Ability to scale instances easily
• Choose from array of services
• Sync code between test and production environments
• Backup and rollback applications and services with ease

Static has leveraged Cloud Foundry to help make this a reality with the Static Cloud Manager, an easy-to-use but robust interface which interacts with Cloud Foundry. Users are able to 1-click create a Platform as a Service application with a wide array of frameworks and services while taking advantage of integrated hosting features such as domain registration, DNS, billing, support, Virtual Private Servers (VPS), and email.

The Cloud Network

Having choices does not stop at applications and services. Static is working to create a unified cloud network of datacenters and hosting companies that will:

• Run your application in multiple data centers for high availability
• Migrate applications seamlessly from one datacenter to another while maintaining uptime
• Choose your application and services based on data centers capable of meeting your needs

Static’s Commitment to Open Source Development

Static believes that open source software development drives innovation and leads to higher quality software. We are deeply committed to the open source ecosystem and being a leader in the Cloud Foundry community. Static is proud to contribute back to the Apache Hadoop project, as well as Cloud Foundry, through services such as snapshot functionality to the file system service, chef cookbooks, bug fixes and enhancements. These contributions can also be found on our GitHub account at http://github.com/staticcorp.

About the Author: Jake Farrell is the Chief Technical Officer for Static Corporation. He specializes in scalable distributed back end infrastructure systems. He is actively involved in numerous projects with the Apache Software Foundation and is the Project Management Committee Chair for the Apache Thrift project.

Want to Contribute to Cloud Foundry? Come on in!

Posted on May 16, 2013 by Andy Piper

Cloud Foundry is an Open Platform-as-a-Service, and an Open Source project. It has attracted phenomenal interest from the community - including partners, companies using the code internally, and those individual developers with a passion for getting involved. You can find the source code on Github. Community contributions are what help to make the platform so extensible. We are always happy when we receive a Github pull request to offer new functionality or fixes! We also appreciate bug reports submitted through Github Issues.

Looking at the Cloud Foundry project as a whole though… where should you start?

As you might imagine, there are a lot of moving parts in a PaaS. At Pivotal, we have teams working on the backend (the main runtime environment for Cloud Foundry, also known as ‘vcap’); the frontend (the tools and APIs for deploying apps, such as the ‘cf’ gem); services (database, message queues, and related resources); and Cloud Foundry BOSH, the installer and deployment tool, which has different plugins targeting infrastructures like AWS, OpenStack and vSphere. In the future, we would love to see even more Cloud Provider Interfaces (CPIs) for BOSH to allow Cloud Foundry to be deployed onto additional clouds.

One of the best ways to get involved with the community and the codebase is to start with the Github repositories and the mailing lists. If you are not sure where particular functionality resides within the project as a whole, and you’ve had a good look at Github already, then we have a number of mailing lists where you can ask for help. vcap-dev is for those working on the PaaS itself; bosh-users is for those who want to understand how to use BOSH to deploy Cloud Foundry; and bosh-dev is for the elite hackers (like Dr Nic Williams!) who want to help us make BOSH even more awesome. If you participate in the mailing lists you will also be able to keep up with what others are working on, and learn who some of the leading developers on the project are. If you want to get an idea of the general direction of development, you’ll find that in our roadmap.

Once you are up-and-running with Cloud Foundry, or if you know to which part of the project you want to contribute, then consider the size of an initial contribution. If you are new to the project you might want to start with something small (some Open Source projects call these kind of small changes to smooth out any rough edges “paper cuts”). If you have something larger, we are always keen to work with you to understand how we can integrate your code. Before sending a pull request, take a look at our OSS contribution information in the project readme, which includes details on the Contributor License Agreement for individuals and corporations.

We thought it would be good to highlight a recent pull request which was a superb example of a major addition to the project. Recently we received a contribution via a detailed Github pull request, adding Oracle support to some of the major components inside Cloud Foundry: the User Account and Authentication service (UAA) and the Cloud Controller. Originally, these components were built to use Postgres as a backend, and more recently MySQL support was added. Since many enterprises already use Oracle as their main relational data store, it is great to give them this additional storage option.

Taking a look at the specific request for the Cloud Controller, we were really struck by a few things. The first one is that the pull request itself is very detailed, and walks through the various changes required in order to replace the database with Oracle.

This pull request is a lot to digest. If you want you can review the single feature PR that lead to this PR for some more concise context into some of the decisions I made in creating this PR. Here is a summary of the more notable changes I had to make and some context for why I made those changes:

This level of detail is not always required with every patch, of course, but for something this extensive it was very welcome. Another aspect of this patch is that was was made of up several individual changes (things like tweaks to the database schema, differences between Oracle datatypes and those used by other databases, etc), and they were broken down into separate commits which made it easier to consume. It also helped that this set of changes was extensively discussed on the vcap-dev mailing list before this larger pull request was submitted, so the engineering team were aware of some of the other impacts it would have.

Although the resulting pull request was detailed and clear, it has taken a few days to make all of the changes, as the core code was still being worked on. This was actually one of the rarer cases where we had to do more work to get the patches integrated – and that shows how willing we are to work with contributions. Smaller changes are extremely welcome too, and often much quicker to digest. Don’t be put off by this larger example – come and start hacking with us!

We hope this post highlights some of the things that help to make it smoother to contribute to the project. To recap:

review the contribution guidelines and complete the CLA;
if you want to submit a major code change, discuss it on the relevant mailing list beforehand;
think about how the pull request is structured, and submit changes in separate consumable commits (rather than as one monolithic change) where appropriate;
the patch should be well-tested, should include tests if possible, and should pass our Travis CI process;
the changes should be clearly documented in the request, especially when the updates are more extensive than correcting a few typos.

The past few months have seen the Cloud Foundry Open Source community grow hugely, and mailing list activity continues to be at an all-time high – so we’re really looking forward to continuing to work with other developers to make the platform even more awesome! Thanks for being on this journey with us.

Andy Piper @andypiper

Developer Advocate, Cloud Foundry

UK Charity Raises Record Donations Powered by Cloud Foundry

Posted on April 30, 2013 by Colin Humphreys

For Comic Relief – a UK based charity, fifty minutes of downtime during peak fundraising hours could result in half their annual online donations income being lost. This blog describes how Cloud Foundry was used to provide an Enterprise grade donations platform that helped Comic Relief raise a record £75million (about US $115 million) in funds for their humanitarian projects.

Guest Blog by Colin Humphreys, CloudCredo, Inc.

Comic Relief is a well known charity based in the UK which strives to create a just world free from poverty. They raise millions of pounds through two big fundraising campaigns – Red Nose Day and Sport Relief. The money raised is spent in the best possible way to tackle the root causes of poverty and social injustice. All the money raised by the public is spent by Comic Relief to help poor and disadvantaged people in the UK and the world’s poorest countries.

Seven Hours to Maximise Funding For The Entire Year

A year of planning for Red Nose Day 2013 resulted in a 6 week media campaign culminating in 7 hours of prime time television coverage on the 15th March. Their donations platform is required to process in the region of 600,000 transactions in this 7 hour period, handle in excess of 10,000 concurrent call centre operators, and handle peaks of 500 donations completing per second from web, mobile and call centers.

These requirements pose an operational nightmare. A fifty minute outage at peak traffic, allowed within an annual “four nines”(99.99%) uptime SLA, could result in 50% of the charity’s annual income being lost. Comic Relief require a platform delivered with no outages; there won’t be a second chance for another year. Feedback on the performance of the platform under high load from real users is only received on an annual basis. To demonstrate the difficulty of this challenge, JustGiving, one of the largest charity-orientated service providers, had a huge outage beginning early on Red Nose Day 2013.

For the previous eight years the donations applications have been delivered via a monolithic Java application and RDBMS backend, deployed and scaled with the help of twelve partners. This setup suffered from single points of failure, high recovery times from potential failures, and a lack of consistency between environments in the deployment pipeline. Comic Relief were also looking to remove their reliance on any single third-party supplier so as to not be limited in their technology choices.

Working Prototype Delivered in a Single Day on CloudFoundry.com

Moving from traditional development methodologies to a lean, agile approach delivered by a small team required a leap of faith from Comic Relief. Their fears were allayed by delivering a working prototype via CloudFoundry.com on the first day of application development. This was critical to receiving constant feedback from Comic Relief, and gave a starting point from which to iterate on the applications and the platform.

The software that drives the ability to take donations is a series of small micro-applications decoupled via queuing technologies. The service-layer application generates events that are used to mutate an eventually consistent view of the donations domain, enabling failure handling and fault tolerance across the distributed architecture. The applications were all developed to the platform contract represented by Cloud Foundry.

Vendor Neutrality and High Availability are Primary Architectural Goals

Developing the applications to the Cloud Foundry contract brought vendor neutrality to Comic Relief’s donations deployment. Wherever Cloud Foundry ran the donations suite could run too. This commoditised the infrastructure vendors and freed Comic Relief from vendor-related constraints, allowing infrastructure choices to be based on price, performance and efficiency – rather than forced by vendor lock-in.

Developing on the operational capabilities of Cloud Foundry played a major role in meeting Comic Relief’s requirements. The data services were enhanced with redundancy and replication, intelligent connection load-balancing was added to each instance, and a distributed global load-balancing/fault tolerance service added to recover quickly from single or multiple instance outages. The service was distributed across multiple AWS EC2 regions and zones, and also London-based VMware vCloud/vSphere IaaS provider, Carrenza (See Figure).

Service distributed across multiple regions and zones

Enhancing Cloud Foundry’s capabilities involved the same Continuous Delivery-based patterns employed to develop the donations applications. The platform pipeline was based on Jenkins orchestrating Cloud Foundry BOSH, with automated testing using Cucumber and RSpec, automated load testing using Grinder, and automated security testing with Zed Attack Proxy in tandem with a custom suite. The platform pipeline for Cloud Foundry then formed part of a larger integration pipeline for continuous delivery of the donations service as a whole to production-like environments. Frequent and regular deployments following extensive automated testing generated the confidence required to make any necessary changes to such a mission critical system.

Record Earnings With No Outage

So how did it actually perform on the night? Shortly after 01:30 GMT, comedian Russell Brand announced the money raised stood at £75,107,851 – passing the previous high of £74.3m. The new record was delivered by a platform that suffered absolutely no outage in receiving donations – the first time this has ever been achieved by a donations platform for Red Nose Day.

I’ve been delivering platforms for nearly fifteen years; I can’t recall ever being more excited about a new technology than I was on the day Cloud Foundry was released. I’m exceptionally proud to have taken the promise of Cloud Foundry and delivered real value in a mission-critical scenario.

About the Author: Colin Humphreys is CEO of CloudCredo, a team of people with extensive knowledge in running and customizing Cloud Foundry. He led the installation of the first Cloud Foundry to deliver SLA-driven production services, delivers tooling to the Cloud Foundry community, and is a regular conference speaker on PaaS-related topics. He also organizes the London PaaS User Group.

Scaling Real-time Apps on Cloud Foundry Using Node.js and RabbitMQ

Posted on January 31, 2013 by Raja Rao DV

In the previous blog Scaling Real-time Apps on Cloud Foundry Using Node.js and Redis, we used Redis as a ‘session store’ and also as a ‘pub-sub’ service for chat messages. But in many enterprise grade real-time apps, you may want to use RabbitMQ instead of Redis to do pub-sub because of the reliability and features that comes out-of-the-box in RabbitMQ. This is especially true for financial or Bank apps like Stock Quote apps where it is critical to protect and deliver each-and-every message AND do it as quickly as possible.

So, in this blog, we will start from Scaling Real-time Apps on Cloud Foundry Using Node.js and Redis and simply replace Redis with RabbitMQ pubsub.

The app architecture (before):

The app architecture w/ RabbitMQ (after):

Introduction to RabbitMQ

The Node.js community may not be familiar with RabbitMQ. So here are some of the high-level intro of RabbitMQ.

RabbitMQ is a message broker. It simply accepts messages from one or more endpoints “Producers” and sends it to one or more endpoints “Consumers”.

RabbitMQ is more sophisticated and flexible than just that. Depending on the configuration, it can also figure out what needs to be done when a consumer crashes(store and re-deliver message), when consumer is slow (queue messages), when there are multiple consumers (distribute work load), or even when RabbitMQ itself crashes (durable). For more please see: RabbitMQ tutorials.

RabbitMQ is also very fast & efficient. It implements Advanced Message Queuing Protocol “AMQP” that was built by and for Wall Street firms like J.P. Morgan Chase, Goldman Sachs, etc. for trading stocks and related activities. RabbitMQ is an Erlang (also well-known for concurrency & speed) implementation of that protocol.

For more please go through RabbitMQ’s website.

Fundamental pieces of RabbitMQ

RabbitMQ has 4 pieces.

Producer (“P”) – Sends messages to an exchange along with “Routing key” indicating how to route the message.
Exchange (“X”) – Receives message and Routing key from Producers and figures out what to do with the message.
Queues(“Q”) – A temporary place where the messages are stored based on Queue’s “binding key” until a consumer is ready to receive the message. Note: While a Queue physically resides inside RabbitMQ, a consumer (“C”) is the one that actually creates it by providing a “Binding Key”.
Consumer(“C”) – Subscribes to a Queue to receive messages.

Routing Key, Binding Key and types of Exchanges

To allow various work-flows like pub-sub, work queues, topics, RPC etc., RabbitMQ allows us to independently configure the type of the Exchange, Routing Key and Binding Key.

Routing Key:

A string/constraint from Producer instructing Exchange how to route the message. A Routing key looks like: “logs”, “errors.logs”, “warnings.logs” “tweets” etc.

Binding Key:

Another string/constraint added by a Consumer to a queue to which it is binding/listening to. A Binding key looks like: “logs”, “*.logs”, “#.logs” etc.

Note: In RabbitMQ, Binding keys can have “patterns” (but not Routing keys).

Types of Exchange:

Exchanges can be of 4 types:

Direct – Sends messages from producer to consumer if Routing Key and Binding key match exactly.
Fanout – Sends any message from a producer to ALL consumers (i.e ignores both routing key & binding key)
Topic – Sends a message from producer to consumer based on pattern-matching.
Headers – If more complicated routing is required beyond simple Routing key string, you can use headers exchange.

In RabbitMQ the combination of the type of Exchange, Routing Key and Binding Key make it behave completely differently. For example: A fanout Exchange ignores Routing Key and Binding Key and sends messages to all queues. A Topic Exchange sends a copy of a message to zero, one or more consumers based on RabbitMQ patterns (#, *).

Going into more details is beyond the scope of this blog, but here is another good blog that goes into more details: AMQP 0-9-1 Model Explained

Using RabbitMQ to do pub-sub in our Node.js chat app.

Now that we know some of the basics of RabbitMQ, and all the 4 pieces, let’s see how to actually use it in our Chat app.

Chat App:

Connecting to RabbitMQ and creating an Exchange

For our chat application, we will create a fanout exchange called chatExchange. And we will be using node-amqp module to talk to RabbitMQ service.

//Connect to RabbitMQ and get reference to the connection.
var rabbitConn = amqp.createConnection({});

//Create an exchange with a name 'chatExchange' and of type 'fanout'
var chatExchange;
rabbitConn.on('ready', function () {
    chatExchange = rabbitConn.exchange('chatExchange', {'type': 'fanout'});
});

Creating Producers (So Users can send chat messages)

In our chat app, users are both producers(i.e. sends chat messages to others) and also consumers (i.e. receives messages from others). Let’s focus on users being ‘producers’.

When a user sends a chat message, publish it to chatExchange w/o a Routing Key (Routing Key doesn’t matter because chatExchange is a ‘fanout’).

/**
     * When a user sends a chat message, publish it to chatExchange w/o a Routing Key (Routing Key doesn't matter
     * because chatExchange is a 'fanout').
     *
     * Notice that we are getting user's name from session.
     */
    socket.on('chat', function (data) {
        var msg = JSON.parse(data);
        var reply = {action: 'message', user: session.user, msg: msg.msg };
        chatExchange.publish('', reply);
    });

Similarly, when a user joins, publish it to chatExchange w/o Routing key.

/**
     * When a user joins, publish it to chatExchange w/o Routing key (Routing doesn't matter
     * because chatExchange is a 'fanout').
     *
     * Note: that we are getting user's name from session.
     */
    socket.on('join', function () {
        var reply = {action: 'control', user: session.user, msg: ' joined the channel' };
        chatExchange.publish('', reply);
    });

Creating Consumers (So Users can receive chat messages)

Creating consumers involves 3 steps:

Create a queue with some options.
Bind queue to exchange using some “Binding Key”
Create a subscriber (usually a callback function) to actually obtain messages sent to the queue.

For our chat app,

Let’s create a queue w/o any name. This forces RabbitMQ to create new queue for every socket.io connection w/ a new random queue name. Let’s also set exclusive flag to ensure only this consumer can access the messages from this queue.

rabbitConn.queue('', {exclusive: true}, function (q) {
 ..
 }

Then bind the queue to chatExchange with an empty ‘Binding key’ and listen to ALL messages.

q.bind('chatExchange', "");

Lastly, create a consumer (via q.subscribe) that waits for messages from RabbitMQ. And when a message comes, send it to the browser.

q.subscribe(function (message) {
   //When a message comes, send it back to browser
   socket.emit('chat', JSON.stringify(message));
 });

Putting it all together.

sessionSockets.on('connection', function (err, socket, session) {
    /**
     * When a user sends a chat message, publish it to chatExchange w/o a Routing Key (Routing Key doesn't matter
     * because chatExchange is a 'fanout').
     *
     * Notice that we are getting user's name from session.
     */
    socket.on('chat', function (data) {
        var msg = JSON.parse(data);
        var reply = {action: 'message', user: session.user, msg: msg.msg };
        chatExchange.publish('', reply);
    });

   /**
     * When a user joins, publish it to chatExchange w/o Routing key (Routing doesn't matter
     * because chatExchange is a 'fanout').
     *
     * Note: that we are getting user's name from session.
     */
    socket.on('join', function () {
        var reply = {action: 'control', user: session.user, msg: ' joined the channel' };
        chatExchange.publish('', reply);
    });


   /**
     * Initialize subscriber queue.
     * 1. First create a queue w/o any name. This forces RabbitMQ to create new queue for every socket.io connection w/ a new random queue name.
     * 2. Then bind the queue to chatExchange  w/ "#" or "" 'Binding key' and listen to ALL messages
     * 3. Lastly, create a consumer (via .subscribe) that waits for messages from RabbitMQ. And when
     * a message comes, send it to the browser.
     *
     * Note: we are creating this w/in sessionSockets.on('connection'..) to create NEW queue for every connection
   */
    rabbitConn.queue('', {exclusive: true}, function (q) {
        //Bind to chatExchange w/ "#" or "" binding key to listen to all messages.
        q.bind('chatExchange', "");

   //Subscribe When a message comes, send it back to browser
        q.subscribe(function (message) {
            socket.emit('chat', JSON.stringify(message));
        });
    });
 });

Running / Testing it on Cloud Foundry

Clone this app to rabbitpubsub folder
cd rabbitpubsub
npm install & follow the below instructions to push the app to Cloud Foundry

[~/success/git/rabbitpubsub]
> vmc push rabbitpubsub
Instances> 4       <----- Run 4 instances of the server

1: node
2: other
Framework> node

1: node
2: node06
3: node08
4: other
Runtime> 3  <---- Choose Node.js 0.8v

1: 64M
2: 128M
3: 256M
4: 512M
Memory Limit> 64M

Creating rabbitpubsub... OK

1: rabbitpubsub.cloudfoundry.com
2: none
URL> rabbitpubsub.cloudfoundry.com  <--- URL of the app (choose something unique)

Updating rabbitpubsub... OK

Create services for application?> y

1: blob 0.51
2: mongodb 2.0
3: mysql 5.1
4: postgresql 9.0
5: rabbitmq 2.4
6: redis 2.6
7: redis 2.4
8: redis 2.2
What kind?> 5 <----- Select & Add RabbitMQ 2.4v service (for pub-sub)

Name?> rabbit-e1223 <-- This is just a random name for RabbitMQ service

Creating service rabbit-e1223... OK
Binding rabbit-e1223 to rabbitpubsub... OK

Create another service?> y

1: blob 0.51
2: mongodb 2.0
3: mysql 5.1
4: postgresql 9.0
5: rabbitmq 2.4
6: redis 2.6
7: redis 2.4
8: redis 2.2
What kind?> 6 <----- Select & Add Redis 2.6v service (for session store)

Name?> redis-e9771 <-- This is just a random name for Redis service

Creating service redis-e9771... OK
Binding redis-e9771 to rabbitpubsub... OK

Bind other services to application?> n

Save configuration?> n

Uploading rabbitpubsub... OK
Starting rabbitpubsub... OK
Checking rabbitpubsub... OK

Once the server is up, open up multiple browsers and go to <servername>.cloudfoundry.com
Start chatting.

Tests

Test 1

While chatting, refresh the browser.
You should automatically be logged in.

Test 2

Open up JS debugger (On Chrome, do cmd + alt +j )
Restart the server by doing vmc restart <appname>
Once the server restarts, Socket.io should automatically reconnect
You should be able to chat after the reconnection.

That’s it for now. Hopefully this blog helps you get started with using RabbitMQ. Look forward for more Node.js and RabbitMQ related blogs. The content of this blog has also been covered in a video. Feel free to get in touch with us for questions on the material.

General Notes

Get the code right away – Github location: https://github.com/rajaraodv/rabbitpubsub.
Deploy right away – if you don’t already have a Cloud Foundry account, sign up for it here.
Check out Cloud Foundry getting started here and install the vmc Ruby command line tool to push apps.
To install the latest alpha or beta vmc tool run: sudo gem install vmc --pre.

Cloud Foundry Visits India

Posted on September 20, 2012 by Rajdeep Dua

Cloud Foundry Open Tour developer events are designed to help technologists behind the industry’s leading open Platform as a Service to meet and exchange ideas. Last week, we visited India with a huge success–about 1,100 developers attended a series of Cloud Foundry sessions and a hackathon. Developers learned about the open source Cloud Foundry Platform as a Service and how it supports multiple services, frameworks and IaaS layers.

The Cloud Foundry Open Tour is not only a developer event for professional developers; it also attracts students who ended up building some great apps in the hackathon. There were a few professors from technology schools trying to understand how Cloud Foundry fits into the larger cloud ecosystem. We also saw a healthy media presence and coverage before, during and after the event.

We were really impressed by the dedication the developers showed by arriving at 9:00 a.m. and staying on until 10:00 pm in Bangalore and Pune. The enthusiasm was also evident in the overwhelming number of requests to participate in the morning sessions and evening hackathon, even after the seats had sold out.

The five session speakers, who came from various geographies including the US, Singapore and India, deserve a big thank you. From VMware were Chris Richardson, Josh Long, Raja Rao and Rajdeep Dua. Guest speakers included Hugues Malphettes, Senior Software Architect at Intalio, and industry spokeserson Janakiram MSV.

What We Covered

Morning Sessions
We started the morning sessions with keynote delivered by Niranjan Maka and Chris Richardson. Niranjan covered the VMware product strategy and portfolio, and the concept of the software-defined data center. Chris’s talk focused on the history of Cloud Foundry and various aspects of open source PaaS. This was following by a very well-received Node.js session by Raja Rao. Josh covered the Spring framework and Spring integration with Cloud Foundry.

Chris came back on stage to do his architecture session on decomposing apps for scalability. After lunch, Hugues from Intalio showcased Intalio|Create, which is an innovative way of building business applications. It is built using Cloud Foundry and can be deployed on public as well as private clouds. Rajdeep had a session on the Play Framework and its support in Cloud Foundry. The morning session was wrapped up with Janakiram’s talk on deploying .NET applications on Iron Foundry. Developers responded very favorably to the choice of frameworks available with Cloud Foundry.

We wrapped up the morning session and doing an iPhone 4S raffle for the attendees.

Evening Hackathon
The evening hackathon started with an hour-long boot camp on how to get started with Cloud Foundry using vmc and the Spring Source Tool Suite (STS). This was run in a similar manner in Bangalore and Pune.

Participants pushed over 185 Hello World apps to win t-shirts. This was significant because just a few hours back these same developers were totally new to Cloud Foundry and now they were pushing their applications.

Boot camp was followed by a two-hour hackathon where developers formed teams, hacked over their ideas and published a total of 19 apps to cloudfoundry.com.

Hackathon Winners

The winner in Bangalore was a group of students from P.E.S. Institute of Technology who built a GRE test helper app. This app sends an SMS to a number for an English word. Then the app talks to a Word Link service and returns English word’s definition.

Winners in Pune built an online exam results portal using Ruby on Rails. Another runner-up built a social sentiment analysis service using Spring MVC, Neo4j and Twitter4J. Another winner built a chat application.

Quotes from Bloggers and Attendees

A developer conference’s pulse can be gauged from what audience has to say or write about it.
Cloudstory.in: “The best thing of the event was the Hackathon that was scheduled in the evening. In both the cities the developers stayed till late evening to deploy live applications on cloudfoundry.com and appfog.com. It was exciting to see hundreds of developers coding away in their favorite language and deploying the application on a platform that they experienced only a few hours ago. That only shows how simple it is to get started on Cloud Foundry.”
One of the developer attendees said: “Just wanted to send a THANK YOU and tell you how much I enjoyed the Cloud Foundry Pune Open Tour 2012. You people did a great job in putting it all together and I especially enjoyed my first ever hackathon. It was indeed great experience.”

Presentation Slides

Slides for the talks can be found at the following links:

The Open Tour Continues

It was a great experience interacting with developers in Pune and Bangalore, helping them learn about Cloud Foundry. Since the Cloud Foundry Open Tour 2012 is a global series of one day developer events, stay tuned for more announcements on new dates and locations.

Rajdeep Dua, the Cloud Foundry Developer Relations Team

Cloud Foundry Integration for Eclipse Now Supports Tunneling to Services

Posted on July 31, 2012 by Nieraj Singh

Today we announce a new release of Cloud Foundry Integration for Eclipse which features the ability to open a tunnel to any Cloud Foundry data service. Now Eclipse users can use familiar client applications to directly analyze, manipulate, or port the data contained in their Cloud Foundry applications.

The Cloud Foundry Data Tunneling service can be created from the Services table in the Cloud Foundry Eclipse server editor. The new integration (version 1.1.0) allows users to create data tunneling (also known as ‘Caldecott‘) from within Eclipse Indigo JEE or SpringSource Tool Suite (STS) version 2.9.0 or higher.

Follow the documented instructions to install the Cloud Foundry Integration for Eclipse. If you had previously installed the Cloud Foundry plugin in Eclipse or STS, the update will be automatically detected or you can manually check for updates in the IDE.

Creating a Tunnel

You can create a tunnel to connect to any running service in your Cloud Foundry account. Go to the Applications tab in the Cloud Foundry Server view. There is a listing of existing services under the Services section. Creating a tunnel is performed by simply right-clicking on a service in the table and selecting “Open Caldecott Tunnel” menu action:

This will automatically publish a tunneling application to your account, if one isn’t already published, and start or restart the application as necessary. This tunneling application will appear in the list of published applications as Caldecott. Cloud Foundry will also automatically bind the selected service to the Caldecott application prior to opening a tunnel.

The process of creating a tunnel requires services to be bound to the tunneling application. Cloud Foundry will automatically stop a running Caldecott application, bind the service, and restart the application to create the tunnel. Therefore, existing tunnels may be closed when a new tunnel is created, if the desired service was not previously bound to the tunneling application. Multiple tunnels can be opened to different services in your account at the same time, as long as all the related services are already bound to the Caldecott application prior to creating the data tunnels.

In general, any operation that requires the tunneling application to be stopped, restarted or removed will result in all existing tunnels being disconnected. Manually unbinding a service from the Caldecott application through the Services table will also result in the associated tunnel being disconnected.

Once a tunnel is successfully created, a dialogue will open displaying the data service tunnel information necessary to use a tool like the Eclipse Data Source Explorer to connect to a data service in a Cloud Foundry server. The information displayed includes a username, password, and local port number:

As URLs are needed for database connections in tools like the Eclipse Data Source Explorer, they are automatically constructed for certain data services like MySQL and PostgreSQL. That way, users do not need to manually construct them when creating a database connection.

Right-clicking on the tunnel entry in the tunnel dialogue will display several context menu actions to copy field values to the clipboard. The menu action to copy the URL appears if the service is of MySQL or PostgreSQL type:

Managing Tunnels

Once a tunnel is opened, it can be managed from the Services table in the Cloud Foundry server editor. A sortable “Tunnel” column indicates which services have an open tunnel:

Right-clicking on a service allows users to either disconnect the tunnel or show the tunnel information.

Data tunnels can also be managed in the Servers view by right-clicking on a server instance and options will be presented to manage individual tunnels via wizard flow or disconnecting all existing tunnels:

These Servers view context menu actions are only displayed if the server has at least one active tunnel.

Creating Database Connections

Using the service tunnel information, database connections can then be created with the Eclipse Data Source Explorer, which is available by default in STS and Eclipse Indigo JEE installations:

Once a database connection is established, the database can be accessed through the Data Source Explorer:

To disconnect the tunnel, all data service connections must be disconnected. Therefore, active data service connections created by tools, such as the Data Source Explorer, must be terminated prior to disconnecting the tunnel from the Services table.

Cloud Foundry Integration for Eclipse 1.1.0 can be installed or updated from the official update site:

http://dist.springsource.com/release/TOOLS/cloudfoundry/

- The Cloud Foundry Team

Don’t have a Cloud Foundry account yet? Signup for free today

RabbitMQ + Cloud Foundry: Cloud Messaging that Just Works

Posted on August 9, 2011 by Cloud Foundry

Cloud Foundry™ is the industry’s first open platform as a service. Providing a choice of developer frameworks, application services and deployment clouds, Cloud Foundry simplifies application development and makes it faster and easier to build, test, deploy and scale applications. Cloud Foundry already supports multiple application services including MySQL, MongoDB and Redis. And we are working to add more.

Today, we are pleased to announce an important milestone: the RabbitMQ messaging service, available today as a free public beta. You can get started right away: on CloudFoundry.com, you will find sample applications and guides. If you create a cool application, please let us know and we’ll link to it. And if you get stuck, tell us what we need to get right.

Our goal is to make it as easy as possible for you to use messaging to create and connect to cloud applications. This radically simpler portability of applications and integration of services is the essence of Cloud Foundry. To understand what this means for messaging as a service, let’s look at how people use RabbitMQ in the cloud and then see why we think offering RabbitMQ as a service makes sense.

Messaging for the cloud

In the cloud, communication is the design center.

Messaging is fundamentally a communication technology and therefore a cloud enabler. People talk about “event streams” and “task queues” but the core pattern is “moving a lot of data reliably”. Cloud applications that involve multiple processes or VMs can benefit from a communication centric design. Take a look at this blog post from Union Station for example, and notice that their architecture is not a ‘stack’ but a ‘network’. Or have a look at Google’s design for their Rocksteady monitoring and analytics system.

You can see this in any development meeting. Increasingly people who build applications ask “how do these components wire together?” and “what’s my event model?” where they used to ask “what’s my database schema and what’s my language platform”. This was always true for “enterprise integration” but now these patterns are needed even for new applications. The applications that are leading the way are also some of the biggest, e.g. near real-time data analytics and activity streams on global scale social and mobile enabled apps. The shift to these design patterns is driving adoption of streaming data services and event based technologies like messaging.

Messaging is essential for successful cloud applications for two reasons.

First, messaging provides stable communication patterns that scale across multiple network topologies. In the cloud it is critical for applications to cope when networks change or grow. This means that the constituent components of cloud applications cannot be coupled directly. Instead, asynchronous decoupling and indirection based on message brokers is used. These two patterns enable work to be addressed, routed and delivered between components. Those components may be running in one cloud, or several, or on multiple devices e.g. phones. RabbitMQ has a proven track record of moving a lot of data reliably in these scenarios at scale.

Second, because those components are likely to be written in multiple programming languages, it is necessary that communication be “polyglot” and therefore “data centric”. Because of this, people look for a scalable and stable data fabric or communication backbone that can cope with a wide range of client languages, broadcast and load patterns. Messaging systems are designed to be robust with respect to arbitrary traffic conditions, e.g. reliably paging data to disk when consumers go offline. Again, RabbitMQ has the required breadth to deliver on this requirement.

Here are some benefits for cloud applications:

Maintainability: messaging lets you more easily maintain your application without impacting uptime. Decoupling components reduces complexity and simplifies integration. Moreover logging, alerts, reporting and management benefit from a messaging based design.
Scalability: you can improve responsiveness in applications. For instance, messaging lets you separate factor time-consuming processing tasks out of web-facing applications and into a separate tier of worker instances. In addition you can add more of these workers and back end services to achieve scale.
Efficiency: messaging pushes data to users, devices and applications, which is much more efficient than using a database to share information between applications and continually querying for changes. In the cloud, polling is aggravated by variable latency. Pushing data when it changes is more effective.
Robustness: in the cloud, not all components are connected or online at all times. Messaging lets you queue up data for subsequent consumption without fear of losing your data.

What’s next? Simple, Effective Cloud Messaging

Arguably, the success of RabbitMQ thus far has been due to providing a convenient and trustworthy way to get the benefits above, across lots of languages, and with a simple open source license. And certainly this is visible ‘in the cloud’ where RabbitMQ is a top choice both on the main clouds and running some of them under the hood too. One example is NASA’s Nebula cloud, but there are many more.

But there’s one problem – in the age of ‘IT as a service’, not everyone wants to install and look after their own RabbitMQ server. Wouldn’t it be great if management, maintenance, upgrades, rollbacks and all the other potential hindrances to scaling a business… just were taken care of by someone else? In 2011 all this seems obvious and logical to people across all kinds of infrastructure – including customers’ own hardware, behind their own security perimeter.

The self-service experience is quite natural for messaging, and requests like “I just want a dev queue” or “spin me up ten instances of rabbit” should be part of the cloud. And that means part of the PaaS. So the first step is to provide RabbitMQ as a service for CloudFoundry.com.

Get Started

Cloud Foundry.com makes it easy to begin using RabbitMQ. If you don’t have a CloudFoundry.com account yet, signup for free today.

In Cloud Foundry, the RabbitMQ server is a service on par with MySQL, MongoDB, and Redis. For instance, you use standard Cloud Foundry vmc commands to create, bind, unbind, clone, and delete RabbitMQ services.

To learn more about using RabbitMQ on Cloud Foundry, you can use the following resources:

Ruby on Rails tutorial, sample application, and suitable RabbitMQ Ruby client (ruby gem)
Java Spring tutorial 1, tutorial 2, sample application, and AMQP client for Spring
Ruby Sinatra sample application and suitable RabbitMQ Ruby client (ruby gem)
Node.js tutorial, sample application and AMQP client
Grails tutorial 1, tutorial 2, tutorial 3
Additional sample applications
RabbitMQ service FAQ

These applications should get you started but you can implement other patterns too. For example, you can use the RabbitMQ service to integrate distinct applications running on Cloud Foundry, even applications built using different languages and frameworks. Or perhaps you could wire RabbitMQ up with another service such as MongoDB. We want people to test the limit of what is possible so that we can stretch it.

The RabbitMQ service lets you implement a full set of essential cloud messaging patterns:

Work queues that distribute time-consuming tasks among multiple workers, in order to avoid doing a resource-intensive task immediately and having to wait for it to complete. Work queues let you schedule the task to be done later. This pattern is especially useful in web applications where it’s impossible to handle a complex task during a short HTTP request window. See for example the Celery project.
Publish/Subscribe to distribute messages to multiple consumers. This greatly simplifies integration and improves maintainability, since message producers and message consumers don’t need to know about each other. Publishers simply send their messages to an exchange (part of RabbitMQ server), which then looks at properties of the messages to distribute them to the appropriate queues, which are then read by one or more consumers.
Routing, to enables message consumers to subscribe only to a subset of the messages.
Topics, to do routing based on multiple criteria.
Remote Procedure Call (RPC), enabling a software application to run a function on a remote computer and wait for the result.

These core patterns are described in our online tutorials for RabbitMQ and in the Manning book “RabbitMQ in Action”. For a short introduction to the RabbitMQ AMQP messaging model see here.

If you don’t already have a CloudFoundry.com account, signup here (it’s free).

Background, Pricing and Availability

The RabbitMQ service is now available on www.CloudFoundry.com as a free public beta. It is currently implemented using RabbitMQ server 2.4.1, and can be used by all languages and frameworks that are supported by Cloud Foundry and that have an AMQP 0-8 or 0-9-1 client available, including Ruby on Rails, Ruby Sinatra, Spring Java, and node.js.

RabbitMQ on Cloud Foundry is a cloud-based message broker. This is a type of server software that is used to integrate distinct software systems, by sending and receiving data (in the form of messages) between those systems. These systems can be components of the same application, or part of distinct applications, and can reside on the same machine (physical or virtual), on different machines in the same datacenter, or can be physically remote.

RabbitMQ stands out among message brokers for several reasons. RabbitMQ scales and is extremely easy for developers to use. As the leading implementation of AMQP, an open-standard messaging protocol, RabbitMQ works with dozens of languages and frameworks that support the Advanced Message Queuing Protocol (AMQP), enabling developers to integrate applications built with completely different technologies, such as a Ruby application that needs to connect to a Java app. These capabilities – performance, usability, and ease of integration — have helped RabbitMQ become a leading choice, growing its popularity to the point where it is included as a standard message broker for major Linux distributions including Ubuntu, Fedora and Debian.

Please try the RabbitMQ service on Cloud Foundry and let us know how we can improve the experience by asking us questions or posting feature requests in our community forums.

Cloud Foundry Open PaaS Deep Dive

Posted on April 19, 2011 by Cloud Foundry

by Ezra Zygmuntowicz (aka @ezmobius)

You are probably wondering about how Cloud Foundry actually works, hopefully these details will clear things up for you about how Cloud Foundry the OSS project works, why it works, and how you can use it. Cloud Foundry is on github here: https://github.com/cloudfoundry/vcap. The VCAP repo is the meaty part or what we call the “kernel” of Cloud Foundry as it is the distributed system that contains all the functionality of the PaaS. We have released a VCAP setup script that will help you get an Ubuntu 10.04 system running a instance of Cloud Foundry including all the components of VCAP as well as a few services (mysql, redis, mongodb) up and running so you can play along at home.

We want to build a community around Cloud Foundry, as that is what matters most for now as far as the open source project. We imagine a whole ecosystem of “userland” tools that people can create and plug into our Cloud Foundry kernel to add value and customize for any particular situation. This project is so large in scope that we had to cut a release and get community involvement at some point and we feel that the kernel is in great shape for everyone to dig in and start helping us shape the future of the “linux kernel for the cloud” ;)

So how do you approach building a PaaS (Platform as a Service) that is capable of running multiple languages under a common deployment and scalability idiom, that is also capable of running on any cloud or any hardware that you can run Ubuntu on? VCAP was architected by my true rock star coworker Derek Collison (this guys is the man, for realz!). The design is very nice and adheres to a main core concept of “the closer to the center of the system the dumber the code should be”. Distributed systems are fundamentally hard problems. So each component that cooperates to form the entire system should be as simple as it possibly can be and still do its job properly.

VCAP is broken down into 5 main components plus a message bus: The Cloud Controller, the Health Manager, the Router’s, the DEAs (Droplet Execution Agents) and a set of Services. Let’s take a closer look at each component in turn and see how they fit together to form a full platform or for the cloud. NATS is a very simple pub/sub messaging system written by Derek Collison (this dude knows messaging, trust me;) of TIBCO fame. NATS is the system that all the internal components communicate on. While NATS is great for this sort of system communication, you would never use NATS for application level messaging. VMware’s own RabbitMQ is awesome for app level messaging and we plan to make that available to Cloud Foundry users in the near future.

It should be stated here that every component in this system is horizontally scalable and self healing, meaning you can add as many copies of each component as needed in order to support the load of your cloud, and in any order. Since everything is decoupled, it doesn’t even really matter where each component lives, things could be spread across the world for all it cares. I think this is pretty cool ;)

Cloud Controller

The Cloud Controller is the main ‘brain’ of the system. This is an Async Rails3 app that uses ruby 1.9.2 and fibers plus eventmachine to be fully async, pretty cutting edge stuff. You can find the Cloud Controller here: https://github.com/cloudfoundry/vcap/tree/master/cloud_controller . This component exposes the main REST interface that the CLI tool “vmc” talks to as well as the STS plugin for eclipse. If you were so inclined you could write your own client that talks to the REST endpoints exposed by the Cloud Controller to talk to VCAP in whatever way you like. But this should not be necessary as the “vmc” CLI has been written with scriptability in mind. It will return proper exit codes as well as JSON if you so desire so you can fully script it with bash or Ruby, Python, etc.

We made a decision not to tie VCAP to git even though we love git, we need to support any source code control system, yet we want the simplicity of a git push style deployment, hence the vmc push. But we also do want to have the differential deploys, meaning that we want to push diffs when you update your app, we do not want to have to push your entire app tree every time you deploy. Feeling light and fast is important to us. Our goal is to rival local development.

So we designed a system where we can get the best of both worlds. You as a user can use any source control system you want, when you do a vmc push or vmc update we will examine your app’s directory tree and send a “skeleton fingerprint” to the cloud controller. This is basically a fingerprint of each file in your apps tree and the shape of your directory tree. The cloud controller keeps these in a shared pool, accessible via their fingerprint plus the size for every object it ever sees. Then it returns to the client a manifest of what files it already has and what files it needs your client to send to the cloud in order to have all of your app. It is a sort of ‘dedupe’ for app code as well as framework and rubygem code and other dependency code. Then your client only sends the objects that the cloud requires in order to create a full “Droplet” (a droplet is a tarball of all your app code plus its dependencies all wrapped up into a droplet with a start and stop button) of your application.

Once the Cloud Controller has all the ‘bits’ it needs to fully assemble your app, it pushes the app into the “staging pipeline”. Staging is what we call the process that assembles your app into a droplet by getting all the full objects that comprise your applications plus all of its dependencies, rewrites its config files in order to point to the proper services that you have bound to your application and then creates a tarball with some wrapper scripts called start and stop.

DEA

The Droplet Execution Agent can be found here: https://github.com/cloudfoundry/vcap/tree/master/dea . This is an agent that is run on each node in the grid that actually runs the applications. So in any particular cloud build of Cloud Foundry, you will have more DEA nodes then any other type of node in a typical setup. Each DEA can be configured to advertise a different capacity and different runtime set, so you do not need all your DEA nodes to be the same size or be able to run the same applications. So continuing on from our Cloud Controller story, the CC has asked for help running a droplet by broadcasting on the bus that it has a droplet that needs to be run. This droplet has some meta data attached to it like what runtime it needs as well as how much RAM it needs. Runtimes are the base component needed to run your app, like ruby-1.8.7 or ruby-1.9.2, or java6, or node. When a DEA gets one of these messages he checks to make sure he can fulfill the request and if he can he responds back to the Cloud Controller that he is willing to help.

The DEA does not necessarily care what language an app is written in. All it sees are droplets. A droplet is a simple wrapper around an application that takes one input, the port number to serve HTTP requests on. And it also has 2 buttons, start and stop. So the DEA treats droplets as black boxes, when it receives a new droplet to run, all it does it tells it what port to bind to and runs the start script. A droplet again is just a tarball of your application, wrapped up in a start/stop script and with all your config files like database.yml rewritten in order to bind to the proper database. Now we can’t rewrite configs for every type of service so for some services like Redis or Mongodb you will need to grab your configuration info from the environment variable ENV[‘VCAP_SERVICES’].

In fact there is a bunch of juicy info in the ENV of your application container. If you create a directory on your laptop and make a file in it called env.rb like this:

$ mkdir env && cd env 
$ cat «EOF > envvars.rb 
require ‘sinatra’ 
require ‘pp’ 
get ‘/’ do   
  “#{ENV.pretty_inspect}”
end 
EOF
$ vmc push …

That will make a simple app that will show you what is available in your ENVIRONMENT so that you can see what to use to configure your application. If you visit this new app you will see something like this: ENV output.

So the DEA’s job is almost done, once it tells the droplet what port to listen on for HTTP requests and runs it’s start script, and the app properly binds the correct port, it will broadcast on the bus the location of the new application so the Routers can know about it. If the app did not start successfully it will return log messages to the vmc client that tried to push this app telling the user why their app didn’t start (hopefully). This leads us right into what the Router has to do in the system so we will hand it over to the Router (applause).

Router

The Router is another eventmachine daemon that does what you would think it does, it routes requests. In a larger production setup there is a pool of Routers load balanced behind Nginx (or some other load balancer or http cache/balancer). These routers listen on the bus for notifications from the DEA’s about new apps coming online and apps going offline etc. When they get a realtime update they will update their in-memory routing table that they consult in order to properly route requests. So a request coming into the system goes through Nginx, or some other HTTP termination endpoint, which then load balances across a pool of identical Routers. One of the routers will pick up the phone to answer the request, it will start inspecting the headers of the request just enough to find the Host: header so it can pick out the name of the application this request is headed for. It will then do a basic hash lookup in the routing table to find a list of potential backends that represent this particular application. These look like: {‘foo.cloudfoundry.com’ => [‘10.10.42.1:5897’, ‘10.10.42.3:61378’, etc]}

So once it has looked up the list of currently running instances of the app represented by ‘foo.cloudfoundry.com’ it will pick a random backend to send the request to. So the router chooses one backend instance and forwards the request to that app instance. Responses are also inspected at the header level for injection if need be for functionality such as sticky sessions.

The Router can retry another backend if the one it chose fails and there are many ways to customize this behavior if you have your own instance of Cloud Foundry setup somewhere. Routers are fairly straightforward in what they do and how they do it. They are eventmachine based and run on ruby-1.9.2 so they are fast and can handle quite a bit of traffic per instance, but like every other component in the system, they are horizontally scalable and you can add more as needed in order to scale up bigger and bigger. The system is architected in such a way that this can even be done on a running system.

Health Manager

The Health Manager is a standalone daemon that has a copy of the same models the Cloud Controller has and can currently see into the same database as the Cloud Controller. This daemon has an interval where it wakes up and scans the database of the Cloud Controller to see what the state of the world “should be”, then it actually goes out into the world and inspects the real state to make sure it matches. If there are things that do not match then it will initiate messages back to the Cloud Controller to correct this. This is how we handle the loss of an application or even a DEA node per say. If an application goes down, the Health Manager will notice and will quickly remedy the situation by signaling the Cloud Controller to star a new instance. If a DEA node completely fails, the app instances running there will be redistributed back out across the grid of remaining DEA nodes.

Services

These are the services your application can choose to use and bind to in order to get data, messaging, caching and other services. This is currently where redis and mysql run and will eventually become a huge ecosystem of services offered by VMware and anyone else who wants to offer their service into our cloud. One of the cool things I will highlight is that you can share service instances between your different apps deployed onto a VCAP system. Meaning you could have a core java Spring app with a bunch of satellite sinatra apps communicating via redis or a RabbitMQ message bus. Ok my fingers are tired and my shoulder hurts so I am going to call this first post done. I plan on blogging a lot more often as well as trying to help organize the community around Cloud Foundry the open source project. I hope you are as excited as I am by this project, it is basically like “rack for frameworks, clouds and services” rather then just ruby frameworks. Pluggable across the 3 different axis and well tested and well coded. This thing is very cool and I am very proud just to be a member of the team working on this thing. This has been a huge team effort to get out the door and we hope it will become a huge community effort to keep driving it forward to truly make it “The Linux Kernel of Cloud Operating Systems”. Will you please join the community with me and help build this thing out to meet its true potential?