DB level Isolation Here is another school of thought, if tenants are running the same kind of application, the only difference is the data each tenant store. Why can't we just introduce an extra attribute "tenantId" in every table and then append a "where tenantId = $thisTenantId" in every query? In other words, add some hidden column and modify each submitted query.
In additional, the cloud provider usually needs to re-architect the underlying data layer and move to a distributed and partitioned DB. Some of the more sophisticate providers also need to invest in developing intelligent data placement algorithm based on workload patterns. In this approach, the degree of isolating is as good as the rewritten query. In my opinion, this doesn't seem to be hard, although it is less proven than the Hypervisor approach. The advantage of DB level isolation is there is no VM overhead and there is any minimum charge to the tenant. However, we should compare these 2 approaches not just from resource utilization / efficiency perspective, but also other perspectives as well, such as ... Freedom of choice on technology stack Hypervisor isolation gives it tenant maximum freedom of the underlying technology stack. Each tenant can choose the stack that fits best to its application's need and in-house IT skills. The tenant can also free to move to latest technologies as they evolve. This freedom of choice comes with a cost though. The tenant needs to hire system administrators to configure and maintain the technology stack. In a DB level isolation, the tenants are live within a set of predefined data schemas and application flows. So their degree of freedom is limited to whatever the set of parameters that the cloud provider exposes. Also the tenants' applications are "lock-in" to the cloud provider's framework, and a tight coupling and dependency is created between the tenant and the cloud provider.
You've reached the end of your free preview.
Want to read both pages?
- Winter '18
- Amazon Web Services