I was born in an independent house. Small house, yet independent. We styled it whatever way we wanted it. We partitioned the house into two and had a cow shed on one side and a living space on the other. We didn't have to seek permission from our neighbors to do that. We had the freedom to do whatever we wanted within our plot of land. That freedom had a cost. If we had any issue with any utilities (say water) we had to handle it ourselves.
When I went to college, I lived in a hostel. Each of us had an independent room. We could bring our own furniture. Some of us brought bare minimum to get through four years, while few rich kids brought luxurious furniture. The college took care of the maintenance and repairs. While we were allowed to bring our own furniture, we couldn't modify the rooms, not even the color of the walls. The rooms did not represent us.
After few years in job, I bought a flat. Each of the 200 owners have the same layout but each of us have filled our homes with our own style of furniture. Some of them have customized even further. They have a sound-proof room for audio recording! Like in our hostels, the maintenance and repair is by a common agency.
It is no coincidence that designers of software systems are called architects. Software architects have borrowed quite a lot of concepts from civil engineering. Multi-tenancy is one such concept borrowed from civil engineering. Much like in civil engineering, software multi-tenancy optimizes resource utilization, but offers flexibility of customization.
Let us talk with examples from software industry.
Say that I want to host my own email and document server. After much search I choose owncloud. I install it on my own server. I create one account for myself and I use it. This is a single-user, single-tenant system. I'm the user as well as the tenant. I can make whatever modification I want on the system.
Want to host it on a separate domain? Check. What to change the colors in the system? Check. What to pick and choose modules? Check.
As I get used to this system, I want to share the calendar with my wife and family. I create individual accounts for each of them. Now the system becomes multi-user, but it is still single-tenant. Each user can customize few features, like calendar name, but they can't pick and choose a functionality. If my sister wants to sync this calendar with her gmail calendar, she can't. Why? Because if I enable it, it will be enabled for all and I don't want to confuse my father with a new option. There is no option to enable it only for one user or set of users.
Now my colleagues Martin and Bob are impressed with how I manage my family schedule and they want to do the same. I could install owncloud in their own server. They will get the freedom to customize the way they want. But they don't want the headache of managing their servers and monitoring them. So they ask me to manage for them. They also tell me, they don't want to share their data with anyone else. They ask me if I could set up independent data storage for them. It doesn't stop. Martin wants only calendar facility and want to access the system via schedules.martinfamily.com. Bob on the other hand, wants to access the system from familyroom.bob.com. As indicated by the url, he wants to store family documents in addition to using calendar. He wants AWS S3 to be his data store. I can setup all of these because Owncloud supports multi-tenancy. They are pleased with the setup and invite all their family members to use the system. They decide to pay me for my service. I charge them according to the usage instead of a flat rate. (I wish I could end the story like the fairy tales: I lived happily ever after in Hawaii :-) ). This setup is now a multi-user, multi-tenant system.
As you can understand, not all web applications have to be multi-user system and not all multi-user web-applications have to be multi-tenant system. All solutions are contextual. An architect has to select the right approach for a given set of requirement.
Architecting a multi-tenant system is more complicated than architecting a multi-user system. There are two models of architecting a multi-tenant system: instance replication and data-segregation.
In instance replication model, the system spins a new instance for every tenant. This is easier to start, but hard to scale. It becomes a nightmare when 100s of tenants signup.
In data-segregation model, the application is shared between tenants but data of each tenant is stored in separate data stores. Separate data stores could be separate databases or separate schema within the same database.
To support such data-segregation, there has to be an additional management layer in the system architecture to provision a separate data-store every time a tenant signs up. Multi-tenancy includes customized UI for each tenant, selective subscription of services, and metered billing. This management layer is responsible for all of these functions.
By now it should be obvious that multi-tenant systems are not appropriate for every web-application. A multi-user architecture is sufficient enough for a B2C (business-to-customer) web-application. A multi-tenant architecture should be considered for a B2B (business-to-business) application.
Even though a multi-tenant architecture is a complex one, data privacy regulations like GDPR will force most B2B SAAS applications to become a multi-tenant system. If you are building a new B2B SAAS application, you better start with a multi-tenancy architecture.
I have no connection with owncloud. This is only an example. ↩
Like the post? Retweet it. Got comments? Reply.
What is a multi-tenant system? by @jjude: https://t.co/zX4TkjPsZk— Joseph Jude (@jjude) November 17, 2017