Last night i had been diving a little more in to my little azure case study, and i ask myself and if i consider a Multi tenant. This had report me to an all new study and issue consideration.
In this post i will explain some of the thoughts that had occur me about Multi Tenant application and Windows Azure.
Single Tenant and Multi Tenant
1st of all is important to remember the mean and difference of this two concepts. In an abstract way we can say that a Single Tenant Application offers a separate logical instance of the application for each costumer while a Multi Tenant Application offers a single logical instance for multiple Applications, that means that the logical instance is shared across clients. Is obvious that in the case of datadriven applications different clients will have different access and views over the data, but the logical “infrastructure” to get that data is shared across clients. The next Figure illustrate the logical view of the two different concepts.
Understanding Multi Tenancy in Windows Azure
The distinction between Multi and Single Tenancy in Windows Azure is not as straightforward as in the conceptual view of Patterns, since an application in Windows Azure is almost always made up multiple components, each of which should be analysed to understand the “Tenancy option” of each one. So when talking about tenancy in azure we should think in each part of the solution and because for sure we will have different modules with different missions evolved (Web UI , Worker Roles, Storage and so on).
The decision of each what approach to make in an Azure web application should be analyzed in each part of the application and in each module essence.
So let’s discuss the architecture issues we should always to consider when talking about Multi Tenancy in the Microsoft Cloud.
- Making your Application Stable: If one of your architecture goals is to guarantee stability remember that an Multi Tenant approach is more vulnerable to instance failure then a multi instance approach. However he should always remember that Azure by concept allows you to deploy identical copies of our application in to different Windows Azure Roles instances.So we need to consider in the design of our application that she could be deployed to multiple instances.
- Handling Authentication: authentication and authorization handling is another thing you must consider. Since we can provide our own authentication mechanism or existing authentication systems. In a Multi Tenant application this will imply the support to multiple authentication systems.
- Scalable: In Azure scalability depends essentiality on being able to deploy multiple compute nodes while being able to access the same data from all that nodes. Both single Tenant and Multiple Tenant allows applications to use this feature to scale out. When designing a client server app you must consider that you may not want to have all your costumers sharing a single multi tenant instance, a case of this need is when you want group clients based on a functionality. We should also consider that in Windows Azure the prefered way to scale an application is to scale out by adding additional nodes instead of scaling up by using larger nodes.
- SLA: Another important issue to consider is the Service Level Agreements you intend to offer on you application, if you intend to offer different subscriptions to your application service sharing Application logic or computational power wouldn’t be a good idea.
- Application Upgrade: If we intend to create an application which the Applications upgrades are frequent, having a multi tenant solution makes it easy and cheaper at the same time, since all the application logic is updated in just a single step.
- Data architecture and Multi Tenancy: One of the major issues to consider is to ensure that a clients data is kept private from other clients. The perceived risk of data disclosure is greater in Multi Tenant architectures.
- Data architecture: There is a lot of ways that you can enable tenants to extend the data model and to include their own custom data. In the case of SQL Azure much of the applications hard implementation work will be based on having to work with constrains of fixed data schemas. In the case we are working with Azure table storage we can have the records in the same table with completely different structure, which give us a great flexibility.
- Scale at the data level: If we can partionate data horizontally we will be able to scale at out at data storage. In cases where SQL Azure is a must have to scale out we need to be able to move all our individual tenant dat to a new SQL azure instance.
This are some of the points to consider when discussing or thinking about a single or multi tenant architecture in Windows Azure platform. Don’t forget also the financial part of this choice.
Hope this small discussion can be off any help in your future architecture discussions and considerations, having Multi Tenant or Single Tenant architecture in Windows Azure goes far beyond the software patterns design cocepts.