Geekly Articles each Day
⬆️ ⬇️

Multi-Tenant Architecture for SaaS Applications

What is multitenancy?



In simplest terms, multi-tenancy is the ability to serve users in isolation from different organizations (ie, independent SaaS subscribers) in a single service (one installation or deployment). The main thing here is to maintain the isolation of subscribers from each other. Indeed, customers will not be happy if the data they store in your SaaS application will be available when searching for other customers. This is a clear violation of isolation.



Multi-tenancy is different, for example, it can be represented by the following scheme:







Now very often multi-tenancy appears together with the terms cloud computing, but in fact, multi-tenancy in some of its manifestations was relevant before, for example, for hosting sites. For example, SQL Server and IIS allow you to administer databases and sites independently: when you log into the IIS Management Console of a remote server, you see only your sites, similarly for SQL Server, you see and manage only your database in the Management Console. This can also be called a variation of multi-tenancy - all hosting clients live on the same web server or database server, but work only with their nodes / elements / data. Multi-tenancy is also an integral part of many ERP and CRM systems ( Multi-tenant versus Single-tenant ERP - a comparison ).

')

For your SaaS application, you already have to take care of multi-tenancy, although with this you can use existing features or ready components, for example, which provide PaaS platforms. Generally speaking, it is easier to design an application right away with a focus on multi-tenancy than to redesign the application later to support it.



What are the advantages of a multi-tenant approach?



In addition to the multi-tenant architecture, there is a dedicated architecture (single-tenant), when each user is provided with its own infrastructure (this is typical for non-SaaS applications): logical or physical servers. For cloud services, this approach may not be justified, because for each subscriber, fixed resources are allocated, regardless of how much is required (and this increases the final cost of the SaaS subscription for the user, in the end 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.



Multi-tenant architecture is a fundamental way to reduce the cost of computing resources and storage for SaaS solutions: due to the minimum required amount of resources used (shared infrastructure) and their maximum load. The most tangible benefit becomes with a combination of multi-tenancy and “unlimited scaling” (when there is no need to spend additional funds on provisioning additional resources or adding new servers). You can try to implement unlimited scaling on your own or use cloud PaaS platforms.







Source: Cloud Computing: Sharpen Your SAAS Smarts Before Committing to the Cloud



And yet, what to choose a selected model or multi-tenant?



Multi-tenancy can also be different, for example, at the data level, at the resource level, etc. And all this can be combined, used all together or not at all.



Source: Multi-Tenant Data Strategies for Windows Azure - Part 1



Therefore, there is no right or wrong answer to the question of choosing one approach or another, but there are a number of factors that may affect your choice. I’ll tell you about these factors on the example of the Widows Azure platform, although most of them are applicable to other cloud platforms.



Architecture







1. In a multi-tenant application, you can always emulate a dedicated mode (one subscriber), while there are usually no possibilities to extend a dedicated application to several independent subscriptions.



2. Fault tolerance . A multi-tenant application is more vulnerable to instance failure than a dedicated application. The failure of a dedicated deployment affects only the client that uses this application, while the failure of the multi-tenant application will affect all clients.



You can reduce the negative consequences of a failure with the help of several instances of a multi-tenant application or its part. For example, Windows Azure can reduce this risk by allowing you to deploy multiple identical copies of an application by using multiple instances of roles (this approach just fully implements the multi-instance model with multiple instances). Windows Azure automatically distributes the query processing load between these role instances, therefore, the application must be designed in such a way that it functions correctly when using multiple instances. For example, if an application uses session state, you must ensure that each instance of the web role can access the state. Windows Azure also continuously 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 a single multi-tenant deployment. For example, you may need to group clients based on the functionality of the application 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-tenant 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 subscriptions. If subscribers with different service level agreements share the same multi-tenant deployment, ensure the highest SLA.



4. Legal and regulatory environment . For some applications, specific regulatory or legal issues need to be considered. This may require differences in functionality, the display of legal agreements in the user interface, the provision of separate databases or storage areas for each specific subscriber, the location of the service and storage in a specific geographic region. Under these conditions, it may be necessary to implement separate multi-tenant deployments for different groups of users, 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 this case, application subscribers 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 having to create new credentials for the application. The second option for a multi-tenant application means that you need to support multiple authentication providers, and you may also need to map the application authorization scheme in the cloud to the local authorization infrastructure scheme. In Windows Azure, Access Control Services is used to configure authentication and authorization, with which you can implement forms authentication, via Active Directory, via LiveId, Google, Facebook and other OpenID providers. If we are talking about integration with Active Directory and setting up a federation between the AD subscriber and the service, then, most likely, this may also require a dedicated deployment.



Application Lifecycle Management







1. Maintain the code base . For development companies, maintaining separate code bases for various customers incurs an increase in support and maintenance costs, as well as problems in tracking which customers use which version. This can lead to errors that will lead to additional costs. A multi-tenant system with one logical deployment guarantees one code base for the entire application. You can still maintain a single code base with a dedicated model with multiple deployments, but you may want (with long-term implications) to fork the code for different clients. In some scenarios where there is a need for fine-tuning 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, through the interface) . If there should be several code bases, then the application should be structured in such a way that user code is limited to only the minimum required number of user components.



2. Application updates . Multi-tenant application allows you to simultaneously distribute updates to all clients. This approach means that only one logical instance is updated, which reduces maintenance efforts. 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 instances of the role without stopping the application. If the client has operational procedures or software tied to a specific version of the application, then any updates must 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 are distributed to the remaining users.



3. Monitoring the application . Monitoring a single application deployment is easier than monitoring multiple deployments. In a dedicated model with multiple deployments, for any new instance of the role, it is necessary to set the settings of the monitoring environment, which increases the complexity of the entire process. If you decide to use sequential update, monitoring will also be more difficult, since you need to simultaneously monitor two versions of the application and use the monitoring data to assess the stability of the version of the application.



4. Use of third-party components . If it is decided to use a multi-tenant architecture, it is necessary to evaluate how well third-party components will work in this mode. To ensure 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 customer or initializing a free trial of a service is greatly simplified if the process involves only a configuration change. For the selected model, you need to deploy a new instance of the application for each client, including those using a free trial version. Although you can automate this process, it will be significantly more difficult than changing or creating configuration data in a multi-tenant application.



Windows Azure allows you to make the process of provisioning automatic (provisioning services, certificates, storage, etc.), for this you need to use the REST Service Management API. Software implementation of all necessary actions is very relevant, since allows users to log in to the portal, click the “try” button and in a few minutes receive a temporary trial subscription created specifically for them. It is also relevant when placing the application in Marketplace, when users can first try the application, and then purchase it and continue using it - and no calls or letters of support.



Application setup







1. URLs to access the application . By default, Windows Azure provides each application with a DNS name of the following form <application_name> .cloudapp.net. In the case of a dedicated deployment, you can use the CNAME record to match the DNS name of the subscriber (for example, contoso.com ) with the application. In a multi-tenant application, you can use the following addressing schemes: http: //.cloudapp.net// or again using CNAME and Host Header. For example, you can map mydomain.ru with http: // <multi-application-name> .cloudapp.net, where the requested tenant is determined by the Host Header. More information about this approach is written in the article “ Identifying the Multi-Tenant Azure Applications - Part 2” . This approach allows you to hide from the user the fact that this is a multi-tenant application, because The appeal goes to a unique URL to the address selected for the tenant. A little more difficult is the situation when access should be via HTTPS, more about this in the article Identifying the Tenant in Multi-Tenant Azure Applications - Part 3 .



2. Setting up the application by the client . Allowing clients to load their own code increases the risk of an application crashing, because it reduces the level of control of the code executed by the application. Therefore, many SaaS providers place restrictions on the use of custom code in multi-tenant applications (because failure will affect all users). In most cases, this is simply forbidden, sometimes the code is allowed, but its functionality is severely curtailed. Allowing clients to download code or scripts also increases the risks associated with the security of the application.



Data Layer Architecture







1. Data protection from other tenants (subscribers) . The risk of accidental or malicious disclosure of data in a multi-tenant model is higher. It is difficult to convince a client that his personal data is safe if the client knows that the application is physically shared with other clients. However, the high-quality architecture of the application, which logically isolates the data of each client, must provide the required level of protection. Such an architecture can use the following approaches (the approaches are described in more detail in the Multi-tenant Data Architecture Hubrost):



The approaches described above apply to both Windows Azure storage and SQL Azure. However, they are associated with different pricing models. For Windows Azure storage, an invoice is issued for the amount of stored data and the number of transactions to the storage, so the costs do not depend on the number of individual accounts or storage containers. The bill for using SQL Azure depends on the number of databases available, so from a cost point of view, it is optimal to use one database for the maximum possible number of subscribers (tenants).



Windows Azure Tables and BLOB's allow you to implement various levels of data isolation at the level of: individual account, tables, partitions and containers. SQL Azure implements isolation at the expense of individual: database, database federation, or server. For example, we can create a mobile application that stores data in a BLOB storage. In this case, we can create a separate BLOB container for each user and assign the corresponding rights to this container (ie, not public access).



2. Extensibility of data architecture . There are several ways to build a data warehouse in such a way that clients are allowed to extend the data model to include their own custom attributes. There are several approaches:



When using SQL Azure, the main difficulty is the need to work within a fixed data scheme. When using Windows Azure table storage, complexity, on the contrary, is due to a non-fixed storage scheme. Windows Azure table storage allows entries in one table to have a completely different structure, which provides greater flexibility due to the greater complexity of the code.



3. Scalable data architecture . Horizontal partitioning allows you to scale the data warehouse. To achieve SQL Azure scalability, you can transfer individual customer data to a new instance of SQL Azure.



The key factor determining the scalability of Windows Azure table storage is the choice of partition key. To avoid viewing (scanning) multiple partitions, all requests must include the partition key.



Learn more about the choice of data architecture and tradeoffs associated with this in the articles Multi-Tenant Data Strategies for Windows Azure - Part 1 and Multi-Tenant Data Strategies for Windows Azure - Part 2 . In particular, it raises interesting questions about SLA, backup and recovery of relational data when using the same shared database.



Financial questions







1. Billing customers . One approach to billing is to use a payment plan for actual use. With this approach, it is necessary to track the resources spent on each client, calculate the cost of these resources and add a margin for profit.



For a dedicated application, you can create a separate Windows Azure account and determine the total amount for each client. However, for a dedicated deployment running in a separate Windows Azure account, some costs will be fixed, i.e. they can not be avoided. For example, payment for the use of 24x7 computing resources and SQL Azure base can make the initial cost of your service too high for small companies. With a multi-tenant architecture, fixed costs can be divided between customers, but the costs per user are not so easy to calculate, and you will need to add additional code to the application to determine the amount of resources consumed by each customer. Moreover, customers will want to track their costs in some way, so the calculation of costs must be made as transparent as possible, as well as implement a mechanism for customers to access this data.



The module Cloud Ninja Metering Block for Windows Azure: allows you to remove resource usage metrics for each tenant, has a built-in portal for displaying reports for clients.





It is difficult to determine in advance the load and resources that will be required for a particular subscriber, because It is difficult to predict the resource usage curve of a specific subscriber in advance. If you apply a pricing model that offers a SaaS application for a fixed monthly fee, the profitability will vary between subscribers (and may even be negative in some cases). By making the SaaS application multi-tenant, you can smooth out differences in the patterns of use of different subscribers, which makes it easier to predict expenses and revenues and reduce the risk of losses. The more customers, the easier it is to determine the patterns of service usage based on statistical data.



From the client’s point of view, charging a fixed fee for a service means that the client knows in advance exactly what the costs will be in the next payment period. It also means that the pricing system becomes much easier. Some costs, such as storage and transaction costs, will be variable and will depend on the number of existing customers and how they use the service. Other expenses, such as the cost of the calculated resources will be clearly recorded.



As a result, in order to get the total profit, you need to sell a sufficient number of subscriptions that will cover fixed and variable costs.



If your customer base includes both large and small companies, then the standard subscription fee may be too high to attract smaller customers. In this case, it will be necessary to modify the second approach and offer a number of packages for different levels of use. For example, to offer a limited package of services with lower monthly prices than a standard package.



2. Cost management application . For SaaS applications on the Windows Azure platform, current costs can be divided into fixed and variable costs. For example, if the tariff for computing resources is $ 0.02 (Extra Small instance), then the cost of running twenty-four-hour computing nodes (for redundancy and fault tolerance) per month is a fixed amount, approximately equal to $ 28.8 dollars. If this is a multi-tenant application, then all customers share these costs among themselves. To reduce the cost per customer, try to dial the maximum possible number of users to share the application without adversely affecting the performance of the application.



It is also necessary to analyze the performance characteristics of the application to determine the best approach for increasing the load on the application:



Variable costs will depend on the number of existing customers or how these customers use the application (how often they load data, fill up reports, etc.), because This largely determines the monthly storage and transaction costs.



The cost per client does not depend on a dedicated or multi-tenant application architecture. Regardless of the model, a specific client requires the same amount of storage and the use of the same number of computational cycles. To manage these costs, it is necessary to ensure the most efficient use of these resources by the application.



findings



  1. Multi-tenancy should be thought out both from a business point of view and from a technical point of view.
  2. Multi-tenancy should not be evident, i.e. Subscribers and their clients should have the impression that they are working with a customized / personalized site (for example, also a DNS name). Although it seems to me that this is just a matter of psychology and external perception.
  3. The multi-tenant SaaS application allows you to make the cost of the solution lower for customers, i.e. raise it as competitively as possible.
  4. To build a multi-tenant SaaS application, you must select a cloud provider. For this approach more PaaS platform.
  5. Automate the tenant provisioning process so that users can easily try the SaaS application (literally in one click).


Resources



Source: https://habr.com/ru/post/145027/

More articles:



All Articles