We FROGRIOT codzienne jesteśmy stawiani przed wymogami przyszłości. Budowane przez nas platformy już dziś powinny być odpowiedzią na warunki zmieniającego się świata technologii w kolejnych latach. A technologia nieustannie się zmienia i rozwija. Zmieniają się też wymogi klientów. Dlatego kluczowym przy budowie każdej nowej platformy czy aplikacji online jest odpowiedni wybór infrastruktury i architektury, które sprostają nie tylko obecnym, ale również przyszłym, jeszcze niezdefiniowanym wymaganiom. Zanim jednak o przyszłości, zróbmy krok wstecz i spójrzmy na przeszłość.
W słusznie minionych, starych czasach wystartowanie z własną stroną czy aplikacją wymagało kilku kroków:
Wbrew pozorom czwarty krok był najważniejszy: wielokrotne pady stron e-commerce, które zawieszały maszyny pod wpływem własnego sukcesu (dużej ilości ruchu) należały co prawie codzienności i były tego najlepszym przykładem. To jednak nie koniec przygód: w trakcie zarządzania serwerem (rękami admina) należało zadbać o wszelkiego rodzaju aktualizacje całego oprogramowania jakie zostało na nim zainstalowane. Do tego dochodziła kwestia backupów oraz względów bezpieczeństwa każdego komponentu jaki został zainstalowany.
Tak właśnie wygląda architektura monolityczna – wszystkie składowe systemu trzymane są w ramach jednego serwera.
Można by o tym napisać więcej, ale szkoda czasu, ponieważ stare czasy są, cóż – stare. I choć tego typu architektura będzie miała nadal zastosowanie w niektórych projektach, to ważne aby wiedzieć kiedy warto ją stosować: np. w prostych aplikacjach jak strony internetowe czy prostych e-commercach, a kiedy już nie: np. w aplikacjach działających 24/7, których użytkownicy potrzebują stałej dostępności, a właścicielowi (czyli biznesowi) zależy na stabilności i możliwości ciągłej ewolucji.
Przed nowoczesnymi platformami i aplikacjami internetowymi (oraz ich infrastrukturą) stoją nowe wyzwania, wielokrotnie pomijane przy starych rozwiązaniach monolitycznych serwerów (z racji dużych nakładów czasowych koniecznych do ich spełnienia).
Nowe wymogi można sprowadzić do 5 kategorii:
Budowa rozwiązania, które spełni wymogi nowoczesnej platformy, powinna opierać się o usługi typu cloud. W odróżnieniu od starych rozwiązań, nowoczesne platformy pozwalają na budowę całej infrastruktury w oparciu o składowe będące osobnymi usługami, które można ze sobą łączyć. I tak, baza danych może być osobną usługą, system kolejkowania czy stałych zadań także, storage do przechowywania multimediów, API służące do komunikacji, a nawet poszczególne funkcje API czy aplikacja webowa (dostępna przez przeglądarkę) również. Tak skonstruowana architektura składa się z tzw. mikroserwisów. Każdy z nich stanowi osobną usługę, nad którą może pracować osobny zespół w optymalnej dla niego technologii. Jest to rozwiązanie wygodne, bezpieczne i łatwe dla developerów do rozwijania, ale szczegółowo o zaletach w następnych akapitach.
Istnieje szereg dostawców odpowiednich usług, które pozwalają spełnić wymogi nowoczesnej architektury. Niezależnie czy wybierasz Amazon AWS, Google Cloud czy Microsoft Azure – wybierzesz dobrze. W codziennych projektach opieramy się na Amazon AWS – szeroka dokumentacja, wachlarz stare powiększających się usług i dobra obsługa są dla nas najważniejsze i tym właśnie wyróżnia się na rynku AWS. Na tych usługach oprzemy także niżej opisywany przykład.
Zacznijmy od schematu. Przykładowy schemat nowoczesnej infrastruktury technologicznej może wyglądać tak:
Omówmy nieco szerzej składowe przedstawionego schematu.
Niezależnie od tego jaka baza danych jest potrzebna, Amazon ma ją skonfigurowaną jako usługę. Liczba zapytań do takich baz jest w zasadzie nieograniczona, płatność związana jest z ich liczbą, a Amazon zapewnia praktycznie nieskończoną przepustowość. Co więcej każda baza podlega automatycznemu procesowi backupu – dlatego można zapomnieć o backupowaniu w starym stylu (snapshoty dysków itp.).
W sercu całej infrastruktury leży API. Realizuje ono wszystkie zapytania do systemu i wysyła niezbędne odpowiedzi. Taką usługę można zrealizować w różny sposób, jeżeli jednak zależy Ci na klarownej formie (i po raz kolejny: na niskich kosztach infrastruktury), to do obsługi API możesz wykorzystać wbudowaną usługę Amazona API Gateway (jak pokazane na schemacie wyżej). Dla realizacji celów funkcji można wykorzystać AWS Lambda, czyli wolnostojące kawałki kodu pozwalające realizować funkcję przy praktycznie zerowych kosztach, jako że koszty ponosi się za liczbę ich wywołań.
API może być wykorzystywane przez wszystkie aplikacje frontowe korzystające z naszej infrastruktury jak aplikacje webowe, mobilne czy zewnętrzne systemy do których musimy dostarczyć dane. API tworzone jest raz, co także znacząco oszczędza czas i środki.
Aby nie zmuszać systemu do realizowania wszystkich zadań naraz można podłączyć system kolejkowania Amazon SQS. Wygodne, proste i efektywne rozwiązanie skutecznie realizuje wszystkie napływające do API (oraz z API) zadania. W przypadku bardziej skomplikowanych kolejek i wymogów można użyć innej usługi zewnętrznej np. Kafka czy Kinesis.
Front aplikacji można oprzeć o Vue.JS. Najnowocześniejszy, lekki i szybki framework JS’owy, w którym praca jest czystą przyjemnością. Niedawno ukazała się trzecia odsłona tego najszybciej obecnie zyskującego na popularności frameworka opartego o javascript. Więcej o zaletach VUE można przeczytać we wpisie o Vue.js.
Nasza przykładowa aplikacja osadzona jest na storage’u S3 dzięki czemu jej używanie praktycznie nie generowałoby kosztów innych niż zajęte miejsce (a tego jest zazwyczaj bardzo niewiele).
W wielu platformach wykonywane są zadania cykliczne, które pozwalają np. na wysyłanie maili o określonej godzinie, zadania związane z automatyzacją marketingu, albo płatnościami. Wszystkie tego typu zadania realizować można przy pomocy potężnego narzędzia Amazon Event Bridge.
Kod standardowo trzymany jest w repozytorium kodu, a za jego wdrożenie na serwer produkcyjny odpowiada uprzednio skonfigurowane narzędzie pozwalające na dokonanie wdrożenia typu Continuous Development. Takie podejście pozwala bezkonfliktowo dostarczać nowe wersje kodu (funkcjonalności, update’y) bez wstrzymywania pracy aplikacji co jest kluczowe zwłaszcza w platformach działających globalnie 24/7 w różnych strefach czasowych.
Każda platforma powinna mieć przynajmniej jedną wersję testową na której umieszcza się i testuje nowe rozwiązania oraz funkcje. Przetestowana w ten sposób funkcjonalność trafia na wersję produkcyjną. I tutaj rozwiązania chmurowe wykazują przewagę ponieważ pozwalają na kopiowanie kluczowych komponentów, niezbędnych do stworzenia wersji testowej na potrzeby wykonania testów. Nie ma potrzeby kopiowania i tworzenia osobnej instancji całego serwera oraz aplikacji na nich, wystarczy zduplikować niezbędne elementy. Jest to szybsze i wygodniejsze.
Dzięki podziałowi platformy na poszczególne moduły istnieje możliwość skalowania tylko najbardziej obciążonych elementów bez potrzeby skalowania całej infrastruktury. To z kolei ma bezpośrednie przełożenie na stabilność działania całości. Rozwiązania tego typu są idealnie skrojone pod możliwość obsługi chwilowo zwiększonej ilości zapytań (np. w przypadku znacznie zwiększonego ruchu użytkowników). Wpisuje się to w tzw. wzorzec osi Y skalowalności, idealny w przypadku architektur mikroserwisowych.
Samo przygotowanie nowoczesnej infrastruktury do skalowalności także jest zdecydowanie prostsze i szybsze. W przypadku monolitycznej infrastruktury podobne przygotowanie się jest możliwe, jednak jest to proces dalece bardziej skomplikowany, a co za tym idzie kosztowny.
Dzięki rozwiązaniom chmurowym można uzyskać znaczne niższe koszty utrzymania względem architektury starego typu; zwłaszcza w platformach z dużą ilością wykonywanych operacji (czy to przez użytkowników, czy z powodu innych realizowanych zadań). Przerzucenie części kodu do szybkich funkcji opartych o bardzo korzystny model rozliczeń (np. AWS Lambda), wykorzystywanie tylko niezbędnych w danym momencie modułów platformy, nie używanie całej aplikacji gdy nie jest to niezbędne – to wszystko wpływa optymalizację kosztów w przypadku usług w chmurze.
Sprawa jest tu dość prosta – dzięki zastosowaniu nowoczesnego frameworka front-endowego oraz podziałowi platformy na moduły obciążamy tylko jej niezbędne elementy, a w rezultacie uzyskujemy znacznie lepszą wydajność.
We wszystkich nowoczesnych platformach kluczowe stają się kwestie bezpieczeństwa (przepływ i przechowywanie danych). Dzięki podziałowi platformy na składowe z jednej strony łatwiej jest zarządzać dostępem dla poszczególnych deweloperów, ponieważ każdy ma dostęp tylko do elementów które go dotyczą. Z drugiej strony, każdy komponent ma zapewnioną ochronę poprzez usługodawcę, który dba o bezpieczeństwo. Ceną za lepsze podejście do kwestii bezpieczeństwa jest większa czasochłonność całego procesu, niż w przypadku architektury monolitycznej.
W przypadku wykorzystywania gotowych usług chmurowych ich uaktualnienia dokonywane są automatycznie poprzez ich dostawcę. Oznacza to, że aktualizacje wykonywane są bardzo szybko i w ramach kosztów utrzymania. Jest to kolosalna różnica w stosunku do utrzymywania własnego serwera w przypadku którego tego typu aktualizacje software’u trzeba wykonać ręcznie a to oznacza ich planowanie i kolejne koszty. Jest to szczególnie odczuwalne przy długofalowych projektach złożonych technologicznie platform.
Technologia ciągle ewoluuje, a nowe usługi wypierają stare. To z kolei wymaga elastycznego podejścia do możliwości zmiany poszczególnych rozwiązań. Tylko w 2019 Amazon wprowadził kilkadziesiąt nowych usług (łącznie było ich 175 na koniec 2019 roku), to olbrzymi potencjał, ale również spory problem. Podział platformy na komponenty składowe sprawia, że zdecydowanie łatwiej testuje się nowe rozwiązania i finalnie wymienia poszczególne składowe na lepsze. Przy dobrze skonstruowanej platformie zmiana bazy danych, API czy nawet całej aplikacji front-endowej nie stanowi tak dużego problemu jak w przypadku architektur monolitycznych (i tu znowu – w rezultacie koszta są niższe).
Charakterystyczna dla długofalowych projektów jest pewna rotacja w ramach teamu, który nad nim pracuje. I tu ponownie, podział platformy na komponenty znacznie przyspiesza wdrożenie nowych osób do teamu. Dodatkowo, jeżeli projektem opiekuje się team zewnętrzny, to w przypadku wyboru innego wykonawcy z jednej strony łatwiejsza i tańsza jest zmiana opiekuna, a z drugiej strony o wiele łatwiej jest znaleźć chętnych do pracy nad platformą opartą o nowoczesną architekturę.
Produkt oparty o nowoczesne technologie uzyskuje znacznie większą wycenę i budzi większe zaufanie inwestorów. To z kolei przekłada się na większe wsparcie w przypadku finansowania uzyskiwane w poszczególnych rundach oraz wyższą wycenę całkowitą całego biznesu. Wydaje się to oczywiste, a jednak jest często pomijane, zwłaszcza w przypadku budowy MVP.
Jeżeli postawimy na nowoczesne technologie już na etapie MVP, kupujemy sobie również spokój i stabilizację. Możemy być pewni, że dokonany wybór stanowi podstawę kolejnych kilku lat rozwoju; nawet gdy zmienia się technologia czy na rynek dostarczana jest nowa, lepsza usługa, nie zostajemy postawieni w sytuacji w której musimy dokonać zmiany całej platformy.
Dzięki wykorzystaniu rozwiązań dostarczanych przez chmurę mamy do wyboru szeroką paletę gotowych narzędzi, która pozwala na szybsze dostarczanie funkcjonalności na serwer. Narzędzia te są od razu gotowe do działania w ramach chmury, bez potrzeby ich konfiguracji, która zabiera czas i środki. Pomijamy dzięki temu cały proces poznawania technicznych aspektów oprogramowania pozwalając skupić się deweloperom na wdrożeniu jego funkcjonalności, co przyspiesza i upraszcza pracę. A paleta gotowych usług jest naprawdę imponująca i rośnie z każdym rokiem – może dotyczyć obsługi kolejek czy zarządzania odpalaniem eventów, ale również bardziej zaawansowanych usług opartych o Machine Learning czy Internet of Things.
Na podstawie powyżej przedstawionych informacji można porównać ze sobą architekturę mikroserwisową z monolityczną. Nie ma czegoś takiego jak jedno słuszne podejście, ale jeżeli mamy możliwość wyboru i stajemy przed budową poważnej aplikacji, to ten staje się dość oczywisty, zwłaszcza w kontekście łatwości postawienia i utrzymania projektu.
Wybór technologii dla nowej platformy to olbrzymia odpowiedzialność. Jego konsekwencje latami będą wpływać na biznes. Warto decyzję podejmowaną dzisiaj przemyśleć w kontekście kilku najbliższych lat.
Jeżeli rozważane są takie czynniki jak ciągły rozwój produktu, potencjalne zmiany technologii wynikające z jej rozwoju czy rosnące zaawansowanie aplikacji oraz ruchu, to przedstawiona przeze mnie propozycja nowoczesnej architektury mikoserwisowej opartej o rozwiązania chmurowe wydaje się optymalnym rozwiązaniem. Budując swój biznes warto oprzeć go o elastyczne rozwiązania, ułatwiające jego ewolucję i jednocześnie podnoszące jego wartość.
