How to Build SaaS Application with Data Isolation but No Run-time Isolation?
Solution Architect - 30 June 2020 -
Solution Architect - 30 June 2020 -
As you have already considered SaaS implementation, we recommend choosing the right SaaS architecture type so that all the hardware and automation costs you bear are well optimized. In case you are considering SaaS type 3 architecture for your startup, you are at the right place to get started.
Type 3 SaaS architecture is the right fit for cases that require data isolation but no isolation. In this type, different data stores are placed for different customers; however, the application is shared by all. Type 3 SaaS architecture is considered in businesses like e-mail marketing, content management systems (CMS), health care applications, and so on.
For your understanding of the type 3 SaaS architecture, I will take you through the example of an innovation management platform that I worked on for a fast-growing startup. The platform enabled industry leaders to tap into the collective intelligence of employees, partners, and customers, find the best ideas as well as make the right decisions. This platform drove innovation through the following-
It also enabled enterprises to manage the entire idea lifecycle, right from coming up with an idea of delivering impact at scale. Now, you must be wondering why we chose SaaS for this platform? The platform had to be made available as a service to enterprises with an option of subscription for a limited period. Herein, hosting/licensing wasn’t a viable option, taking into consideration the cost of deployment, data privacy concerns, and the IT assistance involved. We picked SaaS Type 3 deployment model for this platform wherein we could keep data of each enterprise isolated from others, all the while retaining flexibility of application runtime being shared.
Fig 1- Saas Type 3 Architecture
Having the right foresight and visualization is the key to good decision-making. That worked well in this case too, when we could rightly foresee the results of deploying SaaS type 3 on this platform. This decision helped us address the areas mentioned below-
Isolating data for each customer by having separate databases, all the while sharing a common application runtime, was a critical challenge that we tackled. In other words, we got one application runtime capable of supporting multiple databases for customer-specific data management. Along with this, we also had to accelerate customer onboarding in less time. This implies the deployment process should be automated enough to handle database provisioning, disaster recovery, and rollout of new versions.
As explained earlier, we had one application runtime that supported multiple databases for the respective customers. In our case, we had built N-number of Tomcat web applications deployed in one server that shared the common application runtime. This way, every customer had access to an independent application, with every application having its connection pool to manage connections. However, a plan of merging these deployments to one application is underway, so that we don’t have to run duplicate processes.
We brought down the customer onboarding time by automating the database creation with templatized data using Chef scripts. Apart from the database creation, it was also essential to set up a backup-recovery process and failover & load balancing for the application, which we could achieve by using the cloud solutions and Chef scripts.
As the solution helps in innovation management, the data was highly critical to our customers. This implied that our SaaS system should be able to weather any unexpected disasters and unforeseen accidents. To handle this, we had deployed the application & database across multiple availability zones that ensured timely updation of application and copies of the database whenever the primary DS is down.
For a new version rollout, along with the SaaS application deployment, we had to deploy a new version of the database or upgrade the existing version for each customer. However, with one-click deployment automation that we had in place, we could safely upgrade all customer applications to the new version all the while ensuring the existence of a recent backup in case of a rollback.
As we had an isolated database for each tenant, we had to spin up multiple DB servers for each of them, and this was more of a requirement rather than a choice. But since the application runtime can be shared, we had options of hosting it in a single server depending on the usage. By grouping customers based on utilization, we could reduce the number of servers and, in turn, accelerate the usage.
As stated earlier, we isolated data for each customer by having a separate database all the while sharing a common application runtime. This came with the additional baggage of securing the application runtime that would restrict the urge of end-users to access other end-users’ data points. How did we implement this? Here’s how-
Apart from that, there were many other security compliances we had to follow for the SaaS application-
Despite the above challenges, this model helped us live up to the promise made to the customer. Our SaaS application had ideas across enterprises remain isolated and high-security compliance remains ensured for every customer.