It seems the phrase “in the cloud”, sadly, has become a marketing-hyped euphemism for “the Internet.” I say sadly because the use of cloud to refer to every and any service delivered over the Internet dirties up the cloud. It obscures the intent of cloud computing and makes it difficult for technologists in the trenches to get a handle on how cloud – both external and internal – can provide benefits and solutions to problems they have right now. The very loose use of the term means that every last little web application on the web could be (and sometimes is) called “cloud computing”.

And while that may be technically true based on the very loose definition of “compute resources”, the problem really is in the use of “cloud” to refer to very different architectural models that just all happen to fit a very broad definition.

Of late, the use of the term “cloud computing” to specifically mean SaaS (Software as a Service) is one that’s not only getting under my skin but causing a great deal of irritation sitting there. Every trade publication, every analyst and research firm has been digging into the adoption of cloud computing and every one of them ends up with essentially the same conclusion: organizations aren’t ready to buy into it. Yet.

But then we see news about “cloud computing” like this report titled, “IT spending on cloud computing up 22% in 2009 to $9.6 billion” on TechRepublic. The entire report is about SaaS. Period. There’s nothing in it about the market for IaaS (Infrastructure as a Service) or PaaS (Platform as a Service). It’s all about SaaS. And SaaS is hardly cloud computing in the same way that IaaS is cloud computing. This lack of qualification between the two makes the market look much more robust, mature, and mainstream than it actually is. It is misleading, and that can eventually backfire by leaving would-be customers to continue to question viability long after maturation because they can’t trust the information.

ARCHITECTURE MATTERS

There is a very real difference between the architectural models and benefits of cloud computing (i.e. compute resources as a service) and multi-tenant hosted software, a.k.a. SaaS. These architectural differences are important to every discussion we have about cloud because they affect the security and costs of cloud computing. Those architectural differences manifest themselves with very different issues surrounding integration, data integrity, internetworking, and efficiency.

Invariably when the question of “cloud” security comes up someone brings up SaaS and the fact that organizations have been safely using it for years. This fact is then used to dismiss the very real concerns surrounding security issues and cloud computing. Let’s take just a moment to consider the differences and why this is such a problem.

1. SaaS is all about the database The way in which multi-tenant hosted software like Salesforce.com and SugarCRM provide security and services is at the database layer. The software, the interface, is the same for every customer. Customization is accomplished through data-driven layout and field definition. The networking stack, the servers, the operating system is all the same. Every customization, every unique process, every branded page is driven solely through data in the database. Security in a SaaS is inherently tied to the robustness of the security model on the database.
   
   Database security is well-understood, well-known, and very mature. The ability to restrict access down to a single-cell if necessary has long been available and it is this flexibility in database access security that makes SaaS possible.
   
2. Many well-known SaaS offerings are not about customer data Another argument tries to dismiss security concerns by pointing out the widespread use of hosted services like Ceridian (payroll and HR) and Concur (travel, expenses). While it is true that these SaaS vendors have long been popular amongst a wide variety and very disparate set of industries, both are focused on employee data, not customer data. While employers are certainly protective of and concerned with the security of their employee’s data, this data is not a competitive advantage, it is not tied directly to revenue, and it is governed by a completely different set of regulations. It’s a completely different set of risks that are managed in a completely different way.
   
3. SaaS has a smaller attack surface IaaS has to expose a lot more of the stack to end-users while SaaS has to essentially expose a web  interface. Even integration with SaaS software is via the web (SOAP, REST, etc…) and in a way that is very well controlled. IaaS? There’s very little control because the provider has no idea what application you’ll be deploying. As Hoff pointed out via Twitter, this does not prove that SaaS is more secure even though it seems logical to deduce that; it’s just a different set of risks that need to be managed. Understanding the differences in what those risks are is important when choosing a provider or implementing a cloud model internally.
   
4. IaaS introduces the unknown SaaS is well-understood. It’s software stack and therefore its potential vulnerabilities are well-documented, well-understood, and relatively easy to protect if you know what to look for. SaaS, because it is essentially just hosted software, has been very well exercised over the past decade. Its vulnerabilities and potential points of exploitation have been discovered, tested, exposed, and closed. IaaS, however, introduces a new layer where vulnerabilities are not well-understood, not well-known, and not-well exercised. The virtualization layer is completely new and should be considered an “unknown” risk at this point.
   
   The “sharing of resources” in a SaaS model is really about sharing the database, and even that is strictly contained by very granular security. Code is shared, but in such a way as to make it less relevant. I don’t have to, as a customer, worry about the quality or security of an application of another organization or individual that may be executing on the same hardware as mine and may, through the exploitation of some yet unknown virtualization vulnerability, cause my application to become another 'bot in a giant distribution network for malware.
   
   The “sharing of resources” in cloud computing is about sharing everything – from the network to the operating system to the infrastructure. Every aspect of cloud computing is about sharing and reusing resources in a way that makes it efficient for both the provider and the customer.

The goal of SaaS is to deliver software. But the software it is delivering is pre-defined. It’s a constrained set of features/functions that are designed to perform a specific task. IaaS, on the other hand, is about delivering on-demand computing resources for use in whatever way the end-user/customer wants to use it.

They are not the same – not architecturally, not in implementation, and not in the issues they bring to the table.

SaaS MAY BE A CLOUD BUT IT IS NOT “THE CLOUD”

NIST has recently published a working definition of cloud that takes pains to distinguish between the various subtypes of cloud computing:

Cloud computing is a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is comprised of five key characteristics, three delivery models, and four deployment models.

The document goes on to describe, succinctly and with what I think is more than good enough accuracy the characteristics, delivery and deployment models. I could (and may in the future) argue against the inclusion of “applications” in the definition of “computing resources” and am fairly certain it is included solely because people assume SaaS is cloud computing but for now I’ll let sleeping dogs lie. The important part of the definition, I think, is the separation and qualification of each type of “cloud computing”. NIST provides this type of delineation because architecture matters when you’re discussing things like security, reliability, and data integrity as well as who the end user of the cloud service really is.

When organizations ask for direction and guidance on building their own “clouds” they aren’t asking about deploying a SaaS. They want to create an on-demand, dynamic data center that affords them many of the same benefits as “cloud computing” – efficiency, sharing of resources, automation. They want the IaaS version of cloud computing, not SaaS or PaaS. But the lack of qualification around the term “cloud” confuses the issue and makes it difficult to have a conversation about specific models.

No wonder people aren’t flocking to “the cloud” – they aren’t even sure what the heck we mean when we say it because we use it as a broad brush with which to paint every service on the Internet these days.

The more I hear and the more I read and the more I see the dismissal of very real issues with IaaS cloud computing that need solutions because of the successful adoption of SaaS the more I think that SaaS either needs to be excluded from discussions of “cloud computing” or that we need to do a better job qualifying the term “cloud” when we discuss it.

The issues with SaaS are not the issues with “IaaS cloud”; they are very different simply because they are two different architectural models with two very different goals. Applying the success or failure of one to the other isn’t realistic, nor is it benefiting cloud computing as a paradigm in any way to mix them up.

Related blogs & articles:

• NIST Working Definition of Cloud Computing
• Let go, let cloud
• The Cloud Is a Fickle Mistress: DDoS&M
• Infrastructure 2.0: As a Matter of Fact That’s Not What It Means
• As a Service: The Many Faces of Cloud
• Cloud Strategy: Apathy or Architecture?

Read the original blog entry...