Software On Demand

SaaS Journal

Subscribe to SaaS Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SaaS Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

SaaS Authors: Elizabeth White, Pat Romanski, Andy Thurai, Ed Witkovic, Simon Hill

Related Topics: Virtualization Magazine, MultiTouch Developer Journal, Cloud Interoperability, SaaS Journal

Virtualization: RSS Feed Item

Virtualization vs. multi-tenant architecture

For software developers, SaaS is typically associated with "multi-tenant architecture", which many believe is a prerequisite for a SaaS application.

Traditionally, there would be only one instance of an application running on a server, and this instance would only serve one customer a.k.a. tenant. In the SaaS world, giving each tenant a dedicated server is a huge waste of resources and service providers want to put as many customers on the same server as possible. However, many applications (on Windows – most applications), by design, cannot have multiple instances on the same server.

To solve this problem, software developers came up with "multi-tenant architecture". The application is redesigned in such a way that a single physical copy of an application provides multiple "virtual" instances – each tenant gets an instance. Compared to several independent instances, using the same physical instance allows extensive sharing of data and metadata between instances/tenants

Multi-tenant design is considered to be more efficient than multi-instancing, but in reality, as always, your mileage will vary. And to make the estimation process easier, I'd like to shed some light – from the ISV's point of view – on the "dark side" of the multi-tenant approach:

  • Cost of transition – There are no good recipes for converting a traditional single-tenant application to multi-tenant design. Empirical data shows that typically the process takes 12+ months and requires resources of nearly the entire development organization. The existing feature development is essentially frozen.
  • Ongoing costs – Current generation of software – development tools, middleware, management tools – do not natively support multi-tenant paradigm. For traditional applications, mundane development tasks were taken care of by frameworks and tools, and mundane management tasks were taken care of by management solutions. None of this software natively supports multi-tenant paradigm, so an ISV will have to develop a lot of plumbing-ware from scratch.
  • Skills mismatch – The ISV must deliver complex services outside their area of expertise – hosting, SLA enforcement, monitoring, data protection, security, etc. The expertise associated with running a large-scale datacenter is not something that can be acquired overnight.
  • Limited customization – It's very hard to efficiently implement per-tenant database schema customization in a single database, and it's not possible to use standard DBMS tools – like built-in indexing. Plus, the multi-tenant application cannot use script-based customization of the internal logic – what if a buggy script loops infinitely?

    SmoothSpan Bob Warfield and Unreasonable Men argued that customization capabilities are often excessive and there is little harm in removing much of that flexibility. For newly written applications, it might even be true. But if an ISV has a customer base to migrate to SaaS model, telling customers that their solutions will be broken because some of the customizations don't work anymore is hardly an option.

  • Weak isolation – Because all tenants run inside the same application instance, one tenant can bring down everyone else on the same machine – due to a security breach, memory leak, "infinite loop" bug – you name it. It is technically possible to build some resource management capabilities into the application itself, but the existing development tools – languages, frameworks – do not support safe multi-tenancy and hence don't provide resource management capabilities.
  • Inflexible service levels – Finally, lack of resource management means that you cannot provide and hence monetize service level guarantees.

Virtualization – The silver-coated bullet

There is no silver bullet, but in this case, there is a silver-coated one.
Virtualization technology provides a solution to all the problems mentioned – put the application in a virtual environment and ship it – in unchanged state – to the service provider's datacenter. If the front-end is not web-based, use a VPN. This topic has already been discussed by Bob Warfield and Phil Wainewright who cites a real success story. Hardware virtualization, with single-digit real-life consolidation ratio, will probably not be good enough. But a light-weight server virtualization technology that can host 100+ instances on a single server - Virtuozzo – provides very cost-effective solution. Even if you are very determined to pursue multi-tenancy, Virtuozzo will buy you enough time to make the transition smooth and successful. However, in the majority of cases, further transition will not even be necessary because the Virtuozzo-based solution works well for most customers.

Shameless plug – check out my SaaS blog.

Read the original blog entry...