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!
Related Posts
Tags
Share This
Sinclair, let’s be really clear about what was meant by “green crystals” marketing. If you read my post again, you will see that I did not label multitenant itself as a “marketing gimmick.”
Rather, it is bringing up multi-tenancy with customers that is the marketing gimmick.
Customer don’t care about multitenancy. The more technical detail you give them about it, the less relevant it is to them.
They care about what benefits we can deliver by virtue of multitenancy or whatever other technologies exist, not the technologies themselves.
Cheers,
BW
Great post Sinclair. The Big Takeaways you mentioned are spot-on. I too noticed the chatter picking up over the last few weeks and prepared my own “response” over on the Sixteen Ventures blog to show that the pundits and analysts were completely missing the point.
My take on this subject is that we need to start explaining the Business Value of Multi-Tenancy rather than the technical or operational. Once the argument comes up to that level, all of the technical arguments go away because you now have business drivers pushing for what only a true Multi-Tenant Business Architecture can provide.
That said, your angle on this subject, which is at the technology architecture level, is quite valid especially given the capabilities of SaaSGrid.
I just find it interesting that the industry analysts missed, and continue to miss, the mark so completely on the Multi-Tenancy topic.
Looking forward to your follow-up post!
- Lincoln
@lincolnmurphy on Twitter
Bob, sorry for the misrepresentation. I reread the post and understand what you meant!
I agree whole-heartedly with the notion that multi-tenancy is mostly irrelevant to the end customer.
I’ve updated the post to correct the mea culpa.
[1] As a firm believer in abstraction I have a really hard time seeing any real outcome from exposing technical details like this with a Cloud customer outside of Marketing FAIL (see #4 below).
[2] If multitenancy does in fact result in a more cost-efficient implementation, who is the real beneficiary – the end user or the Cloud provider? Will the savings be passed on go to the bottom line?
[3] Multitenancy is not strictly defined, and can mean very different things. Are we sharing a hardware server or an instance of a database?
[4] De-segregating tenants should NOT be trivial! One of the biggest issues today that’s keeping organizations from adopting Cloud computing is security. Telling them how “easy” it is to get everybody all connected up together would almost confirm their worst fears.
Just my 2 cents.
TL
Thomas,
Some good points made and good questions raised. I’ll speak to your second question:
I would think that both are beneficiaries of efficiencies at the platform level, although, for different reasons.
Cloud platform providers recognize efficiencies early and often in operations. Properly implemented multi-tenancy (along with other aspects of the platform’s architecture) mean immediate cuts in ongoing operational expenditure. This allows the platform provider to focus on innovation, which has implications to the end-user experience further down the road.
On the other hand, cloud end users will tend to recognize efficiences when they are absent or when technology fails. With improperly implemented multi-tenancy (and other architectural aspects, of course), a cloud platform is susceptible to scalability ‘buckling’. This is when efficienies, or rather the lack thereof, become startling apparent to end-users.
I do agree with Bob and Sinclair that end-users care that their ‘piece of the pie’ works and works well, not necessarily how it is technologically implemented to do so. However, during those times in the life of a cloud platform when the technology is tested, hopefully it is architected well enough that it does not become a concern of the end user.
Tom, thanks for the input. De-segregating should be trivial. The ease of which application code can make things like collaboration happen is not indicative of it’s security.
For example, it’s trivial to add a new network user to most corporate networks. Does that make it inherently less secure? No. Similarly, it’s easy to write code that ‘logs in’ as a specific network user while logged in as a user. Is this problematic? Nope.
Sinclair, with all due respect, it’s a bit naive to say that making it trivial to mash up data between potential competitors does not weaken the security that they’re counting on from a Cloud provider.
Confidentiality is every bit a part of the Security model as anything else. Storing one company’s sensitive data in the same physical database table as their competitor’s data, with only the value of ‘column x’ to keep them (logically) separated is not a very compelling story to tell a worried prospect that you would like to see moving to the cloud.
Whether through carelessness or malevolence, a single programming error could easily destroy a company or two, and just because it hasn’t happened yet is no reason to think that it can’t or won’t.
TL
Thomas, unfortunately, my comment never stated that it didn’t weaken the security model. Clearly, exposing any surface area creates attack vectors for either malicious parties or mishaps. I simply countered your blanket statement that desegregating should not be trivial because triviality is somehow inversely proportional with security. This is not correct. Exposing any sort of collaborative capability *may* weaken a security model, but to say that de-segregating should not be trivial is too broad stroke for my taste. Should it be hard? Does difficulty of implementation somehow remove the existence of an attack vector? No.
As for multi-tenant data models, using simply a ‘column x’ for logical partitioning of customer data is an unbelievably unrealistic implementation of a multi-tenant data model. Anyone who has built a secure multi-tenant data model can tell you that in a shared database, security goes well beyond ‘column x’ segregation. I’m not sure what architectures you’ve bumped into, but I can assure you that such a simple technique is far too trivial an implementation to take seriously.
Interestingly enough, whether we’re talking a properly implemented (not some trivial ‘column x’ only approach) mixed data model or isolated database, once you move outside of virtualized containers, any ‘data leak’ errors would come from the application layer. Leaks are generally a result of incorrectly selecting a datasource, bleeding data between requests, etc. Physical separation being more secure than logical is mostly a perceived security and not an accurate representation since the mishaps occurs, as you stated, via programming errors.
Thanks for the continued dialog.
>> “Exposing any sort of collaborative capability *may* weaken a security model, but to say that de-segregating should not be trivial is too broad stroke for my taste.”
Look, you can’t have it both ways; if it *may* weaken security then it *WILL* – what do you think attackers look for? Weak spots. You want to hand them one in your design? One that can’t just be “plugged” easily?
The fact that it has the effect of weakening security is precisely the grounds for my stating that it should not be trivial. It is irresponsible to advocate features over security concerns.
And IMHO, security isn’t a matter of taste unless you include bad taste as adequate justification for making security in the Cloud a lower priority than anything else, esp. when it comes to hosting Healthcare and Financial data.
>> “As for multi-tenant data models, using simply a ‘column x’ for logical partitioning of customer data is an unbelievably unrealistic implementation of a multi-tenant data model.”
This is, in fact, the implementation in place at Salesforce.com for their multitenancy database.
TL
I think things need to be kept a bit simpler when discussing benefits of multi-tenancy.
Seems like there are at least two major end customer benefits to Multi-Tenancy. First, the SaaS vendor has reduced operating costs for infrastructure and the new account activation process, which could lead to lower activation and monthly subscription fees. Second, the SaaS vendor can upgrade the application and it’s supporting platform software to all tenants instantly, leading to faster delivery of fixes, enhancements, and major new functions.
So some end user benefits of multi-tenancy are lower software costs and faster availability of fixes and new features.
@russ
>> “I think things need to be kept a bit simpler when discussing benefits of multi-tenancy.”
I completely agree. There are so many safer and better arguments for SaaS adoption than “de-segregation can be trivial”, including those that you’ve pointed out: reduced costs (that can be passed on to the Cloud consumer) and frictionless updates without up-charges.
TL
Great stuff from everyone! Russ, to clarify a couple of things, I do agree that there are other things that make multi-tenancy valuable, but my discussion is purely around single instance, multi-tenant. Virtualized tenancy can still accomplish things like reduced new account activation costs and operating costs when compared to other models. As for rolling out updates, a mechanized/automated approach across instances is also possible. My goal was to target benefits that are difficult to replicate in other architectures like virtualized tenancy approaches.
Thomas, we’ll have to agree to disagree on some of these issues. I don’t see your approach as practical. For example, it’s common now to open up secure APIs to your business applications, trivializing functional access to core business functions and opening up the door to integrations capabilities. This is how the world works. Is it more secure to never open up an API? Yes. But if done right and with a small controlled surface area, opening up an API could unleash massive benefits in trade for a possibly reduced security model. I’m not advocating trading features for security. That’s an absurd suggestion, I’m just pointing out that you can “open things up” and allow for trivial use of complicated topics without some massive sacrifice on the security side, that’s all.
As for salesforce.com, you’re trivializing their (and most) column based implementation. Many good (caveat being good) column segregated multi-tenancy models leverage things like role/user based view filters, credentialed access to indexed ranges, optimized indexes for querying, and full lockout on underlying datasets. All of this is on the back of column partitioned data, but it’s not ‘only the value of column x’ protecting data. I’m sure some folks have built multi-tenancy with simple column filtering and a bunch of SQL WHERE clause filters in their application code, but those bad examples don’t justify trivializing or dismissing an entire implementation practice.
Sinclair.. for you to write “opening up an API could unleash massive benefits in trade for a possibly reduced security model” and then immediately follow with “I’m not advocating trading features for security” then you are obviously conflicted. Enough said.
TL
SaaS is much more than just cost savings. It allows for creative pricing models that can provide a steady recurring revenue stream and it facilitates data aggregation. There is a good description of SaaS benefits at the bottom of the site http://www.metrisoft.com.
Thanks,
Matt
You are right Matt, SaaS is not only about the TCO, its more about the ‘value’ – and not only for the provider but also for the consumer.
There are so many factors which could determine the cost but still we only talk about the architectural styles.
I am asking the same here – Yet another SaaS debate
Thanks,
SC
@Matt & @Sameer,
Both great points; we’ve written about the SaaS benefits several times before but this post summarizes some of the key benefits.
Cheers,
Abe Sultan