Monthly Archives: March 2011

SaaS, Paas, IaaS: Which of These Things is not Like the Others?

There’s an interesting debate raging over at Focus.com (a newly formed site that is dedicated toward facilitating the sharing and exchange of information as well as provide access to subject matter experts). The question was posed, “Is Facebook a cloud?” Clearly, there’s differing opinions on the response to this question, which makes for good reading and opens the door for discussion. Incorporated into this question is a underlying skepticism that I addressed in my entry, Scale is the Common Abstraction of Cloud Computing, which is does Software-as-a-Service (SaaS) really belong within the definition of cloud computing?

Let’s use Facebook as the reference model for answering this question. As I posited in the discussion at Focus.com, how Facebook chooses to implement their application is mostly irrelevant to us as a consumer of that application. To make assumptions about their application’s architecture or to incorporate knowledge from interviews and articles about how Facebook works into our decision to call Facebook cloud acts to introduce irrelevant information into the discussion. To incorporate SaaS or any application under the moniker of cloud merely begs the question of the value of the term to the industry and the role marketing is playing on formulating this industry.

Indeed, SaaS by the nature of what it is should relish the abstraction of itself from its implementation. After all, what they’re selling customers is their ability to provide a highly-available and easily accessible application. Now, as I also posited in the Focus.com discussion, Facebook also provides a platform for authenticating users and authorizing access to their data. This component of Facebook I would be open to incorporating into the cloud discussion under the moniker of Platform-as-a-Service (PaaS). However, due to ambiguity, to blindly state that Facebook is cloud without clarifying that you are discussing the PaaS component of Facebook would leave one to believe that you are discussing the SaaS component of Facebook, which I would continue to argue does not belong to the class of things that are incorporated under the cloud moniker.

I have danced around this topic for some time now, but this discussion finally pushed me to come out against including SaaS in the definition of cloud computing moving forward. Software-as-a-Service is merely a consumer of cloud computing and not a component of cloud computing. Or, as we like to say in the architecture world, SaaS uses cloud, not SaaS is a cloud. Hence, the Facebook application is not cloud.

I realize there’s going to be a lot of unhappy campers who read these words, but having written an entire book on semantics and ontology, I would be remiss if I did not raise my hand up and say that we need some aspect of rational thought about what’s in the cloud class and what’s outside the cloud class. Now, since no one group or person officially owns the definition of cloud computing, SaaS vendors will most likely to reject this entry and continue to stomp all over the term in favor of being included in the class of “what’s hot”, which is most likely the root cause for Larry Ellison’s statement that the computer industry is more fashion-driven than women’s fashion.

In Consideration Of Transitioning Email to the Cloud

So it seems that with regard to Kundra’s 25-point plan and the mandate to move three applications to the cloud in 18 months that email seems to be the primary target for the first transition.  The decision to move email into the cloud is a relative no-brainer.  Email needs to be ubiquitous, accessed across a wide array of client devices, needs to scale out to support the growing community of users and demand for storage, and, most importantly, needs to be available.  So, the question isn’t should you be transitioning your email to a cloud-based solution, but instead, what is the appropriate service—SaaS, PaaS or IaaS—and deployment—private, public, hybrid, or community—model for your cloud-based email solution.

The difficulty in this decision is comparing the alternatives given that there are many tangible and intangible factors.

Software-as-a-Service (SaaS) options can be evaluated from a purely financial viewpoint.  That is, one can compare the following:

(number of seats * $/seat) / (cost of software (incl. annual license costs) + cost of hardware + cost of labor)

Given positive growth in the organization and taking into account requirements to scale the email solution to support the growth in users, at some point it costs more for the SaaS solution than the in-house solution (see Chart).  Also, there’s the benefit from the tax implications for moving the dollars from capital expenditures to operational expenditures and the present value of money not spent on hardware and labor that can be used for other activities.

The intangibles for SaaS solutions include trust, availability, support, user experience, accessibility, etc. Ultimately, you are relying on a SaaS provider to ensure that your email is available when you need it.  Given that email has become a critical tool for communications, lack of availability can mean loss of business, missed business opportunities or delays in servicing customers.

A larger intangible issue is how management views email.  If management views email as a standalone tool for electronic communications, then the SaaS decision becomes much easier to make.  However, if management understands that email is part of a much larger unified communications strategy that incorporates voice, video, chat/SMS, mobile and presence, then selecting a single SaaS provider becomes much more difficult as this is not a single service, but a complete integrated set of services that need to be acquired.  That is, the SaaS provider must now deliver your telecommunications infrastructure as well as your email.

The final issue regarding SaaS alternatives for email is vendor lock-in.  Given how critical email has become as means for communication, if a single vendor holds all of your organization’s email it makes it very difficult to leave that offering should the need arise.  Migrating email boxes is a very expensive effort; certainly one capable enough of wiping out any past savings that occurred from going with a SaaS vendor in the first place.  Of course, these costs will drop over time as the need arises and the process becomes more automated.

Then again, even with a SaaS email provider you are still most likely going to want to provide your users with a single means of authentication with your own internal networks.  So, you’re still responsible for building and maintaining your own identity management and authentication methods that facilitate access for your users into the SaaS email environment and not force them to have alternate identities for internal and SaaS solutions.  Of course, you could always acquire Security-as-a-Service to mange this for you.  Then again, managing proliferation of external services is no easier, and indeed may be more difficult, than managing that set of services from a single internal data center.

Platform-as-a-Service (PaaS) offers some interesting opportunities for bringing your email to the cloud.  Typically, the available PaaS offerings provide unified communications capabilities so that you can develop an integrated suite of tools for your users that includes email, chat, voice mail, paging, presence, email transcription and voice dialing.  In addition, these platforms also are open enough to integrate cyber security and authorization schemes that limit data loss and promote ease of forensics and eDiscovery.  The benefits of the PaaS alternative is that it reduces the hurdles to entry, promotes rapid deployment, can scale on demand, and can integrate with existing telecommunications systems through SIP-based protocols.  The downside is that you will most likely need to design and support your own means of disaster recovery and continuity of operations.  Unfortunately, there are very few of these platforms available on the market at this time, but I expect this will grow as more companies begin to understand this option.

The final alternative, Infrastructure-as-a-Service (IaaS) only offsets the need for you to acquire, maintain and run the hardware for your solution.  You’re still responsible for acquiring and deploying the software and paying the licensing and maintenance on that software.  In addition, you still need to develop and acquire the infrastructure for your disaster recovery and continuity of operations.  Moreover, you may not even get to control where your data ends up physically residing or what other virtual machines are running on the same server hardware.  The good news is that you will have significant control over the virtual machine configurations and be able to secure access to them.

So, transition your email to the cloud? Sure, why not? But what service model will you use?  Once you decide what service model to use, will it be a public, private or hybrid deployment?  Suddenly, this seems like a bigger decision than initially perceived.