In general, these are e-commerce class systems, which, in the case of all markets and industries, are very similar to each other in terms of logic, differing only in overall system configurations and product-related aspects. The process we conducted involved transitioning the architecture, where each application instance had its separate hosting and dedicated database for a single-instance model operating in the Azure cloud, where we deal with one application serving multiple tenants while maintaining separate databases. Additionally, we carried out the following tasks to enable operation in various contexts: implementing a different type of event logging in the application, collaboration with Azure services, expanding the ingress layer, and migration processes without which functioning within the Azure cloud would not be possible.

Application structure and hosting

At the outset, we asked ourselves the question: Since we have the same set of applications, which is only differently configured in separate hosting spaces, is this multiplication not an additional complication for us? The diagram below illustrates the initial state of the application and hosting.

It is worth noting that the operation of the aforementioned ecommerce application in the gastronomic sector is specific in terms of resource utilization. Below is a case from our 'backyard,' and yet the situation is similar to other entities that deliver products only during the established working hours of their sales points (e.g., restaurants, stores).

As evident, the shape of the order volume closely resembles a sinusoid but intensifies during the so-called lunch peak. This means that our applications hosted in the server space precisely require the highest hardware resources only at this moment (17:00-18:00). However, outside the working hours of sales facilities, practically nothing happens in the application. This raises another question: Is there a need to pay for conventional hosting for parameters that we utilize only for a brief moment throughout the entire day?

Cloud solutions, multi-tenant application.

Cloud solutions come to the rescue, enabling the implementation of such tariff plans and smooth horizontal scaling of applications. However, it is essential to have an application that can handle multiple contexts and connect to a dedicated database for each tenant based on these contexts. A broader concept of a multi-tenant application is described here. For the purposes of this article, it is sufficient to know that based on a parameter specifying a specific tenant, the application can handle requests in that particular context, connect to the appropriate database, and log all behaviors per tenant/context, which is useful during application maintenance processes. The diagram illustrating the final shape of the application is as follows:

The above indicates that converting the application to a multi-tenant version and deploying it in the cloud space has had a very positive impact on reducing hosting costs, but that's not the end of the benefits. Having the application in one place undoubtedly simplifies all procedures in the application release process, which in its current form does not require delivering new versions of the application to multiple environments. This, in turn, reduces testing environments and simplifies release processes. The impact of implementing new functionalities, going through integration tests, regression tests, and comprehensive automated testing of critical system paths, does not need to be duplicated in many different environments. A slight expansion of tests in the aspect of multiple contexts is sufficient. The cost of such expansion does not have to be high, provided that all work is well thought out and carefully planned. Application Maintenance Process (SLA): Let's imagine an Urgent-type event observed by our client and reported in a selected environment/market. Let's assume it's an issue that, according to the reporter, negatively affects sales (revenue reduction). After support reviews the report, they go to the specified environment and try to reproduce the described case to verify its behavior. If the reported behavior is confirmed by a support employee, in the case of a multi-application solution, the same scenario should be verified on all hosts where the application has been deployed. In the case of a multi-tenant environment, with the same logic of handling, we are confident that the scenario will occur for other tenants, and moreover, after solving the problem, it is enough to repeat the test only once.

The Application Maintenance Process (SLA)

Let's consider an Urgent-type incident that has been observed by our client and reported in a selected environment/market. Assume it is a report that, according to the reporting person, negatively affects sales (revenue decrease). After reviewing the report, the support team proceeds to the specified environment and attempts to reproduce the described scenario to verify its behavior. If the reported behavior is confirmed by a support team member, in the case of a multi-application solution, it would be necessary to verify the same scenario on all hosting platforms where the application has been deployed. In the case of a multi-tenant environment, using the same handling logic, we can be sure that the scenario will occur for other tenants as well. Furthermore, after resolving the issue, it is sufficient to repeat the test only once.

Adding an Additional Tenant

Another significant advantage of the multitenant approach to building applications is adding another client/tenant to our system. Let's imagine a situation where we receive such a request from a client and need to undertake the endeavor of 'exposing' the environment in a traditional hosting setup. The following tasks are at hand:

1. Purchase hosting space.
2. Prepare the application for a dedicated environment along with version control in the repository.
3. Deploy the application.
4. Conduct all necessary tests.
5. Carry out the procedure for handing over the new environment to the maintenance department.

In contrast, with the multitenant approach, we need to:

1. Configure an additional tenant.
2. Add only scenarios related to the new tenant to the existing tests.
3. Conduct the procedure for handing over the new environment to the maintenance department.

The simplicity and speed of adding additional tenants are apparent at first glance, but one should not forget about the financial aspect, which is also much more favorable in the multitenant option. In our implementation, the client can add new sales markets without worrying about costs. Each new market brings revenue, and the client avoids risks and fees for additional hosting in the traditional sense, only incurring costs associated with the generated traffic, which also means generating profits. An additional advantage is the short implementation time of such a project and lower costs when adding tenants for trial purposes to explore the market.

Application Performance

With established hardware resources (CPU, RAM) and an application running on multiple tenants, it is obvious that operations will never be executed exactly at the same time. These processes will cross-utilize resources and compensate for each other. There may be situations where any number of tenants will use more resources at the same time, but it will never be a situation comparable to multiple separate virtual machines. Horizontal scaling of applications provides our API with the ability to work on a greater number of instances only in specific situations, and the client will only pay for that time.

Summary

Based on our experience working with the application, we can affirm that the decision to modify the application and migrate to the cloud was justified. The changes we had to make were minimal compared to the scale of benefits.

Summarizing the advantages in the form of a short list, the following achievements can be highlighted:

• We reduced hosting costs.
• We influenced greater simplicity in maintaining the application (SLA).
• We streamlined the application release process (reducing the risk of overlooking the application in a classic approach).
• Through horizontal scaling of the application, we increased its performance.
• We significantly simplified the process of adding additional tenants.
• We achieved improved error monitoring and application behavior.
• Standardization of logic for multiple tenants.