Uogólniając są to systemy klasy ecommerce, które w przypadku wszystkich marketów oraz rynków są bardzo do siebie zbliżone pod względem logiki, a różnią je tylko finalne konfiguracje ogólnosystemowe oraz dotyczące produktów. Proces, który przeprowadziliśmy polegał na tranzycji architektury, w którym każda instancja aplikacji posiadała swój oddzielny hosting oraz dedykowaną bazę danych do modelu jednoinstancyjnego działającego w chmurze Azure, w którym mamy do czynienia z jedną aplikacją obsługującą wielu tenantów przy zachowaniu osobnych baz danych. Dodatko przeprowadziliśmy następujące praceumożliwienie działania w wielu kontekstach, inny rodzaj logowania zdarzeń w aplikacji, współpracę z usługami Azure, rozbudowanie warstwy ingress, procesy migracyjne bez których nie dałoby się funkcjonować w obrębie chmury Azure.

Kształt aplikacji i hosting

Na wstępie zadaliśmy sobie pytanie: Skoro posiadamy taki sam set aplikacji, który jest tylko inaczej skonfigurowany w oddzielnych przestrzeniach hostingowych to czy ta multiplikacja nie jest dla nas dodatkowym utrudnieniem? Poniższy rysunek przedstawia stan początkowy aplikacji oraz hostingu.

Warto jeszcze nadmienić, że specyfika działania w/w aplikacji ecommerce /branża gastronomiczna/ jest specyficzna w kontekście utylizacji zasobów. Poniżej przypadek z naszego „podwórka” jednak sytuacja jest zbliżona do innych podmiotów, które dostarczają produkty tylko w ustalonych godzinach urzędowania swoich punktów sprzedaży (np. restauracji, sklepów).

Jak widać, kształt wolumenu zamówień jest bliższy sinusoidzie, ale nasila się w tzw. peak’u lunchowym. Oznacza to, że nasze aplikacje umieszczone w przestrzeni hostingowej dokładnie tylko w tym momencie (17:00-18:00) potrzebują najwięcej zasobów sprzętowych. Natomiast poza godzinami pracy obiektów sprzedaży, w aplikacji nie dzieje się praktycznie nic. Nasuwa się więc kolejne pytanie: Czy jest potrzeba opłacania klasycznego hostingu dla parametrów, które wykorzystujemy tylko przez moment w skali całego dnia?

Rozwiązania chmurowe, multitenantowa aplikacja.

Z pomocą przychodzą rozwiązania chmurowe, które umożliwiają wdrożenie takich planów taryfowych oraz płynne skalowanie horyzontalne aplikacji. Musimy jednak posiadać aplikację, która potrafi obsługiwać wiele kontekstów oraz na ich podstawie łączyć się do dedykowanej, dla tenanta, bazy danych. Szersze pojęcie aplikacji multitenant zostało opisane tutaj. Na potrzeby tego artykułu wystarczy wiedza, że na podstawie parametru określającego specyficznego tenanta aplikacja jest w stanie obsługiwać żądania w tym konkretnym kontekście, łączyć się do odpowiedniej bazy danych oraz logować wszelkie zachowania per tenant/kontekst, co przydaje się podczas procesów utrzymania aplikacji. Rysunek ilustrujący ostateczny kształt aplikacji:

Z powyższego wynika, że konwersja aplikacji do wersji multitenant oraz deployment w przestrzeni chmurowej wpłynęła bardzo korzystnie na zmniejszenie kosztów hostingowych, ale to nie koniec plusów. Posiadanie aplikacji w jednym miejscu to bez wątpienia uproszczenie wszelkich procedur procesu wydawniczego aplikacji, który w obecnym kształcie nie wymaga dostarczania nowych wersji aplikacji na n-różnych środowisk. Wpływa to więc na redukcję środowisk do testowania oraz upraszcza procesy releasowe. Wpływ wdrażania nowych funkcjonalności, które przechodzą przez testy integracyjne, testy regresyjne oraz kompleksowe zautomatyzowane badanie ścieżek krytycznych systemu nie musi być powielane na wielu różnych środowiskach. Wystarczy drobna rozbudowa testów w aspekcie wielu kontekstów. Koszt takiej rozbudowy nie musi być wysoki, o ile wszystkie prace są przemyślane i starannie zaplanowane. Proces utrzymywania aplikacji (SLA) Wyobraźmy sobie zdarzenie typu Urgent, które zostało zaobserwowane przez naszego klienta i zgłoszone na wybranym środowisku/rynku. Przyjmijmy, że jest to zgłoszenie, które wg. osoby zgłaszającej wpływa niekorzystnie na sprzedaż (zmniejszenie przychodu). Support po zapoznaniu się ze zgłoszeniem udaje się na wskazane środowisko i próbuje zreprodukować opisany przypadek, aby zweryfikować zachowanie. Jeżeli zgłoszone zachowanie jest potwierdzone przez pracownika supportu, w przypadku rozwiązania wieloaplikacyjnego należałoby zweryfikować ten sam scenariusz na wszystkich hostingach gdzie dana aplikacja została wydana. W przypadku środowiska multitenantowego z taką sama logiką obsługi mamy pewność, że scenariusz będzie występował dla innych tenantów, a co więcej po usunięciu problemu, wystarczy powtórzyć test również tylko ten jeden raz.

Proces utrzymywania aplikacji (SLA)

Wyobraźmy sobie zdarzenie typu Urgent, które zostało zaobserwowane przez naszego klienta i zgłoszone na wybranym środowisku/rynku. Przyjmijmy, że jest to zgłoszenie, które wg. osoby zgłaszającej wpływa niekorzystnie na sprzedaż (zmniejszenie przychodu).

Support po zapoznaniu się ze zgłoszeniem udaje się na wskazane środowisko i próbuje zreprodukować opisany przypadek, aby zweryfikować zachowanie. Jeżeli zgłoszone zachowanie jest potwierdzone przez pracownika supportu, w przypadku rozwiązania wieloaplikacyjnego  należałoby zweryfikować ten sam scenariusz na wszystkich hostingach gdzie dana aplikacja została wydana. W przypadku środowiska multitenantowego z taką sama logiką obsługi mamy pewność, że scenariusz będzie występował dla innych tenantów, a co więcej po usunięciu problemu, wystarczy powtórzyć test również tylko ten jeden raz.

Dodawanie dodatkowego tenanta 

Kolejną ważną zaletą multitenantowego podejścia do budowania aplikacji jest  dodawanie kolejnego klienta/tenanta do naszego systemu. Wyobraźmy sobie sytuację, że otrzymaliśmy taki request od klienta i mamy doprowadzić do przedsięwzięcia „wystawienia” środowiska w klasycznym hostingu. Do wykonania mamy następujące zadania:

1. wykupienie przestrzeni hostingowej,
2. przygotowanie aplikacji pod dedykowane środowisko wraz z utrzymywaniem wersji w repozytorium,
3. deployment aplikacji,
4. wykonanie wszystkich testów
5. przeprowadzenie procedury przekazania kolejnego środowiska do działu utrzymania

W odróżnieniu do powyższego rozwiązania przy podejściu multitenant musimy wykonać:

1. konfiguracja dodatkowego tenanta
2. dodanie do obecnych testów jedynie scenariuszy związanych z nowym tenantem
3. przeprowadzenie procedury przekazania kolejnego środowiska do działu utrzymania

Prostota i szybkość dodawania kolejnych tenantów jest więc widoczna na pierwszy rzut oka, ale nie należy zapominać o aspekcie finansowym, który w opcji multitenant również jest o wiele korzystniejszy. W przypadku naszej realizacji, klient może dodawać kolejne nowe rynki sprzedaży bez obaw o koszty. Każdy nowy rynek przynosi przychód, a klient nie ponosi ryzyka oraz opłat za dodatkowy hosting w ujęciu klasycznym, a jedynie związany z generowanym ruchem, który oznacza też przecież generowanie zysków. Dodatkowym atutem jest krótki czas realizacji takiego przedsięwzięcia oraz mniejsze koszty w przypadku dodawania tenantów na próbę, by zbadać rynek. 

Wydajność aplikacji

Mając do dyspozycji ustalone zasoby sprzętowe (CPU, RAM) oraz aplikację pracującą na wielu tenantach oczywistym faktem jest, że nigdy operacje nie będą wykonywane dokładnie w tym samym momencie. Procesy te krzyżowo będą utylizować zasoby i kompensować się wzajemnie. Mogą być oczywiście sytuacje kiedy dowolna liczba tenantów wykorzysta więcej zasobów w tym samym momencie, ale to nie będzie nigdy sytuacja porównywalna do wielu oddzielnych maszyn wirtualnych. Skalowanie horyzontalne aplikacje daje możliwość naszemu API pracy  na większej ilości instancji tylko w określonej sytuacji, a klient zapłaci tylko za ten czas.

Podsumowanie

Na bazie naszego doświadczenia podczas prac z aplikacją jesteśmy w stanie stwierdzić, że decyzja o modyfikacji aplikacji i migracji do chmury była zasadna. Zmiany jakich musieliśmy dokonać były nieznaczne w zestawieniu ze skalą korzyści.

Podsumowując  korzyści w postaci krótkiej listy można wymienić następujące osiągnięcia:

• zmniejszyliśmy koszty hostingowe,
• wpłynęliśmy na większa prostotę utrzymywania aplikacji (SLA),
• uprościliśmy proces wydawniczy aplikacji (zmniejszenie ryzyka pominięcia aplikacji w klasycznym podejściu),
• za sprawą skalowania horyzontalnego aplikacji zwiększyliśmy jej wydajność,
• znacząco  uprościliśmy proces dodawaniakolejnych tenantów,
• uzyskaliśmy lepsze monitorowanie błędów oraz zachowań aplikacji,
• uspójnienie logiki dla wielu tenantów