5 Reasons Your Next App Should Be Multi-Tenant
Austin Startup Week begins today and I thought it was a good time to share some thoughts on why you should design your application for multitenancy even if you don’t plan to support more than a single customer on the app today.
1. Better Security
Designing an application for multitenancy forces you to think early about Roles Based Access Controls (RBAC) like system level superuser and (per company) administrator roles. This is a is a VeryGoodThing™. It also requires thinking about data protection like encryption to protect customer data.
2. Faster (and better) Testing
Say your product has only 1 customer configurable option (changing the font from Arial to Comic Sans) you’ll need to either spin up 2 VMs to test in parallel or execute some of your tests in series with each font selected. If instead, your product is designed for multi-tenancy you can create 2 customers on the same instance and execute ‘duplicate’ tests in parallel. In any reasonably complex product the time savings of parallel testing add up quickly.
For larger and more complex products you also introduce unpredictable workloads throughout your test matrix ,making it easier to identify potential bottlenecks and timing issues. This is especially important when your application may not be running on a dedicated server when the customer deploys it.
2. More Scalability
Multiple tenets encourages thinking about larger and more complicated deployments… from simple things like where do I put the data to how should I balance and prioritize workloads. I can’t tell you how many applications where simple things like changing the default install drive or data storage location broke the software. Coupled with feedback from parallel testing on bottlenecks you have a better chance of discovering scale issues and working to address them before your customers find them.
4. Better Design Patterns
When you’ve added per customer font choices it is more likely you’ll have implemented the solution in a way which allows you to further scale within a single customer. This higher level of abstraction makes it easier when the product manager decides there should be a configurable option to allow per department or user font choices. As you add new features at a customer level if a QA test reveals leakage across customers you know there’s a security issue to be addressed.
5. Better Supportability
If your support team needs to ‘build out’ an environment to test a customer scenario they can do so in many cases without having to spin up a new VM of your software by just adding a new customer and changing configuration options. Multiple support engineers can work off of the same instance without overwriting changes as they troubleshoot an issue. Also your team doing demos can now customize a demo instance based on customer discovery calls to feature a customer logo or a configuration the customer has expressed instance in. Another advantage for DevOps is that across the board you’ve reduced the number of instances for designing, testing and supporting your product. You spend less time on arcane orchestration tasks that have no applicability outside of you internal use cases and instead the time you do spend on automation and management more closely aligns with the challenges your customers will face in deploying and managing your app.
I won’t pretend multitenancy doesn’t come with a cost on the development end, but it’s a worthwhile investment
One last thing… If you decide there may be a SaaS play for your solution at some point you’ve got a foundation. In the past I’ve been tasked to provide technical evaluation of software for acquisition and partnership with SaaS companies. Of all the products I’ve evaluated, I’ve never green-lighted a single tenant software solution. The engineering cost to modify the system to support multi-tenancy was unacceptably high.
