How do you go about
defining an architecture that supports multi-tenancy? What are the design
considerations? Let us explore answers
to these questions. In the first part of
this two-part series, I am setting the context and presenting a list of
questions that will help you get adequate information on the task on hand. In the next and final part I will discuss the broad areas of
architecture that influence multi-tenancy and provide some references.
The term multi-tenancy
became popular with the advent of Software-as-a-Service or SaaS applications. One of the
characteristics of SaaS based products is the ability to serve multiple customers
through a single installation. This is known as multi-tenancy. With
multi-tenancy every customer or company will have administrator and user
credentials to access the system. This warrants privacy and security. In order
to achieve multi-tenancy, it is essential to ensure configurability and
scalability. With configurability, each customer or company can configure the
product, and customize the UI as well as other elements (such as business
logic, report formats, user preferences, personalization, etc.). Hence new
customers can be added with ease – there is no need to get the product
installed again! Also this architecture is required to provide cross platform
support – for example it has to support multiple browsers based on a
pre-defined set of browsers. Above all the SaaS enabled product needs to be
highly robust and offer ease of integration.
What
matters is the kind of questions you ask when a problem like this is
thrown at you. The typical questions are,
1)
How do we define
the details of multi-tenancy requirements for our application?
2)
How many tenants –
both minimum and maximum, to be served?
3)
How will the
application and other routines identify a specific tenant?
4)
What are the
security requirements (across all layers)?
5)
How are we going to
validate users?
6)
What are the configurable
parameters needed to support multiple tenants?
7)
How are we going to
add new tenants?
8)
How are we going to
retire an existing tenant?
9)
What is going to be
the volume of data over the next five years? What are the scalability and
performance requirements?
10)
What are the UI
requirements? Do we need to enable tenants or customers to define their UI or
theme? (Obviously, yes. But to what extent?)
11)
What are the
external systems and interfaces? Are these different for different customers? How
are we going to handle these?
12)
What is the
implementation view? Are we going to have multiple databases or application
servers? Why? Why not?
13)
How many browsers
and languages are going to be supported?
14)
What are the other
devices from which the application will be accessed (such as tablets, smart
phones)?
15)
What is the
expected load (number of transaction) during different times in a year?
16)
What are the
expected benefits of implementing multi-tenancy and what are the corresponding
architectural or design considerations?
17)
What are the
maintenance routines and dashboards required to monitor the performance?
18)
What kind of
dashboard is required by the administrator or super user(s) of each tenant?
19)
What is going to be
the maintenance and release cycle? How will it affect multiple tenants?
20)
Is there a need to
implement usage based pricing or monitoring the number of transactions per
tenant? If yes, what are the design considerations?
21)
What is going to be
the level of reuse to improve maintainability?
If you have designed (or are designing) a multi-tenant application these questions will lead you to additional questions. Please feel free to share those questions. I will add them to this list. Finding answers to all these questions will help you define an architecture that fits well.
In the next and final part of this series, I have discussed the broad areas of architecture that influence multi-tenancy.
No comments:
Post a Comment