Cloud Apps Don't Necessarily Scale Automatically

Considering all the marketing hype about cloud computing, some might be left with the impression that apps, once deployed in the cloud, automatically scale up and down with demand. Not true. If this topic is of interest to you, please have a look at my latest blog post at The Cloud View. Here, I provide a more complete list of thoughts on this topic that stem from my quotes in a recent article at CIO.com.

CloudTrends Tracks Cloud Computing Trends

I wanted to make my readers aware of a great new way to watch who's winning in the cloud computing wars: CloudTrends. In particular, I think it's interesting to keep an eye on the number of cloud computing jobs, both by platform and by language, that appear every week. Why? Because beyond all the hype, the trend in the number of jobs available for each cloud is a true indicator of its health and growth.

Apps.gov = Huge Step Forward for Cloud Computing

Please see my latest post at The Cloud Option about federal government cloud computing: Apps.gov, FISMA compliance, Salesforce, and Google.

Enterprise Demand Driving Vendor Consideration of Internal Clouds

Please see my latest post at The Cloud Option about an emerging micro-trend in cloud computing platforms—the licensing of PaaS platforms for use in private data centers.

Introducing The Cloud Option

I have moved my blogging activity over to The Cloud Option blog. Please follow me there directly, although I will announce new posts in this blog as well.

-- Steve

BEA's Project Genesis SaaS Platform at SaaSCon

Sorry I haven't been posting much (actually at all). I've been hard at work with my new job as BEA Systems' Director of Technology, Project Genesis SaaS Solutions. We will be be at SaaSCon in Santa Clara, CA from March 24-26. If you are thinking about building SaaS, this would be a good venue to learn more about the compelling features of the Project Genesis SaaS platform. We are also putting together an invitation-only talk on this project aimed specifically at ISVs that are building SaaS applications -- if you are interested in attending, please contact BEA's ISV support group.

The Multi-Tenancy Myth Exposed

The scenario: You've been tasked to build an on-demand application, or software as a service (SaaS). You are new to this, so you start by reading countless works from so-called technical experts. One article and blog post after another all seem to promote the myth that a sound SaaS design is synonymous with multi-tenancy, an application architecture that allows one instance of the application to support many concurrent customers, or tenants. Why do I call this misconception the multi-tenancy myth? Please read on and see if I can convince you to agree with me.

The Big Picture

Let me start by stating that multi-tenant architectures certainly have their place in the rapidly emerging SaaS world; they've proven their worth with very successful products such as Saleforce.com's Customer Relationship Management (CRM) service. But after looking at SaaS from different business perspectives, researching alternative technologies, and experimenting with different development designs, my thinking has gradually evolved. When I first started working in this field, I believed that "multi-tenancy is the way to go" for SaaS. But now I believe that "multi-tenancy is sometimes the correct choice, and in others, it's the exact wrong choice." Recent trends identified by major IT analysts and strategies announced by major software vendors seem to underscore my viewpoint. Here's what I mean.

The SaaS-Wary Enterprise?

Currently, I work for Computer Sciences Corp. (CSC) as the CTO of SaaS Business [UPDATED January 2008: I now am the Director of Technology, SaaS, at BEA Systems]. In my job capacity, I talk with a lot of SaaS providers. Most notable SaaS vendors that I've talked with to-date state that their target markets are small- and medium-sized businesses (SMBs). Many have told me that, while they certainly welcome business from larger companies, they do not expect significant revenue from bigger customers. Accordingly, the bulk of SaaS revenue is from "long tail" sales to SMBs. Sure, it's true that SaaS is also penetrating the enterprise space as well, but to a much lower degree and typically as departmental or business unit implementations. In other words, centralized IT departments within large enterprises seem to be shying away from SaaS for now. Why? I'll list just a couple of reasons.

First, consider the culture of a typical enterprise's centralized IT department, the people that decide what approach to use for mission-critical enterprise applications. The enterprise IT staff's primary value to the organization is the deployment, configuration, and ongoing maintenance of traditional, complex, on-premises software. It's obvious that their job security is directly threatened by simpler, outsourced SaaS solutions. Hmmm, let's see: on-premise = keep my job, or on-demand = get a pink slip. Which would you choose?

While the previous argument holds weight, let's naively assume that job security isn't a factor in a decision making process that considers an on-premises solution and competing on-demand solution. What else might factor in? In my opinion, the biggest SaaS-related issue for the enterprise is control, or lack thereof. Enterprises don't yet seem comfortable with 100% outsourced on-demand solutions that co-mingle their data with other customer data in multi-tenant databases, manage everything outside their firewall, and expose their organization's crown jewels to the public Internet. Don't agree with me? Oracle Corp., the #1 enterprise-focused software vendor in the world, has publicly been stating similar sentiments. According to Oracle president Charles Phillips, "Multi-tenancy has nothing to do with on-demand. [It is] a convenience for the vendor. Whether they put all customer data onto one database or onto multiple databases is of no value to the customer. In the enterprise it is the opposite. They do not want to put all their data [into the same database] as their competitors. It is illegal in some industries."

Perhaps you would then argue, if multi-tenancy is so scary, then please explain to me why applications based on multi-tenant architectures such as Salesforce.com's CRM service are doing so well? Easy. There are lots and lots of SMBs that have done without CRM forever because, until SaaS solutions, there wasn't anything convenient and affordable to meet their needs. More simply put, SaaS success to date is largely due to consumption by those that don't have anything to lose. A tougher sell for SaaS is currently pending, as SaaS vendors try to sell upstream to large enterprises and chip away at accounts held by traditional on-premise providers. Should be interesting to watch.

The primary point I'm trying to get across here is simple: Understand your market. If you want to sell SaaS to SMBs, by all means, consider a multi-tenant architecture. But if you want to sell to the enterprise too, don't be surprised if the door slams shut when you say "multi-tenant."

What's a Query Got to Do With It?

Now that I've identified a business reason against multi-tenancy, let's focus on a technical reason when a multi-tenant architecture makes sense and doesn't make sense: scalability.

Generally speaking, applications that serve up SaaS are database-centric. The overall performance and scalability of SaaS is therefore dependent on how well you design the underlying application with respect to database mechanisms. And understand that with SaaS, the fewer resources that you can use to service a large number of customers = the greater economy of scale that you can achieve = the lower you can price your solution = the more customers you can appeal to = the more profit you can make. Basic arithmetic.

So what types of things affect the scalability of database applications? Many things, but in this post I'll focus on database application query patterns. I define a database application's query pattern as the set of queries that are at work to service application requests.

For some applications, such as online transaction processing (OLTP) systems, a consistent set of SQL statements execute over and over again, and with little variance. As long as you design these statements well (for example, using bind variables for run-time substitution of selection criteria), the overhead associated with query execution is trivial because database mechanisms cache optimized statements in memory and require very little CPU to execute the application. In other words, database applications with static query patterns generally achieve a steady-state after startup and scale well for hundreds, thousands, and even tens of thousands of concurrent users.

Next consider a data mining application. This type of application has a query pattern that is highly volatile because analysis activities generally issue ad-hoc queries that are consistently unique. As a result, the database system is forced to perform CPU-intensive parse and optimize operations for each query execution. Applications with volatile query patterns do not favor SQL statement caching and reuse, which translates to limited scalability.

Let's now bring this understanding of query execution and scalability back to SaaS and multi-tenancy. The types of applications that will scale well on top of a multi-tenant architecture are those that have static query patterns, not just for one tenant, but for all tenants. CRM applications are a great example of this, and Salesforce.com's CRM performance statistics prove this. But applications that will not scale well on top of a multi-tenant architecture are either those that have volatile query patterns for each tenant, or static query patterns for each tenant but patterns that vary among tenants; in either case, the net sum is a volatile query pattern across the entire database system. Enterprise content management (ECM) systems have highly customized query patterns for each tenant, and as a result, have yet to be successful in an on-demand model.

Think Before You Dive In

In conclusion, I hope it's clear that the choices you make about the underlying architecture for a SaaS application should consider both technical and business factors. If you reflect on one without the other, your chances of success are at risk. In my next post, I plan to present a technical alternative that's gaining acceptance as an alternative to multi-tenant architectures, something called virtual appliances.