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!

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

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.

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”.

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

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

“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

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)