There is a truth about SaaS (software as a service) solutions that twist the definition of cloud-based technology. Is the solution offered by the vendor a lift and shift of their traditional software solution in the cloud? Or is it truly cloud-native, built from the ground up, to be optimized as a cloud solution?
Now the twist.
Do you actually care?
If the price is right, if the uptime is measurable against a service level agreement, and the solution is secure, what do you care? Does it really matter if the solution is cloud-native and multi-tenant, or a reengineered version to work in the cloud as a single tenant?
The answer is it does matter. But not for the reasons you may be thinking. Surprisingly, being cloud-native may not be the right choice for your business after all, despite all the marketing around multi-tenant cloud-based solutions.
To understand the problem, let's establish a few definitions:
The first is single-tenant versus multi-tenant. A single-tenant solution is the installation of an application that does not share backend or database resources with another operating instance. That is, the runtime and data is dedicated to a single company, department or organization and a role-based access model is used to control permissions and isolate datasets.
A multi-tenant solution shares common resources including potentially a backend database to provide a logic separation of data and permissions to isolate information, configurations and runtime from other logical groups of users. It provides a method to efficiently scale the solution and, if properly implemented, prevents improper data bleed from one tenant to another while consuming shared resources.
Traditional on-premise technologies are generally thought of as single-tenant solutions while cloud-based solutions are generally thought of as multi-tenant solutions. That is not always true and, in many cases, not good for your business. Here is why.
When you subscribe to a SaaS multi-tenant solution, the shared resources behind your subscription are utilized by multiple other organizations. You company forgoes the following security best practices:
• Change control: A multi-tenant SaaS vendor controls when your version is upgraded and patched. They will provide a maintenance window for the upgrade, and you will be forced to accept the changes even if it is not in a desirable timeframe for your business. If the upgrade introduces an undesirable change (bug or incompatibility), there is no way to roll back the changes since multiple organizations are sharing the same multi-tenant shared resources.
• Security: With any multi-tenant solution, there is always a risk of data bleed with another organization or a vulnerability affecting one organization being used to expose data from another. This can even be true with a simple backend misconfiguration or an insecure third-party add-on that risks the security of the multi-tenant model. In essence, this is out of your control.
• Customization: Outside of a few multi-tenant SaaS vendors that have designed customization directly into their platform, most multi-tenant solutions do not allow extensive customization to meet individual business requirements due to the number of shared resources they consume. While this may also be perceived as an advantage to avoid customized obsolesce, it can also cause distribution and unnecessary rework when APIs or features become deprecated as the service releases newer versions.
These are candidly a trade-off in lieu of maintaining the hardware, operating system, maintenance and security patches for the solution compared to an on-premise instance. However, the same could be true of a single-tenant SaaS solution. A single-tenant solution has a different set of concerns based on the same topics that are contrary to a multi-tenant solution:
• Change control: In a single-tenant SaaS model, the end-user can decide when to upgrade to a new version and if they want to skip a version altogether. The risk is waiting too long to upgrade and potentially operating with an end of support or end of life version. A SaaS-based single-tenant version needs to be managed within your current change control procedures and policy. This requires effort not normally associated with a SaaS solution even if the upgrade is fully automated.
• Security: Your SaaS-based single tenant is your own. Any misconfigurations or missing security patches that need to be manually authorized can introduce unnecessary risk. Even though it is a SaaS-based solution, you still have the change control responsibilities of patching and maintenance just like full versions even though the vendor will fully automate their installation. Again, while this is probably fully automated, the organization will need to maintain this just like any other application for patch management. And, since the solution is a single-tenant, there is a very low risk of data bleed unless the hosting company is compromised, somehow, themselves.
• Customization: A single-tenant SaaS solution allows for the most possible customization since any changes will not affect any other tenants or organizations. However, there is a risk since compatibility with future versions might break when the version is upgraded. Luckily, since you can control the version, you test customization before any upgrade and stay on an older version until you are ready.
So what else is different between a single-tenant and multi-tenant SaaS solution?
If the cost to the end-user is acceptable regardless of model, multi-tenant versus single tenant is really just a trade-off between change control and acceptable security risk. If you always want to be on the latest version, either model is acceptable. You just have to manage the change control yourself.
If you want to customize the SaaS solution, then it becomes the capabilities of the SaaS vendor that should be evaluated and not the tenancy model.
And finally, security. All SaaS solutions should allow automatic security patching, but the difference defers back to your change control requirements. So there really is no difference unless any of these are unacceptable to your organization. It is truly up to you decide if change control, security and customization are that important when choosing a SaaS solution.
