In addition to multi-tenant architecture, there is a separate architecture (single-tenant) when each user is provided with their own infrastructure (this is typical for non-SaaS applications): logical or physical servers. For cloud services, this approach may not be justified, because fixed resources are allocated for each subscriber, regardless of how many are required (and this increases the final cost of the SaaS subscription for the user, as a result, it may turn out that the cost of the solution will be higher than that of competitors). Such a dedicated architecture for cloud services can only be justified for premium subscriptions, etc.
Multitenant architecture is a cardinal way to reduce the cost of computing resources and storage for SaaS software: due to the minimum required number of resources used (shared infrastructure) and their maximum load. The most tangible benefit is the combination of multi-tenancy and “unlimited scaling” (when there is no need to spend additional funds to promote additional resources or add new servers). You can try to implement unlimited scaling on your own or use cloud-based PaaS platforms.
1. In a multi-tenant application, you can always emulate a dedicated mode (one subscriber), while there is usually no way to expand a selected application to several independent subscriptions.
2. Fault tolerance. A multi-tenant application is more vulnerable to instance failure than a dedicated application. A dedicated deployment failure only affects the client that uses this application, while a multi-tenant application failure affects all clients.
Reduce the negative consequences of a failure can be with the help of several instances of the multi-tenancy application or part of it. For example, Windows Azure can reduce this risk by allowing you to deploy multiple identical copies of the application by using multiple instances of roles (this approach just fully implements a multi-tenant model with multiple instances). Windows Azure automatically distributes the load on request processing between these role instances, therefore, the application must be designed so that it functions correctly when using multiple instances. For example, if the application uses session state, you must ensure that each instance of the web role can access the state. Windows Azure also constantly monitors all role instances and automatically restarts instances when a failure occurs.
For some applications, it may not be appropriate for all clients to share the same multi-tenant deployment. For example, you might need to group clients based on the functionality of the application that they use, and then optimize each instance for each of the created groups. In this case, you may need two or more copies of a multi-tenancy application deployed even in different Windows Azure subscriptions.
3. Service Level Agreement (SLA). You can offer different service level agreements (SLAs) for different levels of service subscription. If subscribers with different SLAs share the same multi-tenant deployment, the highest SLA should be achieved.
4. Legal and regulatory environment. For some applications, specific regulatory or legal issues need to be considered. This may require differences in functionality, display of legal agreements in the user interface, provision of separate databases or storage areas for each specific subscriber, location of the service and storage in a specific geographical region. Under such conditions, it may be necessary to implement separate multi-tenant deployments for various user groups, or a strictly dedicated mode for each subscription to the service.
5. Authentication and authorization. An application in the cloud can use its own authentication and authorization system, in which case subscribers of the application will need to create credentials for all users of the application. On the other hand, customers may prefer to use their existing authentication system and avoid the need to create new credentials for the application. The second option for a multi-tenant application means having to support multiple authentication providers, and may also require mapping
application authorization schemes in the cloud with a scheme of local authorization infrastructure. In Windows Azure, Access Control Services is used to configure authentication and authorization, with which you can implement authentication by forms, through Active Directory, through LiveId, Google, Facebook, and other OpenID providers. If we are talking about integration with Active Directory and setting up federation between the AD subscriber and the service, then most likely this may also require a dedicated deployment.
Application Lifecycle Management
1. Maintaining a codebase. For development companies, maintaining separate codebases for different clients entails an increase in support and maintenance costs, as well as problems when tracking which clients use which version. This can lead to errors that result in additional costs. A multi-tenant system with one logical deployment guarantees one code base for the entire application. You can still maintain the same code base with a dedicated model with multiple deployments, but you may want to (with long-term consequences) fork the code for different clients. In some scenarios where there is a need to fine-tune applications, several code bases may be an acceptable option, but before choosing this path, it is necessary to study the possibility of applying custom configurations or custom business rules at the level of standard system settings (for example, via the interface) . If there should be several code bases, then the application should be structured so that user code is limited to only the minimum required number of user components.
2. Application updates. The multi-tenant application allows you to simultaneously distribute updates to all customers. This approach means that only one logical instance is updated, which reduces maintenance effort. In addition, you have the confidence that all customers use the latest version of the application, which simplifies support.
For example, the Windows Azure Update Domain simplifies this process by allowing you to distribute updates to multiple role instances without stopping the application. If the client has operating procedures or software associated with a specific version of the application, then any updates should be coordinated with the client.
To reduce the risks associated with updating the application, you can implement a sequential update procedure: in the first phase, the application is updated for a small group of users, in the second phase, if there are no difficulties with the new version, the updates apply to the remaining users.
3. Monitoring the application. Monitoring a single application deployment is easier than monitoring multiple deployments. In a dedicated model with several deployments, for any new role instance, it is necessary to set the monitoring environment settings, as a result of which the complexity of the entire process increases. If it is decided to use a sequential update, monitoring will also be more difficult, because you must simultaneously monitor two versions of the application and use monitoring data to assess the stability of the version of the application.
4. Use of third-party components. If you decide to use a multi-tenant architecture, you need to evaluate how well third-party components will work in this mode. To make sure that a third-party component can work in a multi-tenant architecture, you may need to perform some additional steps.
5. Providing test access and new customers. Providing an area for a new client or initializing a free trial use of a service is greatly simplified if this process involves only a configuration change. For a dedicated model, you need to deploy a new instance of the application for each client, including those using a free trial. Although you can automate this process, it will be much more complicated than changing or creating configuration data in a multi-tenant application.
Windows Azure allows you to make the provisioning process automatic (provisioning of services, certificates, storage, etc.), for this you need to use the REST Service Management API. The software implementation of all necessary actions is very relevant, because allows users to enter the portal, click the “try” button and after a few minutes receive a temporary subscription (trial) created specifically for them. This is also true when placing the application in the Marketplace’s, when users can first try the application, and then purchase it and continue using it — and no calls or letters to the support service.