Tag Archives: database
Migrate Legacy Application To Multi-Tenant Cloud Based Application
Is the real future Multi-Tenant Cloud based application? What is the true path to illumination Multi-Tenant architecture or single-tenancy? Is Multi-Tenant architecture truly “faster-better-cheaper”?
The answers to all of these have been looked upon in this article. Let us first understand a few basics.
What is Multi-Tenant architecture?
Multi-Tenant architecture is a software architecture where a single instance of the software runs on a server and serving multiple client organizations (tenants). The architecture of the software is built as such that it separates software instances for different tenants or customers i.e. it virtually separates its data and configuration for each customer making it customized in nature. Its also an indispensable attribute of cloud computing.
How is Multi-Tenant architecture different from single-tenant systems?
In Single-Tenant architecture, as the name suggests, the software can be tailored for each tenant separately. The system houses the data for each company on a separate server. Each tenant runs its own copy of the software. The separation can be either virtual (virtual machines on a same server) or physical (running on separate machines).
In a Multi-Tenant Cloud based application, the data from multiple companies are placed on the same server generally separated from each other via a simple partition that prevents data to migrate from one company to another. As the data is housed on the same server, each company using the software is running the same basic application, with the same basic functionality and with the same limited configuration capabilities.
What are the potential challenges of migrating into Multi-Tenant architecture?
In many instances the capacity requirements of a small tenant could go below the minimum capacity database thats available. There is an invariable cost to a database and a smaller database does not perk up much in cost to provide benefits.
In cases of larger tenant count, organizing huge independent surfaces leads to issues. While handling thousands of tenants, thousands of databases needs to be created for them so operations scoped globally to address all the data such as schema deployments or queries that need to report size usage per tenant across all databases would take extremely longer durations to work out.
The applications compatible with much larger databases end up creating connection pool fragmentations. Since every server has a single connection in each pool pointing to the individual database that encloses every tenant, so these connections tend to go cold if every application server does not constantly get a request for each tenant recurrently. In such situations the application finds no connection in the pool and hence needs to start the connection all over again creating performance issues.
How does SaaS overcome the challenges?
SaaS loaded with numerous advantages over the legacy applications presents dramatic changes to both the migration and the delivery of the software solution. Some of the key benefits listed are:
SaaS dynamically allows adjusting the number of tenants per database at any moment in time.
Intense packaging of tenants is possible as one is not trapped with a stagnant tenant layout. With this an affordable and dynamic tenant model is available that can regulate increasing workloads in each tenant.
A major advantage with SaaS is it results in cost savings by merging IT resources into a single operation. Since an application incurs an amount of memory which is sizeable when in proportion to many customers, SaaS reduces this operating cost.
SaaS enables data mining. Instead of collecting data from several sources with diverse database schemas, all the data gets saved in a single database schema. As a result, managing queries across customers, mining data, and looking for trends is much simpler.
Improved usability, custom user Interface and branding.
SaaS abridges the release management process as packages containing code and database changes are required to be installed on a single server.
On the whole, SaaS provides an improved deployment of hardware resources and an enhanced simplicity of maintenance, resulting in lower overall application costs. This makes the technology smart for service providers aiming the small and medium enterprise (SME) business segment.
Migrate Legacy Application To Multi-Tenant Cloud Based Application
Is the real future Multi-Tenant Cloud based application? What is the true path to illumination Multi-Tenant architecture or single-tenancy? Is Multi-Tenant architecture truly “faster-better-cheaper”?
The answers to all of these have been looked upon in this article. Let us first understand a few basics.
What is Multi-Tenant architecture?
Multi-Tenant architecture is a software architecture where a single instance of the software runs on a server and serving multiple client organizations (tenants). The architecture of the software is built as such that it separates software instances for different tenants or customers i.e. it virtually separates its data and configuration for each customer making it customized in nature. Its also an indispensable attribute of cloud computing.
How is Multi-Tenant architecture different from single-tenant systems?
In Single-Tenant architecture, as the name suggests, the software can be tailored for each tenant separately. The system houses the data for each company on a separate server. Each tenant runs its own copy of the software. The separation can be either virtual (virtual machines on a same server) or physical (running on separate machines).
In a Multi-Tenant Cloud based application, the data from multiple companies are placed on the same server generally separated from each other via a simple partition that prevents data to migrate from one company to another. As the data is housed on the same server, each company using the software is running the same basic application, with the same basic functionality and with the same limited configuration capabilities.
What are the potential challenges of migrating into Multi-Tenant architecture?
In many instances the capacity requirements of a small tenant could go below the minimum capacity database thats available. There is an invariable cost to a database and a smaller database does not perk up much in cost to provide benefits.
In cases of larger tenant count, organizing huge independent surfaces leads to issues. While handling thousands of tenants, thousands of databases needs to be created for them so operations scoped globally to address all the data such as schema deployments or queries that need to report size usage per tenant across all databases would take extremely longer durations to work out.
The applications compatible with much larger databases end up creating connection pool fragmentations. Since every server has a single connection in each pool pointing to the individual database that encloses every tenant, so these connections tend to go cold if every application server does not constantly get a request for each tenant recurrently. In such situations the application finds no connection in the pool and hence needs to start the connection all over again creating performance issues.
How does SaaS overcome the challenges?
SaaS loaded with numerous advantages over the legacy applications presents dramatic changes to both the migration and the delivery of the software solution. Some of the key benefits listed are:
SaaS dynamically allows adjusting the number of tenants per database at any moment in time.
Intense packaging of tenants is possible as one is not trapped with a stagnant tenant layout. With this an affordable and dynamic tenant model is available that can regulate increasing workloads in each tenant.
A major advantage with SaaS is it results in cost savings by merging IT resources into a single operation. Since an application incurs an amount of memory which is sizeable when in proportion to many customers, SaaS reduces this operating cost.
SaaS enables data mining. Instead of collecting data from several sources with diverse database schemas, all the data gets saved in a single database schema. As a result, managing queries across customers, mining data, and looking for trends is much simpler.
Improved usability, custom user Interface and branding.
SaaS abridges the release management process as packages containing code and database changes are required to be installed on a single server.
On the whole, SaaS provides an improved deployment of hardware resources and an enhanced simplicity of maintenance, resulting in lower overall application costs. This makes the technology smart for service providers aiming the small and medium enterprise (SME) business segment.
Effective database activity monitoring (Page 1 of 2)
There are a number of reasons for organisations to deploy Database Activity Monitoring or DAM solutions, which can range anywhere from compliance to cover overall security.
DAM is a data centre technology, which monitors how the data that is stored in core databases and file servers is being accessed; it works on analyzing access behaviour to detect data breaches, if any; and takes action accordingly to mitigate them.
Various rules and regulations, compliance laws, etc also are increasingly forcing organisations to tighten their control over sensitive data they store, and have a verifiable audit trail that can be signed off, if required, by the appropriate organisational executives.
Database Activity Monitoring Architecture
Different DAM vendors have different ways of tracking activities in a database and therefore implementation of architecture is also slightly different.
A DAM with single appliance or single server architecture provides 1-to-1 mapping of a database server with a monitoring appliance; thus it acts both as a sensor and a collector of appropriate data. DAM with this configuration is good for a small database; however, for larger databases it might not be enough effective. Then there is DAM with 2-tier architecture, consisting of a centralised management server; this server collects information from a set of remote sensors or collection points. With this architecture there is a better degree of system scalability.
DAM with hierarchical architecture builds further onto the 2-tier architecture; this system is best suited for larger organizations; these DAMs are capable of supporting a larger number of sensors and collectors, distributed across a large enterprise.
Advanced Database Activity Monitoring Techniques
The process through which all SQL traffic to a database is monitored is called Network monitoring. Network monitoring allows monitoring multiple databases simultaneously; all the commands that are sent across to databases under scrutiny, are kept track of. The activities of users that are logged directly into the server via a local console are not recorded. Performance of a database is not affected by network monitoring, as no overhead is placed over the database directly.
In remote monitoring, a SQL collector is placed on the database with administrative privileges; the native database auditing is also enabled. The collector aggregates all activity collected by the auditing tools. This type of monitoring imposes an overhead on the database as logging is enabled on the database server, causing it to work more. The advantage of remote monitoring is that all database activities are collected, including that of a user who is logged directly into the server.
One can install local agents on each database that is being monitored, but it is not necessary that they would be successful in detecting all database activity; it would depend on how these agents have been configured, and how much closer to the database they are allowed to sit.