Today i spent a short bit of time experimenting with VMware Cloud Foundry, VMware's new (beta) PaaS (Platform as a Service) offering. Cloud Foundry is solidly based upon the concept of being "open" in many respects: open source (available on Github here), open with respect to supporting a variety of frameworks, languages, and databases, and open with respect to being able to run in a variety of cloud and virtualization environments.
My initial experimentation was aimed at seeing just how fast I could get a couple of different types of trivial applications up and running on Cloud Foundry. In short, the answer is:
<!--break-->
Moments. That's right, moments! With very scant documentation (a small "getting started" doc, and some command line "help"), getting applications deployed on Cloud Foundry is very simple.
Deploying a Ruby web application (using Sinatra) was as simple as moving the source code into a directory by itself, changing to that directory and typeing:
vmc push
The following took several seconds (including answering few questions):
Would you like to deploy from the current directory? [Yn]: Y
Application Name: rbapp1
Application Deployed URL: 'rbapp1.cloudfoundry.com'? y
Detected a Sinatra Application, is this correct? [Yn]: Y
Creating Application: OK
Would you like to bind any services to 'rbapp1'? [yN]:
Uploading Application:
Checking for available resources: OK
Packing application: OK
Uploading (0K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK
And there it was....my first application running on Cloud Foundry! As simple as that! There was no XML to write, no complex interface to figure out, no manual set-up of keys, their simple command line utility (vmc) does all the work for you. Deleting the application was as simple as typing:
vmc delete rbapp1
My next experiment was to validate the claim that Groovy/Grails applications could also be easily deployed to Cloud Foundry. I've been working in Grails quite a bit lately, so I just happened to have a working project lying around. I packaged it up as a WAR file, changed directory to my projects "target" directory, and once again typed:
vmc push
I was rewarded a few seconds later with:
Would you like to deploy from the current directory? [Yn]: Y
Application Name: grailsapp1
Application Deployed URL: 'grailsapp1.cloudfoundry.com'? y
Detected a Java SpringSource Grails Application, is this correct? [Yn]: Y
Creating Application: OK
Would you like to bind any services to 'grailsapp1'? [yN]:
Uploading Application:
Checking for available resources: OK
Processing resources: OK
Packing application: OK
Uploading (4K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK
And as simply as before, my Grails application was running on Cloud Foundry. The vmc command provides options for updating an application, mapping and unmapping URLs, changing memory resevations, scaling instances, starting, stopping and restarting applications, as well as getting logs, seeing resource utilization, and also a bunch of commands to manipulate "services."
I really appreciated the fact that there was a single short command with a bunch of subcommands. Amazon's command line tools are tedious, and unnecessarily long, not uniform, filled with ugly dashes and just not tremendously intuitive. vmc just makes sense. Even command line interfaces can benefit from thoughtful design.
Realizing this is beta, there were a few "nits." The most annoying being that there seems to be little written documentation readily available. There appear to many instructional videos available, but as that's a very inefficient learning mechanism (for me, at least) I decide to take the plunge without the benefit of watching any of them. I'm pretty confident this will be resolved by the time Cloud Foundry is out of beta.
More along the lines of a "feature-request" than a problem is that many subcommands of vmc try to present information in a "pretty" human-readable format. For example, vmc list, which lists currently deployed applications returns output that looks like this:
+-------------+----+---------+-----------------------------+----------+
| Application | # | Health | URLS | Services |
+-------------+----+---------+-----------------------------+----------+
| grailsapp1 | 1 | RUNNING | grailsapp1.cloudfoundry.com | |
| rbapp1 | 1 | RUNNING | rbapp1.cloudfoundry.com | |
+-------------+----+---------+-----------------------------+----------+
Reasonably nice to look at, but unnecessarily painful to parse for use within a script. My "feature-request" would be that they'd provide a --simple flag to enable a more parser friendly version (CSV list? Colon separated values, etc).
I tried to play a bit with "services." Currently, vmc provides the ability to provision MongoDB, MySQL, and Redis. MySQL and Redis seem to provision correctly, while provisioning MongoDB consistently returned an error. I don't know whether the error was due to a temporary service failure, or whether MongoDB is simply not ready yet. I will explore these further over the next few days, especially MongoDB as I find myself using it in more and more projects lately.
The applications I deployed were extremely trivial. They were not meant to exercise performance or scalability of Cloud Foundry. In fact, there's much more functionality for me to explore. My initial experiments were really aimed at checking out how easy it is to get started with and deploy on CloudFoundry. My conclusions are: It's great stuff! It's a rich environment. It doesn't force you to know anything about the specifics of CloudFoundry to code for it. It's open. Both applications I ran on Cloud Foundry were originally developed to run in other environments. In short, Cloud Foundry really delivers on the key true promise of a PaaS: it just works, enabling developers to focus on writing great applications.
Welcome to my place!