Yesterday, I was watching a documentary about green solutions in technology, especially in server environments. With issues like global warming and the carbon dioxide emission problem nowadays, any solution which helps us keep this emission as small as possible can contribute to a better environment.
I believe that for software engineering, multi-tenancy is one of the key technologies which can help minimize the CO2 emission. The idea behind this is actually quite simple: in a traditional setup, each customer has his own dedicated resources. For most customers, 80% of these resources will be idle most of the time (based on the Pareto principle). Even though the resources are idle, they are still consuming energy, and therefore producing CO2. Using multi-tenancy, we need fewer resources, while we can increase the utilization of resources we need.
I’m not claiming to be a power management specialist, but I can’t imagine that running 1000 customers on one server consumes more power than having a dedicated server for each one of them. So, the more companies start implementing multi-tenant solutions, the more we, as software engineers, are able to contribute to the CO2 emission problem.
Although not related to how green multi-tenant solutions are, I wanted to mention something about multi-tenant database designs.
ReplyDeleteI happen to be managing a multi-tenant project. Our solution was to use completely isolated databases but a shared code base. As you know there are significant issues with trying to share database storage.
1. Convincing large customers as the security of shared storage but perfect data isolation is difficult. The chance of a developer writing a query where they forget to pass the tenant identifier and thus exposing other tenant's data is incredibly high.
2. It does not provide for tenants using different versions of the software. Since everyone must have the same database schema, everyone mostly needs to be using the same version. I have found this to be problematic in terms of release management especially if you want tenants to pay for a major upgrades.
3. Moving a tenants to another database server or providing a tenants with backups of their data is much more difficult in a shared database solution.
4. Some database constraints are tougher to create due to the fact that the tables must contain the tenant identifier. For example, I can no longer require that invoice numbers alone be unique. We must change the constraint to be invoice number and the tenant identifier.
I have found that the problem of "custom" storage, to which many people have claimed to be a significant issue, to be minor. There is a simple solution for that IMO.
One design that is intriguing is the idea of a single database but tables are segmented by username (e.g. TenantA.Table1, TenantB.Table1, TenantC.Table1). This would provide very good data isolation but I'm not convinced it would provide much of an advantage over separate databases.
Anyway, it is nice to see that more people are recognizing the challenges of developing multi-tenant applications.
Thomas, thanks for your comments. I believe the points you mention are valid indeed, and I'm looking forward to dedicating my research to trying to find a solution for some of those problems!
ReplyDelete