One of the significant challenges accompanying the expansion of a company into new markets is the question of scaling IT solutions. Should we duplicate the existing solution for the new location, or scale the existing application to accommodate it? How to deal with the individual needs of new branches? How will such decisions affect the further development, maintenance, quality, and security of the solution?

Before we move on to the considerations, it is worth clarifying the terms and variants that we will be comparing. In common understanding, the terms multi-tenant and SaaS are often equated. This results from the fact that for the application of the SaaS business model, an application is often built in the architecture of multi-tenancy. In such a situation, the tenant in the architectural sense corresponds to the business person of the end customer. In our article we will focus on the potential consequences of choosing one of the following variants of the architectural approach:

1. Deploy another instance of the application in each market. In such an arrangement, each instance requires an individual infrastructure and works independently for a given location. We call this approach on-premises. (In publications, the term multi-premise or single-tenant is also used).
2. A solution based on a single multi-tenant application. One application instance can support multiple business units. In this sense, a tenant is a business unit operating e.g. within a local market, brand, etc.

The first infographic shows the applications in the single-tenant (multi-premise) system. The second shows a multi-tenant solution.

We will compare the above schemes in the context of the problem of scaling to additional markets, locations, brands, etc. In the on-premises approach (variant A), the development path often looks as follows: An enterprise develops an IT system that works well within its local business. As it expands into new markets, further dedicated instances of this software are deployed. At some point, there may even be dozens of installations running in parallel. These instances need to be maintained, developed, upgraded and errors corrected. Each of the launched copies requires a separate infrastructure, which needs to be provided even before the start-up and then maintained. An additional challenge may be the differences in implementation for individual markets, e.g. integrations with local payment systems, fiscal issues, etc. At such a point, the temptation may arise to separate the application source codes, creating separate entities for each country or brand and thus fulfilling individual requirements. Such a direction will prove to be wrong in most cases. Separating the source codes of an application means losing the possibility of its joint development and de facto multiplying the expenses related to development and maintenance. Therefore, as long as the specifics of the new location are not fundamentally different from the original one, it is worth fighting to maintain the common code.

Maintaining code consistency during the expansion will be key to maintaining the ability to transform the solution to a multi-tenant model (Option B). What is multi-tenant architecture? In a nutshell, the idea is that one instance of the application can serve many business units, the so-called tenants and that launching another unit is connected with software configuration (e.g. adding new records describing a new customer), without the need to launch and configure a new, dedicated infrastructure. In such an arrangement, some of the complexity of the system, particularly related to local application requirements, is shifted to the configuration level.

The multi-tenant model allows for many benefits, here are the most important ones:

• centralization of the solution, easier to manage than multiple distributed environments
• infrastructure savings
  • The implementation of the new tenant does not require the construction of a dedicated infrastructure, 
  • The incremental consumption of resources is related to the actual use and not directly to the number of business units (tenants) deployed 
• all tenants work on the same system version (there may be intentional deviations from this, e.g. canary deployments)
• a significantly shorter start-up time for the new unit. In some cases it is possible to automate the onboarding of a new tenant: create an account yourself and start operating immediately
• Maintaining a single application code effectively influences its development capabilities by concentrating all aspects of its life cycle: planning, analysis, development, testing, and support and infrastructure

The nature of a multi-tenant solution also raises some challenges, both at the business owner and vendor level. It is important to remember that the complexity of the system does not disappear, but only migrates to the level of configuration or microservices. The solution taken as a whole may be characterized by a higher level of complexity than a single-tenant instance in the on-premises approach and may also present the following challenges:

• Larger range of possible errors. Incidents are more likely to affect all tenants at once. This effect can be mitigated by using a "canary" deployment strategy.
• Increased workload on the maintenance team and the need to handle pressure from multiple markets at one time. 
• The quality assurance team should test the application independently for each configuration.
• Planning and coordinating the development of a system must take into account all business units, which can be a challenge for analysts. However, there are many benefits to be gained from tackling this, especially when weighed against the alternative of source code separation and independent development of multiple applications.
• It is therefore a good idea for an application that will operate in a multi-tenant model to already have a period of stabilization behind it.

In summary, the multi-tenant model may prove to be a good choice for companies planning an expansion into new markets, brands, etc. This solution will be particularly useful in the case of mature applications supported by experienced teams. The expenses incurred will reflect in the concentration of all aspects related to development and maintenance, which ultimately may constitute a significant competitive advantage.