The World Is Your Oyster: Installing and Using Cloud Foundry on Windows

CloudFoundry is an incredibly cool way to build and deploy cloud apps to any target cloud using very simple commands.

The basic api has just three commands:

1. vmc target cloud.url //select cloud provider
2. vmc login // login to cloud
3. vmc push app.name // run cloud app

Three commands and the (cloud) world is your oyster! Very cool.

This may be just me but I found it difficult to follow the install guide for Cloud Foundry on my windows machine. For those of us trapped behind corporate firewalls and proxy servers, things got even more complicated.

After scurrying around the cloud foundry forums and stackoverflow, here are my slightly revised notes for getting Cloud Foundry running on a Windows machine using a proxy server:

1. Apply for a Cloud Foundry account at www.cloudfoundry.com you will be notified by email when your account is activated

2. Install Ruby from www.rubyinstaller.org. The Cloud Foundry cloud controller command line is built in Ruby so this is required. As the installer runs, make sure to check the boxes to add the ruby directory to your command path

3. Start the Windows command line client on windows by typing "run cmd" in start menu

4. Install the Cloud Controller software. Type:

gem install vmc

If you are behind a firewall, you will get a nasty error message:

ERROR: Could not find a valid gem 'vmc' (>=0) in any repository

5. Install vmc gem through a proxy server, type:

gem install --http-proxy http://proxy.vmware.com:3128 vmc

Congratulations! The Cloud Foundry Cloud Controller is now installed. From here on, you can type Cloud Foundry commands into the Windows command window.

6. Tell Cloud Foundry which cloud you want to connect to. Type:

vmc target api.cloudfoundry.com

Again, if you are benhind a firewall, you will get the error message

Host is not valid: 'http://api.cloudfoundry.com

7. To communicate with Cloud Foundry through a proxy server, set the environment variable "http_proxy". In the command window, type

set http_proxy=http://proxy.vmware.com:3128

vmc target api.cloudfoundry.com

8. Login to Cloud Foundry

vmc login

Enter your email address and password

9. Create a simple Ruby application.

cd \

mkdir hello

cd hello

The above commands create a "C:\hello" directory. Using a text editor type the following and save the file as "hello.rb"

require 'sinatra'

get '/' do

"Hello from Cloud Foundry +VMware and may I add you look dashing today?"

end

11. Publish the application to the cloud. Type:

vmc push

The following prompts will appear :

Would you like to deploy from the current directory? [Yn]

Assuming that you are in the hello directory hit enter (this answers Yes)

Application Name: hello_username

NOTE: use a unique name for your application best to concat your user name and "hello"

Application Deployed URL: ‘hello_username.cloudfoundry.com’?

Press enter to accept default

Detected a Sinatra Application, is this correct? [Yn]

Press enter to accept default

Memory Reservation [Default:128M] (64M, 128M, 256M, 512M, 1G or 2G)

Press enter to accept default (128MB)

Creating Application: OK...

Would you like to bind any services to ‘hello’ [yN]:

Press enter, you don’t want to bind any services for this example

12. Launch a web browser and go to your Application Deployment URL.

Now wasn't that easy?

Troubleshooting Problems With CloudFoundry

In deploying or updating an application, you may get the following error:

Uploading Application:
Checking for available resources: OK
Processing resources: OK
Packing application: OK
Uploading (2M): OK
Error (JSON 500):

The workaround for this is to make sure that the application is stopped (vmc stop foo) before you update the application (vmc update foo).

Death by Cloud - How Amazon is Killing Open Source Software

The mood at last week's Open Source Think Tank was surprisingly somber. Two years ago, the open source community was celebrating huge acquisitions such as Sun's purchase of MySQL (and even the VMware acquisition of WaveMaker). This year, the consensus was that the economic model which led to success for companies like MySQL and RedHat is being fundamentally disrupted by cloud computing.

For example, Amazon recently launched a successful Relational Database Service (RDS). This hugely profitable service is based on MySQL, but Amazon doesn't pay MySQL a penny for it. This spells death for the traditional open source business model.

To understand why, let's look at how the open source model used to work. The open source business model has traditionally been based on two revenue streams: 1) revenue from OEMs who embed an open source product into their commercial offering and 2) revenue from providing support services for production systems that embed an open source product.

Whenever a company embedded MySQL into their commercial offering, they had to either license their own product under an open source license like GPL or buy a commercial license from MySQL. Just as importantly, a company using MySQL in a production environment would purchase support from MySQL as an insurance policy.

Now let's look at Amazon RDS. First of all, Amazon gets around the GPL license because they are not delivering binaries to their customers. This means that Amazon can deliver a commercial service without being forced to open source their own software. Next, Amazon has sufficient internal expertise on MySQL that they can provide their own support.

The open source community has tried to fight back. For example, the new Affero GPL license (AGPL) was supposed to fix the loophole which allows Amazon to deliver MySQL as a commercial service. However, since almost nobody is using the AGPL license, every OSS project faces the prospect of seeing someone else deliver commercial services based on their product for which they don't get paid.

New open source companies are trying to get ahead of this trend by offering their own cloud-based service - such as Cloudera (Hadoop). This is a good idea, but it is not clear how these stand alone services will be able to compete with Amazon's Elastic Mapreduce service, also based on Hadoop.

Of course, none of this is going to stop the success of the open source movement in general. There are many projects which have no commercial aspirations. However, until open source companies can articulate a business model that can thrive in the cloud, this does cap the potential valuations of open source companies and hence their access to venture capital.

Cote's rule: If it ain’t broke, don’t cloud it

I took the title of this post from a recent blog entry by Michael Cote. Cloud enthusiasts (often people with limited operations experience) talk in grandiose terms of moving the entire data center to a public cloud. Cloud naysayers (often people with extensive operations experience) talk in detail about all the things you can't get in the cloud, like latency, lack of multi-cast, weaker security etc.

In general, cloud computing fits modern web architectures very well, by which I mean any app built to support a web browser client. These applications are "cloud-ready" and require little effort to move to a public or private cloud.

In general, any application not build to support a web browser client is going to be problematic to move into the cloud. These applications often rely on technologies that are not readily available in the cloud, such as multi-cast.

The decision to cloud or not to cloud is not a binary decision made at the data center level. Instead, it is a more nuanced decision made at the app level.

Similarly, the decision to go public cloud or private cloud is a decision made at the app level.

At the margin, be governed by Cote's Rule of Cloud Migration: If it ain’t broke, don’t cloud it!