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

Thanks,
SC

Thanks,

Matt

TL

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.

>> “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

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.

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

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.