Demystifying The Cloud: Where Do SaaS, PaaS and Other Acronyms Fit In?


I’m sure we can all agree that the number of acronyms and phrases related to online software keeps growing rather than shrinking. In order to make sense of it, we really need to focus on understanding where different concepts fit in from a big picture perspective. For example, I am often asked if Apprenda’s SaaSGrid competes with Amazon’s EC2 or now with Microsoft’s Azure. For any long time readers, I wrote a taxonomy article a while back that distilled SaaS Platforms (which have materialized under the PaaS banner as of late) a bit beyond the generalized SaaS platform moniker. Similarly, I think the same is required of the current ‘cloud’ market space, although a bit more high level. Robert Anderson had a good post a little while back that distilled some of this, as did Peter Laird via a follow up to Anderson’s post. Despite the quality of these posts and and their approaches to this taxonomy problem, I think the issue requires a touch more refinement and clarity.

The reason this is important to me is because I hear a variety of cloud oriented acronyms and words tossed about with little regard to what they mean, what their relationships are to each other, and how they bring deliver value to varying market constituents. To start off, let’s rattle off a short list of things to address: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Now, for a snapshot of definitions (and a bunch of very good links that I recommend everyone follow, despite how trivial the term may seem):

  1. Infrastructure as a Service - Traditional computing resources such as servers, storage, and other forms of low level network and hardware resources offered in  a virtual, on demand fashion over the Internet. IaaS in a general sense, provides the ability to ’summon’ resources in specific configurations at will and delivers value similar to what one might find in a traditional datacenter. IaaS’ power lies in its massive on-the-fly flexibility and configurability. It can be equated to owning a magic wand that could conjure up a variety of network and server resources in zero time and occupying zero space. Examples include services like GoGrid, Amazon’s EC2 and even S3 ( as a storage infrastructure play)
  2. Platform as a Service (The space I play in via Apprenda’s SaaSGrid platform) - A runtime-system and application framework that presents itself as an execution environment and computing platform available over the Internet with the sole purpose of acting as a host to application software. Generally, PaaS focuses on enabling SaaS applications, so many well-expected core concepts, such as abstracting away multi-tenancy issues, are expected of any reasonable PaaS offering. Another key concept for PaaS is that it needs to run semi-arbitrary instructions. If it ain’t runnin’ code, it ain’t a platform! (Now, I’m using ‘code’ loosely here. For example, a drag and drop business process editor could be considered as living on the edge of a platform definition, but a set of marketing tools and human drive services is most definitely not a ‘SaaS Platform’) This beyond the definitions offered in some of the aforementioned articles that PaaS deals with scale issues. Examples include SaaSGrid and Google AppEngine.  There are also some higher level PaaS offerings with non-traditional IDEs and coding paradigms like Bungee or Force.com that require (IMHO, unnecessarily) new knowledge, skills, and component frameworks.
  3. Software as a Service - Specialized software functionality delivered over the Internet to users who intend to use the set of delivered functionality to augment or replace real world processes. Generally speaking, users within the SaaS space are aggregated into ‘tenants’, or bodies of 1 or more categorically related users. Think Salesforce.com CRM, or SugarCRM.

So we’ve got these simple definitions out of the way, and in isolation they make sense, but how do they relate to one another and who cares about each? Diagram time!

Triangles and people, of course
(bigger)

We can definitely take a stack approach to this relationship; IaaS offerings can create a foundation for PaaS offerings, and PaaS offerings can do the same for SaaS offerings. Now, notice the curved arrows to the left of the triangle diagram? That identifies the lack of a tight coupling: SaaS offerings can be hosted through a PaaS, or can hop-scotch PaaS and build a delivery architecture on top of raw IaaS. Furthermore, IaaS can be replaced with raw metal (traditional infrastructure) by both PaaS and SaaS layers that might directly depend on it. This hop-scotching can lead to confusion about the competitive nature of offerings across these buckets (I’ll discuss that later). Another thing to note in the diagram is the use of ‘people’ icons which identify which constituents actually care about which part of the stack (clearly, all care about all parts, but some are more directly affected than others - and more importantly, some constituents jobs are defined by their usage and even expertise in a particular piece of the stack). SaaS tends to cater to end users looking to satisfy some business, general process or even recreational need. PaaS, however, primarily interfaces with application developers and software companies, providing them the tools and run time to quickly build SaaS offerings, while IaaS tends to focus on identifying value to network planners that need to organize specific, lower level resources in support of PaaS or SaaS offerings. These are the ideal constituents in the value stack. However, I frequently bump into cross talk, which is something that needs to be addressed.

So do PaaS offerings compete with IaaS offerings (i.e. can a SaaS offering be built without using a PaaS offering). As I described earlier, the answer is yes but with a dash of hesitation for good measure. When I’m asked the question (or on occassion, told that this is fact) “Does SaaSGrid compete with EC2?”, I always pause and search for a good way of describing the relationship. Essentially, we (Apprenda) can utilize an IaaS to deploy our SaaS platform as a PaaS offering, so in one respect, it’s a resource for us. On the other hand, someone can build scaffolding around an IaaS offering and create a SaaS offering. For example, you might cut a new server image on EC2 for each customer your provision to your new SaaS offering, and route subdomains to those images, and integrate it with some sort of authentication framework, and wrap all of this in some sort of billing and payments engine taking a Papier-mâché and duct tape approach to your offering.  OR, you can deploy it on top of a specialized layer like SaaSGrid (PaaS) that is built to deal with SaaS problems and requirements out of the box. So are they competitive? IaaS offers some semblance of a solution, but requires significant overhead compared to PaaS value propositions and is not built to inherently solve SaaS problems. My answer is definitely not. It’s like saying hard drive manufacturers are competitive with relational databases; when writing an application, you can choose to write straight to disk instead of a relational database (which depends on non-volatile storage like hard drives). However, you lose all of the benefit of the specialization presented by a database like indexing, query languages, searching and aggregation, backup functionality, etc. Generally, you’ll start asking questions like: how can I quickly access and search data I saved directly to disk? Oh, just download a library that indexes the data! What about a structured way to change search criteria? Easy, just create a domain specific language to search the data on disk. Sounds like someone is putting together a  Papier-mâché database ontop of straight disk access… Is writing straight to disk sometimes warranted? Absolutely. Most of the time, however, its that someone made the mistake of pitting hard drives against databases when they solve very different problems.

There are some blurry lines like Microsoft Azure, where they neatly span parts of IaaS and PaaS, but don’t offer a pure solution for either. For example, Azure doesn’t solve a majority of SaaS problems like tenancy in your architecture, customization, or business process issues like billing or migrating customers to a new version of code. Similar to the SaaSGrid to EC2 relationship but not as clear cut, something like SaaSGrid can utilize Azure for certain deployment needs reducing the notion of any competitiveness.

Do you find this articles categorization accurate? Do you feel that IaaS offers a valid substitute to PaaS for those writing software as a service offerings?

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts
SaaSGrid Is Here!
Good “Top 10″ Resource for SaaS Providers



Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Sinclair,

I think that your Cloud Categorization is quite accurate, in fact, I’m glad to see the concept of the “Cloud Pyramid” that I have been championing for some time being used. See this (older and a bit outdated) presentation A few months ago, I added two more categories to the pyramid for Cloud Aggregators (like RightScale) and Cloud Extenders (like SimpleDB). Aggregators will see some more success, I predict, in 2009 as they look to diversify their offerings to encompass more Clouds (not putting all of your eggs in one basket sort of thing). Extenders (services that require the use of other Clouds) will also continue to grow as ancillary services emerge.
To answer your other question, IaaS and PaaS will continue to be quite different beasts IMHO as they offer a different type of service and control. You liken IaaS to bare-metal (there are obviously huge difference but from the control perspective, they do somewhat equate). Platforms offer a bit less control (e.g., you have to code in Python for AppEngine or use Force.com’s proprietary language). Platform plays can be built upon Infrastructures (whether cloud or traditional).
We will definitely see a lot of intermingling over the next few months. I think things will get blurry once again in terms of offerings can span multiple layers of the Cloud Pyramid.
Good article! Got me thinking!

-Michael Sheehan
(Technology Evangelist for GoGrid)

Michael,

Thanks for the link to the presentation! You’re absolutely right in terms of lines getting blurry and the interactions between the layers. I suspect that good marketing can help ISVs identify how different partners in the pyramid might help them in building their SaaS offering. In the future, it should be as easy as recognizing that JBoss is hosted by managed service providers and that I can deploy to JBoss installs on a variety of cloud or traditional providers. We don’t confuse JBoss with say, Rackspace; we all understand that they are distinct entities.

Sinclair,

Great post, goes a long way towards decluttering the space.

Hi,

I think that Categorization is good. I think there will be some sort of subcategory in PaaS. I named for myself as with community and without community. My point is that if you made your application on Force.com you have instant distribution channel to Force.com community. And you have access to some basic data of application subscriber. With GAE you have application gallery and access to Google Account, but I think there is a difference. Okay, maybe it is useless to categorize in this way. I am not quite sure about it. What do you think?

Hi Jan,

While I wouldn’t use the presence of a channel as categorization criteria (since it’s not a technical attribute of the PaaS offering), I think you’ve identified an important part of the decision making process when evaluating PaaS offerings. Having a good channel is important for distribution, but I suspect PaaS providers not built around a central offering (like Salesforce) will employ unique business models to tap into even more expansive distribution channels offered by partners.

[…] Yesterday’s blog post by Apprenda CEO Sinclair Shuller is an interesting attempt to clarify the hodge-podge of terms that tend to be thrown around almost interchangeably; Cloud, SaaS, PaaS and more. […]

It is great to see the industry coming to a consensus around cloud and SaaS terminology. We are starting to see our legacy enterprise competitors abusing the language to stall the market and compensate for decades old technology that can’t hold a candle to the benefits of true SaaS and cloud computing. The most common offense, trying to pass off ASP or a legacy on-premise app with a bolt-on Web front end as SaaS. Customers aren’t fooled, but there is enough uncertainty in the market that categorizations and definitions like this are very useful.

Rhett
Service-now.com

Rhett,

I definitely see redefined usage all over the place. It’s a tactic, as you mentioned, the focuses on creating uncertainty/confusion and can generally slow things down.I look forward to when the industry really shakes out the obvious poor definitions, but that’ll take some time.

[…] здесь , здесь и (наиболее понятный текст) здесь. Каждый из авторов претендует на понимание […]