Software as a Service, or SaaS, is a software delivery model where that software is centrally hosted and then licensed to users through some kind of subscription.
But how can you offer your web application as a SaaS product?
There's plenty of incentive for you and for your customers to figure out how to do deliver a SaaS product.
By alleviating all software and hardware considerations from your users, the SaaS model provides faster time to market and replaces capital costs with on-demand operating costs, all in a clear 1-stop shop solution.
There are two major ways to implement your SaaS product: single and multi-tenancy.
Single-tenant software exists as a single instance per single customer. Data and resources are isolated for their needs, which makes instances easier to customize and scale for each customer. But there are also disadvantages. A one-to-one relationship between customer and SaaS instance can make it more difficult to update all instances in the fleet, and resource isolation can result in a greater cost per customer to operate.
On the other hand, in multi-tenant SaaS products sharing data is possible across all customers from a central instance. This makes it easier add new customers and can result in lower operating costs. However, multi-tenancy can be more difficult to scale, and customization for individual customers becomes much more difficult. Effort will always have to be made to keep customer data segregated at the application layer.
But I want it all. I want the advantages of multi-tenancy for my single-tenant application.
Well, we can take a look at a case study from Open Social to get an idea of what that might look like. With Platform.sh, Open Social provides a Drupal distribution for community groups, where each of their customers has their own instances. Open Social retains control of that instance, and no customers are given access to their server.
Open Social built their own management tool, which uses the Platform.sh API internally.
A customer's community is a unique SaaS instance powered by its own project on Platform.sh, not that they would ever need to know that that's how it's done.
Then, all of the community instances can be accessed by the vendor to manage updates and apply customizations.
Open Social manages all the code in the PaaS fleet. Since it's all just Git in the background, they can automate it - no matter the number of communities - very easily.
As a result, the vendor can receive all of the benefits of multi-tenancy, while keeping the advantages of a single-tenant application architecture for their customers.
With Platform.sh, they get the ease of single-tenant isolation, but the kind of complete control over scaling that comes with multi-tenancy in the background.