Problems with multi-tenancy

June 2, 2008 at 8:46 pm Leave a comment

Let’s play a little word association:

What comes to your mind when I say 2008 NBA Eastern Conference Champions? Did you think of the Boston Celtics?

How about SaaS? Did you say multi-tenant architecture? I don’t blame you.

See, the words multi-tenant have been used so much in discussions around ways of creating a SaaS architecture that SaaS an multi-tenant are almost joined at the hip. But he truth is that not every SaaS solution needs to be multi-tenant. Not every architecture needs to be rewritten to be single instance, multi-tenant. Why? Because multi-tenant comes with it’s own set of challenges and without properly understanding that these challenges are and what alternatives might be better, ISVs might lose time and money just blindly re-architecting their products to conform to a multi-tenant architecture.

For those of you that are not familiar with multi-tenancy, please visit this post that I have made on that topic. From a perspective of lower costs in terms of infrastructure and maintenance, yes, it is very desirable to move to a multi-tenant architecture. However, doing so raises a slew of problems:

  • Potential cost of re-architecture – Let’s face it, no IT service provider, Patni included, has a magic recipe to automatically make your on-premise product in to an on-demand product. So an ISV that is thinking about SaaS has 2 options – either re-build the entire architecture from the ground up or weave in multi-tenancy in to the existing product. Either way, it is going to be costly. And what about new features while the product is being transitioned from on-demand to multi-tenant?
  • Security – One of the most often touted concerns from a customer perspective – is my data going to be secure? Often times, a lot of extra design and development needs to happen around the product and database to keep sensitive data safe since the data all resides in the same database in different schemas.
  • Hosting – Even if an ISV is not hosting their own product, hosting for multi-tenant architectures needs a lot of prep work and that is why not all hosting providers can be a good fit for multi-tenant products. The database configurations, the shared infrastructure and other related issues can make it complicated sometimes to find the right hosting company.
  • Increased operational and infrastructure costs and people skills – Although not a problem strictly associated with multi-tenancy but more so with SaaS itself, the problem is still worth mentioning. It is not easy to scale up suddenly to managing your own data center, servers, and the hiring of people associated with the SaaS infrastructure.
  • Availability – Since you now have a single instance of the product servicing 100s or 1000s of customers, anything that the customer does either accidentally or maliciously could mean downtime for your application (things like an infinite loop, or a security breach or memory leak).
  • Limited Customization – Whereas there are ways to provide customization at the data level, workflow level and UI level, the truth is that these options are limited when you pursue a multi-tenant approach. This becomes more of a problem when an ISV has an established customer base who have highly customized their on-premise product and telling them now that the new SaaS product will provide limited amounts of customization or worse still, break if you try to customize it beyond a certain point will just not fly with these customers.
  • Rigid service levels – SaaS delivers the promise of one customer, but this is a boon and a curse to ISVs at the same time. Larger customers will often not be happy with the one size fits all service levels that most ISVs provide to all their customers and the main reason behind this SLA approach is because the ISVs want to keep customization to a minimum to better control rogue behavior and also because their product now is a single instance serving multiple customers over the Web. Many customers might not be happy with this scenario.
  • Forced upgrades – SaaS makes it really easy for ISVs to do upgrades. They go from multiple service pack type of upgrades that need to cater to multiple environments to doing infrequent, small upgrades to their product. But this now means that customers are often times not give much of a choice as to which version they want to be on.

So as you can see, a multi-tenant architecture brings along with it it’s own set of challenges and one needs to think though these issues before deciding if multi-tenancy is the best way to go. When to implement a true multi-tenant architecture depends on various factors. The thing to keep in mind is that multi-tenancy is not the only way to go about architecting a SaaS solution. There are other alternatives to this approach, one of them being virtualization in conjunction with some level of multi-tenancy. Whereas a strict multi-tenant solution might be suitable for SMBs, larger enterprises with more acute needs and desires might not be too happy with a strict multi-tenant solution. This is where using a virtualization product from VMWare to provide for virtualized storage and hardware might be a good compromise.


Entry filed under: SaaS. Tags: , , .

Brand Monitoring With Web 2.0 SaaS: A Boon Or A Curse For ISVs?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

Add to Technorati Favorites
June 2008
« May   Jul »

Recent Posts

%d bloggers like this: