Multi-tenant, multi-instance: the SaaS spectrum
- Summary:
- Time to slaughter the sacred cow: multi-tenancy isn't the defining ingredient we all thought it was in SaaS and cloud architectures
This doesn't mean that any single-tenant architecture will do. But the archetypal portrayal of SaaS — and by extension, public versus private cloud — as a good-vs-evil battle between multi-tenant purists and single-tenant reactionaries is a gross over-simplification. It turns out that SaaS is more of a spectrum in which many permutations of multi-tenancy and multi-instance can happily coexist.
Understanding that spectrum is important when evaluating cloud architectures, whether internally within an organization's own IT infrastructure or when assessing a potential SaaS or cloud provider. This post aims to bring some clarity to the topic.
The magic of demand pooling
Multi-tenancy has always been at the heart of the better economics of the cloud, because it allows the magic of a phenomenon called demand pooling. Just like hot-desking in a busy office, this ensures that every resource is used at maximum capacity — when it's not being used by one tenant, then another can take over.
With a sufficiently large and diverse population of tenants, demand pooling evens out all of the individual spikes and troughs in their usage. A variety of business cycles, timezones and usage patterns will ensure that there will always be some tenants busy enough to take up resources at times when others' workloads are winding down.
Demand pooling was one of the reasons for the early success of multi-tenant software-as-a-service vendors, who came to market long before the rise of cloud computing infrastructure providers. People who signed up for vendors such as Salesforce.com, WebEx or NetSuite each received the same service (often derided by conventional software vendors as 'cookie-cutter'). Customers could configure the application to behave in custom ways, but the functionality available to everyone was identical and their usage was pooled.
Mainly because their competition came from managed hosting providers of traditional client-server software, this became the totemic test for 'true' SaaS. If someone signing up for the service was able to request a custom version that was individually dedicated to them and not interchangeable with any other tenant then clearly it was not a multi-tenant offering.
The rise of multi-instance
But behind the 'black box' of the service interface, a more complex story was hidden away. Concealed behind the scenes, there were many variations between SaaS providers in the detail of how the multi-tenancy was architected. So long as it didn't impact long-term performance, these variations were more a concern for the provider than for the customer. But in many ways they contradicted the clear-cut message being given out in public about multi-tenancy.
The rise of public cloud infrastructure-as-a-service (IaaS) providers such as Amazon Web Services blew the cover on these trade-offs, as new choices emerged in cloud architectures. IaaS still gives you all the benefits of multi-tenancy at the infrastructure layer — and the same restrictions, in that you don't get an option to customize the underlying servers. But what you put on top of that layer is entirely up to you.
IaaS therefore presents an entirely new alternative to the traditional SaaS model. Instead of hot-desking within the constraints dictated by the application vendor, the IaaS customer can bring in their own pop-up application furniture to run on as many servers as they need for as long as (and no longer than) they need that resource.
SaaS vendors had always used virtualization in their own infrastructures. Spreading the multi-tenant workload across racks of low-cost commodity physical servers was always the simplest way of achieving cloud economies of operation. Some, like Salesforce.com, scaled up the size of their multi-tenant instance as they grew to take on more and more customers. Many others scaled out by replicating new instances as their customer base expanded. Eventually, even Salesforce.com grew so large that it had to spawn a second instance, then a third and so on. For established SaaS providers, multi-instance architectures became a fact of life.
SaaS as a spectrum
This infrastructure was still multi-tenant from a customer perspective. Behind the 'black box' service interface, the provider's IT management software distributed the computing workloads across its racks of servers on its own terms. But it quite often happened that the most efficient configuration for larger customers was to run that customer's instance on a dedicated server. Deep within the multi-tenant infrastructure, some instances were reverting to single tenancy.
Many vendors have gone on to make a virtue of this architectural happenstance by offering it as a customer benefit — perhaps to give more flexibility on upgrade timings, to offer a more stringent SLA or report customer-specific service level metrics. Even Salesforce.com has now decided to do so with its newly announced Superpod.
Thus it becomes clear that multi-tenancy is not the whole story; SaaS is a spectrum all the way from one extreme of the monolithic single multi-tenant instance that supports every single customer, all the way across to the opposite extreme of multiple identical instances each supporting one customer as a single tenant. So long as all of this infrastructure is implemented behind a 'black box' service interface that leaves the provider free to move customers from one instance to another at will, then the arrangement still conforms to the original principles of SaaS.
Where it gets a little more complicated is when the degree of multi-tenancy varies within the stack. Many traditional client-server vendors such as Oracle and Microsoft have implemented SaaS using a hybrid architecture in which the application servers are multi-tenant but each database is a single-tenant instance. These single-tenant databases (the model is sometimes called 'isolated tenancy') are then virtualized across a multi-tenant physical server infrastructure.
The general consensus in SaaS circles has been that if those databases are customized to the needs of individual customers then it does not qualify as 'true' SaaS. The instance ceases to be interchangeable, which breaks the 'black box' principle.
Angels on a pin
But in a modern, virtualized architecture in which databases can be spun up and down on demand, this distinction starts to look as relevant as querying the number of angels that can dance on the head of a pin. As cloud architectures advance, there may be cases where economy is best served by spinning up single instances rather than using multi-tenancy — running web server instances on ARM server processors is one potential example. Therefore it may be that multiple instance will trump multi-tenancy as the defining characteristic of cloud application architectures.
Tnis point of view is reinforced when you consider the fix a vendor like Salesforce.com has got itself into by engineering multi-tenancy into its application architecture. It's ended up with a monolithic, scaled-up architecture that's so proprietary it can't take advantage of many of the technology advances in the database layer that have evolved in the years since it first started building its application.
In comparison, the multi-instance approach allows a SaaS vendor to take full advantage of all the pooled innovation that takes place at the infrastructure layer. There's arguably even more of an advantage if a vendor runs its multi-instance architecture on open-source platforms such as OpenStack and Open Compute. Indeed we learned this week that Salesforce.com is set to join the OpenStack community although its reasons for doing so are unlikely to be as radical as some have speculated.
None of this gives a pass to any vendor that seizes on the multi-instance model to shirk on the pressing need to evolve its client-server application. But that's quite another spectrum — from client-server to cloud architectures — which deserves a post all of its own. See the third and final post in this series, From client-server to cloud: SaaS evolution.
