Building SaaS based enterprise cloud applications – white Paper


INTRODUCTION

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 the client.

MULTI-TENANACY MODELS

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).

  • Separate Database

  • 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 offering.

In addition to its multi-tenant capability, the application was built considering the following key architectural goals.

  • 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 load situation.
  • Integration – Internal integrations are via REST web services and external integrations can be SOAP/REST web services



Figure 3 – The Solution Architecture

REFERENCES

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

Crishantha Nanayakkara

Director of Technology