Cloud Applications Done Right - Part 1: Why Multi-Tenancy Matters

At Intacct, we’ve spent the past 12 years building a best-in-class cloud financial system. When we got started, we struggled to differentiate ourselves from ASP's (anyone remember ASP's?), "multi-tenancy" was only discussed among realtors, and "the cloud" was a purely meteorological term. We've come a long way. Over the years, we've accumulated a ton of knowledge about building cloud/SaaS applications – some stuff we did right from the start, and other things we had to learn through our mistakes. Over the next few months, I plan to take a closer look at the best practices and guidance for building and operating cloud applications through a series of blog posts. In this first post, we'll look at the benefits and challenges of multi-tenancy in cloud applications. I look forward to your comments and starting an ongoing dialog around this topic.

Why multi-tenancy is fundamental to SaaS applications and is better for both the vendor AND the customer

Multi-tenancy is the core design principal behind cloud applications. Companies like Intacct and salesforce.com rely on multi-tenancy to deliver mission critical applications securely and reliably to customers ranging from small start-ups to large public companies. People in the industry have come to accept multi-tenancy as the first and most important architectural decision facing cloud application developers. The benefits of this approach are well-known to the developers and backers of these companies. Less well understood is why multi-tenant solutions are actually better for the customer too.

Multi-tenancy has forced cloud vendors to innovate entirely new approaches to scalability, customization, user experience and interoperability that have resulted in capabilities far better than their traditional single-tenant peers. But multi-tenancy alone isn’t enough. A vendor can't just design a cloud application, choose to make it multi-tenant and expect to build a better product. Multi-tenancy introduces a host of design challenges that must be met head on.

Over the next several blog posts, I'll talk about all these design problems. Some of them are obvious, like user customization, while others may be surprising. For example, much of the challenge in building a great cloud application is that from the start customers and users simply expect more. They expect a more usable product. They won’t settle for any-time, any-where access – they expect ubiquitous access from any browser, device or operating system. They want a modern user experience designed not just for business professionals, but also for casual users.

In this post, however, let’s explore why multi-tenancy is better for both the vendor AND the customer. I know I'm treading on well-explored ground here, but let's lay out the basics so we can get into some of the more interesting topics. Multi-tenancy simply means that users share a common pool of resources. A simple way to view it is like this: Intacct has more than 5,000 customers. As a multi-tenant solution, we are able to manage the service as if it's one discrete unit. If Intacct were a single-tenant solution, we'd have to manage more than 5,000 discrete units.

The most obvious example of this concept is how customer data is hosted on a common database, often termed "co-mingled.” In the early 2000's, when we were just getting started, this was the biggest objection we had to overcome with potential customers. Even today, some of the loudest mouths in the industry use this as an excuse to avoid building multi-tenant solutions. Never mind that banks, insurance companies, public utilities, government agencies, and basically, anyone who keeps data securely tucked away in a database has been co-mingling customer data since before we all started putting up dot coms.

The reality is that it simply won't work otherwise – it’s too expensive and too error-prone to separate the data. And, believe it or not, co-mingling is better for the customer too. Take disaster recovery as an example. How many small companies plan, implement, and actually rehearse disaster recovery for their critical systems? With Intacct, all customers, regardless of size or how much they pay, get disaster recovery for free. And it's not just some promise in a contract. We actually hold annual, audited rehearsals. Imagine how complex, time-consuming, and error-prone it would be to implement disaster recovery for each of those 5,000 customers. Instead, we treat the Intacct system as one complete (multi-tenant) unit.

Disaster recovery is only one example of many. The same holds true for security and backups. It’s a simple matter of economies of scale. We spend more and, therefore, provide a level of service far beyond what any one customer could afford. The same principal applies to scalability and performance. We build our operations with ample excess capacity. That excess capacity is available to whoever needs it. A small customer with low volume most of the year can burst as needed to a level typically only experienced by large customers. With the traditional single-tenant model, that same customer would need to purchase enough capacity year round.

This notion that we are managing one complete system, not 5,000 separate systems, is at the heart of why we can operate the service economically. Extending this principal, it must also mean that all customers are running the same version of the software. Obviously, we can't require every customer to run the same software version while leaving them responsible for managing upgrades. Here’s another example of where the solution is better for both the customer and the vendor. It's better for us, the vendor, because we only have one version to support and operate and we can release new versions at a much faster pace. It's better for the customer because they no longer need to devote time and resources to planning, testing, and deploying upgrades but are still always on the latest, greatest version.

Think again about the deployment process for new versions. I mentioned that we take care of the plan, test, and deploy portion of the work. However, there's more to it than that. We have to consider how users will respond to the new version and utilize new features. So deploying upgrades isn't just about putting new code on servers and making sure it works. Intacct and other mature cloud vendors also help customers manage the upgrade process. We do this in several ways.

• First, we separate new features into two categories: disruptive and non-disruptive. A disruptive feature, by definition, requires a user to modify their behavior. Our first rule is simply to avoid disruptive changes. In most cases, customers can choose to enable and configure new features on their own schedule. On the odd occasion where we do need to release a disruptive feature, for example an upgrade to the user interface, we take pains to help customers get ready for the upgrade by adding messages to the system to alert users on the actual pages that are changing.
• Second, we are responsible for ensuring backwards compatibility. We cannot break customer integrations, customizations, or extensions, including 3rd party APIs. If we do, the repairs are our obligation. In other words, there must be no cost to the customer for our upgrades.
• Third, we have a public preview three weeks before the release that is free for anyone to participate. So if customers have been waiting for a new feature, they can get up to speed in the preview.

There’s one more overlooked benefit to the multi-tenant model. Phil Wainewright calls it “the democratization of IT,” though I have a slightly different spin on it. In the old single-tenant world, customers pay for functionality and are left to their own devices to deploy servers, configure operating systems, manage back-ups, ensure up time and security, etc. The software publisher has one responsibility – to ship software. In that traditional model vendors make money on features. The more sophisticated they make the software, the more they can charge. In the new multi-tenant world, the economics are quite different. All customers run the same version of the product and have access to all the sophisticated features. In this world we choose to charge less for sophisticated features, but because we’re also operating the system, we can charge for users, transactions, or some other measure that actually captures value. In other words, we can more closely tie the price of the system to the use of the system. Smaller companies can now afford to use advanced features without buying a high-end system. They can support their peak periods without having to purchase excess capacity that sits idle most of the year. They can buy one system that grows and scales as they do.

Times are changing. I don't think there's any more stark comparison of the old way and the new way than how we actually upgrade our service. We joke that traditional single-tenant vendors sling CD's from the back of a fast moving truck. While the truth is a little more complex than that, it doesn't come close to the modern world of multi-tenant solutions. At Intacct, and most likely at other mature cloud vendors like Salesforce.com, the release process is a highly automated, simple, quick process – we simply update the code running on our servers.

A couple years ago, I was returning to California from overseas on a Friday night when we have our scheduled release. Somewhere over the Black Sea at 35,000 feet I fired up Skype and started a conference with our release management team, launched a shell to our staging servers, ran a short script, and updated our system for all 5,000 customers. Forget for a moment how cool it is that I was on Skype while accessing our staging environment from a secure shell at 35,000 feet going 600 miles an hour. The fact that we can, with confidence, upgrade the service for all those customers with the execution of a short script is the culmination a huge investment in multi-tenant operations!

I know this was a long post, but there was a lot of groundwork to get through. The rest of this blog series will focus on the derivative problems developers face when building cloud solutions. How do you run a multi-tenant service with one code version while allowing customers to build rich customizations? How do you keep the system up at near 100% availability? How do you scale for high volume customers without impacting every other tenant? Stay tuned!

I encourage you to post questions/comments and start a dialog on this topic below.

[Twitter: @aaron_r_harris]

Image: FreeDigitalPhotos.net