The Hitchhiker’s Guide to Telco Transformation - Part 8
Choosing a Multi-Tenant Approach for You
In my prior blog, I discussed the different SaaS Data architecture options available. We discussed the pros and cons of each of the following options: Separate DB, Shared DB/Separate schema and Shared DB/Shared Schema. To summarize:
Each of the three approaches offers its own set of benefits and tradeoffs that make it an appropriate model to follow in some cases, as determined by a number of business and technical considerations. Here are some of the considerations a data architect needs to take into account when choosing a multi-tenant approach.
Always an important consideration. Applications optimized for a shared approach, tend to require a larger development effort and investment than applications designed using a more isolated approach ﴾because of the relative complexity of a shared architecture﴿, resulting in higher initial costs. However, because they can support more tenants per server, ongoing operational costs tend to be lower.
The shared schema approach can end up saving you money over the long run, but it does require a larger initial development effort before it can start producing revenue. If you are unable to fund a development effort of the size necessary to build a shared schema application, or if you need to bring your application to market more quickly than a large‐scale development effort would allow, you may want to consider a more isolated approach.
A good number 2. The more your application stores or requires more sensitive tenant data, prospective customers will have more security concerns and your service level agreements ﴾SLAs﴿ will need to provide strong data safety guarantees. While a common misconceptions suggest that total security can be ensured only via physical isolation, a shared approach can do the same but requires the more sophisticated design.
The number, nature, and needs of the tenants you expect to serve all affect your data architecture decision. Some may require a more isolated approach, while others a more shared approach.
- How many prospective tenants do you expect to target? Think in terms of orders of magnitude: Are you building an application for hundreds of tenants? Thousands? Tens of thousands? More? The larger you expect your tenant base, the more likely you will want to consider a more shared approach.
- How much storage space do you expect the average tenant's data to occupy? If you expect some or all tenants to store very large amounts of data, the separate‐database approach is probably best. In any case, it is best to make this decision up-front rather than changing you approach half way through the design.
- How many concurrent end users do you expect the average tenant to support? The larger the number, the more appropriate a more isolated approach will be to meet end‐user requirements.
- Do you expect to offer any per‐tenant value‐added services, such as per‐tenant backup and restore capabilities? Such services are easier to offer through a more isolated approach.
Encryption is a way to further protect tenant data within the database, so that it remains secure even if it falls into the wrong hands. Public‐key cryptography requires significantly more compute power than symmetric cryptography; a strong key pair can take hundreds or even thousands of times as long to encrypt or decrypt data than a symmetric key of similar quality. For SaaS applications in which all stored data is encrypted, the resulting processing overhead can render public‐key cryptography infeasible. A better approach is to use a key wrapping system that combines the advantages of both systems.
Large‐scale enterprise software is intended to be used by thousands of people concurrently. If you have built enterprise applications of this sort, you know first‐hand the challenges of creating a scalable architecture. For a SaaS applications, scalability is even more important, because you'll have to support data of all your customers. Instead of a widely deployed, business‐critical enterprise application, you're really building an Internet‐scale system that needs to actively support a user base potentially numbering in the millions.
Databases can be scaled up ﴾by moving to a larger server that uses more powerful processors, more memory, and quicker disk drive) and scaled out ﴾by partitioning a database onto multiple servers﴿. Different strategies are appropriate when scaling a shared database versus scaling isolated databases. Also, when developing a scaling strategy, it's important to distinguish between scaling your application and scaling your data.
Scaling is a big consideration in, and of itself. I will tackle it in my last blog of the Hitchhiker series. See you next time….