Thanks go out to Richard Goering for his recent blog post about Hybrid-SaaS. At the end of Richard’s post he thought a definition of the different layers of the stack would help, so this is a much simplified series of summary descriptions for each of the layers.
The Cloud Computing Stack
Starting at the beginning, below is the three layer Cloud Computing stack. We start at the application level with the Software-as-a-Service (SaaS) layer. I recently learned that the term was coined by David Thomas, (CEO and Founder of Intacct, now at TechAmerica) in a “gathering of the clans” at the salesforce.com offices in San Francisco involving Marc Benioff and a number of other early SaaS leaders in the early 2,000’s. The objective of the meeting was to come up with a term to differentiate themselves from “ASP“s, but I digress.
SaaS is the delivery of the end-application within a browser. Next down is the Platform-as-a-Service (PaaS) layer and represents a collection of development tools, API’s, and resources used to create SaaS applications. Finally, there is Infrastructure-as-a-Service (IaaS); a collection of (usually) virtualized compute, network, and storage resources.
This is the piece of Cloud Computing that we come into contact with everyday (every hour!?). It is Facebook, Google Docs, LinkedIn, Virgin’s online booking app, Expedia, etc. It is a remote application accessed and used via a common web browser. There are no downloads, no installations, and no licenses to deal with. Although consumer applications do not have Software License Agreements (SLA), many B2B (Business-to-Business) apps do have SLA’s, especially when deployed throughout an enterprise.
Implicit in the fact that SaaS is remote, and nothing needs to be installed - no servers and no IT required. Two of the especially sweet reasons to go with SaaS.
Within each application there is the core functionality that delivers the value of the application. The app engine, if you will. This holds the secret sauce of an application, the core algorithms and differentiated functionality. Outside of this, there is a varied collection of fairly standard components (see diagram below).
There are usually at least two interfaces or views of the app, and often there are more depending upon privileges . An administrator view and a user view. Below this layer is a collection of common services, such as Identity Management, Access Control, Analytics, etc.
All of these components need to be seamlessly integrated for usability and security purposes (why bolting something together around a Google Group, for example, doesn’t work). Security needs to be integrated across the entire app to ensure functional and data integrity.
Last, but not least, there will be a database that underpins everything. The database is on the boundary between SaaS and IaaS and is commonly MySQL in most SaaS applications.
The entire app must be “infinitely” scalable. Meaning that any number of users can start using the application at any given time. In the bad-old days, in order to manage any spiky traffic, this meant leasing a whole mess of servers from a hosting provider. Now we just develop the app on a scalable provider, such as Amazon’s EC2 and we’re good to go…as long as your credit card doesn’t max out
SaaS vs Client App Development
In my last blog post, I gave a collection of reasons why many enterprise software applications will have a hard time converting into a SaaS application. The greatest technical reason is architectural - moving from a single-user client app (”single tenant”) to a mult-user server-based app (”multi-tenant”). A Service Oriented Architecture (SOA) may help this transition, but there’s still a lot of work to do…in fact, the reality is, the endeavor will be a complete re-write. (As a point of reference, I was talking to an Enterprise Software developer the other day, and he said his application had 11 Million lines of code…)
I hope this was a useful summary. It is in no way intended to be exhaustive.
If you know of any useful references, please add them in the comments.
Next up, Platform-as-a-Service, or PaaS.
Connect with me:
This post was written by James Colgan on April 26, 2010