It would appear, from initial studies, that SAAS as a business model makes economic sense; well for small to medium businesses anyhow (large organisations may prefer to spend their larger budgets on their own home baked solutions supported by their expansive IT department). Economies of scale means less expenditure for underlying IT infrastructure and the human aspect involved in maintaining it – sounds very attractive to the small and medium sized business, but is it really so?
A SAAS (software as a service) application in simple terms is really a web based solution, that can be used by numerous tenants, and is maintained by the application provider. The cost for servers, hosting, security, maintenance, high availability, backups etc is already factored into the price of the application being offered.
The biggest threat to SAAS is the question over security. How does a business know that their confidential data is safe from other companies who are using the system, some of whom may even be direct competitors? Thats down to the solution the SAAS provider has created. All offer working solutions, but some are more “robust” out of the box than other solutions, but are less scalable. Conversely, the solutions that are more flexible (read cheaply scalable) also require the most effort to develop.
There are various solutions to architecting a SAAS application. The main aim is to securely facilitate multi-tenants. Thats is, to use the one application to serve more than one user/company/multinational. However as always, there’s more than one way to skin a cat.
Probably in it’s simplest form, the most simplest solution is to create a database for each tenant that is using the system. This solution is very easy to instigate; simply copy the existing master database and create another instance that is individualised to the tenant in question. This probably sounds more secure than other alternative solutions. Each data transaction is separated and isolated from those of other users. It is easy to visualise the security benefits of this SAAS solution. However the DB layer can only be extended so far before it has to be scaled upwards to facilitate growth. Not cheap nor realistically economic for bottom line profit for the SAAS provider. After all, we are all in business to make money!
It would appear that the most scalable and affordable and expandable SAAS architecture is to use a shared database solution. This means we have only one database, and one copy for each main table. Each row on the tables would utilise a TenantId column. For each CRUD transaction (create, read, update, delete) the application has to serve, it will have to ensure that the requesting tenant is only served up with/accesses data that belongs to them, keeping data that belongs to other tenants securely hidden away. The downside is that this solution does requires the most significant effort at the application end – one which the developer may not be too happy to develop! However it will most likely be the most scalable. Used with a stateless environment, like encrypted local client cookies, it can be scaled sideways as and when required to cope with tenant demand. It’s all more easier to add additional mid-range servers to extend the SAAS solution than to upgrade to a more powerful server.
In summary, a stateless web application coupled with a shared row based / horizontal partitioning database with data transactions secured on tenant ID sounds like the ideal best practice SAAS solution.
So there you have it; thats my personal take on SAAS applications. SAAS can be utilised to be beneficial for both the service provider and also the service user, which is the utmost important customer.
Oh and finally, where does the ASP.Net SAAS Multi-tenant aspect come into play? Well sorry to sat that the details of a technical ASP.Net solution is for another days blogging. I’ll update this post with a link to follow-up posts when I have time to work on some personal solutions. Until then, why not share your personal SAAS solutions in the comments…
Tags: .net · architecture · multi-tenant · SAAS · scalable DB · stateless1 Comment