How to Build a SaaS Product with Both Data and Run-time Isolation?

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, wherein isolation of both data and runtime environments is required, this article 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.

The project management platform that we were working on was an enterprise-level software based on a well-established algorithm to perform an optimal schedule for different types of project environments. However, to further delve into providing scheduling solutions at a much granular level, the product was going through a major overhaul in terms of new functionality being provided in addition to existing solutions, along with a UI revamp to make it more user-friendly.

Challenges that Came Along

The main challenge was to get early feedback for the new functionality from the existing customers for quick incorporation into the product. At the same time, it was also necessary to give the product to a wide variety of potential customers for initial trials, 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 product was hosted in the customer’s environment. Therefore, we decided to provide the platform as a SaaS 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.

Arrival at the ‘Make-or-Break’ Decision

Since every organization’s business model is different, the task management and execution could be different, so that these platforms are designed in a way that 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 data specific to the businesses.

In this 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 could agree that Type 2 architecture was the right fit for this case and decided to implement it using our experience of saasifying products for growth-stage startups from various domains.

Dealing with the Architectural Roadblocks

Given below are some of the architectural challenges that we encountered, and our approach of effectively tackling them to drive successful implementation-

Scaling

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

New customers need to be onboarded quickly, 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 provision the application and database instance within minutes of signing up. This was done using the automated scripts to provision 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).

Customization

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.

Hardware Utilization

The new architecture should be optimized for hardware availability. While there will be existing customers with huge data sets and customizations, there will be some customers with few data and almost zero customization. This was done by analyzing the costs of cloud infrastructures like instances, database servers, etc. and preparing the pricing plans for end-users accordingly.

Security

A lot of security aspects were already handled by isolating data as well as application runtime for each customer. The data in transit was over HTTPS only. The application itself provides secure access for all customer data.

Cloud

In the current example that we are discussing, the customer wanted to modify the existing platform in the form of “Portfolio as a service”, and 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. The architecture was built around multiple clusters so that all customers have their own runtimes (applications) and database server and no sharing of data or applications are entertained-

Design

As demonstrated in the diagram given below, on every new customer onboarding, our automated services created keys and did provisioning of applications and databases as per the pricing plan adopted by customers. Once this is step is completed, they could immediately start using the platform.

For every customer’s request, the load balancer identifies the right IP address of 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.

Advantages of SaaS Type 2 Architecture

They say- sometimes it’s the smallest decisions that can change things forever. In our case, it was our decision to probe the customer’s case up close and choose the right SaaS architecture type that would serve their purpose well. Some of the advantages that the customer enjoyed-

• Security is handled at the infrastructure level so that the application doesn’t have to take care of data sharing.
• No necessity of managing connection pools for tenant-specific databases.
• Low chances of the system’s underutilization as scaling can be done differently for different clients.
• Faster customer onboarding is possible since no tenant-specific items are built.
• The system can be customized as per user’s need without worrying about its impact on other users.

 Conclusion

We have customized customer onboarding in place, wherein customers can pick pricing plans as per portfolio size and the number of users, and our fully automated deployment solution provisions correct instances in the cloud and ensure optimization of the system. While SaaS type 2 architecture comes with several benefits, startups considering to implement it must be aware of the heavy investments on automation and monitoring that are tied to it.

(4 votes, average: 3.75 out of 5)
Loading...