|By Dave Jilk||
|June 26, 2012 11:00 AM EDT||
Think back to when you were a kid. Remember that thing you thought, felt, wanted or did that you were embarrassed about? You probably worried that you were the only person in the world who had that thought, feeling, desire or behavior. It was your Little Secret. Only as you got older did you figure out that it was actually pretty common, that everyone did that, or felt that way, at least once in a while. And that maybe it even had a name.
If you're a nerd like me, you probably had more than one of these.
As we've talked to customers, prospects and vendors in the industry, we've realized that the Cloud has a Little Secret. It doesn't have a popular name yet. But I'm here to reassure you that everyone does it. And it's okay if you do it too.
Before I let you in on the Secret, let's start with a little history.
The "cloud" terminology has been around for a while, but it was broadly popularized when Amazon Web Services started offering its S3 storage service and its EC2 compute service. With these services, you could easily store data or run software without owning or managing the physical infrastructure. Quickly, Software-as-a-Service (SaaS) companies like Salesforce.com realized that there were similarities between their offerings (which had been around for almost a decade) and this new "cloud." So as not to be left out of the hype cycle, they started calling their offerings "cloud." Fair enough: indeed, with SaaS you don't have to manage the infrastructure or the software.
Lately, though, it seems that partisans of this model - I am talking specifically about SaaS that is shared-everything, and multi-tenant at the application and database level - are attempting to abscond entirely with the term. I've had industry analysts and others tell me that, for all intents and purposes, Cloud means multi-tenant SaaS. When I challenge this point of view by asking whether Amazon EC2 is "cloud," they mutter something about it being transitional, or mainly for online games, or for high-performance computing. Certainly it's not where enterprises or ISVs should be, according to this viewpoint.
Let's face it; shared-everything SaaS has a lot of advantages. It's easy to get started, you can access it from anywhere, the pricing model is subscription-based rather than license-based, and you don't need any technical skills or staff to use it. It just works. Standing Cloud uses Rally, Google Apps, Beanstalk and Desk.com. We certainly have no aversion to the model.
But there is another way to deploy software in the cloud and deliver it as SaaS. Forbes columnist Dan Woods and the folks at SugarCRM sometimes call it "Distributed SaaS." I like to call it "cloud-premises" or "virtualization SaaS" (vSaaS). I'm sure there are other names floating around, but none in common use.
The Naughty Little Secret of the Cloud is that people are deploying their applications as a distinct instance on Infrastructure-as-a-Service virtual servers. It's multi-tenant, but through server virtualization rather than application code, and therefore is not "shared everything." We've talked to many companies and ISVs who are doing this, and some feel vaguely embarrassed about it, as though they were doing something wrong. But they needn't feel that way. A lot of people do this, and they have good reasons for it, and it's nothing to be ashamed of.
For example, 451 Research analyst Carl Lehmann noted in a recent report that Exostar Corporation, a leading provider of cloud-based business-to-business collaboration solutions to the aerospace and defense industries, "began implementing a shift in strategy when it realized, after six years of trying a multi-tenant SaaS model, that it was unable to satisfy the needs of its top clients." According to Lehmann, issues of identity assurance, security and control of intellectual property combined to "make multi-tenant architectures suspect" in their industry.
Similarly, Interactive Intelligence, a provider of Communication-as-a-Service delivered under a virtualized single-tenant model, is winning against multi-tenant competitors, due in large part to their customers' need for control over the timing of upgrades, and strong preference for true data isolation.
Let's take a closer look at some of the reasons why this deployment model might be right for you and your application:
- Data isolation. Some customers are nervous about proprietary company information in a shared-everything application model. Indeed, every time the service has a feature update, customers are just one bug away from a potential data leakage problem: the isolation depends on the software code and the quality assurance procedures of the software provider. In IaaS, data is isolated via virtualization, and the hypervisors that provide the virtualization are vetted much more broadly than the application code.
- Control over upgrades. This is the reason we hear most often. Invariably, a shared-everything SaaS application is upgraded on exactly the day you most need to be productive. Everything takes longer because the features work differently, and integrations / automations / add-ons actually break due to incompatibility. If the application is used broadly within an organization, a customer may want to train staff on the new version prior to launch. When an application instance is deployed separately, the customer controls when upgrades happen.
- Customization and configuration. Some firms must customize applications to match their business processes, either because those processes are a competitive differentiator, or because the cost of changing them to match an application is too high. Recognizing this need, Saleforce.com created the Force.com Platform-as-a-Service (PaaS) that allows applications to be customized or built within the Salesforce environment. But most SaaS companies do not have the resources to build this sort of environment, and their architecture may even preclude it. In contrast, an application deployed separately on IaaS is easy to customize and configure.
- Infrastructure lock-in. Shared-everything SaaS usually bundles the application subscription and infrastructure costs into a single monthly price, typically by number of users. End customers have no say in where the application is actually hosted, and if the infrastructure fails to keep up with the market with respect to performance, cost, and reliability, there is no recourse short of converting to a new application. Whenever you use a software application, you are locked into the application to some degree, but when the application is deployed as a separate instance on IaaS, you can at least move to new infrastructure if necessary.
- Development effort and pitfalls. Depending on how the application code is written, and what level of quality assurance resources you have available, converting an "on-premises" application to "multi-tenant shared-everything" can be an extensive and ongoing development effort. It will increase your time-to-market and may or may not be what the market actually wants, given the points above. Further (and if you have a sense of irony this is really quite funny), a lot of shared-everything implementations find that the database is a performance bottleneck and they end up having to "shard" it - i.e., split it into separate databases in some way. What's typically the easiest way to shard a shared-everything database? Yep, that's right: by customer. This deployment Franken-model is very difficult to manage.
- Single point of failure. If a shared-everything SaaS application is down, you and all their other customers are down, and there is pretty much nothing you can do about it. Even if you have some sort of data download, there is no application on which you can immediately get this data up and running. You're just going to have to wait for them to fix it. With a separately deployed application instance, in the event of infrastructure downtime you can simply redeploy the application on another IaaS service (temporarily or permanently) and restore a backup.
There's no question that shared-everything SaaS is a terrific model and works well in many circumstances. But the same is also true of separately deployed applications on IaaS. Maybe someday, someone will come up with a catchy name for this deployment model. But for now, just remember it's okay. Everyone does it.