Z artykułu dowiesz się:

Architektura monolityczna – samodzielna i niezależna jednostka

Ten model programowania był używany przez wiele lat, zanim oczywiście pojawiły się mikroserwisy i nieco namieszały, ale o tym później. W architekturze monolitycznej chodzi o stworzenie oprogramowania, które będzie stanowiło jednolitą jednostkę, niezależną od innych aplikacji. Architektura monolityczna posiada jedną bazę kodu. Jeśli chcemy w takiej aplikacji wprowadzić jakiekolwiek zmiany czy aktualizacje, to konieczny jest dostęp do bazy kodu. Wdrożenie zaktualizowanej wersji odbywa się po stronie usługi, a zmiany są bardzo czasochłonne, a często nawet niemożliwe. To dobra opcja na start, ponieważ w takim projekcie bardzo łatwo zarządza się kodem. Wszystkie elementy architektury monolitycznej udostępniane są w jednym czasie, co przekłada się na łatwość wdrożenia aplikacji.

Architektura monolityczna charakteryzuje się łatwym programowaniem, co jest efektem obecności pojedynczej bazy kodu. Co więcej, interfejs API może spełniać wszystkie te funkcje, które w mikroserwisach realizuje kilka interfejsów API, co przekłada się na bardzo dobrą wydajność aplikacji. Na pewno też testowanie takiej aplikacji jest szybsze i prostsze, niż jest to w przypadku aplikacji rozproszonych.

Aplikacje monolityczne mogą spełnić swoją funkcję, ale najczęściej jest tak do momentu, kiedy zaczynają się rozrastać. Stają się większe i ich skalowanie staje się dużym problemem. Niemożliwe jest wprowadzenie jakiejkolwiek zmiany w pojedynczej funkcji bez kompilowania całej platformy, a to już duże przedsięwzięcie. Wystąpienie nawet najmniejszego błędu w jednym module może skutkować niesprawnościami w całej aplikacji. Dużą wadą takiego podejścia do budowy aplikacji są niewielkie możliwości jej rozbudowy. Aplikacja jest ograniczona pod względem zastosowanych już technologii i nie nadąża nad postępem technologicznym, co sprawia, że pozostaje w tyle za tymi aplikacjami, które się rozwijają i zmieniają.

Pomimo, że monolit to nie jest doskonałe rozwiązanie, to nie można rozpatrywać go jedynie w kontekście wad. Przez wiele lat istniała tylko taka architektura i dobrze się sprawdzała. Wdrożenie aplikacji było łatwe, a jej testowanie szybsze. Technologia jednak postępuje i wraz z pojawieniem się mikroserwisów okazało się, że architektura monolityczna może już wkrótce całkowicie odejść do lamusa.

Mikroserwisy – sprawne współdziałanie niezależnych od siebie komponentów

Mikroserwisy to już zupełnie inne podejście do tworzenia aplikacji. To metoda architektoniczna oparta na wdrażaniu niezależnych od siebie usług. Mają być one jednak spójne i ze sobą współpracować, tworząc jedną całość. Każdy taki komponent ma swoją funkcję i przeznaczenie. Jeśli chodzi o testy, aktualizacje i modyfikacje, to każdy z elementów podlega tym działaniom osobno. Co więcej, w mikroserwisach możliwe jest rozdzielenie głównych aspektów biznesowych na osobne niezależne od siebie bazy kodu. W mikroserwisach zadania zostają podzielone na mniejsze, niezależne od siebie procesy.

Największą i najważniejszą zaletą mikroserwisów jest możliwość modyfikacji i skalowania aplikacji bez konieczności przerabiania jej w całości od podstaw. Jedyne, co trzeba zrobić, to wybrać element wymagający poprawy i rozpocząć nad nim pracę bez ingerencji w pozostałe. Nie ma tym samym ryzyka, że podczas kodowania posypie się cały system, jak jest to w przypadku architektury monolitycznej. Zdecydowanie łatwiej jest kodować i testować pojedyncze elementy, niż „dłubać” w złożonym systemie, którego nie można podzielić na mniejsze jednostki.

Czy to rozwiązanie idealne? Takie nie istnieje i mikroserwisy też nie są odpowiedzią na wszystkie problemy w tworzeniu i zarządzaniu aplikacjami. Architektura monolityczna jest zdecydowanie prostsza, z kolei mikroserwisy to już złożony system i bez odpowiedniego zarządzania nim nietrudno o utratę kontroli nad jego rozwojem. Istnieje również ryzyko, że brak standaryzacji może doprowadzić do namnażania się języków programowania i funkcji monitorowania. Mogą pojawić się problemy z debugowaniem, ponieważ każdy mikroserwis ma swój własny zestaw dzienników. Pozostaje jeszcze kwestia kosztów – każdy element takiej architektury to osobny koszt. Im jest ich więcej, tym większa jest cena za całość. Poza tym pojawia się więcej kosztów bieżących – każdy element to osobne testy i aktualizacje, które kosztują.

Netflix prekursorem zmiany architektury monolitycznej na mikroserwisy

O tym, że architektura monolityczna na pewnym etapie rozwoju systemu po prostu już się nie sprawdza, przekonał się sam Netflix. Było to w roku 2009, kiedy to jego infrastruktura przestała sobie radzić z narastającym zapotrzebowaniem na szybko rozwijające się usługi strumieniowego przesyłania wideo. Trzeba było więc znaleźć lepsze rozwiązanie. Do tego czasu cała infrastruktura informatyczna Netflixa znajdowała się w prywatnych centrach danych firmy. Nastąpił jednak przełom i Netflix przeszedł z architektury monolitycznej na mikroserwisy, przenosząc całe swoje zaplecze informatyczne do chmury publicznej. Taka architektura w tamtych czasach nie była jeszcze rozpowszechniona i dobrze znana.

Netflix to jedna z pierwszych firm, która zdecydowała się na taką zmianę. Bardzo szybko okazała się ona korzystna i tym samym zainspirowała inne przedsiębiorstwa do wdrożenia mikroserwisów. Aktualnie architektura Netflixa składa się z tysiąca serwisów, z których każdy odpowiada za zarządzanie konkretnymi elementami platformy.

Można więc uznać, że Netflix jest jednym z prekursorów zmiany architektury monolitycznej na mikroserwisy. Zrobił to, zanim jeszcze zostało wprowadzone pojęcie „mikroserwisów”.

Przejście na mikroserwisy jest nieuniknione?

Skoro mikroserwisy zbudowały sobie tak dużą przewagę nad monolitami, to chyba można o tych drugich po prostu zapomnieć i skoncentrować się na tym, co sprawdza się i funkcjonuje lepiej. Nie do końca tak jest. Monolity są i będą funkcjonować jako jedno z dwóch podejść do projektowania aplikacji. Mają przecież wiele zalet i na pewno to dobry wybór na start, kiedy ruszamy z aplikacją i zależy nam na jej szybkim wdrożeniu i uruchomieniu. Wciąż jest i będzie to architektura dedykowana dla małych serwisów, a także dla firm z ograniczonym budżetem. Wybierając jednak monolit, trzeba mieć świadomość, że może nadejść taki moment, że taka architektura przestanie się już sprawdzać. Jeśli aplikacja się rozwija i rozrasta, to jest to nieuniknione, a taki jest cel przeważającej większości firm – mamy być coraz lepsi, a nie stać w miejscu. W takiej sytuacji nie należy uciekać przed mikroserwisami i próbować różnymi sposobami utrzymać się przy monolitach.

Dzisiaj przejście na mikroserwisy nie jest czynnością przesadnie skomplikowaną, bliską poziomem trudności fizyce kwantowej. Systemu nie trzeba tworzyć od podstaw. Poza tym na początku można zdecydować się na model hybrydowy, który łączy monolit z mikroserwisami, to już duży krok w kierunku zmian, które jednak nie są gwałtowne, a płynne i spokojne. Zawsze jednak trzeba wcześniej dokładnie przeanalizować indywidualne potrzeby i możliwości, aby nie wdrażać mikroserwisów na wszelki wypadek, ponieważ one również mają swoje wady, które mogą w niektórych przypadkach mocno doskwierać.

Dobre praktyki migracji z architektury monolitycznej na mikroserwisy

No dobrze, ale jak przejść z architektury monolitycznej na mikroserwisy szybko i bezboleśnie? Na pewno trzeba mieć świadomość, że to nie jest szybki bieg, a maraton, czyli proces, który trwa i nie dzieje się tu i teraz. Do migracji potrzebne jest specjalne narzędzie, które pozwala na kontrolę poszczególnych mikroserwisów i automatycznie wykrywa kontrole kodu przed wdrożeniem produkcyjnym. Takie narzędzie posiada często interfejs, na którym widoczny jest proces migracji w czasie rzeczywistym.

Przed przystąpieniem do migracji, konieczne jest też przeanalizowanie wysokości zwrotu z inwestycji. To ważne szczególnie przy dużych migracjach. Takie działania kosztują i osoby decyzyjne w firmie muszą wiedzieć, jaki budżet będzie im potrzebny oraz w jakim czasie wydatki się zwrócą, najlepiej z nadwyżką. Migracja nie może być więc spontaniczną decyzją, a poprzedzoną licznymi badaniami i analizami.

Po migracji na mikroserwisy, aplikacja będzie podzielona na mniejsze moduły. Wymaga to zmiany w koordynacji aktualizacjami i testami każdego z elementów. To z kolei wymusza pracę nad komunikacją w zespole, aby każdy wiedział, za co odpowiada, jak również, komu może powierzyć konkretne zadanie. Architektura mikroserwisowa to zupełnie inny wymiar aplikacji niż monolit. Wymaga to wdrożenia nowego zarządzania aplikacją, przygotowania zespołu na zmiany, a często też przeszkolenia go pod kątem nowej architektury. Takie podejście jest jednak zdecydowanie korzystniejsze, niż próba przetrwania na architekturze monolitycznej. W ten sposób tylko hamujemy rozwój aplikacji, która poprzez swoje rozrastanie się udowadnia, że ma potencjał być większą, lepszą i jeszcze bardziej sprzyjającą użytkownikowi.

Mikroserwisy osłabiły architekturę monolityczną, ale całkowicie jej nie wyparły. Każde z tych podejść jest dedykowane dla innych aplikacji. Nawet jeśli serwis powstał w oparciu o monoilt, nie jest to jeszcze dla niego zamknięta droga do mikroserwisów. Duże aplikacje od razu są tworzone w oparciu o innowacyjną architekturę, z kolei małe to w wielu przypadkach jeszcze monolity. I tak jest dobrze, ważne, aby zaplecze informatyczne było zgodne z założeniami całego projektu, pomagało realizować cel i założenia, a nie je oddalało i hamowało.