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-
- Employee engagement: Making ideation a part of daily lives and creating a culture of innovation
- Continuous improvement: Supercharging project discovery by tapping into the employee bases
- Product development: Creating the next big thing with people who understand the business well
- Customer experience: Engaging a wider workforce and reduce customer churn
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
How Our Decision Paid Off?
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-
- Data isolation
- Server utilization, wherein we kept application runtime shared to use the server capacity optimally
- Separating application runtime to the high-end server for some high-paying customers
What are the Challenges We Overcame and How?
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.
Supporting Multiple Database Connections
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.
Faster Customer Onboarding
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.
Effective Disaster Recovery
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.
Automated Deployments
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.
Utilizing Hardware
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.
How did we Ensure Security?
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-
- Maintaining separate configuration keys for each customer and rotating them on every release
- Preserving encryption keys of databases fields for each customer and rotating them on every release
Apart from that, there were many other security compliances we had to follow for the SaaS application-
- Our product was independently audited on an annual basis against a rigid set of SOC 2 controls
- We have an open policy that allows our customers to perform penetration tests of our service
- Our production environment is protected by a robust network infrastructure that provides a highly secured environment for all customer data
- Data in transit is over HTTPS only and is encrypted with the TLS v1.2 protocol. User data, including login information, is always sent through encrypted channels
- The hosting environment is a single isolated database and application components that ensure segregation, privacy, and security isolation in a multi-tenant physical hosting model. Instead of storing user data on backup media, we rely on full backups that are shipped to a physically different co-location site
- Customer instances, including data, are hosted in geographically disparate data centers. Customers may choose the location to host their data based on the corporate location or user base location to minimize latency
- We support Single Sign On (“SSO”), using the Security Assertion Markup Language (“SAML 2.0”). This allows network users to access our application without having to log in separately, with authentication federated from Active Directory
- An automated process deletes customer data 30 days after the end of the customer’s term. Data can also be terminated immediately depending on the contract terms of the agreement.
You may also be interested in: Software Development For Startups: A Founder’s Guide
Conclusion
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.
