Transition to SaaS: Multi-tenant architecture vs. Virtualization

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 Server Virtualization Blog.

Comments

[P]

IllyaYour point about customer migrations is very valid. And to be honest i hadn't considered that option. I've said before that trying to be a start up (saas) in and incumbent (on prem) doesn't work. So to me the logical play is to run you're SaaS business separately. They target different customers, different user needs and people at different ends of the adoption curve. (classic innovators dilemma stuff)

[Ilya Baimetov]

Not sure I agree on separate businesses. From my experience, the customers are the same and for the customers there is not much to adopt - their client software (or browser) continue to work as before, but now they pay in a more convenient periodic fashion.