The perception is that SaaS applications are maintenance free. They certainly alleviate that concern from many customers, allows full scale across tenants who share application and database instances and remove deployment chores. Tenants can continue to download applications via the application store, but this does not impact one another. There is even cost reduction in overall application costs which makes the technology attractive to service providers. The proper architectural choices can address numerous challenges such as resource sharing, configurability, shared instances, and scalability. The improper choices can significantly increase the costs for maintenance and operations.
Companies take
the shortest path for multitenant systems as one where a single-tenant system
is modified to be a multi-tenant system. They encounter two barriers that are:
·
The initial startup costs of re-engineering
their existing single-tenant software systems into multi-tenant software
systems.
·
The high configurability of the new systems
which might even eliminate the maintenance advantage.
On the other
hand, there are significant cost, the architectural choices could have been
very different when the multitenant system is built from scratch. It follows
that the new system design and the reengineering provide two different
perspectives of the problem space and the tradeoffs between the choices.
The choices for
application and database sharing include the following:
AD- A dedicated application server is
running for each tenant, and therefore, each tenant receives a dedicated
application instance.
AS – a single application server is running for
multiple tenants and each tenant receives a dedicated application instance.
AI – a single application server is running for
multiple tenants and a single application instance is running for multiple
tenants.
DD – a dedicated database server is running for
each tenant and therefore the database is also isolated.
DS – a single database server is running for
multiple tenants and each tenant gets an isolated database.
DB – a single database server and a single
database is being used for multiple tenants
DC – a single database server is running for
multiple tenants and data from multiple tenants is stored in a single database
and in a single set of tables with same database schema but separation based on
records.
·
The challenges to overcome can be explained as:
Sharing of resources and higher than average hardware utilization, performance
may be compromised. It must be ensured that all tenants get to consume
resources. If one tenant clogs up resources, the performance of all other
tenants may be compromised. This is specific to multitenancy and not single
tenancy. In a virtualized instances
situation, this problem is solved by assigning an equal amount of resources to
each instance. The solution may lead to very inefficient utilization of
resources and may not suit all multitenant systems.
·
Scalability: When tenants share the same
application and database, scalability suffers. An assumption with single
tenancy is that tenants do not need more than one application or database but
there are no such limitations that exist when placing multiple tenants on one
server. Tenants from various geographies can use the same application which
affects its scalability. In addition, geographies pose constraints,
legislations, and regulations. For example, EU mandates that invoices sent from
within the EU must be stored within the EU. Additional constraints can be
brought by tenant to place all the data on the same server to speed up queries.
·
Security: When security is compromised, the risk
for data stealing is high. In a multitenant environment, a security breach can
result in the exposure of data to other, possibly competitive tenants. Data
protection becomes an important challenge to tackle.
·
Zero-downtime: Introducing new tenants or
adapting to changing business requirements of existing tenants brings along the
need for constant growth and evolution of a multi-tenant system
No comments:
Post a Comment