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:
- 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.
- All data tenants can share the same hardware (memory, CPU) with other tenants, ensuring efficiency.
- 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.
- 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.