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

I had a great conversation today with one of my blog-heros, Jeff Nolan. Jeff recently finished a stint as the CEO of Teqlo, a pioneer in hosted tools for building Enterprise 2.0 applications. Others in this space include Coghead and Bungee Labs.

The nirvana we are all shooting for is a world where developers can assemble useful business applications with minimal coding or scripting. The idea is to take simplify certain tasks that are hard to do with code (e.g., visual assembly of page layouts, hooking controls to services) without making it harder than normal to do the things that will always have to be done with some sort of logic. The reality to date has fallen short of this nirvana.

We identified 5 reasons that Enterprise 2.0 apps today often fail to live up to the hype:

1. “Slowest man sets the pace.” Chaining together service calls to build applications creates bottlenecks where the slowest service call tanks the performance of the whole application.

2. Look but don’t touch widgets. Although this is changing (see here for the latest on Google’s pub/sub widgets), the vast majority of widgets can’t exchange data. This allows for an infinite variety of cute clock and horoscope widgets, but a paucity of useful business functionality in widget form.

3. Web service alphabet soup. There are a number of web service standards and even within a standard there are few rules for how the standard should be applied. This means that creating widgets to integrate web services is unexpectedly time consuming.

4. Still too darn hard. The world of widgets and building AJAX apps is still far too complicated for the typical end user developer. Current state of the art tools still require a knowledge of IDEs, standards and languages far beyond the grasp of casual developers.

5. Service throttling. At ActiveGrid, we have found that a number of web services like Google Maps are easy to mash-up for demo apps but much, much harder to use for doing real work. Given that Google has to pay for all the servers, it is easy to see why they would want to encourage people to use their web services in non-intensive ways.

Jeff believes a big market lies in creating “people, place, thing” applications like project management and time tracking. I would add that the killer app is tying Internet data presentation and collection with email workflow – sort of an updated Lotus Notes.

The market and the tools are evolving quickly, so in six months the landscape will look fundamentally different. For now, however, the vision of idiot-proof assembly of Enterprise 2.0 apps using rich business widgets has yet to be fully realized.

Labels: ActiveGrid, Bungee Labs, Coghead, Enterprise 2.0, Google Gadgets, Jeff Nolan, Teqlo, Web 2.0