Apr 142009
 

As anyone who follows me knows – I use Twitter and TweetDeck to watch the “virtual conversations” about SaaS happening around the ‘net when I can. Today some time was freed-up by a conference call that was delayed so I fired up TweetDeck and took a look around. Imagine my surprise when I read a meme had started around a blog post touting single-tenancy for enterprise SaaS applications.

I’m not going to link to the original post – the writer has his reasons for pushing the idea – they are not entirely wrong, his context is different than mine and most readers of this blog. But I strongly felt the “take away” that might be given to people considering developing a SaaS application was shortsighted to say the least. Without getting into “religious wars” over a complex subject – let me first say that single tenancy does serve as a reasonable tactic for ISVs in some situations:

  • Limited instances for a group of large clients that require hosting and will pay the cost differential for an application that really has no direct future as a fully developed SaaS app.
  • As a short term response to market pressure and provide an alternative to a competitor’s offering.
  • As a beta of a future SaaS application to “get a feel for the market” in a specific vertical where the ISV has not had an offering before.
  • …and similar short term, limited implementations with narrow specific goals
  • Or when you are using a PaaS like Apprenda’s SaaSGrid that actually leverages a single tenant .Net application and provides hooks to services that can enable the application to operate as multitenant and scale properly.

Let me also say that as Bob Warfield of SmoothSpan pointed out recently – multitenancy in itself is not a solution to all architectural problems for SaaS applications or a guarantee the application can be maintained and operated efficiently. Or – as a friend at OpSource recently pointed out, “A single instance of a multitenant application that just keeps growing forever without the ability to spread across infrastructure intelligently is actually less reliable than a single tenant architecture.” You will know this is happening when you and everyone else using an On-Demand application is suddenly caught dead in the water without a lifeboat by a system upgrade. Even a multitenant application needs to be able to seamlessly operate across several instances to be scaleable, maintainable and reliable.

So to address the most common FUD (Fear, Uncertainty and Doubt) thrown at multitenant SaaS architecture:

  • Cloud Computing has solved the problems SaaS application developers need to think about by making it a simple job to put a new instance online as needed and abstracting the “servers” under the application.

Cloud hosting options are in themselves good alternatives for deploying SaaS applications. There is a lot to like about an abstracted infrastructure. Cloud hosting is mature enough for enterprise IT to consider as an alternative to deploying on their own internal infrastructure just as they consider outsourcing other aspects of maintenance and support. But – as an alternative to a multitenant architecture it doesn’t solve the major operational problems posed by individual implementations for each client. For a version upgrade – how long will it take to bring each individual instance through testing and QA up to the current version? Will you be able to move all client instances to the new version in a coordinated way or will the fact that each client has a separate instance lead to a number of “orphans” that fear change and lag by one or more major versions? Will the overhead you face actually prevent you from applying necessary patches and bug fixes until the next “major upgrade?” And what about subscriptions, implementation of instances, payment settlement, self-service, and monitoring of usage? Most cloud-based infrastructure doesn’t address these operational issues and they will all cost you money in terms of overhead as a SaaS ISV even if they don’t cause any support issues and subsequent subscription losses.

  • Most multitenant applications use individual database instances for every client so the idea of a truly multitenant application is a myth. Enterprise clients want data isolation and abhor the very idea of “blended data.”

It is certainly true that many SaaS applications have been developed with an architecture that provides an individual database implementation for each client. Whether it is is “most” or not is an unknown – SaaS vendors seldom actually disclose their underlying architecture. However, to extrapolate from the fact that many services are implemented that way because it is what “clients want” is simply silly. First – the idea that single implementations for each client are inherently “more secure” is an answer from a marketing team that has nothing else to say. If there are security risks in the environment surrounding the databases or the way the databases are implemented – single implementations will not lower them unless you believe that by being just “one tree in a forest” you have somehow “spread the risk.” Second – single implementations are inherently less maintainable (see above), have higher overhead costs and are more likely to have delayed implementations of necessary database tuning, patches and upgrades. Delayed implementations mean less security and lower reliability. Third, application upgrades almost invariably require some changes to the database or at least a cycle of testing and QA. Individual implementations mean every instance needs to be updated, tested, and perhaps rolled back if there is an error. It also means a loss of transparency and that some clients may resist upgrades if they are aware of the isolation as a “strategy” (again see above). If this results in database inconsistencies between versions you can end up with application “orphans” again and no easy way to isolate the clients involved without forking your development (and if you don’t know what that means in terms of headaches you’re in over your head).

  • Big clients are very concerned about upgrades and want strong control over version migration, especially for applications that are used broadly across the enterprise.

This is certainly true when clients have the primary responsibility for end-user support and system maintenance because the application is locally installed. It is very short-sighted however to believe that a client organization won’t expect the SaaS vendor to accept responsibility for a large part or all of the end-user support and provide embedded training and self-help. This is service offering after all. Would your HR department expect IT to solve problems if Expedia didn’t place a travel reservation for a company executive? SaaS is a form of outsourcing and should be sold as such. If your business model is based on the belief that you can somehow just host the application and leave the support and change control to your customers you should take a moment and read Ben Kepes recent article on the idea that SaaS is just an extension of the old ASP model.

  • A SaaS application cannot match the look and feel of their client’s environments or provide ways to be easily customized to fit client operations.

The idea that SaaS applications are somehow required to be “cookie-cutter” with little flexibility is based on a very limited knowledge of current development patterns (or just plain lazy development). Yes, a single code base is a key to maintainability, testing, QA and reliability in a SaaS application. But that doesn’t mean that flexibility cannot be built in from the ground up. It does require understanding what clients might want. It requires allowing a certain amount of “self-service” or at least apparent application “hooks” that services can exploit. On the flip side – if you customize individual instances the risk that a customization will cause incompatibilities rises exponentially in relationship to the number of different customizations. So, as an ISV you have enabled professional services and disabled your operations and reliability.

Finally – the idea that a SaaS application and a premise-based are the “same” should raise flags if you have followed some of the marketing ideas we have written about in the past. Being on the Internet gives applications an entirely different context – if they are not exploiting that idea I would question how much value the SaaS implementation is really giving customers or the vendor.

So – in the end the old adage is true – beware of advisors only carrying hammers to fix problems. They are very likely to believe every problem is a nail…

Addendum –

  7 Responses to “SaaS: More FUD on Multitenancy”

  1. Well said Michael. You have done an excellent job of addressing the myths that surround SaaS. Keep up the good work.

  2. […] Shows Data Matters…Does the Cloud make … on Can Corporate IT Operate as Ef…Haut Tec » Saa… on Can Corporate IT Operate as Ef…treovaweb on Can Corporate IT Operate as Ef…ssacks […]

  3. Hello Michael:

    Given the recent developments with both Ariba’s as well as Oracle’s entry into the SaaS or on-demand world, I wanted to see if you would be willing to be a guest on the PI Window on Business Blog Talk Radio Show (http://www.blogtalkradio.com/Jon-Hansen) to discuss the issue of single versus multi-tenancy relative to these latest developments.

    Note: Here is the link to Part 1 of my 2 part series on the Oracle April 9th announcement: http://procureinsights.wordpress.com/2009/04/13/oracle-launches-sourcing-software-on-demand-as-life-imitates-art-so-too-does-business-imitate-politics-part-1/

    Would you be available on either the 30th of April or the 21st of May?

    Best Regards,

    Jon

  4. “Most multitenant applications use individual database instances for every client”

    I’m just curious, how do you know this? How many multitenant applications have you investigated to come to this conclusion?

    As I mentioned in the article – this is an assertion by people putting forward the idea of single tenancy as a strategy for SaaS architecture. As I responded – many do use individual database instances but whether it is a majority or not is an unknown. I do know from talking to leading hosting providers in the field that it is a common problem.

    I don’t believe it is a good strategy however – for the reasons I listed in the article.

  5. I agree. Doesn’t virtualization and the latest tools to automate provisioning, monitoring, management, code updates/syncs, testing and failover make the need for multi-tenancy moot? So what if its made up of separate stacks if it can scale, is highly available and can be efficiently and cost-effectively monitored and managed?

    Jan – This gets to the core of the misconception that keeps providing nothing but confusion. The answer is – NO.

    Some cloud hosting providers have some or parts of the tools you mention. Most are aimed at the infrastructure (hardware and networking) and common tools. Automation of updates to core functional tools like databases or interpreters can break applications in many unexpected ways because of version dependancies. Automated instance deployment is really nothing more than scripting for the most part.

    And yes, any good web application should be made up in stacks – the display layer, the database layer, the logic tier or whatever your break down happens to be. But that doesn’t eliminate the need to update those layers when you make a change to them. Why would anyone want to update 1000 instances of one or more layers when they could update some much lower number – maybe 5 or 10 multitenant instances? And – if you have heavily customized individual instances to meet customer needs – how might those be impacted by an update? You will have to test each one to see.

    And what about economies of scale? Putting aside maintenance overhead – will 1000 instances all with their separate threads run as efficiently as 10 multitenant instances? The simple answer is no – cloud hosting is not optimized that way.

    And what about using the idea you are on the Internet and in a (by default) community of users under this application? Are there reasons why user communities might want to interact?

    I know many providers want to jump on the “SaaS” marketing bandwagon and tout their offering as making it simple to build and deploy applications for vendors. Right now there are very few vendors who can rightly claim to have provided a transparent platform that provides scaling and multitenancy to a single tenant architecture. But those are platforms – not just cloud hosting providers. The ones that are good do have a level of “lock-in” as a risk but it is a trade off that can be evaluated within all business risks that SaaS vendors face.

  6. I enjoyed your posting. Mulitenancy definitely makes sense for SaaS. Imagine one instance for each google docs user? I don’t think so.

    You might want to fix your twitter link (it’s currently twiiter).

    Thanks for the catch! Done….

  7. […] old post in a recent multi-tenancy discussion, which started a flood of good posts (including a good read from Mike Dunham over at Scio’s Haut Tec blog). I’m a little late to the game, but I wanted […]

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>