This is the personal blog of Tasos Christidis. Evolved from a general technology blog to a cloud- and XaaS-focused resource. Special references to Software as a Service.
You can also reach me at LinkedIn: http://gr.linkedin.com/in/anastasioschristidis
Subscribe to this blog
Follow by Email
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” !
between customers and providers in the cloud business are generally governed by
the Service Level Agreement or SLA. In a previous post I made the point that a
really “tough” SLA is probably not the “holy grail” of the cloud business,
which every customer should be looking for. In this post I will continue the
same line of thought, focusing this time in the impact that a strict SLA has on
the customer organization itself. For this purpose, I will use the term “Reverse
General Data Protection Regulation
(GDPR) puts on the table a lot of new issues to be taken under consideration
and handled by all parties involved in the SaaS market; both SaaS buyers and
vendors. In this post, I’d like to focus on the vendor side and discuss a
little bit more the issue of Privacy by
In the organization’s
journey from an on-premise Business Application setup to a Software as a
Service one, one of the key factors of success is data migration. Of
course, one starts with basic questions like “do I want or need to move to the cloud?”, “Which is the best SaaS solution
for my case?”, “Does it address my special requirements?”, “am I content with
the reporting/BI capabilities that it offers?” etc. But having answered all
of the above, you should take into consideration the data migration issue. This post will point
out some very significant issues around this subject, which you need to address
and examine; probably in close co-operation with the SaaS vendor of your
choice, before accepting their financial proposal and start the journey.