Multi-Tenant SaaS and Virtualization are Two Different Things

Saas-Grund mit Plattjen
Image via Wikipedia

Recently I talked to two companies that said they were Software-as-a-Service (SaaS). After asking more questions and drilling into details for a bit I came to the realization that what they were referring to as SaaS was independent virtualized instances of their product in the cloud. SaaS, to me, is very different.

Here’s how I define multi-tenant SaaS:

  • Application servers that support multiple clients
  • Databases that support multiple clients in the same tables
  • Infrastructure (load balancers, fail-overs, etc) to support many customers

Virtualization of the application delivered via the cloud is essentially a more manageable version of the late 1990s Application Service Provider (ASP) model, and not SaaS. A major benefit of SaaS is the engineering efficiencies and scalability of multi-tenant application services and multi-tenant database instances. Multi-tenant SaaS and virtualization are two different things.

What else? What do you think of people calling their business model SaaS when it isn’t multi-tenant?

7 thoughts on “Multi-Tenant SaaS and Virtualization are Two Different Things

  1. Is it really important to attempt to position independent virtualized instances as not being SaaS? After all, wikipedia defines SaaS as:

    “Software as a service (SaaS, typically pronounced [sæs]), sometimes referred to as “on-demand software,” is a software delivery model in which software and its associated data are hosted centrally (typically in the (Internet) cloud) and are typically accessed by users using a thin client, normally using a web browser over the Internet.”

    Sounds like independent virtualized instances still qualify under that definition and users still see it as “software on demand.” Why try to drive a distinction and pigeon hole that vendor’s offerings as non-SaaS? If you really need to make a distinction at some point you can say “Multi-tenent SaaS” vs. “Independent Instance SaaS”, right?

    I guess I just don’t see why one type should get to keep the other type of using the term SaaS.

    1. I agree that it doesn’t matter for advertising purposes. For internal engineering and business scalability, multi-tenant SaaS is much better.

      1. That’s fair. Here, you’ll probably find this slideshare applicable (I especially like page #14):

        http://www.slideshare.net/ProgressSW/building-a-saas-application-one-of-the-keys-to-success-multitenancy

        Interestingly I’ve found very few articles on the web about best practices for building a multi-tenant system. We’re planning to do just that but it seems those are the dark secrets that proprietors mostly keep locked up. 🙂

      2. I think, as I believe you do, SaaS is multi tenancy with the infrastructure to back it, failover etc. I agree with your point that non multi tenancy applications are not infact SaaS but instead they are asp/hosted versions of the product. From a user/purchaser prospective there’s probably little difference, either way the hassle is away from the customer and in the hands of the vendor.

        That being said…. I think there’s an expectation with SaaS products that there’s full resilience throughout, DR etc and by pitching a hosted product as SaaS you are partially misleading the prospect given that’s often not the case. Those things typically can’t happen cost effectively without the economies of scale that comes with multi tenancy SaaS.

        I do dispute your comment regarding a SaaS product must store data within the same tables as other customers data. I believe its perfectly acceptable for a SaaS product to store data in separate tables or in some cases different databases provided they’re on a shared instance/cluster. For scalability its common for SaaS products to utilise different tables so index etc maintenance can be done easier and quicker on a customer by customer basis rather than forcing all customers tables to be maintained at the same time and having to deal with some of the consequences of maintaining such large database tables if they hold data for all customers.

      3. Thanks Charlie. I could go either way on multi-tenant databases. I do think that a multi-tenant database helps enforce upgrades across all clients (e.g. some upgrades require serious database modifications and it is more scalable for R&D if every client is on the same version of the app).

  2. Marketers seem to always latch onto the latest buzz word. Now “cloud” is used in place of SaaS or hosted.

    Agreed that multi-tenant is much easier to scale and more cost-effective.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.