Is multi-tenancy more important than just cost savings?
Over the past couple of weeks, I’ve watched a healthy exchange between bloggers unfold with a focus on multi-tenancy. A while back, Bob Warfield over at Smoothspan, posted some interesting commentary on multi-tenancy being used by marketers in a gimmicky fashion as a ‘feature that customers care about’ more of a marketing gimmick (not so black and white, but the gist was there) than a technical merit, (see comments for reasoning behind strikeout) thereby categorizing it as ‘green crystals marketing’: my soap cleans better than yours because it has ‘green crystals.’ Phil Wainewright referenced Warfield’s old post in a recent multi-tenancy discussion, which started a flood of good posts (including a good read from Mike Dunham over at Scio’s Haut Tec blog). I’m a little late to the game, but I wanted to pitch in. This is the first of two posts I’m writing regarding the topic.
The conversation has been interesting to follow because it seems that the common theme everyone (including myself) wants to address is the cost effectiveness related to multi-tenancy. In one camp, there are those of us who argue that in many delivery scenarios, multi-tenancy has a drastic impact on delivery costs (even in light of modern virtualization techniques) and in the other camp, folks feel that the cost advantages are overblown/non-existent: merely a manifestation of ‘green crystals marketing.’ If you didn’t gather from the last sentence, I’m firmly in the camp that believes (I’ll go out on a limb and even say knows) that multi-tenancy can have huge relative effects on cost of delivery. I won’t dive into the cost effectiveness (since I’ve touched on this in the past), but instead, focus on a different discussion: the positive impact of multi-tenancy beyond cost, and why other 1-to-many architectures don’t make sense for SaaS.
First, let’s lay some groundwork. SaaS itself is more than just “cheaper software,” but in fact SaaS has a certain number tenets associated with it. SaaS is important because aside from helping drive TCO down for the end customer, it introduces the notions of ubiquitous access, collaborative use of data and function, and rapid adoption of newly introduced value (if your SaaS provider adds new bells and whistles, you just get them. No installs, no updates, etc.) Arguably, the TCO properties will bear less of the ”burden of proof” over time, since most line of business apps will converge to SaaS; TCO won’t differentiate one SaaS offering from another since they’ll all be saying the same thing, but the value that each delivers on the other SaaS tenets I just rattled off. The real question then becomes: does a multi-tenant architecture positively impact an application outside of TCO and does it provide an increase in net value to the end user? The answer is most assuredly yes! Let’s understand why.
When you hear the word “native” with respect to architectures, it usually means that the software architecture has ingrained artifacts of an architectural style. When we say multi-tenancy, it means that the software architecture is built to natively understand (and cope with) multiple constituents accessing shared volatile and non-volatile compute resources, maintaining virtual segregation and isolation despite said sharing. There are two big takeaways from this:
1. Generally speaking, multi-tenancy is captured in an abstract, foundational way within these sorts of architectures so that anything written on/above this part of the stack is inherently multi-tenant. We’ll coin the phrase ‘functional tenancy projection’ at this point. A ‘functional tenancy projection’ is the notion that any new function or dataset defined in a properly architecture multi-tenant system is trivially multi-tenant. This is true from everything from application code to ‘system code’ that helps manage and maintain the operations of the application. I’ve briefly discussed the before, but this is possible because of the notion of cross-cutting concerns.
2. A multi-tenant architecture, by virtue of natively isolating and segregating tenants from one another within a common application and resource set, may trivially de-segregate those tenants. So what, you ask? Because of collaboration! Well architected multi-tenant offerings can trivially allow for tenants to function in ‘de-segregated’ groups, thereby sharing data and function. The ISVs creativity would be the only thing limiting the amount of value that can be delivered to the end customer via collaborative function.
These two takeaways make multi-tenant systems *very* different from virtualized single tenant architectures. When someone makes references to SaaS via virtualized single instance architectures, they indicate that each customer is maintained in a completely isolated virtual container, rather than sharing resources. In other words, the application doesn’t capture tenancy, but instead the infrastructure does. Traditionally, this was a cumbersome proposition because it meant that IT had to fire up a server per customer, so there was a clear advantage to a multi-tenant architecture since everything from provisioning a customer to updating code was trivialized. With the advent of virtualization, this was no longer the case. A customer instance could be spun up virtually (and trivially), updates were easier, etc. Essentially, with virtualization, one can build a multi-tenant “exoskeleton” that routes requests and mechanizes maintenance processes, so the “virtualize it all” camp has some merit to their claim since it is starkly different than the multi-tenant vs single-tenant discussion that people had in a non-virtualized world a few years ago. The problem comes when we try to understand whether advanced form like those defined in the “two big takeaways” are possible. Unfortunately, properties like the two big takeaways simply aren’t present in a single-tenant, single instance architecture. Let’s look at each takeaway through a single-tenant lens.
1. Adding new application logic to a single instance, virtualized architecture becomes trivially available to all customers since the multi-tenant “exoskeleton” would roll out that code to each instance. To a degree, this is equivalent to ‘functional tenancy projection’ in the application layer. But what about “systems” code? If I need to add new maintenance capabilities, can I? If I want to manage something like ubiquitous access, would that systems functionality be trivially multi-tenant? Probably not. Each addition of systems functionality is not a ‘tenant projection’ but must instead address tenancy directly. This means that it takes longer to write these parts of the application and it takes longer for customers to experience value.
2. Since the application code knows nothing about tenancy, the idea of writing functionality that allows for collaboration on data and function becomes far less than trivial. The “exoskeleton” would have to support piping data and function between tenants, creating a cumbersome mechanism for collaborative interaction. This is what happens when something that isn’t multi-tenant wants to play in a multi-tenant world.
Granted, these are just two positive advantages of multi-tenancy, but they actually unfold into a host of other positive attributes that simply cannot be attained easily in single-tenant, virtualized architectures. Hopefully this leans some of the discussion away from cost and toward understanding the positive business impact of multi-tenancy.
For good ‘ole time’s sake, I will briefly revisit the cost question in my next post. Warfield’s discussion of the Salesforce.com 1,000 server measure was intriguing, and may help shed some light on what we really need to understand when comparing multi-tenant architecture to virtualized single-tenant approaches.
If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 1900+ members and is growing every day; make sure you’ re not missing out and join today!
read moreRelated Posts
Tags
Share This
