Often we need to make a call between architecting for single or multitenant instances when designing Software as a Service (SaaS) products. Under a single tenant solution you deploy one instance per customer and under a multitenant solution many customers share a single deployed instance (where ‘an instance’ is all of the server resources you need to make the product available, e.g. web server, database, email server). It’s costly to change architecture once an application has been developed, deployed into production and has live users – so picking the most appropriate architectural approach from the outset is important to ensure longevity and maintainable costs. The following offers a number of considerations in helping decide which approach is appropriate for you.
Single Instance considerations:
- Physically ‘more’ secure – as each customer has a separate instance (likely including database, web servers, and storage) the risk of leaking data between instances is significantly reduced
- Performance can be tuned on a per customer basis. Have a client with heavy loads? Scale up, or out. A load intensive customer won’t affect the performance of other clients as the resources are not shared. Got a light work load? Scale down, reducing cost.
- Deploying to an on-premise, or hybrid cloud location is an easier story if you’re already set up to deploy as single instance model. The nature of single instances means that an instance can be created and deployed as a single package – assuming the target deployment environment supports the required services and any other dependencies, e.g. web server, database server, virtualisation and / or network services (SMTP, DNS routing), runtimes (.NET, PHP)
- Instances can be deployed in different regions to reduce latency (increasing performance by moving the instance closer to users), or to meet local compliance laws, e.g. data sovereignty
- Calculating per customer hosting costs is simple as it’s based on exact, actual resource usage
- Per customer [instance] customisation can be achieved if required. For that customer who just has to have that specific feature. Note: this will complicate your source control and deployment models, and can lead to a fragmented nightmare if not managed effectively, or avoided all together. Just because you *could* customise a solution per customer doesn’t necessarily mean you should!
- Monitoring, maintenance, backups and new version and/or patch deployments and/or data migrations need to be managed on a per instance level, increasing costs proportional to the number of instances. Need to back up instance databases, or roll out an update? Consider how will this be managed, and the cost for 1, 10, 100, 1000, 10,000 instances. This is a significant cost, and should be evaluated against the necessity and likely usage of the other benefits of this model
- Have a clear picture of how new instance provisioning will be managed, and how long it will take. Most cloud platforms allow for automated provisioning via API’s, and you may need additional steps like registering or configuring external services like DNS and authentication mechanisms (e.g. AD accounts)
- Some resources can be shared, e.g. worker queues for background processes and SMTP servers. Plan which resources need to be ‘per instance’, and which make sense to share across instances
Single instance is typically suitable for:
- Applications that store highly commercially sensitive, or personally identifying information of a private nature
- Customers with specific, and varying workloads
- Customers who need to adhere to local compliance laws
- Customers willing to pay a premium for these features as they incur a higher cost to provide and manage
- Careful consideration needs to be made to ensure data is not leaked across clients. This isn’t difficult, and should be managed with suitable design and sufficient testing
- Deployments are much simpler, everyone can always be on the latest version. This approach lends itself to providing an ‘evergreen’ product
- Reporting across all your instances is much simpler when they are in the same place (or all the data is in the same database)
- On-boarding new customer is typically simple as it doesn’t require the provisioning of underlying resources (servers, database, storage)
- An outage will effect *all* of your customers, design for redundancy
- Requires a single monitoring, maintenance, backup and deployment approach. Costs will increase with the number of tenants, though much lower that a per instance approach. It’s probably the biggest benefit to this approach
- There could be a point where you need to scale up, or out – or have *very* large data and need to consider how to partition. This could be one multitenancy per region.
Multitenancy is typically suitable for:
- ‘Self Service’ products scaling up to and greater than 1000’s of customers
- Reducing costs of deploying, hosting and maintaining your service
Shared tenancy with individual database and/or storage
An alternative hybrid approach is to provide shared tenancy of the application, with separate storage per customer. For example your app could be load balanced across a number of web servers which would service all of your customers. Each customer however would have their own separate physical database for data storage. This approach gives you the ability to provide the physical separation of data while having a shared application tier. This approach takes benefits from both single and multitenancy architectures:
- Physically ‘more’ secure
- Storage can be located in different geographic regions (though be aware any latency this might introduce in your application)
- Retains ‘evergreen’ application versioning
- Overall costs are lower than single instance approach