Zanim przejdziemy do rozważań, warto doprecyzować pojęcia oraz warianty, które będziemy porównywać. W potocznym rozumieniu terminy multi-tenant oraz SaaS często są ze sobą utożsamianie. Wynika to z faktu, że dla zastosowania modelu biznesowego SaaS często buduje się aplikację w architekturze multitenancy. W takiej sytuacji tenant w rozumieniu architektonicznym odpowiada biznesowo osobie klienta końcowego. W naszym artykule skoncentrujemy się na potencjalnych konsekwencjach wyboru jednego z następujących wariantów podejścia architektonicznego:

1. Wdrożenie na każdym rynku kolejnej instancji aplikacji. W takim układzie każda instancja wymaga indywidualnej infrastruktury i pracuje niezależnie dla danej lokalizacji. Takie podejście nazywać będziemy on-premises. (W publikacjach spotyka się też termin multi-premise lub single tenant)
2. Rozwiązanie oparte o jedną aplikację multi-tenant. Jedna instancja aplikacji może obsługiwać wiele jednostek biznesowych. W tym rozumieniu tenantem jest jednostka biznesowa działająca np. w obrębie lokalnego rynku, marki itp.

Powyższe schematy porównywać będziemy w kontekście problemu skalowania na kolejne rynki, lokalizacje, marki itp. W podejściu on-premises (wariant A), ścieżka rozwoju często wygląda następująco: Przedsiębiorstwo tworzy system IT, który sprawdza się w ramach jego lokalnego biznesu. W ramach ekspansji na nowe rynki, wdrażane są kolejne dedykowane instancje tego oprogramowania. W pewnym momencie w użyciu mogą być nawet dziesiątki działających równolegle instalacji. Instancje te trzeba utrzymywać, rozwijać, wdrażać aktualizacje, poprawiać błędy. Każda z uruchomionych kopii wymaga odrębnej infrastruktury, którą trzeba zapewnić jeszcze przed uruchomieniem oraz później utrzymywać. Dodatkowym wyzwaniem mogą być różnice w implementacji dla poszczególnych rynków, np. integracje z lokalnymi systemami płatności, kwestie fiskalne itp. W takim momencie może pojawić się pokusa, aby rozdzielić kody źródłowe aplikacji, tworząc osobne byty dla każdego kraju czy marki i w ten sposób realizować indywidualne wymagania. Taki kierunek w większości wypadków okaże się błędny. Rozdzielenie kodów źródłowych aplikacji wiąże się z utratą możliwości jej wspólnego rozwoju i de facto zmultiplikowania nakładów związanych z rozwojem oraz utrzymaniem. Zatem, o ile specyfika nowej lokalizacji nie różni się zasadniczo od pierwotnej, warto powalczyć o utrzymanie wspólnego kodu.

Zachowanie spójności kodu w trakcie ekspansji będzie kluczowe dla utrzymania możliwości transformacji rozwiązania do modelu multi-tenant (wariant B). Na czym polega architektura multi-tenant? W dużym skrócie chodzi o to, aby jedna instancja aplikacji mogła obsługiwać wiele jednostek biznesowych tak zwanych tenantów (ang. najemca) i aby uruchomienie kolejnej jednostki związane było z konfiguracją oprogramowania (np. dodanie nowych rekordów opisujących nowego klienta), bez konieczności uruchamiania i  konfiguracji      nowej, dedykowanej infrastruktury. W takim układzie pewna część złożoności systemu, w szczególności związana z lokalnymi wymaganiami aplikacji, przesunięta zostaje na poziom konfiguracji. 

Model multi-tenant pozwala na osiągnięcie wielu korzyści, oto najważniejsze z nich:

• centralizacja rozwiązania, łatwiejsze zarządzanie, niż w przypadku wielu rozproszonych środowisk
• oszczędność infrastruktury
  • Wdrożenie nowego tenanta nie wiąże się z koniecznością budowy dedykowanej infrastruktury, 
  • Przyrost konsumpcji zasobów jest związany jest z faktycznym użyciem, a nie bezpośrednio  ilością wdrożonych jednostek biznesowych (tenantów) 
• praca wszystkich tenantów na tej samej wersji systemu (mogą być od tego zamierzone odstępstwa np. canary deployments)
• zdecydowanie krótszy czas potrzebny na uruchomienie nowej jednostki. W niektórych wypadkach istnieje możliwość automatyzacji onboardingu nowego tenanta: samodzielnego utworzenia konta i natychmiastowego rozpoczęcia działania
• utrzymanie jednego kodu aplikacji wpływa efektywnie na możliwości jej rozwoju poprzez koncentrację wszystkich aspektów cyklu jej życia: planowania, analizy, dewelopmentu, testów oraz wsparcia i infrastruktury

Charakterystyka rozwiązania multi-tenant rodzi również pewne wyzwania, zarówno na poziomie właściciela biznesowego, jak i dostawcy. Należy pamiętać, że złożoność systemu nie znika, a jedynie migruje na poziom konfiguracji, czy mikro-usług. Rozwiązanie traktowane jako całość może charakteryzować się wyższym stopniem skomplikowania, niż instancja single-tenant w podejściu on-premises oraz wiązać się z następującymi wyzwaniami:

• Większy zasięg ewentualnych błędów. Incydenty częściej dotyczyć będą wszystkich tenantów na raz.  Efekt ten można złagodzić stosując strategię wdrożenia “canary”.
• Zwiększone obciążenie zespołu utrzymaniowego i konieczność udźwignięcia presji z wielu rynków w jednym momencie. 
• Zespół zapewnienia jakości powinien przeprowadzać testy aplikacji niezależnie dla każdej konfiguracji. 
• Planowanie oraz koordynowanie rozwoju systemu musi uwzględniać wszystkie jednostki biznesowe, co stanowić może wyzwanie dla analityków. Sprostanie temu przyniesie jednak wiele korzyści, szczególnie, jeśli zestawimy to z alternatywą rozdzielenia kodów źródłowych i niezależnego rozwoju wielu aplikacji.
• Dobrze jest zatem, by aplikacja, która będzie działać w modelu multi tenant miała już okres stabilizacji za sobą.

Podsumowując, model multi-tenant może okazać się dobrym wyborem dla firm planujących ekspansję na nowe rynki, marki itp. Rozwiązanie to sprawdzi się szczególnie w przypadku dojrzałych aplikacji wspieranych przez doświadczone zespoły. Poniesione nakłady przełożą się na koncentrację wszystkich aspektów związanych z rozwojem i utrzymaniem, co ostatecznie stanowić może istotną przewagę konkurencyjną.