Here's a great example where an agreed-upon taxonomy of Cloud Computing terminology would really be helpful. Software-as-a-Service (SaaS) is fairly-well understood from both a business and delivery model perspective; that is, if we agree that SaaS is software hosted external to the user and billed on a usage basis versus a license basis. A typical SaaS application provides a user with a client to access the service and stores the user's data in the cloud. There are tons of examples of SaaS applications today, both billed and free models including Salesforce.com, Facebook and Google Applications.
However, if a SaaS application, which provides a user interface that a human can use to access the service, also provide an application programming interface (API), does it also qualify as Platform-as-a-Service? The typical PaaS offering has been focused on a coupling of discrete technologies that can be deployed as an integrated offering. It typically has an operating system, some frameworks, a runtime facility and runs completely in the cloud.
Some might also consider a common aspect of these platforms to be that they are deployed and managed as virtual machines and the applications produced on them to leverage elastic computing capabilities. In my opinion, this crosses many aspects of Cloud Computing, including Infrastructure-as-a-Service (IaaS). Thus, another indication that there is lack of agreement on the boundaries between many aspects of Cloud Computing.
However, let's return to our key focus; the border between SaaS and PaaS, and let's look at a well-known entity that meets this criteria—Facebook. Facebook is SaaS. The application manages your social connections and allows you to communicate with your community via text and pictures, both directly and broadcast. Each Facebook account is essentially a unique community with a distinct set of users and connections.
Facebook is also an application platform. The Facebook API allows developers to provide additional services to each of these individual communities. However, Facebook does not host this application. Instead the developer is required to host the application for themselves. Facebook provides a portal to access the new service, provides a facility to allow its community manager to control if the application has access or not and what levels of access are allowed. It also provides an interface to allow each application to connect into community features.
If I draw clear boundaries around PaaS, such that it represents only those offerings that can be deployed as a complete entity, and does not include offerings where the platform is already deployed and accessed via a service interface, then Facebook is not PaaS. However, this means that PaaS is once again a poorly-named IT offering, because, it is a platform and it is offered as a service.
I realize that I do not have a good answer for this conundrum as of this time. I believe the answer lies in semantics and taxonomy, but it is not something one individual can drive alone.
JP,
Good synopsis of the issue. One thing that we like to say is that in order to be a PaaS you must be able to create a complete solution from the application, which essentially eliminates things that simply provide an API to get into their product e.g. the difference between Facebook allowing you to use data and Force.com allowing you to actually create a solution and then sell it all on their infrastructure.
We take this approach as well with our product and that has worked pretty well in recent times. The cloud issue is actually very interesting as well quick example; we have a PaaS offering (ElasticApps) and we allow people to instance that application on a cloud such as Amazon's in effect allowing you to choose the infrastructure, build the application and then deliver a SaaS solution, so it's the ultimate hybrid, of course making it even more challenging to get the taxonomies correct.
The difference between say what we do and Force.com is simply that force does not give you the choice to instance the service in your choice of cloud, which is probably the next evolution of the SaaS/PaaS space.
Thanks,
Ed Loessi
Faulkner Technologies
[url=http://www.faulknertechnologies.com]www.faulknertechnologies.com[/url]
I like Marc Andreessen's essay on the three different kinds of platforms: [url=http://blog.pmarca.com/2007/09/the-three-kinds.html]http://blog.pmarca.com/2007/09/the-three-kinds.html[/url]
JP,
You raise some very valid points. I don't think I have the most accurate definition of what constitutes PaaS – however, I do think that a platform must offer much more than a set of APIs, to qualify as a true PaaS. The Force.com platform, for instance, provides underlying services for database, security, user interface and much more that are essential to building a commercial cloud computing application or product.
Navatar Group provides salesforce for Financial Services verticals, built entirely in the cloud on the Force.com platform. None of these products would have been possible without the comprehensive set of services provided by Force.com. Visit [url=http://www.navatargroup.com.]www.navatargroup.com.[/url]
Alok Misra
IMHO we shouldn't expect to arrive a crisp definition of each layer of the 'XaaS N Layer Model' and in fact should accept them as intentionally abstract. The fuzziness of the XaaS' model shouldn't present us with any more of a problem than it has for the legendary 'OSI 7 Layer Model' of a network.
The 'OSI 7 Layer Model' has proved to be very useful and effective as a guide to understanding and thinking about networks despite the fact that except for components residing in the top-most 'Application' layer or the bottom-most 'Physical Layer', most real-world concrete network components tend to "leak" across the boundaries of those 7 layers in much the same way that XaaS providers cross layers of the abstract XaaS model.
Like a model of the solar system or the economy, every model has limits in how it can be used, but those limits shouldn't be seen as a problem or a reason to think that the model is any less useful.
Thomas,
While I understand your point regarding models, the Cloud is not being discussed in the abstract. Indeed, it's being discussed in physical incarnation and in way that will dramatically impact serious business decisions. No business that I'm aware of ever made a business decision based on the OSI model. Hence, full agreement of these concepts are critical for success in use of the Cloud as a tool.
JP