Many developers create distributed applications that have workers to perform specific functions and communicate via a data or messaging system, such as those developed with Spring Batch, Spring Integration, Resque, or Delayed Job. Now Cloud Foundry supports running these worker components by allowing you to push a directory or single file without choosing a pre-defined framework. Simply provide the command required to run your script or executable, chose a runtime, and you’re done. Besides background processing functions, the standalone application support enables these other types of applications as well:

1. Container-less non-Servlet applications, such as those developed with Netty or Grizzly
2. Web apps that run with their own bundled containers, such as Jetty

In this blog series, we will walk through several example deployments of standalone apps. We will start with a simple Hello World to illustrate the deployment steps. In future posts, we will show examples of worker apps, distributed apps, and bring-your-own-container and container-less Web apps. While the apps may vary in use case and implementation, the deployment procedure remains the same.

All of these apps are meant to be long-running, as with any other app on Cloud Foundry (meaning they can be scaled, will be monitored for health, restarted if crashed, etc.). We do not yet have support for short-lived background tasks or scheduled tasks. However, we encourage you to keep watching this space!

Getting Started with Standalone Apps on Cloud Foundry

First, install or update your Cloud Foundry command line tool (‘VMC’) to the latest version using the following command:

gem install vmc

You can verify that you got the right version using:

vmc -v

which should show the version to be 0.3.17 or higher.

Let’s start by deploying a simple Hello World Ruby application.

mycomp:$ cd simple-ruby-app
mycomp:$ ls
hello-world.rb
mycomp:$ more hello-world.rb
loop {
  puts 'Hello world'
  sleep 5
}

Since we need a long-running application, this script will print “Hello World” every 5 seconds until stopped. Let’s push this to Cloud Foundry using vmc:

mycomp:$ vmc push helloworld
Would you like to deploy from the current directory? [Yn]:
Detected a Standalone Application, is this correct? [Yn]:
1: java
2: node
3: node06
4: ruby18
5: ruby19
Select Runtime [ruby18]:
Selected ruby18
Start Command: ruby hello-world.rb
Application Deployed URL [None]:
Memory reservation (128M, 256M, 512M, 1G, 2G) [128M]:
How many instances? [1]:
Create services to bind to 'helloworld'? [yN]:
Would you like to save this configuration? [yN]: y
Manifest written to manifest.yml.
Creating Application: OK
Uploading Application:
Checking for available resources: OK
Packing application: OK
Uploading (1K): OK
Push Status: OK
Staging Application 'helloworld': OK
Starting Application 'helloworld': OK

So, what just happened?
1. vmc detected that the app was a “Standalone Application” (due to the fact that no other Framework support was detected).
2. We were asked to provide a runtime. Since the app needs Ruby to run, we chose the “ruby18″ runtime (which vmc detected as default).
3. We provided a command to use for starting the application. Since we’ve chosen a Ruby 1.8 runtime, we don’t need to provide the fully qualified path to Ruby. Cloud Foundry will automatically add Ruby 1.8 to the application’s path.
4. We chose “None” for the application URL. This will run the application without a Web port or URL. There are times when we will want a URL and Web port for a standalone application, as we’ll see in a later blog post.
5. vmc pushed the entire contents of the working directory to Cloud Foundry. Since we only had hello-world.rb in the directory, we could have also executed “vmc push –path ./hello-world.rb”. The –path option comes in handy when working with distribution zip files, as we’ll see in an upcoming post.

Let’s have a look at the application’s logs:

mycomp:$  vmc logs helloworld
====> /logs/stdout.log <====

Hello world
Hello world

As you can see, helloworld can be managed just like any other Cloud Foundry application:

mycomp:$  vmc instances helloworld +2
Scaling Application instances up to 3: OK
mycomp:$ vmc instances helloworld

+-------+---------+--------------------+
| Index | State   | Start Time         |
+-------+---------+--------------------+
| 0     | RUNNING | 04/20/2012 04:47PM |
| 1     | RUNNING | 04/20/2012 04:48PM |
| 2     | RUNNING | 04/20/2012 04:48PM |
+-------+---------+--------------------+

Let’s look at the logs again for two of the instances:

mycomp:$  vmc logs helloworld --instance 0
====> /logs/stdout.log <====
Hello world
Hello world

mycomp:$  vmc logs helloworld --instance 1
====> /logs/stdout.log <====
Hello world
Hello world

Standalone app deployment manifest

Let’s take a look at the manifest file we generated with that vmc push:

mycomp:$ more manifest.yml
---
applications:
.:
name: helloworld
framework:
  name: standalone
  info:
     description: Standalone Application
     mem: 128M
runtime: ruby18
command: ruby hello-world.rb
url:
mem: 128M
instances: 1

Seems pretty straightforward. The app is deployed against a “standalone” framework, with a command and ruby18 runtime. To save time, we’ll be sure to save this manifest file for future deployments.

Tips and Tricks

You should now be able to deploy any long-running app that you can package, using any of Cloud Foundry’s provided runtimes. However, there are some tips and tricks to getting the best experience from Cloud Foundry:

1. Use the VCAP_APP_PORT environment variable if your application requires a web port.
2. Connect your application to Cloud Foundry services using provided libraries (see below) or the VCAP_SERVICES environment variable (value is in JSON).

JVM Applications

1. Package your application using a build plugin that creates a distribution zip file or directory.
Maven Appassembler, Gradle Application Plugin, and SBT package-dist are good plugins for creating a distribution, and we’ll show examples of all of these in future posts. It is best not to package your entire application in a single jar file, as you will not be able to take advantage of Cloud Foundry’s incremental upload capability.
2. Always include $JAVA_OPTS in your Java start commands.
When you select your application’s memory reservation through VMC, Cloud Foundry will set the JAVA_OPTS environment variable with corresponding min and max heap sizes, therefore you should include $JAVA_OPTS in your Java start commands (for example, “java $JAVA_OPTS -jar main.jar”). The start scripts generated by Maven Appassembler and Gradle Application Plugin already include JAVA_OPTS. Using JAVA_OPTS will also allow you to start your app in debug mode on local clouds, using “vmc start –debug.”
3. Use the cloudfoundry-runtime library to connect your application to Cloud Foundry services.

Ruby Applications

1. Always include a Gemfile.lock to ensure that all application dependencies are resolved by Cloud Foundry.
2. While not required, we recommend running “bundle package” before deploying your application. This will improve your application start time, as Cloud Foundry will not need to check its cache or download gems from rubygems.org.
3. Standalone Ruby applications can take advantage of Ruby Auto-Reconfiguration.  To make your own connections to Cloud Foundry services, use the cf-runtime gem.

Conclusion

In this post, we used a simple example to get up and running quickly with standalone apps on Cloud Foundry. In the next installments of this four part series, we will have an in-depth look at deploying more complex standalone apps.

Also in this series:

• Running Workers on Cloud Foundry with Spring
• Running Resque Workers on Cloud Foundry
• Running Standalone Web Applications on Cloud Foundry

- Jennifer Hickey
The Cloud Foundry Team

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

The first two stops of Cloud Foundry Open Tour at Beijing and Shanghai were huge successes! We had about 1000+ developers show up at each city for this one day event. 10 speakers from across the world delivered 15 high quality and deeply technical sessions to attendees.

Open Tour is not only a developers’ grand gathering to learn about Cloud Foundry, it’s also for partner executives and university professors to share their success story on Cloud Foundry, and online media to live broadcast the event and interview speakers.

Developers in China are extremely passionate about Cloud Foundry: attendees showed up at the venue before 7AM (for a conference that starts at 9AM); people were lining up for registration at 7:30AM. This phenomenon has only happened before at the Apple Store. There were developers flying to Beijing and Shanghai from south and west side of China just for this event, and every single session at the conference was standing room only.

Big THANKS to our team of speakers: Charlotte Yarkoni, Mark Lucovsky, Patrick Chanezon, Chris Richardson, Alan Ren, Victor Jieh, Stephen Hu, Bill Sun, Figo Feng and Long Wang from the Cloud Foundry global and China team! Our great appreciation and many thanks to all partner speakers: Lei Cong from Sina App Enginee, Tuoc Luong from SNDA Grand Cloud, and Guoxiong Dai from InGeek Cloud.

Staying ‘Till the End’

No developer left the conference before it was over. We had two keynotes delivered by Mark Lucovsky and Chris Richardson in the morning – Cloud Foundry Technical Overview and Bootcamp. Then the ballroom separated to 3 different breakout sessions for topics about languages and frameworks, cloud databases, and solution partners. The Open Tour is a purely developer conference. All sessions include our partners and are deep dives into the code level (which are developers’ favorite, right?). Our elite speakers and well-designed content are the keys to the success.

The keynotes were full of vision, mission and decorated slides, but most importantly they start from code! Mark’s keynote “Developer Perspective” clearly re-emphasized that the Open Tour is a developer conference. After a quick Cloud Foundry introduction, Mark switched to coding mode, he went through a complicated sample app which leveraged many of the key features of Cloud Foundry. He then shared his thoughts on the producer/consumer pattern, node.JS server, tunneling (“caldecott”), redis, and much more. Chris’ “Cloud Foundry Bootcamp” session led people deeper into Cloud Foundry. Chris used 100+ slides to give a very detailed introduction and demo to help developers with different backgrounds to get started with Cloud Foundry.

In the afternoon, Patrick Chanezon and Chris Richardson hosted the track for programing languages and frameworks. This was the most popular track. “Node.JS Introduction”, “Spring into the Cloud” and “Using Ruby in Cloud Foundry” gave developers a more clear understanding of the power of multi-framework support in Cloud Foundry. Chris, Victor and Long Wang contributed 4 very interesting sessions in the Cloud database track. “SQL, NoSQL, NewSQL? What’s a developer to do?”, “Using MongoDB in Cloud Foundry”, “Data Director” and “GemFire/SQLFire, the RAM DB in Cloud Foundry” gained a lot of attention.

Partner Showtime

Enabling partners and making them successful is an important pillar for Cloud Foundry. It is our great honor to invite three famous public cloud service providers, Sina App Engine, Shanda Grand Cloud & InGeek Cloud, to join the events and announce their partnership with VMware to promote adoption of Cloud Foundry. SINA App Engine (SAE), the largest Open Platform in China with 200,000 developers and 100,000 apps, launched its first Cloud Foundry based Ruby PaaS engine. InGeek, by leveraging the vSphere based IaaS cloud, launched a PaaS cloud with Cloud Foundry and vFabric Data Director integrated via Service Gateway. Three tier-1 universities in China, Tsinghua University, Fudan University & Shanghai Jiaotong University, also joined the event. They have formed partnership with VMware China R&D on university innovation programs to drive Cloud Foundry adoption via course ware, joint lab & EDU-PaaS private cloud.

Interesting Sidelights

A developer conference is about fun, we have some interesting sidelights to share:

Weibo: For some reason, there is no Twitter access in China, but we have SINA Weibo, the China version of Twitter with about 300+ million users. With the help of Google Translate, Mark, Patrick and Chris interacted with their Chinese fans at Weibo. They even registered their own Weibo account to start tweeting and win a lot of followers! Here are the links to their account: @大牛马克 for Mark, @快乐的法国极客 for Patrick and @温文尔雅的程序员大爷 Chris. Patrick’s name means “most joyous French geek”, and Chris’ name means “gentle programmer’s uncle”. Mark’s name means “Big Bull Mark”, the story is at below. These accounts were all getting developers feedback to their sessions.

From Chairman to Big Bull: Mark was famous for his chair story. He didn’t bring his chair for the China trip, but he won a lot of new fans in Beijing and Shanghai. He was surrounded by developers after he finished the keynotes, and  people even tried to ask him technical questions in the men’s room! In the Chinese developer community, the “Big Bull” is a kind of respectful title for a distinguished technician or developer, so we made a stone stamp logo (the red one) for Mark and named his Weibo account @大牛马克 (the Big Bull Mark). You will probably soon see this logo in Mark’s email signature.

Li Bai and Cloud: Patrick is a big lover of Chinese ancient poems. He started his node.JS session by quote Li Bai and Wang Wei, the two major Chinese poets of the Tang dynasty. These two sages use poems to describe beautiful clouds over 1200 years ago, but they probably couldn’t imagine that we will quote the poems in today’s Cloud computing era to make the perfect combination of art and technology.

Weibo Feedback

Developers kept track of their feedback to the Could Foundry Open Tour on Weibo, the following are some interesting quotes:

• Look forward to see the 100% open source of Cloud Foundry, this will provide strong foundation for enterprise to build private cloud; this is the Linux in the Cloud. P.S., love to use MacOS for cloud development, recommend to all UNIX developers. From @乔布斯胡
• Join the VMware Cloud Foundry event today, get a USB stick, T-shirt and a substantial buffet lunch. The event is good in general, the key advantage of Cloud Foundry is developers can use their familiar programming language and framework to build app, easy to use and config, love it. From @ArKiarX
• The Cloud Foundry Open Tour is very gelivable, depth technical sessions, great speakers, and a good buffet lunch. From @忘了游泳的鱼ooO
• The SINA guest speaker mentioned about eco-system, the open source based Cloud Foundry is building and developing the cloud eco-system. From @中国董永乐
• Learnt quite a lot in Cloud Foundry Open Tour, feel more and more exciting about Cloud! From @奔跑的大兵
• Patrick is the most joyous speaker of the day, he even trying to access Twitter. From雪中

The Open Tour is continuing across the world

Cloud Foundry Open Tour 2012 is a global series of one day developer events, Beijing and Shanghai are the first two stops. The team is heading to Kiev, Moscow and London. Come join us and feel the power of Cloud Foundry!

-The Cloud Foundry China Team

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

More Clouds

In a recent post, we’ve explained why preserving multi-cloud choice and flexibility is so important in the cloud era. As an open platform as a service, Cloud Foundry is designed to run on a wide variety of clouds and cloud infrastructures.

In a live demo today we demonstrated how Cloud Foundry is making multi-cloud a reality with the deployment of an application to four different Cloud Foundry-based clouds within minutes without any code or configuration changes.

More Code

Today we introduced and open sourced Cloud Foundry BOSH, an open source tool chain for release engineering, deployment and lifecycle management of large scale distributed services.

Designed to enable the systematic and prescriptive evolution of services, BOSH facilitates the operation of production instances of Cloud Foundry. BOSH automates a variety of cloud infrastructure and allows targeted service updates with consistent results and minimal to no down time.

Proven in the course of operating CloudFoundry.com, BOSH is available under an Apache license from CloudFoundry.org and currently includes support for VMware vSphere as well as early support for Amazon Web Services.

Additional technical details on BOSH are available on GitHub.

More Community

Cloud Foundry has been an open source project from the day it was released. The project is active on GitHub and has seen broad and meaningful contributions from the developer community, including support for dozens of major developer frameworks and application services.

Today we unveiled the new CloudFoundry.org,  a new source code management system for Cloud Foundry. The new system converges Cloud Foundry source code to a single set of public code repositories on GitHub integrated with Gerrit for code reviews and Jenkins for continuous integration.  The new system enables developers to submit day-to-day change requests directly to the public repository. It simplifies community code contributions, improves code quality and offers greater visibility into code changes as they happen.

Additional details on how to contribute and participate are on the Cloud Foundry open source blog.

More Partners

There are a broad range of companies investing in and around Cloud Foundry, including development and deployment tools, public cloud operators, private cloud distributions, application service developers and ISVs.

Today five additional companies announced they are joining the Cloud Foundry ecosystem:

• Cloud9’s browser-based integrated development environment now supports deployment to CloudFoundry.com.
• Collabnet is making Cloud Foundry a core deployment platform for their suite of agile enterprise development tools.   
• ServiceMesh has added policy-driven deployment and governance of Cloud Foundry to their enterprise Agility Platform^TM.
• SOASTA’s CloudTest Lite® rapid test creation and real-time analytics now offers support for Cloud Foundry deployment targets.
• X.commerce, eBay’s open, end-to-end commerce technology platform, is building upon Cloud Foundry.

We are in the midst of the Cloud Foundry Open Tour – a series of developer days across the globe attended so far by thousands of developers.

Upcoming dates include:

• Kiev, Ukraine: Tuesday, April 24 2012
• Moscow, Russia: Thursday, April 26 2012
• London, United Kingdom: Tuesday, May 1 2012

We are looking forward for an exciting second year with more code, more community, more partners and more clouds.

-The Cloud Foundry Team

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

It is well known that VMware developers are the stewards of the incredibly popular Java Spring framework.  Therefore, Cloud Foundry’s support for running Java applications in a platform as a service environment has always been excellent.  However, many CloudFoundry.com users may not realize that most of Cloud Foundry’s system components are built using the Ruby programming language, and providing great support for Ruby applications is also very important to us.

In the past few months, we have been quietly adding features and improving support for running Ruby, Rails, Sinatra, Rack, and even JRuby applications on CloudFoundry.com.  Jennifer Hickey, a developer on the Cloud Foundry team, recently hosted a webinar on deploying Ruby applications to Cloud Foundry and covered the following topics:

• Rails 3.1 and 3.2 applications are now well-supported on CloudFoundry.com.  The development team resolved a number of issues that had previously required workarounds.
• JRuby applications can run on CloudFoundry.com with some simple tweaks.  Look for a blog post soon that will document the steps to deploy a JRuby application to Cloud Foundry.
• Auto-reconfiguration for Ruby are now supported for Rails and Sinatra applications using Cloud Foundry services.  The auto-reconfiguration capability will automatically locate the initialization for Postgres, MySQL, Redis, Mongo, or RabbitMQ anywhere in your code and dynamically update them to the service(s) bound to your application.  This allows you to simply deploy your Ruby applications to CloudFoundry.com without changing any code or configuration.  We have fully detailed this feature and its technical details in a blog post: Part 1 – Auto-reconfiguration.  We also give to the option of having more control and explicitly configure your application to run on Cloud Foundry. This is documented in another blog post: Part 2 – Run-time Support for Ruby Applications.
• Rails console, a popular tool for Rails developers to interact with their Rails application, is now available through the VMC command line client.  A blog post, Cloud Foundry Now Supports the Rails Console, was published to explain how to use this feature to connect to Rails applications.  Using the Rails console, you can easily view and modify your data, inspect state, or interact with application methods.  You can even run Rake tasks inside the Rails console to perform administrative tasks on your applications.
• Rack applications, a modular Ruby web server interface, are now supported.  Cloud Foundry’s VMC will automatically recognize a config.ru Rackup file and use it to run your web application.  The auto-reconfiguration feature is also supported for rack applications.

If you develop Ruby applications, you will want to view Jennifer’s webinar recording and see how fast and easy it is to deploy Ruby applications on CloudFoundry.com.

We strive to provide the best PaaS support for running Ruby applications.  If you have any feedback for us on how to improve Cloud Foundry’s Ruby support, we welcome you to drop us a note at our support site.

-The Cloud Foundry Team

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

Guest blog post by Mícheál Ó Foghlú.

Available today at mobilecf.feedhenry.com, Cloud Foundry developers can build mobile apps using HTML5, JavaScript and CSS fully integrated and instantly staged to their CloudFoundry.com account. To get started, simply download the FeedHenry Command Line tool, using your existing CloudFoundry.com credentials. New subscribers to CloudFoundry.com can join using the promotion code “feedhenry“.

In the following blog we will demonstrate how to use the FeedHenry Command Line tool to clone a sample/template app, (from GitHub), stage the server-side code to CloudFoundry.com (Node.js and Redis), and build a HTML5 & JS app for an Android device. See http://mobilecf.feedhenry.com for detailed instructions. Also check out the FeedHenry App Studio to preview the app that you create here.

Installing node.js

The FeedHenry CLI tool, fhc, uses node.js on your local machine. To setup node.js use the node installer located at http://nodejs.org/#download

Installing or Updating the FeedHenry CLI Tool (fhc)

Use the Node Package Manager (npm) to install or update the FeedHenry CLI tool (fhc).

$ sudo npm install –g fh-fhc

(the optional prefix “sudo” gives permission to install system-wide in a Unix style environment).

To test fhc is installed correctly and see the version you have installed, use:

$ fhc -v

fhc has some built-in documentation; use fhc help for general help, or fhc help [command] for help on a specific command.

Logging in using your CloudFoundry.com credentials

To get started with the CLI tool you need to login to the FeedHenry platform using your CloudFoundry.com credentials.  This will automatically create a FeedHenry account at mobilecf.feedhenry.com.

$ fhc target https://mobilecf.feedhenry.com
$ fhc login <your CloudFoundry.com email> <your CloudFoundry.com password>

In the next 3 simple steps, we will illustrate how to create a HTML5/JS app with an instant backend in cloudfoundry.com

Forking a template app in github (code)

To edit/modify the template app, login to github, and fork the app to your personal account.

https://github.com/feedhenry/App-Anatomy

Get the read-only git identifier for your cloned app.

git://github.com/<YOUR-ID>/App-Anatomy.git

Now create an app in the FeedHenry platform linked to your fork of the template app in github.

$ fhc apps create App-Anatomy git://github.com/<YOUR-ID>/App-Anatomy.git

If using a secured repository, please check out the documentation docs.feedhenry.com for generating and uploading public/private keys.

Staging the backend to Cloud Foundry

Staging to Cloud Foundry requires the use of the unique app identifier <APP-ID> that can be acquired by listing the active FeedHenry apps.

$ fhc apps

The staging can be done to the debug environment or the live environment.  The former hosts the server-side for “debug” apps, and the latter for “release” apps.  Separating these allows developers to exercise functionality separately in testing before deploying to production.

$ fhc stage <APP-ID> --devel

or

$ fhc stage <APP-ID> --live

To ensure that the app has indeed staged correctly use the Cloud Foundry CLI tool (vmc).

$ vmc target api.cloudfoundry.com
$ vmc login
$ vmc apps
$ vmc logs <my Cloud Foundry app-id>


We have just staged the cloud code from our forked app.  Each app contains three directories: client, cloud, and shared.  The client directory is for the client-side HTML5/JS app, the cloud directory is for the server-side Node.js code (this is what has been staged).  The shared directory is in both. Check out the documentation for more information on using the shared directory.

Building the Android client

To generate an Android debug build of the app:

$ fhc build app=<APP-ID> config=debug destination=android version=2.2 download=true

The appropriate files are gathered, bundled and dispatched to the FeedHenry build farm. The resulting binary file, for Android, an .apk file, is returned and can then be downloaded to your desktop. You can preview the app using the FeedHenry studio at mobilecf.feedhenry.com.

Load the app onto the phone by using email or Dropbox

That’s it – you have built and staged an app in 3 easy steps.

Note: Editing the code in the git repository can make changes to the server-side and the client-side functionality.  Those changes can be uploaded to FeedHenry via a git pull request. The updated server-side code can be re-staged, and the updated client-side code can be used to build a new version of the app. To find out more about this template app, App-Anatomy, see FH App-Anatomy in the References.

To get started go to http://mobilecf.feedhenry.com

Additional information

• Installing vmc: http://start.cloudfoundry.com/tools/vmc/installing-vmc.html
• Installing Node.js: http://nodejs.org/#download
• Installing npm: http://npmjs.org/
• Installing fhc: http://docs.feedhenry.com/our-tools-for-developers/fhc-command-line/
• Cloning an app: http://docs.feedhenry.com/training-labs/fhc/creating-an-app-from-github/
• FeedHenry App-Anatomy: http://docs.feedhenry.com/training-labs/app-labs/app-anatomy/
• FeedHenry Android Build: http://docs.feedhenry.com/training-labs/fhc/creating-an-android-debug-build/
• FeedHenry Staging to Cloud Foundry: http://docs.feedhenry.com/training-labs/fhc/creating-an-android-debug-build/#step3

Join us for a Cloud Foundry mobile meetup, March 25th, San Francisco.

Signup for Cloud Foundry today, and start building your own mobile app!

Beijing, Shanghai & Tokyo

The Cloud Foundry Open Tour begins with special events in Beijing (March 28), Shanghai (March 30) and Tokyo (April 2). The leading engineers behind Cloud Foundry will give a hands on guide for getting started with the platform and the follow-up sessions will teach developers all the details they need to create productive applications in Java, Ruby or Node.js. Essential sessions include

• Cloud Foundry Technical Overview by Mark Lucovsky
• Cloud Foundry Bootcamp by Chris Richardson

San Francisco, Portland, Austin & Washington D.C.

There are four great locations for the developer community to learn more about Cloud Foundry: San Francisco (March 30), Portland (April 2), Austin (April 5) and Washington, D.C. (April 9). The North American cities will help developer learn the basics about Cloud Foundry but will also focus on the broad community of contributors to the open source platform.  In select cities, attendees will have access to special sessions by 10gen about MongoDB, AppFog about PHP as well as presentations about cloud application design by prominent community members. Key sessions include:

• Cloud Foundry Bootcamp by Dave McCrory
• Using MongoDB for Cloud Foundry Applications by Jared Rosoff (10gen)

Kiev, Moscow & London

In Europe, the Cloud Foundry Open Tour joins forces with the Spring and Grails developer communities to provide multiple tracks that are sure to interest any enterprise developer: Kiev (April 24), Moscow (April 26) and London (May 1). These events are perfect for learning about the latest Spring 3.1 release, recommendations for using noSQL, Grails 2.1 capabilities as well as incredible details about how the Cloud Foundry platform works. Top sessions include:

• Developing Polyglot Applications on Cloud Foundry by Chris Richardson
• Spring 3.1 Review and 3.2 Preview by Juergen Hoeller
• What’s New in Groovy 2.0 by Guillaume Laforge

Register Today

Meet-up with other cutting edge developers, learn from the expert technologists behind Cloud Foundry and expand your opportunities by attending the Cloud Foundry Open Tour.

There is a small registration fee for attending the Cloud Foundry Open Tour, but the current early bird registration provides discounts and space is limited in each city so be sure to save your spot today.

Micro Cloud Foundry is a complete version of Cloud Foundry that runs in a virtual machine on a developer’s computer. Micro Cloud Foundry has established itself as the convenient and portable Cloud Foundry environment from which developers can easily develop and test their applications.

The new version we release today (version 1.2) , immediately available for download at www.cloudfoundry.com improves upon that convenience and portability by making it very simple to configure your Micro Cloud Foundry instance to either run disconnected from or connected to the internet.  The default network setting has been changed to the offline configuration, so that Micro Cloud Foundry can work flawlessly and consistently anywhere you are: home, office, coffee shop, conference, or even on a plane.

Java developers can now debug a Java application running in Micro Cloud Foundry with a Java debugger similarly to how they have always done with locally running applications.  The user can set break points in the source code, suspend and resume running applications, view the application stack and perform code stepping operations.  To enable Java debugging  users can either push an application through the Cloud Foundry command-line (VMC) using the ‘vmc push <my app> -d‘ command option or use the built-in debugger of SpringSource Tool Suite (STS).  An upcoming release of STS will further improve Java and Grails debugging with Micro Cloud Foundry applications to a seamless user experience.

The new release of Micro Cloud Foundry has updated its included runtimes to the versions indicated in the table below.  These runtimes are now up-to-date with the CloudFoundry.com public service.  A notable addition to the runtimes is Node.js 0.6, which is now available as an option:

(This information can be retrieved using the ‘vmc runtimes‘ command)

Micro Cloud Foundry services have been updated as well to the following versions :

(This information can be retrieved using the ‘vmc services‘ command)

Since a Micro Cloud Foundry instance by default runs all of the services available in CloudFoundry.com, some of the services may be utilizing precious resources on your machine even if you do not use them.  This can easily be remedied by turning off the services that are unnecessary.  From the main menu of the Micro Cloud Foundry console, select option 8 for services.

From the services menu, you can easily choose to disable a service or re-enable a service that was previously disabled.

To get specific instructions or find out more about these new features for Micro Cloud Foundry, please visit our documentation site at: start.cloudfoundry.com.  Additionally, we will be detailing some of these features and technology behind them in future blog posts.  Micro Cloud Foundry 1.2 is immediately available for download at CloudFoundry.com, so update yours today!

-The Cloud Foundry Team

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

Getting Started

First, install or update your Cloud Foundry command line tool (‘VMC’) to the latest preview version using the following command:

gem install vmc --pre

You can verify that you got the right version using:

vmc -v

which should show the version to be 0.3.16.beta.3 or higher.

Next, push or update a Rails app using vmc push.

To access the console, run:

vmc rails-console appname

That’s all there is to it!  Read on for a more detailed example…

Using the Rails Console

Let’s get started by deploying a Rails application to Cloud Foundry. We’ll use Enki, an open source blog engine.   I’ll use the cloudfoundry-samples fork, where I’ve added the mysql2 gem to enki’s Gemfile.  Now I’m ready to push to Cloud Foundry:

mycomp:enki$ vmc push mynewblog
Would you like to deploy from the current directory? [Yn]:
Application Deployed URL [mynewblog.cloudfoundry.com]:
Detected a Rails Application, is this correct? [Yn]:
Memory Reservation ("64M", "128M", "256M", "512M", "1G") ["256M"]:
Creating Application: OK
Create services to bind to 'mynewblog'? [yN]: y
1: mongodb
2: mysql
3: postgresql
4: rabbitmq
5: redis
What kind of service?: 2
Specify the name of the service [mysql-8f1d2]:
Creating Application: OK
Creating Service [mysql-8f1d2]: OK
Binding Service [mysql-8f1d2]: OK
Uploading Application:
  Checking for available resources: OK
  Processing resources: OK
  Packing application: OK
  Uploading (20M): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

Looks like the app deployed successfully.  I saved the manifest generated from this vmc output, so you can do just a simple “vmc push” with the application name and URL after cloning the sample.

I’ll make my first blog post about this new Rails Console support and wait for the comments to start rolling in…

Unfortunately, it looks like I have a nasty comment from Joe that needs deleting.  Let’s fire up the Rails Console through vmc to easily get rid of that comment.  The vmc rails-console command can be run from any directory.

mycomp:enki$ vmc rails-console mynewblog
Deploying tunnel application 'caldecott'.
Uploading Application:
  Checking for available resources: OK
  Packing application: OK
  Uploading (1K): OK
Push Status: OK
Staging Application 'caldecott': OK
Starting Application 'caldecott': OK
Connecting to 'mynewblog' console: OK

irb():001:0>

Since this is the first time I’ve run Rails Console, vmc will deploy the caldecott application for me, which helps tunnel communication to my remote Rails application.  After that, it fires up the console and waits for input.

irb():001:0> @comment = Comment.find_by_author("Joe")
#<Comment id: 7, post_id: 1, author: "Joe", body: "I have something real...">
irb():002:0> @comment.delete
#<Comment id: 7, post_id: 1, author: "Joe", body: "I have something real...">
irb():003:0> @comment = Comment.find_by_author("Joe")
nil
irb():004:0> exit

In this console session, I use Comment.find_by_author to find Joe’s comment, delete the comment, and then check to ensure that Joe’s comment has been removed.   Let’s refresh the web page and see that it’s gone:

This is just one small example of what can be done with Rails Console.  I could use it for all sorts of diagnostics as well, such as perusing the database, running ruby commands to inspect state, or interacting with controller methods to check responsiveness.  For more information, check out the Rails Console documentation or this handy screencast from RailsCasts.

Enabling the Rails Console

The console will automatically be available when you push any Rails application.  If you already have a Rails application deployed to Cloud Foundry, you will need to update or redeploy your app to stage the console support.

What are you waiting for? Go try it out!

Ready to start interacting with your Rails app on Cloud Foundry? Make sure to update to the latest vmc gem, and you should be ready to give it a whirl.  Please feel free to direct any suggestions or feedback to the support forums!

- Jennifer Hickey
The Cloud Foundry Team

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

Most PaaS solutions today force you to write your application to that specific PaaS and that is where your app will stay, much like writing to an OS.  It sits on a public cloud somewhere and cannot be moved without recoding and dependency swaps.  In extreme cases, you as a developer are still directly tied to the constraints of the infrastructure.

Limiting yourself to a single cloud instance restricts your flexibility now and in the future. You may want to move from private to public cloud, or vice versa.  You may want to change from one public cloud provider to another or maybe you are dissatisfied with the pricing or reliability from a particular provider.  Geographic market expansion or compliance needs may push you to new clouds.  Building and deploying applications to clouds that have a proprietary deployment and/or technology stack will impede your cloud flexibility.  You want to preserve your “Multi-Cloud” ability.

Cloud Foundry gives you the ability to make your application Multi-Cloud by allowing you to write your application once and deploy it to any Cloud Foundry instance, be it public or private or even on to Micro Clouds.

The Cloud Foundry eco-system has grown a great deal in the last 9 months.  There are now multiple public clouds based on Cloud Foundry and several private cloud deployment options that rely on Cloud Foundry.  In addition, we also offer Micro Cloud Foundry (Cloud Foundry in a VM).  All of these options have the ability to take the same Java, Ruby, or other code and deploy an application without modification.

How does Cloud Foundry achieve Multi-Cloud Application Portability?

There are several technologies at work to make Multi-Cloud a reality.

DEAs – The Dynamic Execution Agents operate as independent entities that carry out requests made by the Cloud Controller.  By being independent, DEAs provide a place for the Application to run without the application being aware of where it is executing (like in a traditional OS).
Service Gateways – Provide a common/uniform way of exposing Services (Databases, Message Queues, Stores, etc.) to the Applications running on the DEAs.  By presenting services in a common and uniform way to a running application, it becomes more easily portable.
Environmental Variables – The last portion to make applications portable is to provide credentials for services in a standard way to all application runtimes.  In all Cloud Foundry implementations, this is done by injecting a JSON document as an environment variable that lists all bound services and their credentials to the Application.  Once a developer has written their code to leverage this (either by parsing the JSON themselves or by leveraging a framework feature such as Spring 3.1 Profiles, the application can be run on any instance of Cloud Foundry without modification to any of the code.

Below is a 5 Minute video showing a Multi-Cloud Deployment to 5 different Cloud Foundry based Clouds

Multi-Cloud using Cloud Foundry – The Demo

(For the fully detailed 13 minute version, click here)

Steve Herrod, VMware’s Chief Technology Officer further discusses the advantages of the Multi Cloud approach to PaaS in the following blog post.

Watch a short flash video – “Multi-Cloud and Proud”

-The Cloud Foundry Team

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

We’re finalizing node.js 0.6.7 support, which will be committed to the Cloud Foundry GitHub repository.  Cloud Foundry.com will begin to support node.js 0.6.7 as a runtime framework in the next week or two.  Because of the rapid pace of innovation around node, we are adding node.js 0.6.7 as an additional runtime, letting you select which version of node you want to run with your application.  This lets Cloud Foundry support multiple node.js versions simultaneously, which is important as it allows applications written against the node.js 0.4.12 version to co-exist with applications developed on node.js 0.6.7.

This work represents the first fruits of our partnership with Joyent, who is the Cloud Foundry Community Lead for node.js.  Going forward, we will have a joint open source engineering model with Joyent that lets the Cloud Foundry, node.js, and Redis teams all work together to deliver a highly optimized PaaS solution across those components.

The next few months should be big for node.js and the community around it.  Modern applications are becoming more demanding, diverse, and complex.  We see node.js as a great fit in addressing many of the problems posed by this.  A few examples of the efforts going into leveraging node.js with Cloud Foundry are covered in the links below.

• Using MongoDB, Redis, node.js, and Spring MVC in a Single Cloud Foundry Application
• Getting Started with VMware Cloud Foundry, MongoDB, and node.js
• Using the RabbitMQ Service on Cloud Foundry with node.js

- The Cloud Foundry Team

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