Thoughts on Platform-as-a-Service

The recent news about layoffs at Bungee Labs has triggered a discussion about the viability of the Platform-as-a-Service concept. In this post I attempt to map the PaaS landscape and discuss possible strategies and approaches for the platform vendors. But first, to understand PaaS, we need to look at where it fits in the larger picture. PaaS is one of what I view as the three pillars of cloud computing:

1. Software-as-a-Service: Although the term "software" denotes any piece of software, the term SaaS is usually applied to the idea of delivering a complete software application to its end users over the Web, and typically with a subscription or per-usage pricing model. Examples include Zoho and Salesforce.com.
2. Infrastructure-as-a-Service: IaaS is about providing basic IT resources, such as compute power, memory and storage, over a network (typically the Internet) and usually with a subscription or per-usage pricing model. Examples include Amazon Web Services, GoGrid and Flexiscale.
3. Platform-as-a-Service: The term PaaS is often confused as it is actually used to refer to to two distinct elements:
   
   1. Web-based development tools (aka IDE). This could more accurately be refered to as Tools-as-a-Service (TaaS).
   2. A run-time application platform that enables running applications in the cloud, typically on top of an IaaS and delivered as SaaS.

 The two types of PaaS are sometimes confused because vendors often offer them combined as a single solution. Things are further confused because they often include a third, separate, component: that of a development framework or programming model (what is commonly referred to as the API).

To understand this better, let's compare to the more familiar and established world of Java. Building and running a standard Java app requires three main elements: the API (the Java programming language itself), a run-time platform (the Java Virtual Machine, or JVM -- or more accurately, the Java Run-time Environment, or JRE) and development tools (popular IDEs such as Eclipse and IntelliJ). Note that the three are separate from each other. A developer can choose which IDE and which JVM implementation (from IBM, Oracle, Sun or others). Also taking advantage of the Java Run-Time Environment does not require the Java programming language. One can use other interfaces such as JavaScript, Groovy and JRuby.

 The same principles apply to the Java Enterprise Edition (JEE). A developer can choose from a number of application server implementations (the run-time), IDEs and APIs (e.g., Spring Framework or EJB).

 

Armed with this understanding, let's look at Bungee Labs again. They made some crucial decisions with their product, BungeeConnect, which significantly impact the adoption of the product. the first was that they provide all of the elements: the development tools (a web-based IDE), the run-time platform (they may be leveraging other platforms underneath but it is transparent to the user), the hosting (i.e., IaaS) and the API (they offer a proprietary C-like API).

 
Second, they decided that you cannot separate the four elements from one another. They are tightly-coupled. You cannot use their tools without also adopting their API, run-time platform and hosting service. If you like their tools, and want to use them with other run-time platforms, APIs or cloud providers (hosting), too bad.

Third, they didn't leverage standards. Although their programming language syntax is C-like, so it is at least familiar to many developers, it will not execute on other run-time platforms as-is.

The adoption barriers created by Bungee's self-imposed limitations are becoming evident. A developer or company contemplating the use of BungeeConnect are forced to make a strategic, long-term decision about the future of their business: to be locked-in to Bungee's product in almost all aspects of their own product.

 

I don't mean to pick on Bungee. As a fellow entrepreneur, I sympathize. I can also understand the considerations they had when making these choices. For one, the notion of creating a "total solution" seems appealing at first. And from a practical perspective, it is easier to create a more powerful solution when you restrict and control the environment it operates in. Besides, they were being ambitious, and I respect that.

 

Let's look at some alternative approaches that Bungee could have taken (and still can), as well as what other players have been doing.

Go-To-Market Strategy

Generally speaking, achieving adoption for a new platform is a difficult task. It is true that the advent of cloud computing creates an opportunity for new players, but major challenges remain. There seem to be four main approaches to doing this:

• Brute Force: the very biggest vendors have the marketing muster, credibility and resources to make it happen by "brute force." An example of such an approach would be Google App Engine. Google has taken the exact same approach as Bungee -- they provide all four elements -- but they obviously have the market visibility and budgets to achieve fast adoption.
• Open Source: It means two things: first, pricing adoption barriers are removed (i.e., offer it for free and develop premium products and services later). Second, the product source code is available, allowing end users to customize it and the comfort of having access to source if something happens to the vendor. 10gen is an example of a vendor taking this approach.
• Specialized: Focus the platform on a particular segment of the market, instead of trying to be all things to all people. The key is that you have to build a "total solution" for that particular segment. This is reminiscent of Geoffrey Moore's Crossing the Chasm model. Ning is a good example, as it's a platform focused exclusively on building social networking applications. Other forms of specialized platforms could focus on a particular industry or type of application.
• Ride the Coattails:This strategy involves building a platform that allows developers to leverage an existing install base. The Facebook Platform is a good example. Given that today many applications expose their APIs to the general public, vendors other than the 'owner' of the install base can take this strategy.

Target User

Another dimension PaaS vendors should think about is who is the target user of the platform. The typical choices are programmers versus so-called business users (non-programmers). Bungee, Google App Engine and 10gen are all clearly targeting programmers. Ning, on the other hand, allows people without any code-writing skills to quickly create their own social network. They do, however, offer developers the ability to further customize their application through programming.

Totality of the Solution
As already noted, PaaS-related vendors need to decide which elements of the 'stack' they provide. Specifically, do they provide the run-time platform, the development tools, the hosting service, all of the above? And if so, do they lock users into their components or do they allow use of certain components from other vnedors? Here's a list of vendors and the choices they made:

Product	Run-Time	Tools	IaaS	API	Primary Target Users	App Focus
BungeeConnect	Yes	Proprietary web-based IDE	Yes	Yes. Proprietary	Developers	Free form
AppJet	Yes	Proprietary web-based IDE	Yes	Semi-proprietary, JavaScript-based	Developers	Free form
Jboss Cloud	Yes	Stanadard, installed IDEs	No (suports EC2)	Standard (J2EE)	Developers	Free form
GigaSpaces Cloud	Yes	Standard, installed IDEs + Cloud Tools for deployment	No (supports multiple clouds, including EC2)	Standard (Java/Spring, .Net, C++, JavaScript, Groovy, JRuby, JMS, JDBC, Jcache)	Developers	Free form
Aptana Cloud	Yes, for PHP and AJAX1	Aptana's open source installed IDE (based on Eclipse)	Restricted to Aptana hosting2	Flexible IDE for a variety of APIs, including JavaScript/AJAX, PHP, Ruby, Java	Developers	Free form
Force.com	Yes	Yes	Restricted to Salesforce.com hosting	Proprietary		Database-centric
DabbleDB	Yes	Proprietary web-based tools	Restricted to DabbleDb hosting	JavaScript based on JSON schema	Business (developer customization options)	Database-centric
Zoho Creator	Yes	Proprietary web-based tools	Restricted to Zoho hosting	Proprietary	Business (developer customization options)	Database-centric
LongJump	Yes	Proprietary web-based tools	Restricted to LongJump hosting	Java, REST, SOAP	Business	Database-centric, Workflow-centric
Google App Engine	Yes	Standard, installed IDEs + SDK	Restricted to Google App Engine hosting	Python (with limitations) and additional task-specific APIs	Developers	Free form
Coghead	Yes	Proprietary, web-based tools	Restricted to Coghead hosting	Proprietary	Business	Database-centric, workflow-centric
WyaWorks	Yes	Proprietary web-based tools, and accessible via installed IDEs	Provide hosting and allow deployment on any infrastructure	JavaScript, JSP, Java	Business and Developers	Free form
Intuit Quickbase	Yes	Proprietary, web-based	Restricted to Quickbase hosting	Proprietary3 Http API, XML/XSL and a Formula Language	Business	Database-centric
10gen	Yes	Yes, but you can develop code with standard IDE	No, supports multiple clouds	Standard (JavaScript, Python, Ruby)	Developers	Free form
Rollbase	Yes	Proprietary, web based tools	restricted to Rollbase hosting	Proprietary	Business (developers cutomization options)	Database-centric
Morph Labs	Yes	Not provided by Morph	Restricted to Morph Labs hosting	Standard (Java, Ruby)	Developers	Database-centric

Notes to Table:

1. According to a comment posted by Kevin Hakman of Aptana, a Ruby-on-Rails run-time will be available soon.
2. Aptana Actually uses Joyent as the host today (although this fact is transparent to the user). The company plans to add the ability to choose other hosting providers and does not see hosting as part of its business model (see comment by Kevin Hakman below).
3. The QuickBase API is proprietary, but like others on the list, it it can be wrapped by other, standard APIs. The QuickBase user comunity has already done so for Perl, Ruby, PHP and others.

Community and Eco-System

Another important aspect for any platform, PaaS included, is the notion of an eco-system and a community that is built around it. How well the platform vendor encourages, enables, nurtures and promotes this community is of critical importance. There are a number of ways to do this:

• Classic community tools: forums, ability to share and blog, wiki documentation editable by users, etc.
  
• Allow Extension of the Platform: This can be achieved by exposing APIs and/or open sourcing the code and providing the process and tools for submitting extensions, plug-ins and add-ons, bug fixes, etc. 10gen, for example, has open sourced its platform. Many of the other players in the table above are exposing APIs and providing other ways to modify and customize the platform. At GigaSpaces, as another example, we open sourced our API -- OpenSpaces -- and created the openspaces.org community site, which lets developers share their creations.
  
• Create a marketplace around the platform: Often the PaaS vendor already garners interest and attention and can make that marketing prowess available to its own users. Many of the PaaS providers listed here allow their users to list their creations in some sort of a catalog or marketplace. Other users can sometimes clone the creation and extend it, leveraging work that has already be done. In many cases the platform vendor allows its users a way to monetize their efforts. Salesforce.com's App Exchange is a good example of this. By making its platform open and extensible, Amazon enabled a whole cottage industry to develop around its Amazon Web Services platform, with companies such as RightScale.
  
• Access to end-user data: One of the most effective (and tricky) ways to foster an eco-system around the platform is to allow building applications that can access end-user data in other applications. Now when I say "access", I mean that they have the technical ability to do so. The end user, of course, needs to approve such access. For example, when you build an application on Force.com, it can access the contact, account and deal information in the users Salesforce.com application.

If anyone thinks I misrepresented any of the solutions in the table above, or if you have any other thoughts, please comment.