Is Multi-tenancy Just a Database Architecture?


Most everyone that’s part of SaaSGrid has converations either with customers, industry types, media, etc. about multi-tenancy capabilities that we “inject” into guest applications that live on SaaSGrid. One common misconception that we hear people spew out is that  multi-tenancy “is just a database thing.” That is so far from the truth! While many typically think of multi-tenancy as data segregation, it’s in fact much, much more. Usually, folks that haven’t done it (multi-tenancy) don’t get it!

First, let’s look at multi-tenancy at it’s core. What we’re really saying is that we want each customer to feel as if they have their own application instance regardless of what instance orientation is being used (single instance, multi-instance, etc.) Let’s look at the holy grail of single instance, multi-tenant. What we’re really saying is that generally (this doesn’t fit all applications, but most):

  1. Customers needs to login to some *shared* frontend.
  2. Customers execute business logic on *shared* compute resources
  3. Customers store/get data from a *shared* data stores
  4. Customers use auxilliary systems to manage their presence with the service

Is multi-tenancy just a database issue? I hope at this point some level of obviousness has become part of the equation. Multi-tenancy means that you architect your front-end to fit the instance flavor you’ve chosen (in our case, single instance) so that UIs can segregate provisioning and UI rendering. Second, services layers need to execute against data for the correct customer in a safe fashion (so one customer doesn’t clobber another customer), which means we need execution isolation from a tenancy perspective. Next, data needs to be stored and retrieved correctly per tenant. Last, everything from authentication systems to upgrade engines need to understand tenancy and distinguish tenants from one another.

The footprint of multi-tenancy, when done correctly, is huge on an architecture (which also means you’re not using SaaSGrid;-)) One shouldn’t trivialize it as “just an extra column on some tables” because it’s far from that, so make sure you really understand multi-tenancy before tackling it, as it’s one huge iceberg!

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts
Meet the SaaSBlogs authors in NYC…or join us for a webinar next week
The Role of VARs in SaaS



Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Well said.
Just the security aspects of “multi-tenancy” alone are huge. What do you put into place to ensure that I only see my app/my data? This means that the entire App needs to be aware of how the underlying provisioning/management is supposed to work. If you can’t speak to security, you won’t have much of a life in the SaaS space.

Add to this the fact that customer execution is only one part of the equation. How do you manage disaster/recovery? How do you provision new tenants/users? How do you trouble shoot client reported problems? All of these questions take up as much time and effort as deploying the database.

The latter is the part that seems to sneak up on would-be SaaS practitioners.

Dennis,

It’s quite unbearable how many people either don’t get the latter part of your statement or think “ah, no biggie, it’s easy” or “who cares? We can do that later.”

Successful SaaS companies put all their energy into their business rather than dealing with the surprises of poor architectures. SaaS is an interesting beast where the technology architecture actually has significant impact on the business (traditionally, the separation of concerns which much more pronounced)

Ignorance is no defense from reality. There’s nothing like having a cascading failure in the support mode because you don’t have a mechanism to address issues in a multi-tenant environment. Might as well let all you clients know about the problem… ;)

Gotta figure at least as many hours will be spent supporting the application as went into building it. Probably more like 10-100x the hours.

D

Well, for one, it helps to acknowledge that the term “multi-tenancy” was promoted, bought, and paid for by Salesforce. This debate would not even exist if it wasn’t for their efforts.

Second, most of the benefits you describe can just as easily be achieved in a VM environment where all applications are simply running on the same code base.

And finally, multi-tenancy has a huge internal ROI for software vendors by allowing them to instantly provision application instances for free 30 day trials and developer accounts (VM focused companies don’t have the same flexibility in provisioning).

So, in the end, multi-tenancy really is “just a database thing” that has imperceptible value to the end user.

Mike: “This debate would not even exist if it wasn’t for their efforts.” You can’t make any case around this. I know for a fact I was developing “multitenant” apps back in 1999 before SalesForce was a force. Doing the exact same things I’m doing to day in my multi-tenant apps. This technical strategy is much bigger than its current biggest advocate.

I’ll grant you that VM can do much of the same. It’s a technical decision for every software company to answer as to how they want to crack this nut. The observed reality is that not everyone chooses the same answer. And the value delivered to the customer is the same (whether there is any or not).

I would point out that even doing multi-tenant via VM, there is a bunch of other stuff that someone (especially in a SaaS offering) needs to have to make it a viable service in the market place. Provisioning processes, Security, disaster recover strategies - not to mention the not-insubstantial piece of virtualization software that they have to run and manage.

Regardless of what technical solution one chooses, there are lots of ramifications - bigger and broader than the tool itself.

Granted developers were “doing” multi-tenancy long before Salesforce.

But when a LOB customer (not Developer) inquires a SaaS vendor today with “But are you multi-tenant?”, 4 out of 5 times their impression was formed by SForce.

Not saying that’s a bad thing. Just good for those in SaaS Sales to know what context they’re up against.

Mike,
Fair enough.
I worry less about the LOB customer, than I do about the LOB’s IT person who wants to crawl through every technical decision I’ve made.
As you say, the LOB person just wants to know their data is safe, the system will be available and response times will be fast. And that it does what the glossy brochure promises.

The discussion of “who should care about multi-tenancy” is always interesting. It reminds me of Bob Warfield’s Green Crystals blog post.

Mike, I do agree that they were the first to really push the messaging to the LOB as a differentiator, but at some point, I’m sure car manufacturers sold themselves as “the folks with windshield wipers.” Not perfectly analagous (multi-tenancy is much more complex and important, but should become given at some point, just as one would expect that a scheduler exists in most modern OS implementations)

I put together some of my thoughts on this (a while back) on http://www.Webiplex.com in the “Defining Multi-Tenancy” paper in our “Links and Articles” menu. This “question” or issue seams to keep going on and on even beyond that energized bunny.

Sinclair,

“Multi-tenancy”…Gosh, as a company that’s moved from enterprise deployments to SaaS, we’ve had to re-define our mindsets completely in understanding multi-tenancy.

No way is just userID contentID associations in a DB. That’s probably the smallest part of it.

We had to re-engineer:

1) User management(settings, prefs.)
2) Content storage
3) Video encoding (had to move to the EC2 cloud)
4) Usage tracking
5) Billing
6) Financial models
7) Content management
8) Backup systems
9) Business model
10) Service automation
11) Insight and analytics

When we started out, we were like: “hey…we have the building- let’s make some rooms in it and lease them out.”

And then we realized, thankfully early enough, that we were going to have to tear down the building, and start afresh, with a new foundation….maybe re-use some of the furniture and what not, but that was about it.

It WAS NOT, and DEFINITELY IS NOT, just a database issue!

-preetam

Preetam, thanks for the real world input! You’ve experienced what I’ve seen a million times, and your sort of knowledge provides invaluable guidance to those “diving in head first”

Out of curiosity, how much effort (% of project, man hours, etc.) do you think were invested in your SaaS stack?

Sinclair,

Well, we phased out our enterprise development altogether, and since then, we’ve focused ourselves 100% on SaaS.

The time savings were predominantly in R&D, and that saved us about 35-40%, approximately, when re-engineering to a SaaS model.

Does that answer your question, somewhat?

-preetam

[…] For more: “Is Multi-Tenancy Just a Database Architecture?” […]

Very good points,

One thing that is seldom talked about also is the application meta-data and or how the application is tailored to work for that customer. Application customizations and UI configuration changes are one of the pillars of “multi-tenancy”.

Sorry I am late getting here. This is a very interesting topic. Before getting down to details. Let me say that SaaS concept and architecture are not new. SaaS has been around for a long time. An example of SaaS application is your phone. The phone system was designed and built for phone operators (Bell, AT&T, …) Users must have an account (i.e. phone number) and they are called subscribers. Subscribers do not buy nor own the software (i.e. phone system). Nothing got downloaded into their phones every time they pick up the handsets and the system is available and ready for them (i.e. dial tone).

So the phone system is a multi-tenant application. At run-time, there is only one instant of the code. As soon as a subscriber picks up the handset, a data structure is created for that subscriber and initialized with stuffs like his account information, start time of call, etc., etc. The call then proceeds. At the end of the call, information needed to be saved got copied out of his data structure and the data structure is deleted. As a subscriber, what do we care. Few important ones are: Availability, Reliability, System Performance, Data Security. Availability and Reliability are obvious. System Performance means no drop calls, clear voice, no echo, … And Data Security means I hear only my conversation, not someone else’s. Similarly I want to see my account information at the end of the month, not some other subscribers’.

How does this story apply to SaaS applications today? Is it a new extra column in the tables or a duplication of the entire schema. As a subscriber, do I really care. I do not as long as my data do not end up in someone else’s shop. Of course, data security need to be proven and audited frequently (like “hacker-free” certification at e-commerce sites)

Few years ago, we bought accounts from Salesforce.com and stored our sale information without questioning if our competitors were eating our lunch.

I think SaaSGrid is doing the right things trying to get applications SaaS enabled quickly.