How to Build a SaaS Product with Both Data and Run-time Isolation?
Application Architect - 23 September 2020 -
Application Architect - 23 September 2020 -
After a startup considers SaaS implementation, choosing the right SaaS architecture type is highly imperative to not only ensure the right pricing model but also accommodate special design requirements, such as scalability and customizability. Also, if you’re considering SaaS type 2 architecture for data isolation and runtime isolation environments, this article on how to build a SaaS product easily is a must-read. As an application architect working on enterprise software, let me walk you through how we helped a project management startup succeed by applying SaaS type 2 to build a SaaS product.
The project management platform that we were working on was enterprise-level software. It based on a well-established algorithm to perform an optimal schedule for different types of project environments. However, to provide scheduling solutions at a much granular level, the SaaS product was going through a major overhaul in terms of new functionality for existing solutions. Also, we had to revamp the UI to make it more user-friendly.
The main challenge was to get early feedback for the new functionality from existing customers for quick SaaS product enrichment. Simultaneously, it was also necessary to give the SaaS product to a wide variety of potential customers for initial trials. This was to get them on-board for long-term engagement and provide scheduling solutions based on their needs.
While we started placing our focus on reducing the cycle time for features, it wasn’t possible with the traditional model of deployment wherein the SaaS product was hosted in the customer’s environment. Therefore, we decided to provide the platform with the SaaS model offering. However, the immediate next step was to pick the right SaaS architecture, and this was crucial considering its role in fostering the platform’s future growth.
Since every organization’s business model is different, the task management and execution could be different. Engineers design these platforms in a way to make customization is easy for end-users. Moreover, the platform should be easily customizable for different customer environments. In one common time frame, multiple customers are going to use the platform to create portfolios for their organizations, which will hold very sensitive information for data related to the businesses.
In this SaaS model, the customers were very clear and strict on the need to have complete isolation both at the application level as well as data level. We agreed that Type 2 architecture was the right fit for this case. Hence, we decided to implement this software as a service using our experience of saasifying products for growth-stage startups from various domains.
The following are some of the architectural challenges that we encountered while building a SaaS product, and effectively tackled to drive successful implementation-
Each customer runs on a different scale; some customers have thousands of users using the platform for planning and execution. On the other hand, there are customers with very few top-level executives using the platform. Since we have the freedom to deploy the application at the customer level, the application was deployed keeping the size of user bases in mind.
Fast Customer Onboarding
We had to onboard new customers with minimal assistance from the Engineering or Implementation teams. For this, as soon as a new user signs up on the platform, we need to provide the application and the database instance within minutes of signing up. We did this by using the automated scripts to deliver an application instance from a pre-configured base image quickly. Also, a unique URL for the application was generated using AWS Route 53. Once the provisioning happens, the user is notified that he/she is ready to use the platform with his unique URL (user-specific or organization-specific).
Architecture should support the customization of different business entities without any customer-specific deployment from the engineering team. These customizations were provided in the application via a configuration dashboard, wherein an admin user of an organization will set the configuration parameters based on the organization’s needs.
We had to optimize the new architecture for hardware availability. It is imperative that there will be existing customers with huge data sets and customizations. But there will also be some customers with little data and almost zero customization. We did this by analyzing the costs of cloud infrastructures like instances, database servers, etc. and preparing the pricing plans for end-users accordingly.
By handling data isolation and application run time for each customer, we can solve a lot of security concerns. The data in transit was over HTTPS only. The application itself provides secure access to all customer data.
Our customer wanted to develop the existing platform as “Portfolio as a service.” They didn’t want to manage infrastructure and hire an admin for management. The implicit requirements were complete automation of provisioning, which was achieved with a one-click deployment for the product to provision application and database instances within no time. We built the architecture around multiple clusters so that all customers have their own runtimes (applications) and database server . With this, we could prevent sharing of data or applications and security parameters could be followed–
As demonstrated in the diagram, on every new customer onboarding, our automated services created keys and did provisioning of applications and the databases as per the pricing plan adopted by customers. Once the step is complete, they could immediately start using the platform.
For every customer’s request, the load balancer identifies the right IP address of the application to process. Thereafter, the application gets fully encrypted data from an isolated database, decrypts data using the keys, and sends it back to the user.
They say- sometimes it’s the smallest decisions that can change things forever. It was our decision to probe the customer’s case and choose the SaaS architecture type which is the right one. This was to serve their purpose well. Some of the advantages that the customer enjoyed-
We have customized customer onboarding, wherein customers can pick pricing plans as per portfolio size and number of users. Our fully automated deployment solution provisions verify instances in the cloud and ensure optimization of the system. Software as a service type 2 architecture comes with several benefits. Startups considering implementing a SaaS product type 2 must understand that automation and monitoring need heavy investment.