10

What are the typical challenges that arise when converting a single-tenant app into a multitenant app? Security and data isolation strike me as the most significant. What are some others?

I'm one of the architects for a fairly significant automation effort, and historically it's just been our company using it. We want to make it possible for others to use it as well. Every time we talk about "making it multitenant", the conversation revolves around keeping users with one tenant away from the data that another tenant owns, and making sure that users with one tenant can't (either intentionally or inadvertently) create impacts in another tenant's environments. What I'm wondering is whether security/data isolation are really the only major concerns here, or whether there are some other major concerns that we're just not thinking about.

Improve this question
2
  • The easiest solution? A new instance of the whole system, including hardware, empty, from scratch, one new system per tenant. If the system and the data are quite valuable, this may be a pretty good option. If you don't like new hardware for each instance - use virtualization. It may not be most efficient but certainly will save a ton of headaches.
    – SF.
    Commented Sep 21, 2011 at 13:55
  • Probably from a design perspective this is the easiest, but from an administrative perspective it doesn't seem to be. At least our sysadmins are not very excited about this proposal. (And yeah, we're using VMs.) Way more instances to manage (monitoring, deployment, etc.) We are in fact looking at ways to make this more manageable to get some physical isolation here but on the face of it, this approach seems to trade dev simplicity for admin simplicity...?
    – user21123
    Commented Sep 22, 2011 at 6:26

3 Answers 3

Reset to default
11

Besides siloing of data, you may run into problems with

  1. Availability - with a single tenant, they can only DoS themselves, but even when data is properly siloed, a tenant can still exhaust resources.
  2. Logging - all log messages assumed a single tenant. Unless you silo logs per tenant, your log messages may become less useful.
  3. Concurrency - single tenant apps may run under moderate load, or high contention for a few locks may effectively serialize certain operations. If locks are multiplied per-tenant, you may start to see interleaving of operations that did not happen before. Race conditions that were very unlikely to ever manifest, may now be likely to manifest.
  4. New sources of resource contention - where before you might have n sockets and m filehandles, now multiply that per-tenant.
  5. Configurability/backwards compatibility tradeoffs - where before you can obsolete a component as you roll out a replacement, you may now have one tenant demanding a component, and one tenant demanding that the old component it replaces stay around indefinitely.
  6. Subpoena target - currently you are a subpoena target for problems related to your company. With multiple-tenants, you might have to respond to subpoena requests even when you are not a party to the legal action.

Some of these assume that you're running all tenants in the same address space (machine or cluster). If each tenant is running your software on their hardware, you can moot some of the above and add:

  1. Difficulties accessing machines to debug.
  2. Support requests for older versions.
  3. Requests to allow third-party contractors to configure.
  4. Less control over the hardware it runs on.
  5. Less control over patch/update cycle of the OS it runs on.
Improve this answer
1

The biggest problem in multi-tenancy in my opinion is customization. This happens routinely if you are selling a business application to enterprises. It could vary from something as simple as every customer wanting their own skins to the ability to configure additional fields, rules,forms and reports. The level of customization that you need to support plays a critical part in the architecture.

Improve this answer
1

Mike's answer is very good, and a lot of the points there almost underplay their complexity due to how short they are, so take those to heart.

One point I would add is that you should have good management tools for creating (and later on, managing) new tenants. Depending on the physical architecture you go with, this can be far from trivial, and is something that is often overlooked. The benefits of a software as a service product only really come into play when there are a large number of tenants, so a fair amount of effort should go into catering for this.

To extend on Sriram's answer; per-tenant customisation is pretty much forbidden, everything that a tenant might want to change should be configurable. E.g. if your solution doesn't cater for the dynamic addition of data fields in at least a few key areas, you will likely be inundated with requests for customisation. It's one of the few cases where a little additional complexity upfront does actually pay off (let's say it goes against YAGNI, or at least, this level of configuration is almost a key requirement, so you are gonna need it).

Improve this answer
5
  • Why is customization "forbidden"? It is certainly technically achievable. There are many different patterns that would allow for reuse of the core system for multiple tenants while still providing for customized pieces for individual tenants. If a customer is willing to pay you for the customization it would seem reasonable to consider it. There are many multitenant products that have per-client customizations for this reason. It is more in the spirit of YAGNI IMO to allow for extensibility and not default to making everything configurable.
    – RationalGeek
    Commented Sep 21, 2011 at 13:01
  • 1
    Well, I am referring to software as a service implementations, in general (from "multi-tenancy"). Sure, it's technically achievable, but it goes against the fundamentals of SaaS. In a financial sense, you are achieving lower costs by sharing implementation and probably infrastructure for many tenants. This allows you to offer your product at a lower price, thus catching the "long tail" of the market (large numbers of people only willing to pay a small amount). You can maintain maybe 5 branches of a system, but not 15000, and that is what SaaS is aimed at.
    – Daniel B
    Commented Sep 21, 2011 at 13:10
  • At the enterprise level I see SaaS vendors frequently that are willing to make significant customizations to their code in order to land a customer. When a customer is paying 6 or 7 figures for the service this is probably a reasonable business model.
    – RationalGeek
    Commented Sep 23, 2011 at 13:18
  • Yeah, in those cases, I guess so. Most of the changes I've seen were implemented as new configurable features that were, by default, turned off for existing clients. The problem, I think, is when the first 3 or 4 clients each get special treatment because the solution is yet to take off. The solution ends up too specific, and creates a culture of "OK, we'll just hack it in". But yeah, I agree with your comment around large customers.
    – Daniel B
    Commented Sep 23, 2011 at 13:29
  • This is a helpful distinction you guys are making around customizability. I think the same concept might apply toward manageability too. Our multitenancy probably aims at relatively fewer larger customers rather than long-tail customers. If the main purpose for multitenancy is to capture long-tail then it may not even be the right approach for us. Thanks for these reflections.
    – user21123
    Commented Sep 25, 2011 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.