Phil Wainewright wrote and interesting take on Zdnet (Multi-tenancy: emulation or the real thing?) where he outlines different multi-tenancy levels:
- Hosting single-tenant applications on multi-tenant infrastructure
- Redistributing application processes across virtualized machines
- Injecting a user-specific column in the database driver
Phil also addressed two approaches to achieve multi-tenancy, to which he referred as emulation - multi-tenancy that is pre-backed into the infrastructure as in the case of GigaSpaces, or the "real thing," which stands for a custom build where multi-tenancy is handled at the application level as in the case of Salesforce.
In his final takeaway, Phil suggested that to get the most out of multi-tenancy, you have to deal with it at the application level.
The build vs buy dilemma
Phil's point reminded me of the classic build vs buy dilemma – at first sight you would think that a custom build that is tailored to your specific domain and application would always be better than a generic solution. But is it?
I addressed "build vs buy" in a previous post on the subject (The impact of cloud computing on build vs. buy behavior), using Fred Brooks
's article No Silver Bullet. There are many lessons that Fred points out in his article that are worth reading, but here's a relevant point I'd like to highlight:
The hardest single part of building a software system is deciding precisely what to build.
Fred suggests that we tend to justify custom builds without properly realizing the associated costs. In many cases, what we tend to refer to as “specific requirements” aren’t that specific after all - or to be more accurate, the differences don’t justify the costs.
What to choose?
In the context of multitenancy, we should consider the following things:
-
Does the difference justify the cost?
How different would Salesforce multi-tenancy be compared to the multitenancy of any other SaaS or PaaS provider?
I would argue that most multitenancy providers are the same. Differences are minor; the goal is multitenancy, not a mix-and-match of potential features.
-
Complexity consideration
Dealing with data multi-tenancy at the application level can be error prone and can be significantly more complex than dealing with it at the infrastructure level, with serious effects. For example, I heard from one SaaS provider that a bug in their system led to one customer accidentally getting access to another customer's data. In addition to the complexity, there are things that just can’t be dealt with properly at the application level – for example, in the case of Salesforce, a single tenant is bound to a single database instance and can’t scale beyond that single database.
-
Time to Market consideration
When you launch a new SaaS or PaaS application, time to market often plays a critical role. Dealing with multi-tenancy at the application level requires lots of effort which can lead to a significant delay in time to market.
Joseph Ottinger points out that this effort can be addressed in lots of ways - perhaps by programming language choice, for example. But even these solutions carry costs, in terms of your team's capabilities or even in scalability. The language you choose, for example, might be able to help your time to market, but might cost you in performance, or even address how your architecture is built. These choices can be made well, but you should go in with eyes open to what choices you're making.
-
Cost consideration
When were dealing with multitenancy at the application level, we're often limited to cross-grain multi-tenancy as we don’t have full control over the underlying infrastructure. For example, in the case of data-multi-tenancy we can easily scale out and and scale down our data services based on the actual capacity that is being used – doing that at the application level would be much harder, maybe close to impossible. That means that we can achieve better density and thus control the number of resources and thus the cost at each given point in time by using platform multitenancy.
It’s not a mutually exclusive decision
In the context of multi-tenancy, there are always going to be things better dealt with at the infrastructure level such as data-multi-tenancy – and application specific multi-tenancy such as the user interface layout.
By delegating the generic part of the challenges of multi-tenancy to the infrastructure layer we can devote more time and effort at areas more specific to our business.
The full story in 15 min
Phil's article triggered a more in-depth discussion with Uri Cohen, GigaSpaces product manager, which later led to a recorded interview (15 Min on Multi-Tenancy) in which Uri address the following topics:
- Multi-tenancy: emulation or the real thing? the classic build vs buy dilemma
- What is multitenancy anyway?
- Why is it such a popular topic?
- Is it a feature or best practice?
- What is GigaSpaces Multi-tenancy?
Enjoy..
