How serverless enables new software delivery models for SaaS products in the cloud

Written by Rishabh Bhargava & Raghu Murthy

SaaS (software-as-a-service) products are ubiquitous in the modern enterprise. SaaS is great for cost control and ease of management for both the vendor and the customer, but those advantages come with trade-offs around data security models, primarily due to commingling of data in the multi-tenant architectures of SaaS vendors.

In this blog, we claim that you can have your cake (cost/ease of management) and eat it (security) too! We explore changing the software delivery model of SaaS products to solve for security while maintaining the traditional advantages of SaaS products by leveraging serverless offerings from cloud vendors (AWS, Azure, GCP) and adopting serverless devops workflows.

Multi-tenant architecture — the good and the ugly

Why do SaaS products use multi-tenant architectures today?

SaaS advantages are well-known. Customers don’t have to worry about provisioning resources or deploying, monitoring, maintaining and upgrading the software, which are time consuming and expensive activities. SaaS vendors typically build and manage a single version of their code base for all their customers. Multi-tenant architectures with shared hardware across customers of many different sizes results in economies of scale for the vendors as well.

Security challenges for multi-tenant architectures

Companies take huge risks when storing their sensitive data in third-party SaaS services where their data can get commingled at rest, in motion, or in memory with other companies’ data.

Multi-tenant architectures have security challenges around data isolation. It is very difficult to prevent data from different customers from commingling within the same infrastructure. While the expectation is that only the organization that owns the data is able to access or modify it, legals actions against the vendor or one rogue administrator or application can upend this expectation for all customers of the vendor. While there are design patterns and general good principles to alleviate risks of multi-tenant architectures (primarily through standalone apps per tenant, one database-per-tenant), such projects often end up ballooning costs.

This problem is compounded by the fact that each SaaS application used by a customer is built and managed by a different vendor and the customer’s data is now scattered across all these applications.

Finally, one breach for a vendor leads to data integrity issues not just for one customer, but for all of them. While it is hard to measure the exact cost of a data breach, the fact that worldwide spending on IT security was forecasted to grow by 8.7% in 2019 (as opposed to general IT spend which only went up by 0.6%) speaks volumes.

No wonder, regulators are attempting to enforce data security through various legislations such as GDPR, CCPA and HIPAA.

Scaling challenges for multi-tenant architectures

SaaS products are built with multi-tenant architectures with shared hardware. Shared hardware typically means having a single cluster of machines and central databases that can service the application’s needs across all customers. So as the number of customers or their usage grows, the SaaS provider just needs to keep adding more nodes to the cluster. The advent of container technologies — Docker, Kubernetes — has meant that scaling of compute clusters has become fairly straightforward.

At some point, however, the deployment starts hitting scalability limits of the software platform used to run the cluster. Now, vendors are left with the tough choice of sharding databases and applications into multiple clusters which creates a bin packing problem of assigning customers to clusters. The hope is to make efficient use of each cluster which requires carefully managing which customers are on which cluster as new customers come in and as existing customers grow, shrink or churn. This takes on a life of its own in most growing SaaS companies, with significant engineering resources spent on making the infrastructure scale and be cost effective.

Another problem multi-tenant systems have to contend with is that of rogue tenants or noisy neighbors. A tenant that is growing extremely rapidly can end up consuming too many resources in the multi-tenant environment. Such a situation is challenging for vendor’s engineering and operations teams to handle, and can lead to outages and impact service for neighbors of this rogue tenant.

Despite these challenges, SaaS tools have become so convenient for businesses that “SaaS Sprawl” is now a growing problem in most enterprises, and many data teams now struggle to get visibility into which SaaS vendors get access to which data. There are even products now that provide insight into the proliferation of SaaS tools for a customer, and these are SaaS tools themselves.

Single-tenant serverless architectures

Having seen the security and scaling challenges associated with multi-tenant architectures, let’s consider how we might solve these while retaining the cost benefits of economies of scale and ease of management for the vendor.

First, let’s discuss public clouds

Public clouds are themselves built as multi-tenant architectures. The cloud takes care of sharing hardware and driving utilization of the hardware up across different PaaS (Platform-as-a-Service) offerings. The scale at which public cloud vendors operate means that they are able to achieve incredible economies of scale. Since most SaaS products are being built in public clouds, any given SaaS product is an individual tenant in the public cloud.

SaaS product customers are sub-tenants of public clouds!

It is unlikely that an individual SaaS product is able to gain any more utilization/efficiency by building its own multi-tenant architecture.

In the last few years, public clouds have been making serverless services available to their customers. These charge customers on a pay-per-use basis, and customers don’t have to worry about provisioning the underlying infrastructure. These services are available for databases (relational and no-SQL), compute, storage, distributed queues, etc. Services scale up and down based on usage, and they are backed by the cloud provider themselves, rather than an individual SaaS vendor. No matter the scale of usage, these end up being extremely cost-effective options for a customer considering the total operating cost of ownership.

DevOps and Security case for single-tenant architectures

Maintaining a handful of multi-tenant clusters with a centralized DevOps team for all customers of a SaaS product is a reasonable thing to do. But with the rise of serverless architectures and good serverless development practices, the load on DevOps has gone down dramatically. In the case of function-as-a-service, there is almost zero DevOps overhead and application developers can directly push changes to the code and monitor deployments (assuming that the right tooling is available). Now, the administrative cost of monitoring customer deployments is much more manageable.

Given this reduced load on DevOps, it is possible to have separate deployments for each customer in order to ensure data isolation. This would allow the SaaS vendor to deploy their software within the customer virtual private cloud (VPC) for full security. The SaaS product vendor can have minimal privileges (ideally using the principle of least privilege) to centralize their own DevOps.

An analogy to this are the apps such as Notes and Reminders installed on the mobile phones. The phones have the data and the apps provide the functionality that the customer needs by using data that does not leave the phone.

In light of this, we predict that serverless, isolated, single tenant architectures will become a lot more popular for data-sensitive applications.

Final thoughts

So here are the trends we are seeing. Customers are moving to the public cloud from their on-premise data centers, creating “private data centers” in the public cloud (i.e. a VPC) while continuing to make the most of a rich variety of SaaS tools. While vendors have, traditionally speaking, employed multi-tenant architectures, many forward-thinking vendors are deciding to move towards serverless, private deployments to obtain data privacy benefits and administrative scale.

When we set out to build Datacoral’s data-infrastructure-as-a-service, we wanted to pick a software delivery model that would enable our customers to meet all their data privacy and control requirements while still giving them the full convenience of using a SaaS product. Our challenge was whether we could find a way to provide all the advantages of economies of scale without any of the security challenges. The solution we found is a multiple single tenant architecture.

Over time, we believe that this will be a real win-win for customers and vendors.

What do you think? Leave a comment or for more information contact us at hello@datacoral.co.