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.