The Web is the New App Store

I attended the GigaOm Mobilize conference (where VMware was well represented by CTO Steve Herrod) and came away with a few observations that are relevant for our overall mobile strategy:

1. The web is the new app store. I had dinner with the heads of mobile for two large retail chains. Although each of them have multiple App Store apps, the vast majority of their mobile business is coming through the safari browser and not the app store. Consumer behavior is to go to the web to buy things, even on mobile.
2. There are only two mobile markets, native iPhone and mobile web.The shift to HTML5 (+Phone gap if necessary) is happening rapidly. Almost every speaker talked of the html5/jquery/phonegap stack with a few native iPhone holdouts (e.g., gaming, iPhone only apps like Hipmonk). Phone gap allows html5 apps to access native smartphone features and be packaged for native app stores, effectively erasing the lines between html5 and native. There was zero discussion of native development for Android or any other non-iPhone platform.

Here are some intriguing, but less well formed conference themes:

• Notifications are the "home page" for mobile apps. Mobile apps force developers to rethink and simplify enterprise apps - making them more modular and "attention-driven"
• iPad is rapidly changing expectations about how web apps work. SalesForce's Do.com is using the iPad as their primary web platform and porting from there to browsers and smartphones.

Darwin's Cloud

RedHat conducted a survey of over 1,200 VMworld attendees on their cloud plans. Here is the question that I found most interesting:

What primary development framework are you planning to use in the cloud?

• Java EE 32%
• .NET 29%
• PHP 14%
• Python 6%
• Spring 6%
• Ruby/Rails 5%

If you take this at face value, the ideal PaaS for the enterprise would support Java EE, .NET and PHP. So far, this is well beyond the capabilities of the existing PaaS vendors.

In particular, there is no PaaS vendor bridging the Java/.NET divide. This raises a natural question: what is the fastest way to evolve cloud platforms?

There are two approaches to filling in these PaaS framework holes:

• Do it yourself: Heroku just added Java support to their cloud. Because PaaS offerings from Amazon and Heroku are proprietary, they are pretty much stuck with the go it alone approach.
• Create an ecosystem: Cloud Foundry just added PhP and Python support through partners. A huge advantage for open source clouds is that they can leverage the work of their communities to move farther and faster than closed-source competitors.

Open source clouds should be able to sustain a faster rate of revolution, provided that they can continue to build vibrant communities that contribute back to the core project.

Cloud Foundry is the LAMP Stack of Cloud Computing

Just as the LAMP stack provided a core foundation next gen for web applications, Cloud Foundry is providing a core foundation for next gen cloud platforms.

Cloud Foundry announced today that two new startups are building their clouds based on Cloud Foundry.

Cloud Foundry is proving itself to be truly the foundry for creating entirely new cloud offerings:

• ActiveState is building a cloud for Python and Django and contributing code to support Python back to the Cloud Foundry open source project.
• Appfog is building a cloud for PHP developers and contributing code to support PHP back to the Cloud Foundry open source project

The beauty of this is that innovative startups are able to start with a scalable cloud "stack" that gives them a multi-language PaaS without locking them into a particular cloud provider.

So for example, Appfog gets to use Cloud Foundry's best in class PaaS services and then target deployment to Amazon's EC2 and services like S3. Appfog CEO Lucas Carlson blogged here about how standing on the shoulders of cloud computing giants will allow Appfog to win in the cloud by providing the most compelling user experience.

Expect to see the pace of innovation accelerate dramatically going forward!

DevOps and PaaS - Friend or Foe?

DevOps, which I will arbitrarily define here as "automating SysAdmin tasks to streamline application lifecycle management," raises important questions about the cloud.

• Developers may ask: "if I have a self-service portal for deploying applications (aka PaaS), do I need SysAdmins at all?"
• SysAdmins may ask: "isn't PaaS just a monstrous black box that prevents me from provisioning the specific services we need to deploy real-world apps?"
• VMware asks: "what if you could get a PaaS that wasn't black box, enabling developers to deploy apps easily while still giving SysAdmins the ability to provision any services they needed (aka Cloud Foundry)?

I had a good conversation recently with John Willis of DTO Solutions (twitter feed here) in which he waxed eloquent on how DevOps and Cloud Foundry can live together in harmony. Here were the key points I took away:

• SysAdmins distrust the black box nature of PaaS: Typical sysadmin thinks that they can get to 75% of PaaS functionality with DevOps tools like Chef without giving up any systems architecture flexibility. In contrast, PaaS solutions like Heroku provide developers an easy to use PaaS but gives SysAdmins zero ability to add services that Heroku doesn't support.
• Cloud Foundry solves the SysAdmin aversion to cloud vapor: CloudFoundry runs anywhere, incuding on your laptop. Cloud Foundry's service container concept is particularly strong, kind of an appliance on steroids.

There is a strong natural between DevOps and PaaS. Products like Chef and Puppet are strongest for installing and configuring the OS and middleware stack. PaaS solutions like Cloud Foundry excel it deploying application architectures.

The holy grail is to use Chef or Puppet provisioning Cloud Foundry services that can then be easily consumed by developers. DTO Solutions is putting on events to show SysAdmins how to make this happen.

You can also register for the a DevOps HackDay featuring CloudFoundry. The first one is being put on at VMware, September 8, 2011.

PaaS is a Cloaking layer for clouds

We seem to be coming to the end of the definition of Platform as a Service (PaaS) blog posts and are now moving on to the more pressing question of what is PaaS good for?

In a recent Paul Maritz talk at GigaOm Structure conference, he referred to PaaS as "a cloaking layer for clouds." This is an elegant definition for a rapidly expanding market of add-on cloud services.

If Cloud 1.0 is a set of servers in the sky (think Amazon EC2), then Cloud 2.0 is a layer of services that hide the complexity of developing, deploying and managing applications in the cloud (think CloudFoundry).

The API for Cloud 1.0 is the virtual machine/OS. The API for Cloud 2.0 is the application container itself - services like CloudFoundry, Elastic Beanstalk from Amazon and Heroku allow a developer to hand over an application to the application container without having to know anything about what operating system that application is running on or how it communicates with other services like load balancing, failover and database.

Here are several examples of PaaS cloaking to simplify cloud development:

1. Dev/test environment: WaveMaker pioneered the market for cloud-based development of standard Java applications. In addition, simply virtualizing the provisioning of servers has huge value for development and testing purposes. Today, this is a major driver for developer adoption of cloud in general and PaaS in particular. I have talked to CIOs who claim that over 30% of their resources for new projects goes into provisiong and managing the dev/test environment.
2. Scalable application deployment: Amazon EC2 has made its mark by providing a highly scalable data center in the sky. Zynga uses Amazon as a safety net when it has no idea how popular one of its games will be. Once Zynga has a handle on demand, they move the game over to their own data center. Just a year ago, getting this kind of scaling required detailed understanding of cloud architecture and a whole lotta scripting. Now it's as easy as "vmc push --instances 8"!
3. Resilient application deployment: infinite scaling is great, but what happens when a network configuration error brings down in your infinitely scalable data center? In that case, having a PaaS service that automatically mirrors applications across multiple data centers makes a critical difference.

In a sense, PaaS is just a new kind of virtualization, one that operates at the level of an application container instead of an operating system. No wonder then that VMware has a lot of firepower to bring to the PaaS market.

Where is the Killer App for PaaS?

Over the last month, I have had lengthy discussions about developer adoption of Platform as a Service with two of my favorite cloud computing analysts - John Rymer of Forrester and Michael Cote of RedMonk.

The net of these conversations that we are still early in the adoption curve for PaaS. In particular, developers are not yet demanding PaaS the way operations people are demanding Virtualization.

Here is my summary of these discussion:

• Developers are wary of PaaS: developers are not overly keen on PaaS at the moment. They are not yet mentally prepared to give up the middleware layer of their applications. Lacking a compelling reason to use PaaS, developers are sticking with tried and try development stacks.
• PaaS for existing apps has limited benefit: For existing applications, there's not much to gain by simply moving from non-cloud modes to cloud modes. This is the foundation of Cote's Cloud Rule - "if it ain't broke, don't cloud it".
• PaaS fits best for new apps: with new applications, the benefits of PaaS (cost and agility) all seem to line up.

This means that cloud vendors need to "connect the dots" for developers and business managers to accelerate their adoption of cloud platforms. In particular, there are two

• PaaS lowers the bar for web development: PaaS solutions like Cloud Foundry and WaveMaker make the cloud's benefits available to everyone, not just the A-Team. Of course, this requires significant education to let business developers know that easier web dev tools exist.
• PaaS speeds the delivery of apps for all developers: Michael Cote recently argued that speed is the killer app for cloud. Again, this requires market education to get the word out that quantifies these benefits.

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!

WaveMaker Springs To VMware

We are announcing today that WaveMaker has been acquired by VMware. This partnership is the result of discussions that have been going on between WaveMaker and the SpringSource division of VMware for more than a year.

I have always had great respect for how Rod Johnson revitalized and simplified the Java market with the Spring framework and developer projects. When we started development of WaveMaker over three years ago, we chose Spring as our foundation.

WaveMaker is based on the Spring framework but targets a different audience: non-expert developers looking for the easiest way to build web apps.

It turns out that this is a very large market. According to Gartner, only 20% of IT staff have expert app development skills - WaveMaker is the tool to enable the other 80% of IT to build web apps quickly and deploy them to the cloud with a single mouse click.

As WaveMaker went from 3,000 downloads a month in January, 2010 to 135,000 downloads a month in December, 2010, we realized that we had created the perfect "on ramp" for cloud computing. WaveMaker can play a big role in bringing large numbers of developers to the cloud, but only if we team with the right cloud partner.

With VMware and SpringSource, we have found that partner!

The good news here is that VMware will continue to support and provide services to the WaveMaker customers, via the same team that provided it before.

For Rod’s perspective on the acquisition check out his blog post here.