The most successful cloud service providers, such a Salesforce.com, NetSuite and Success Factors, all utilize and evangelize a multi-tenancy approach. In fact, I contend that multi-tenancy is a requirement for any cloud architecture because of two key benefits for the cloud provider:

• Efficiency and Sustainable Scalability: With a multi-tenant architecture, cloud providers have the ability to ensure the lowest cost of service delivery. Because practically no new software resources are required for each incremental customer, the cost of on-boarding a new customer begins to approach zero at full scale, resulting in ever-increasing marginal revenue associated with each new customer.
• Dramatic reduction in operational cost and complexity over the product lifecycle: Since application upgrades can be applied to all tenants by simply upgrading the single instance of the application, the cost savings fall directly to the bottom line.

In this third and final installment of my implementing a multi-tenant cloud architecture series, I list the benefits of a multi-tenancy approach to cloud providers, as well as the challenges of not implementing multi-tenancy properly. The first installment explored the common strategies for implementing a multi-tenant architecture and the second explored the options for implementing multi-tenancy on each application tier.

Cloud Challenge: Rewriting an On-premise Application

Reaping the benefits of a multi-tenancy approach requires careful upfront planning. Achieving multi-tenancy can be downright hard and expensive if it is not implemented during the earliest stages of a development project — i.e. the architecture phase. For example, re-architecting an existing on-premise application to adopt a multi-tenant architecture is difficult, time-consuming, and fraught with considerable risk. It requires that the database schema (all tables and views) be changed to support the concept of a tenant identifier (tenant ID). In addition, each SQL access statement must be modified with a filter that returns data filtered by the tenant ID. What happens if a filter is forgotten? The security and integrity of all tenants’ data is compromised! Imagine one tenant running a query to return all sales leads for their company and receiving its competitors’ sales leads.

For most cloud providers, an application rewrite is not realistic for two reasons:

• Cost of resources: In my experience (implementing multi-tenant architecture for a financial services company), weaving a tenant identifier into the average-sized application takes roughly 2.5 years and the direct cost for the development resources can range between $2M and $3M. Most developers have never undertaken such an initiative, which reduces the likelihood of having an experienced team member to lead the project.
• Organizational impact: More than the hard costs of such an undertaking, morale can be negatively impacted when a development organization shifts focus from innovation to the creation of an infrastructure layer not directly associated with tangible product enhancements. Pulling valuable development resources off ongoing product enhancement goals for months also leaves an ISV vulnerable to more agile competitors during the conversion process.

Cloud Challenge #2: Multi-Tenancy at the Data Layer

The main challenge in almost every cloud application is multi-tenancy at the data layer. The challenge is how to share data resources (a database in most cases) among multiple users while at the same time ensuring data isolation between those users, as if they are running on completely separate servers.

The challenge with the fine-grained model is that it is fairly complex to maintain and implement. If you have an existing application, it requires a complete rewrite and also forces fairly significant changes in your existing data model. The challenge with the coarse-grained model is that cost margins per user are still rather high.

The other challenge that neither approaches addresses today is dynamic elasticity. What happens when a customer grows beyond their allocated shared capacity? Both approaches seem to rely on certain capacity assumptions and can scale by splitting multiple users between their shared resources. To address dynamic elasticity, suppose 100 tenants share an app on a server (all the way down to a shared database). Then suppose five of them grow quite rapidly such that they need to be moved off that server and the other 95 can continue to exist on the original server.

Something in the application has to know how to take the records that belong to these five, copy them off into a second instance of that database and then kill, move and restore the application service for those tenants. Of course, there’s an implied load balancer element in front of all this to keep up appearances to the clients.

Now imagine what your solution to this challenge is a database that can be easily broken down into small “chunks” without huge overhead, and image it can scale dynamically? A multi-tenant data service is just such a solution.

The following are the principles for a multi-tenant data service:

1. With a multi-tenant database, applications can be written to a single database tenant just as they are today. How tenants are allocated and shared with other tenant needs would be completely abstracted from the application.
2. All data tenants can share the same hardware (memory, CPU) with other tenants, ensuring efficiency.
3. Each database tenant can be distributed and scale dynamically across multiple machines to meet demand. This includes moving data to other machines, if necessary. Scaling must be supported seamlessly without any downtime.
4. With a multi-tenant database, the level of sharing/isolation is set on demand, based on the specific requirements. At that level, a user can choose a dedicated tenant, in which case the multi-tenant database would allocate tenants on a set of machines that is dedicated to that specific user. Clearly, the benefit of this is isolation but at the cost of efficiency. The user can also share with any individual or group under that user’s control. In other words, rather than dictating either extreme (full isolation or full sharing) for all users, with a multi-tenant database the user can dynamically choose the right level that best fits their purposes.

That concludes my implementing a multi-tenant cloud architecture series, hopefully you now have a grasp on the benefits and challenges of using a multi-tenancy approach for cloud architectures. Be sure to check out the first installment on strategies for implementing a multi-tenant architecture and the second on implementing multi-tenancy on each application tier.