The Keene View on Web 2.0, Ajax and SaaS

For cloud computing to take off, there need to be tools available that enable a developer to build and deploy an application without having to download anything to their desktop. This requires an on-demand development tool that sits on top of the cloud and provides a development Platform as a Service (PaaS).

There are two paths that a vendor can take to create a development platform for cloud computing: cloud-first or tool-first.

• Cloud-first approach to PaaS: first build a cloud platform, then build a development tool that runs on top of it. This is the approach pioneered by Force.com and followed by Coghead and Bungee Labs.


• Tool-first approach to PaaS: first build a development platform that is host-able tool (e.g., studio runs in a browser), then "push" that platform into the cloud. This is the approach taken by WaveMaker.

For Force.com, it made a great deal of sense to take the cloud-first approach. SalesForce.com already had a robust cloud platform and expertise in building proprietary development tools to create their CRM application. There was also no requirement to make Force.com work on any other cloud, because SalesForce is aiming to be the only cloud you will ever need for all your enterprise apps.

For most software vendors, however, the cloud-first development process has distinct disadvantages. First of all, it puts you in the data center operations business, which requires a very different DNA than software development. Next, it makes development itself difficult, because the cloud adds a level of indirection and complexity to all development tasks. Finally, you will be forced to do cloud port eventually to get to a SaaS cloud people want to deploy on, like Amazon EC2 or Google App Engine (assuming they ever exit the Python ghetto).

A tool-first approach to PaaS development is much more straightforward. You start by creating a host-able development studio (pretty much rules out Eclipse plugins) and do your build and test on standard hardware. After you have build a solid product, you add multi-tenancy to the studio and customize deployment for your cloud of choice (or use a partner like Elastra to do the deployment and administration for you).

A final oddity of the cloud-first vendors is that they have all delivered proprietary development platforms. This provides a "roach motel" level of lock-in - your logic and data can checkin, but just try moving them to another RIA or Ajax platform! Again, SalesForce can throw its 500-pound gorilla weight around and make the Apex language successful. It is hard to imagine, however, that 5 years from now people who have learned the Coghead language will be in more demand than, say, Java developers.

Labels: Bungee Labs, Coghead, force.com, paas, platform as a service, WaveMaker

Recently there have been a slew of announcements in a category that could be called Platform as a Service. SalesForce launched their new Force.com platform last week, and companies like Coghead and Teqlo have entries in this arena as well.

The details differ, but each Platform as a Service vendor provides roughly the following:

• Web based development tools: graphical environment for building business productivity apps and deploying them immediately to an on-demand server.


• Proprietary server technology: the applications and data are locked into a unique SaaS environment. Goodbye any hope of managing IT standards consistently!

Haven't we seen this movie before and doesn't in end in tears? For example, how many people still think SAP's ABAP is a good idea? In return for short-term pleasure (easy to build apps, don't have to worry about deployment), I let myself in for a long-term world of pain (including security, data quality and integration challenges).

Why would any enterprise want another company to have semi-exclusive control of their business logic and data?

To be sure, the SalesForce platform may well be an excellent way to extend existing SalesForce applications, as ZDnet points out here. It does not make sense, however as a stand-alone platform, particularly in comparison to more accepted platforms like J2EE and .NET.

At ActiveGrid, we believe that the whole distinction between on-site and on-demand deployment is an artifact of poor tool design. The next generation of web development tools will make it transparent whether you are deploying to your desktop, to the data center or to a SaaS hosting environment like Amazon's Electric Compute Cloud. Programmable web has a nice summary of EC2 applications here.

The next generation of virtualization will occur when enterprise developers can make on-the-fly decisions about whether to host applications on-site or on-demand. Put succinctly, SaaS manageability goodness is not enough to overcome proprietary badness.

Labels: abap, amazon ec2, force.com, saas