Multi-tenancy: emulation or the real thing?

Multi-tenancy: emulation or the real thing?

Summary: I don't believe you can get the full benefits of multi-tenancy just by porting your app to a platform that grafts it on. Cloud platform vendor Gigaspaces has introduced just such a platform. Is there a silver lining?


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 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 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., 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.

Topics: Data Centers, Cloud, Data Management, Emerging Tech, Enterprise Software, Hardware, Software, Storage

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • RE: Multi-tenancy: emulation or the real thing?

    Not sure, if its really imitating, but yes players such as AWS aggressively pushing ISV's to do testing and deploy their code for multi-tenancy. After multitasking multi-tenancy is the next big wave..
    Manpreet Singh Brar
  • I don't think this will work...

    ...anything loaded down with that much techno-mumbo-jumbo will never fly.
  • RE: Multi-tenancy: emulation or the real thing?

    True multi-tenant platforms have been around for years in the carrier space. Enterprise "technology" has a lot of work to be efficient and capable at scale. It is one thing to have 100,000 users, another to have 10,000 domains with 10 users each. Not many platforms can accomplish that, and most of the issues have to do with architecture. Our platform scales, CommuniGate Pro has been doing multi-tenant services for a 15 years.
  • Real Multi-tenancy is where the value is

    Thanks for showcasing this important distinction about platform and application multi-tenancy. In the ERP application arena, virtually every software company in the market today is offering some type of service and calling it SaaS. However, a closer look at almost all these offerings demonstrate that they are simply hosting a single tenant application and do not offer the same advantages of a multi-tenant SaaS solution.

    Plex Systems takes true multi-tenancy one step further. Plex Online ERP has been delivered as a multi-tenant solution since 2000 because of our philosophy of serving and growing with our customers. Providing customizations and supporting them was key to our go-to-market model but it became too costly to do at the premises of each customer. Our architects came up with the idea of a single database, each table prefixed with a customer ID, a single code base, disciplined coding procedures and a hosted ERP so that we could provide the same level of service at a fraction of the cost. The result was a win for our customers as we can be much more elastic on our pricing and they are always on the latest version of the release. And because of the opt-in nature of every enhancement, our customers can pretty much implement whatever feature they want, when they want it and even have us develop custom features when they need it.

    We advise the manufacturing sector, in particular, to pay close attention to the application model of any ERP system they evaluate, and seek out the greatest benefits delivered by true multi-tenancy.
  • Please clarify/expand on the benefits

    Phil, I totally get the value of multitenancy, so I would like some clarification on the "full benefit" you are sighting by re-architecting anew vs injecting. Let?s set the foundation first. I'm not talking about virtualization or multi-instance (i.e. what typical cloud provider?s pitch). I'm a businessman. I have a service that I want to sell and need to transition my supporting application to mutitenancy to ensure I have the lowest cost of service delivery. My question to you is what are the benefits I loose should I not re-architect my application? (i.e. say I go the "multitenacy injection route"). Keep in mind I am in the business world, so I am looking at this from a cost benefit perspective. I can inject multitenacy for much less $$ then re-architect anew and I can get to market much faster (i.e. capture market share). You bring up some interesting points, so I am trying to assertain if I am missing the boat by doing the "injection" approach or is the re-architect approach's full benefit really deminished due to the development expense and delay in getting to market.

    Thanks, Zac
  • Multi-tenancy should not be a religion - it has issues

    Phil, I think the arguments about application multi-tenancy are too black and white and they should not be. Multi-tenancy originated as an idea to enable applications to be cost effectively delivered to SMB customers (slicing up the infrastructure and support costs etc to a small enough cost and to bring delivery efficiencies), and prior to virtualisation. Multi-tenant applications will continue to be important to delivering applications to the SMB market, however, multi-tenant applications are a potential problem in two market areas.<br><br>1) Large enterprise customers. These organisations have quite specific performance SLA needs, security needs and complex integration needs and timing of upgrades. Multi-tenant applications are an obstacle to this market for major enterprise application take-up in a multi-tenant app SaaS model<br><br>2) Existing ISVs with existing on-premise solutions need to massively re-write their application architecture to be multi-tenant if indeed this is required to be SaaS. This is an enormous task for ISVs with no guarantees that there will be a market interested in buying their SaaS products after this massive investment. <br><br>With the emergence of virtualisation and now cloud computing, it is both feasible to and possible to deliver almost the same cost effective delivery benefits and multi-tenancy but without any of the constraints above that I mention.<br><br>Therefore it is possible to assist ISVs to make the transition to SaaS without the financial burden and time to market issues of a conversion to multi-tenancy (which may actually not be required at all!), by leveraging the benefits of cloud computing. Our company has built a specific delivery platform and services capability that integrates a range of off-the-shelf tools into our own central management console/orchestration engine that allows us to SaaS enable applications onto cloud services, complete with sophisticated billing solutions allowing them to meet the specific needs of each and every large enterprise customer if required. It takes us around 3-5 months to provide a production ready solution to market. We do all of this work at our own cost in a joint venture partnership arrangements with the ISV. We specifically target ISVs with applications for mid-tier to large enterprise customers (>2000 employees).<br><br>This enables ISVs to enter the SaaS market with minimal cost and cost, whilst considering the option of a later redevelopment to multi-tenant application if deemed necessary, but importantly, avoid many of the constraints that a multi-tenant application bring to these large enterprise customers.<br><br>So I think it wrong to promote the view (as many purists do) that SaaS MUST imply application multi-tenancy. SaaS is Software as a Service nowhere in that name does it say multi-tenancy is a requirement it just comes down to what is cost effective/efficient. If you can do it without this, then what does it matter?<br><br>Klaus Bartosch<br>
  • Emulation or the real thing?

    As the product manager of Gigaspaces new CEAP product, I would like to clarify the multi-tenancy level of support. It goes much beyond "Injecting a user-specific column in the database driver". Gigaspaces schemaless data model (document API) allows for multi-versioned data types, so different tenants can have different set of attributes applied in the same application data. Our customers find it a great way for agile application evolution and multi versionning of SaaS applications
    • RE: Multi-tenancy: emulation or the real thing?

      Phil great summary of the subject. In addition to @yaronpa response we compiled a 15 discussion on the subject which helps to clarify some of the questions that you raised in relation to the GigaSpaces approach - The interview is available here:

      I'd appreciate your view on that.
  • What about 4 levels of SaaS delivery?

    What about the 4 levels of SaaS delivery?

    Good article as always ... Though I am not sure whats the difference or the new news of the "old definition" of the 4 levels of SaaS offering:
    1. Ad-hoc/custom
    2. Configurable
    3. Configurable multi-tenant-efficient
    4. Scalable, configurable, multi-tenant-efficient

    I do see the need of discussing its cost savings benefits.

    Am I missing here somthing ?

  • RE: Multi-tenancy: emulation or the real thing?

    This is welcome technology to help SaaS providers like us to keep our costs low.
  • RE: Multi-tenancy: emulation or the real thing?

    Hi Phil

    I would like to add the following to your argument on the need to re-architect an applicatiom to make it truly multi-tenant.

    1. Customizability - If your application is not designed for customizability and configurability using a meta data based approach then emulation of multi-tenancy can make you technically ready for SaaS, but in the market place, are you going to force all your customers to use a standardised version of your product. What if each tenant wants the data model to be extended, forms and grids to be customized, or the notification templates to be custom designed.

    2. Business rules and Workflows: If your existing application does not generalize and externalize the business rules and workflows out of your code base, you will not be able to support the diverse needs of different verticals and customer organizations using your product. The ability to customize the business rules and workflows at the tenant level is an important business need that you should architect for.

    3. On the other hand, if you have architected your application for such extensive customization and configuration for each customer (from UI to datamodels to workflows), then even if you are not offering your product on the cloud, or if you are not offeringi it as a SaaS, you will still save a lot of money on implementation costs and maintenance costs. (As compared to maintaining a separate code base for each customer).

    So a true multi-tenant architecture for any application, is relevant irrespective of where it is deployed, how it is delivered and how it is monetized.

    Ram Kumar
    Director - Techcello
  • RE: Multi-tenancy: emulation or the real thing?

    Summarizing my previous post : A true multi-tenant architecture is not only about database sharing and data isolation, it is also about the ability of the application architecture to fullfill the diverse needs of multiple tenants / customers / user groups, by customizing and configuring data models, permissions, data scope policies, UI, rules, workflows etc. and still maintain a single code base.

    In that sense whether or not an application needs a true multi-tenant architecture is as much a business decision as it is technical

    Director Techcello
  • RE: Multi-tenancy: emulation or the real thing?

    or nothing.