According to NIST, “cloud computing is a model for enabling ubiquitous, convenient, on-demand network access
to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and
services) that can be rapidly provisioned and released with minimal management effort or service provider
interaction (NIST, 2011The traditional approach incur a huge capital expenditure upfront along with too
much excess capacity not allowing to predict the capacity based on the market demand. The Cloud Computing
approach has the ability to provision computing capabilities without requiring the human interaction with
the service provider. In addition to that, its ability to have a broad network access, resource pooling,
elasticity and measured services are a few of the characteristics, which basically overpower the traditional
hardware approach. As benefits, it can drastically cut down the procurement lead time, can produce better
scalability, substantial cost savings (no capital cost, pay for what you use) with less management headaches
in terms of operational costs.
CLOUD SERVICE MODELS
There are three (03) basic cloud service models such as IaaS (Infrastructure as a Service), Platform as a
Service (PaaS) and Software as a Service (SaaS).
SAAS SERVICE MODEL
In the SaaS cloud service model the consumer does not manage or control the underlying cloud infrastructure
including network, servers, operating systems, storage or even individual application capabilities with
the possible exception of limited user specific application configuration settings. A typical SaaS based
application primarily provide multi-tenancy, scalability, customization and resource pooling features to
There are three basic multi-tenancy models. (See Figure 01)
Separate applications and separate databases
One shared application and separate databases
One shared application and one shared database
MULTY-TENANACY DATA ARCHITECTURE
Based on above multi-tenancy models, there can be three types of multi-tenancy data architecture approaches
explained considering the way the data is stored (See Figure 2).
In this approach, each tenant data is stored in a separate database ensuring that the tenant can access
only the specific tenant database. A separate database connection pool should be set up and need to select
the connection pool based on the tenant ID associated with the logged in user.
Figure 2 – Multi-tenancy Data Architectures
Shared Database – Separate Schema
In this approach, the data is stored in separate schema in a single database for each tenant. Similar to
the first approach separate connection pools can be created for each database schema. Alternatively a
single connection pool also can be used and based on the connection tenant ID (i.e. using SET SCHEMA
SQL command), the relevant schema is selected.
Shared Database – Shared Schema (Horizontally Partitioned)
In this approach, the data is stored in a single database schema. The tenant is separated from the tenant
ID, which is represented by a separate column in each table in the schema. Only one connection pool is
configured at the application level. Based on the tenant ID the database schema should be partitioned
(horizontally) or indexed to speed up the performance.
WHAT IS THE BEST APPROACH?
Each approach has its own advantages and limitations. The solution architects can basically decide the best
possible architectural approach based on the client requirements and the severity of the application.
The isolated/ separated database approach is considered as the easiest and the “premium” approach, considering
the high capability of data isolation. However, as a downside, the cost of hardware is relatively high
mainly because of the number of databases that are created for all the required tenants. This approach
is ideal for applications with very high data isolation requirement with relatively a high deployment budget.
The shared database – separate schema approach is again an easy to implement approach. As a downside,
in the event of a failure, the restoration of tenant data is a time consuming and a costly affair. Since
this approach can handle multiple schema within a single database, this application cost is quite low compared
to the isolated database approach.
The shared database – shared schema approach has the lowest hardware and backup cost compared to other
two approaches. However the development time is relatively more compared to other approaches mainly because
it is required to apply the maximum level of security not allowing to share data of other tenants.
THE CASE STUDY
Auxenta recently engaged in an enterprise SaaS based cloud implementation for an European client. Prior introducing
the new application, the client was managing the operations with a standalone application, which they had
to deploy at each client location. This basically added more operational overheads on a day to day basis.
Due to these limitations, the company wanted to re-write and re-engineer the application leveraging the
latest technologies along with SaaS based multi-tenant features. The developed application consists of
both web and mobile fronts, which can seamlessly interact with the cloud (See Figure 3). Separate native
mobile applications were developed (for iOS and Android) to provide the maximum usability with its asynchronous
data synchronization feature. A lightweight database was used with native mobile application distributions
to facilitate this task. The mobile web application, which has more application features along with administrative
functions communicates real-time with the application back-end via REST APIs.
The product can create multiple instances for each enterprise and allow each enterprise to manage their
own instances. The complete infrastructure is maintained in the Amazon Web Services (AWS) IaaS service
In addition to its multi-tenant capability, the application was built considering the following key architectural
Availability – Application server capability was catered by having elastic load balancers and the
database level availability is managed through AWS native features such as RDS.
Scalability – The AWS auto scale ability will be used to scale out the databases depending on the
Integration – Internal integrations are via REST web services and external integrations can be SOAP/REST
Figure 3 – The Solution Architecture
NIST (2011), NIST Definition, https://www.nist.gov/news-events/news/2011/10/final-version-nist-cloud-computing-definition-published
Cloud Computing Concepts, Technology and Architecture (Book) – Thomas Erl