In the first part of this series I listed a set
of questions to understand the architectural requirements when you want to
enable multi-tenancy. In this final part
of this series, I have included three broad areas of architecture that influence
multi-tenancy.
Data
Architecture: An ultimate approach to
define data architecture is by considering a shared schema. In this approach,
you store the data of all tenants in a single schema by including an identifier
or column such as Tenant_ID to identify data sets corresponding to
tenants. Another approach is to have a schema per
tenant. This helps when you have to deal
with large volume of data per client.
There is yet another approach – a simple and fundamental approach. That is about having separate databases per
client. Every approach comes with some pros and cons.
Code Base: Can you afford to have the same code base for
all tenants and maximize sharing so that you allow some percentage of code that
is unique to each client? Or do you want
to keep the code bases separate and have them run on separate instances of the
application server? Which is right for
you? It depends on the needs of your application and tenants.
Implementation View: How is your application going to be deployed
in production? Is there a need to share
instances? Or do you need to have an instance per tenant? What are the run-time requirements? This is
another broad area that is going to influence your architecture and design.
This makes it clear that
the multi-tenancy needs of your application or product is going to determine
how you are going to implement multi-tenancy.
There are different multi-tenant systems running in production across
organizations. Their architectures and designs are different and they offer
different degrees of multi-tenancy. When
you want to define an architecture and design multi-tenancy you need to look at
these broad areas and ask questions – I had shared those in the first part of
this series, and make your decisions. When
you do this, I am sure you will come up with a meaningful architecture.
Have you come across any
difficulties or challenges in doing this? Let us discuss.
References:
2 comments:
Hi Raja,
A very thoughtful, informative article. I do have experience in do a pilot for SaaS enabling a Legacy J2E Hospital Information Application.
As part of SaaS enablement, apart from what ever you have listed in your part-1 series, I believe a comphrensive business case is required, in case if you know the cost of ownership for the legacy application, it will be easy to see the TCO difference between a software license model and a service based pay-per-use model
One more point, is to have your sales team concurrence on how are they going to position or segment this product since the current existing business for the legacy application can be big so you don't want to position your new "on demand" service as a direct competition to your exisiting licensing product. So your "as a Service" model can start with minimum viable features and customers may need to buy full fledged software for getting a bigger feature list.
Thanks Manikandan, These are two good additions to the list shared in part-1 of this post. Thanks for sharing! Appreciate it.
Post a Comment