SaaS Blogs

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.

Very good article and very healthy debate. I would like to take different approach to explain why multi-tenancy is much more than just a DB Architecture….

I believe that multi-tenancy is a technology answer to the economic problem SaaS business model faces. “Cost to serve customers” is an extremely crucial metric in building SaaS business. Cost to serve can save or sink SaaS business. In order to meet the demands of the lower Cost to Serve (customers)…. Organization needs to minimize costs involved in Operations, Hardware, and Software in serving customers. Only way to achieve this is to make sure that each of these resources are scaled and shared across customers thus helping reduce overall cost(to serve) per customers…..

Operations Costs: When it comes to reducing operations costs, one needs to consider….

Are there processes and procedures which allow ease of management?: Metadata change management/propagation (Orchestration). Is there Central point of control for management (monitoring/correction etc…)?

Are there ways to upgrade customers in one fell swoop? Are all customers on the same version of software?

How many points of failures are there in the overall deployment, are these failure points across all tenants or are they “on a per tenant” basis? (This could make or break support for SLA. Some one in this discussion recommended creating virtualized environment(Virtual machines) and deploying same package of software to reduce costs… but this will increase operations costs if not done properly(as many points of failures in operations as there are virtual machines) and would make it impossible to meet SLA’s)

IS there enough tooling in the architecture to allow for monitoring/measuring performance of all components centrally as well as on exception basis? (This will directly dictate operations personnel cost and what kind of SLA you can provide)

Same consideration goes for hardware and software. Just making database shared across tenants in neither going to reduce software cost nor it is going to scale the hardware infrastructure for several thousand tenants. Only way, is to make sure that almost entire software stack is shared across multiple tenants (UI, Authentication/Authorization mechanisms, Process flows/Process controls, Error handling mechanism, Provisioning, billing etc…) resulting in desired cost/performance scalabilities.

There are other aspects involved in SaaS business from the end user prospective. End users expect to get started with minimal intervention from the vendor providing services… this calls for additional software/application features such as easy UI, integrated billing system, integrated self learning systems in place. This requires for a separate tooling of application stack which is not a must have for on-premise or traditional application stacks.

In summary… it is really about Costs, Scalability, SLA for running a SaaS business which dictates the multi-tenancy architecture.

Vish Agashe

Hi Sinclair,

The SaaS-Attack view is that although Multitenancy begins in the database, it actually transends the application itself and leads to a whole new business model.

This relatively simple concept is responsible for re-shaping the whole application software business.

Those that ‘get-it’ are going to do very well!