It’s a mark of how much progress SaaS has made towards mainstream acceptance that vendors entering the space now proudly wear multi-tenancy as a badge of honor, rather than espousing the argument that it’s a side-issue that’s irrelevant to customers. But in their eagerness to put a check mark in the box, I do find that some vendors are inclined to use a somewhat limited definition of what constitutes multi-tenancy. Not that I want to veer into a ‘green crystals’ debate here about whose multi-tenancy follows the one true path. But the fact remains that there are ways of emulating multi-tenancy that deliver a quick-fix route to some of the advantages of the model, without delivering the full benefits of a top-to-bottom multi-tenant architecture.
This line of thinking was brought into focus for me during a briefing the other week with cloud platform vendor Gigaspaces, which was preparing to launch its new cloud enablement offering at the recent Cloud Connect conference. Gigaspaces is already well known for its cloud infrastructure platform products. It is now going to offer PaaS and SaaS platform software, too. These products will make it much easier for enterprises and ISVs to gain many of the benefits of multi-tenancy, much in the same way that the Corent and Apprenda products I wrote about last month do for ISVs. But whereas those platforms had built-in as-a-service components that took care of important operational functionality such as provisioning, entitlement management and usage monitoring, Gigaspaces leaves it up to the customer to plug in their choice of third-party middleware to add such functions. This means that its own platform stands or falls very much on the core proposition of how well it makes multi-tenancy work for its customers.
I find myself conflicted thinking about this, because I’ve been complaining for a long time that there aren’t enough platforms that make it easier for businesses and ISVs to get started with multi-tenancy. Yet now that they’re finally coming into the market in some numbers, I’m about to complain that they don’t go far enough. So let me begin by saying that I think these platforms are very useful tools for moving enterprises along the path to multi-tenancy. There are many use cases where they will amply repay their investment. Actually, to be fair, these platforms also provide a lot of functionality for fully multi-tenant applications. But it’s important to be clear what we’re talking about here. Full, top-to-bottom multi-tenancy requires more than a platform alone, it requires top-to-bottom re-architecture of the application code. Any single-tenant application that’s ported unchanged to a multi-tenant platform, no matter how much multi-tenancy is ‘injected’ into it, will not derive the full benefit of multi-tenancy until it has been rearchitected or written anew.
Having said that, multi-tenant emulation gets you part of the way, and how far it gets you depends on how deep the emulation is. The Gigaspaces platforms support several different levels. Let’s step through them.
Hosting single-tenant applications on multi-tenant infrastructure. Clearly, this does not make the applications themselves multi-tenant (though a lot of people still get rather muddled up on this point). But the multi-tenancy of the underlying architecture can still deliver a lot of cost savings, scalability and operational flexibility. For example, the Gigaspaces platform will have the ability to provision an instance across a mix of public and private cloud platforms, and even unvirtualized servers, with the option to federate the deployment across all platforms or (more usually) redeploy from one to the other as needed. The potential to save costs and gain flexibility is self-evident, even at this very shallow layer of emulation.
Redistributing application processes across virtualized machines. The next level of multi-tenant emulation is to start to break down the application into separate, shareable components that are distributed across the virtualized infrastructure. This is a step short of taking multi-tenancy into the database, but it is a powerful form of emulation, which starts to make effective use of the available compute resources and is easier to scale up and down. Gigaspace’s implementation distributes all tiers of the application code — from business logic down to messaging — across virtualized containers, maximizing the resource sharing of this approach. It also offers the option of setting policies that determine which applications or user groups can or can’t share resources with others, catering to sensitivities over potential compliance and security risks. Note that all of this happens without having to rewrite the application as multi-tenant — instead the platform just grafts the resource sharing onto the code as provided.
Injecting a user-specific column in the database driver. This is the final layer of emulation, which adds multi-tenant sharing into the database by the simple (and classic) addition of an extra column to every table to associate any field with a specific user group or organization (ie tenant). By definition, this brings multi-tenancy right into the database, which — as I was told in the briefing — “is exactly what salesforce.com does.” Yet while that’s true in a literal sense, it’s a gross oversimplification of the full architectural stack that’s operated by a sophisticated multi-tenant SaaS/PaaS vendor like Salesforce.com. So I’m sticking to my guns and calling this emulation rather than the real thing.
In fairness to Gigaspaces, the platform has a lot of capabilities designed to support the specific needs of cloud delivery of applications, with a lot of emphasis on real-time management and sophisticated support for ‘DevOps‘ process automation. So it depends on how you use the platform whether you’ll get full multi-tenancy or just an emulation of the real thing. While all of the above layers provide the core attributes of multi-tenancy, it’s only by evolving the multi-tenant application code that you can move beyond simple economies of scale to reap the benefits of collective scrutiny and innovation that comes from operating the multi-tenant model. Salesforce.com, for example, not only adds an OrgId column to all its database tables, but it operates a database structure that’s refined to match the known needs of the applications it operates; on top of which there’s a specialized query optimizer to maintain high performance at massive scale. There are many other ways of refining multi-tenancy but the key takeaway I’ll leave you with is to understand that to be able to make those refinements, you need to be dealing with the real thing architected into your application code, not an emulation that’s been grafted onto it.
