When it comes to SaaS architecture, what's old is new again
April 15, 2009 11:48 AMMatt Tucker over at Jive wrote a great post today about SaaS architecture, specifically whether single-tenancy was a viable enterprise SaaS architecture in the age of virtualization, automation, etc. For years, we've been told that single-tenancy, or the idea of one customer to one instance of the product (versus multi-tenancy, which puts many customers on walled-off sections of the same large instance, or often multiple large shared instances also sharing databases), was an impractical SaaS architecture because it wouldn't scale, had high variable costs, inefficient database utilization, etc.
Matt points out a few factors that may make single-tenancy a more compelling architecture than is being given credit. He notes that the costs have changed - "It's now possible to approach multi-tenant level cost efficiency with a single-tenant application." And he also makes the point that things like migration of data and application customization are easier in a single-tenant architecture.
We've gone thru a similar evolution in our perspective at Atlassian, and I think Matt is spot on in his analysis.
- Forcing enterprise software into multi-tenancy is an odd fit. When Atlassian first moved into hosted services, we assumed (as was the default point of view at the time), that multi-tenancy was our only architectural alternative. We built Confluence Team Hosted in a multi-tenant fashion, and can share that re-architecting a traditional enterprise application for multi-tenancy was a ton of work. More recently, with Atlassian's Enterprise hosting and JIRA Studio, we've gone with single-tenant models, and have found, as Matt points out, that the gains of single-tenancy outweigh the benefits of multi-tenancy for customers.
- Enterprise customers have different needs than small businesses and organizations. Especially around security. In recent times, security has been the single greatest concern for enterprise customers. No surprise then that a model which keeps the individual customer's data completely separate from other customers, at both the application and database level, would be compelling here. Equally important to enterprise customers is the ability to integrate SaaS offerings with their behind the firewall apps, LDAP etc., as well as customize these applications with the same degree of flexibility they've historically had with their on-prem applications. In times past, customers might be willing to trade some features for the ease of access, setup etc. of SaaS, but more and more we're seeing the expectation for fully-featured applications with total control in a SaaS model, something that multi-tenancy struggles to provide.
- Virtualization makes single-tenancy cost-effective. Specifically with JIRA Studio, we've worked with our hosting partner Contegix to build a virtualized implementation of a suite of our apps, putting each customer on their own cloned VM (read this great CIO.com article for more specific details). What virtualization gives us for Studio is the ability to emulate multi-tenancy from a cost and provisioning perspective without sacrificing anything in the way of customization, security, and control. We get <five minute installations and upgrades, due to the cloned VMs (customer data is stored separately in a database, meaning the application VM can be deployed and upgraded en masse across the grid). And we get a much more economical cost structure, as well as a high level of fail-over and redundancy, because the standardized virtual images can easily be replicated and switched. By bundling the JIRA, Confluence, Fisheye, Crucible, and Subversion technologies into one package, and leveraging the cost effective scalability of cloud computing, we've been able to deliver a powerful and affordable hosted development suite.
At Atlassian, we're focusing our efforts in the near-term on the single-tenancy approach, and will continue to target ways that we can decrease the cost of a single installation rather than put a lot of focus on re-architecting for multi-tenancy. To that end, we'll be looking especially to take more advantage of Contegix's Project Zeus cloud computing market offering with our other products.
Contegix will be presenting on JIRA Studio, and the cloud computing platform that Contegix uses to power Studio, at Atlassian Summit, 31 May to 2 June, 2009 in San Francisco - read more about Contegix's presentation here.



Copyright © 2009 Atlassian Pty Ltd.

6 Comment(s)
This is really interesting and contrarian view to most of what I am reading at the moment. Thanks for the explanation about the the ability to do the upgrades across the cloned VMs en masse.
By Steve at April 15, 2009 3:31 PM
I am not really sure if I should agree to "Virtualization makes single-tenancy cost-effective" or not, because one mandatory requirement to make SaaS, PaaS or any other delivery model in the cloud cost-effective is to maximize the CPU usage. Running VMs on one single server has a lot of benefits like discussed above, but still has the overhead of the OS and servers running in each single VM. So in my opinion it would be more cost-effective to run multiple e.g. Jira Studios on one single server connected to a single databases using different schemas (don't go for the shared schema or single databases approach). So you still have the mentioned benefits of SaaS but even more CPU power left. Moving a single VM to another machine or moving e.g. the Jira Studio *.war file shouldn't make any differences, right?
By Tobias at April 15, 2009 11:31 PM
Michael -- thanks for the callout to my blog post! :) It will be quite interesting to see where industry thinking evolves on this question.
Tobias is right that maximizing CPU usage is quite important for efficiency, but this is exactly what virtualization is helping make possible. The overhead for the operating system is already fairly low and getting better all the time.
By Matt Tucker at April 16, 2009 4:04 AM
Can anyone quantify what contribution Virtualization actually makes to the cost-effectiveness of Single Tenancy? If the Single Tenancy approach is valid now, can anyone explain why did'nt it work in the ASP model? Is it purely processor power efficiency that made the change or are there other factors involved?
By Vincent at April 29, 2009 1:21 AM
Tobias, if you had a separate schema for each customer then wouldn't the application server need a separate connection pool for each one, possibly with 10-40 active connections each? Maybe idle connections aren't a big deal, but on the db server end that could be a problem.
By Ryan at May 16, 2009 12:38 AM
The SaaS architecture you select should be based upon the business model you have and the target market you are going after. There are several viable models each are dependent on the target market and the amount of capital you have access to.
With SaaS Architecture you have several options:
Option 1: 100% Virtualization (using Virtual Machines (VM)) at all layers, multiple databases, multiple versions of the application, each tenant gets their own VM slice.
Option 2: Virtualization at the application layer (hybrid). This involves multiple databases on in single server via federated database, scripted provisioning and manual customizing for each tenant. The advantages: Low to medium start up costs, medium difficulty to design and build.
Option 3: Single application deployed on a web farm, Single database instance leverage or federated DB. Customization is done dynamically by the customer via the application.
Option 4: True multi-tenant SaaS. Single database, Single instance, Single app. Customization is done dynamically by the customer via the application.
I drill in a lot further the advantages and disadvantages on my blog www.saaswonk.com
By Derek Gilmore at June 15, 2009 12:49 PM