Tenancy models in SaaS

Anybody who works or talks around Software as a Service (SaaS) has dealt (or, at least, come in contact) with the question “multi-tenant or single-tenant environment”. This question has become so common that one might think that there are just these two options. I would like to scrutinize on this issue: What alternatives are there when designing a SaaS environment, in terms of tenancy?

  • Single-tenancy With this model the supplier sets up one complete environment for the client to use. By environment, I mean the application server, the database server and any other component that the application needs in order to be operational; excluding, of course, the network and some common network devices, firewalls etc. With this model, you have 10 servers with 10 OS’es, 10 application instances, 10 databases. You also have 1 rack (with a limited physical capacity, of course) and you are bound to set up the 2nd one, pretty soon!

  • Single-tenancy, virtualized With this model the general architecture is the same as before, with the one very important difference that each new “environment” is not comprised of new servers. On the contrary, new servers are “created” with virtualization of the first one. With this model, you have 1 server with 1 OS, 10 application instances, 10 databases (plus the virtualization software).

  • Multi-tenant In that model the “application infrastructure” is unique. You have 1 application instance with 1 database, residing in 1 server. In these cases, the “1” is not usually true, since these environments are used to serve a larger number of users, and so although logically there is “1” server, physically we may talk about an array of servers, a cluster of databases etc. In general, though, these technicalities do not concern the end-user (except for the part of high availability and disaster recovery, which is another issue…). Anyway, in this model, since the database is common, the data of the various on-board customers are separated “logically” by application entities, such as “Company Code”, “Operational Unit” etc. Modern databases also offer a record-level authority, which is a significant feature.

  • Shared-tenant I don’t think that this is a widely used term but I will define it like this: It is a multi-tenant environment, in which some (not all) application entities are shared between tenants. Tenants (customers) are obviously using their “personal” data (such as user names, sales documents, accounting entries, customer file etc.) but share a number of other entities that they have agreed upon with the other tenants (for example the Car record in a closed or syndicated dealer network, a list of loan products that a bank is offering to that same network or a knowledge database in a community of accounting professionals). In this “hybrid” solution you must want to get on-board, but also the others must allow you to enter, or some “higher authority” decides who gets in (such as the network owner). Therefore, this is an environment where probably users know each other. From the technical point-of-view this is a multi-tenant environment with some database entities that allow common access by everybody. You could achieve the same thing with single-tenant installations that replicate a part of their database to each other. I am pretty sure, though, that this would be a “replication nightmare”.

  • Shared Hardware In this model, the tenants are using the same hardware but their application environments are fully detached from each other, since each one has his own instance of the application and the database. In these cases, database design (schema) and application code can be replicated – if need be – across instances, so that everybody has an exact image of the application structure in his hands. Or maybe not, because each one wishes to have his own, customized version of the software (It is in the vendor’s discretion to allow or disallow such sharing).

    I hope that the above list is close to complete. In one of next posts I will talk about pros and cons of each solution. Till then, keep “SaaS-ing” !
  • Comments

    Post a Comment

    Popular posts from this blog

    Reverse SLA

    Data migration to SaaS

    How can a web-based ERP boost your invoicing process