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…
- The “single-tenancy meme” spread across blogs recently too – read more about the subject in Bob Warfield’s article on the SmoothSpan Blog. It is a well-written response to the misconceptions that have been springing up.
- Bob Warfield of the SmoothSpan blog and I will be talking with Jon Hansen on his PI Window on Business broadcast April 30th about SaaS and cloud-computing and you’re welcome to join us. You can read more from Jon on his blog too!
- The replay of the broadcast is now available on Jon’s site.