There has been lot of talk around various architecture – moving to cloud, SaaS, PaaS etc. And many ISVs we interact are exploring to achieve increased revenues and expand their customer base by moving to these marketing hype. Today, I wanted to just blog around things that come to mind of ISVs for building a strategy of moving their existing product to a SaaS model and this is exactly the time when we hear –
“How can we design for multi-tenancy?"
What does this mean?
Well, Maybe an online search can give you multiple definitions. From an product based ISVs point of view – they design software application to be consumed and used within a single company’s domain. Now what if you wanted to move the same application to the web for multiple users across multiple companies maintaining a single or simpler infrastructure.
A multi-tenant architecture in the SaaS world basically means one instance of your product serving multiple companies and multiple users within each company. There is a difference between users and tenants SaaS which is important to understand – think of a tenant as a company or a team – basically a collection of users. A user on the other hand is an individual person or system that is interacting with the product. There are already well written whitepapers on this very topic and repeating them here will be a waste of your time. I highly recommend reading the below papers for reference:
- Hosting a Multi-Tenant Application on Windows Azure : http://msdn.microsoft.com/en-us/library/ff966480.aspx
- Multi-Tenant Data Architecture: http://msdn.microsoft.com/en-us/library/aa479086.aspx – Article is quite dated but still has the concepts covered well. I was years ago directed to this paper when talking about SODA (Service Oriented Data Architecture).
Being a Database person, I get thrown with a question – “If we add the tenant_ID as part of every table, are we multi-tenant?” For me, that is a good start. Whenever I get a chance to talk on this topic – I bring out some more basic considerations:
- Data isolation – This will describe how each of the tenants want their data. And secondly, if the application mandates some tenants to move their data as part of the backup/restore or maintenance. Also, this can be an regulatory or compliance need. If thought properly, the Single Database (big-bang) approach or the Shared Schema approach fails here. Worst case, if that single DB gets corrupt – every other tenant gets affected?
- Data scoping and access control – When thinking this is also part of the above isolation technique. The important thing here is around who gets access to what part of data. The complications happen when you need to show different *master* data to different tenants.
- Horizontal scaling – This is to get the infinite scale and keeping manageability in mind, partitioning row-wise i.e. tenant-wise would give isolation and scales great. This also is an implementation of isolation tenant-wise. On-premise this can translate into an SQL Server Partitioning concept. In the Azure world we talk about SQL Server Sharding capability (Link) and recommend reading the whitepaper.
- Tenant wise customizability and configurability – Though in the SaaS world the scope for general profile customization are fine and easily implemented. At a business layer, many times the application needs to be extended and customized for different regions based on regulatory, compliance and other needs of a region or country. This is a very important factor – standardization will lead to ease of maintenance, single codebase, Reduced Opex etc. Be careful while taking a decision here, you don’t want to open a can of worms – “Evaluate flexibility at what cost?”. There are standard techniques for allowing customization as discussed in the Data Architecture whitepaper.
- Hosting on a hybrid but elastic infrastructure – When talking about SaaS or Cloud architecture people say Azure, AWS etc. Step back, when I mean hybrid or elastic – it can also mean at your own Data Centers offered to customers or DC of a Hoster or from standard cloud offering vendors. Your application needs to be built for such deployments – stateless, able to run independently on physical or virtual boxes in a dedicated and/or scale-out scenario without any problems seamlessly. Though the specifics on this very topic can be for a discussion some other day, keeping this in mind is an important factor.
Finally, All these when considered wisely could indeed give enterprises cost savings and benefits. If this is not achieved there is no point moving on first place. And if you don’t architect it right the first time and create a chatty application – remember you pay for data-in, data-out in the cloud world and that can dent your credit-card bills end of the month .
There is more on this topic than what has got covered, atleast I got you a start and some thinking pointers if it has not been considered in the past. Do pass around your thoughts and comments.