SygnITy Expert
Transformacja Monolitów: Wprowadzenie do Mikroserwisów
Każdy złożony byt jest zbudowany według pewnych zasad. Stosujemy je, aby osiągnąć założone cele, jednak z drugiej strony ponosimy również pewne koszty. Podobnie jest z oprogramowaniem, w którym świadomie lub nieświadomie przyjmujemy określoną architekturę. Architektura to organizacja naszego kodu lub funkcjonalności, która jest zamykana w klasy, metody, biblioteki czy pliki wykonywalne, aby dostarczyć je do klienta poprzez instalację.
Niezależnie od języka programowania, w którym tworzymy aplikację, punktem wyjścia jest utworzenia projektu. W kolejnych etapach stopniowo rozbudowujemy go, dodając nowe funkcjonalności. Takie podejście nazywamy architekturą monolityczną. W ramach tego modelu twórca często nie zastanawia się, czy nowe wymagania powinny być zawarte w tym samym projekcie, czy wydzielone do osobnej aplikacji.
Wybór tej ścieżki projektowania aplikacji jest zwykle podyktowany względami praktycznymi. Komunikacja między modułami w takim systemie jest prosta, przejrzysta, a wdrażanie zmian jest bezproblemowe. Ewentualne korekty nie wymagają konsultacji z innymi działami, ponieważ wszystko jest widoczne w jednym miejscu.
Prosta ścieżka wprowadzania zmian i jasna komunikacja między modułami to niewątpliwe zalety monolitu. Doskonale zdaje on egzamin w projektach, które są na wczesnym etapie rozwoju i wymagają częstych oraz szybkich modyfikacji.
Trzeba jednak pamiętać, że aplikacja korporacyjna to nie tylko kod, który wysyłamy na serwer klienta. To znacznie więcej – cała grupa zależnych funkcjonalności, opakowanych w różne technologie i wzajemnie powiązanych. To zespoły odpowiedzialne za poszczególne obszary, wyspecjalizowane w konkretnych dziedzinach technologicznych. Pojawiają się również problemy z komunikacją, konieczność monitorowania wydajności i działań biznesowych czy obliczeniowych. To także cykle publikacji nowych wersji, wycofywanie zmian czy przerwy w dostawie spowodowane problemami technicznymi różnej natury.
Wszystkie te elementy wymagają odpowiedniej organizacji, aby złożoność dostarczanego produktu spełniała wymagania jakościowe i kosztowe. Wysoką jakość osiągamy standaryzacją pracy, a koszty obniżamy automatyzacją. Pomimo że mając aplikacje w architekturze monolitu, można to wszystko osiągnąć, coraz większa złożoność projektów IT i ich skomplikowanie wymusiło, aby w naturalny sposób koncepcja mikroserwisów rozpoczęła swoją ewolucję i rozwój.
Nie jesteśmy w stanie jednoznacznie określić kto i gdzie stworzył podejście mikroserwisowe, wiemy jednak, że podwaliny do tej koncepcji kształtowały się stopniowo w latach 2000. Mikroserwisy wyrosły z potrzeby zwiększenia elastyczności i odporności dużych systemów informatycznych na zmiany. A zmiany w kodzie aplikacji są czymś pewnym. W 2005 roku podczas konferencji Web Services Edge wprowadzono termin “mikro-web-service”, który oznaczał, że poszczególne komponenty oprogramowania są jak mikrousługi sieciowe. Tak zrodziło się coś, co dziś nazywamy mikroserwisami, czyli podejście do architektury oprogramowania, a mówiąc prosto – sposób myślenia o tym, jak zorganizować kod aplikacji mając na uwadze dostępną technologię.
Ta nowa idea polegała na podziale jednej dużej aplikacji na wiele mniejszych. Mniejsze komponenty przestają brać odpowiedzialność za mnóstwo rzeczy, ale kierują się zasadą pojedynczej odpowiedzialności. Ta pojedyncza odpowiedzialność jest fundamentalna w projektowaniu mikroserwisów.
W tym miejscu należałoby przejść do przykładu, aby poprzeć teorię. Posiadając aplikację, która obsługuje proces rozliczania inwestycji w papiery wartościowe czy rozliczania faktur, stajemy przed zadaniem implementacji systemu logowań. W podejściu klasycznym po prostu dodamy moduł do projektu, tak że nowa funkcjonalność będzie częścią całości. Jednak to wiąże się z licznymi konsekwencjami. Co w sytuacji, gdy i aplikacja rozliczeniowa jest dojrzała i nie wprowadzamy już do niej zmian, a więc nie ma konieczności wykonywania częstych publikacji, a tym samym przerw w dostawie aplikacji? Przerwy w działaniu aplikacji są wysoce niepożądane zarówno dla projektu jak i klienta. Dodanie do niej modułu logowania, który będzie rozwijany przez kolejne lata, powoduje konieczność częstych aktualizacji, a w konsekwencji częste przerwy w działaniu aplikacji rozliczeniowej. Finalnie jest to kosztem, ryzykiem i obniżeniem jakości produktu jako całości.
W tym momencie z pomocą przychodzi filozofia mikroserwisowa. Funkcja logowania jest całkowicie odmienna od rozliczeń księgowych, więc wydzielenie jej do osobnego projektu wpisuje się w tę nową architekturę. Dzięki temu nie będzie konieczności ingerowania w działanie aplikacji rozliczeniowej, co stanowi znaczną korzyść. Z jednej strony będziemy mieli dwie zupełnie odrębne aplikacje – rozliczeniową i logowania, z drugiej jednak będą one kompatybilne i zdolne do współdziałania.
To, co możemy zauważyć w tym przykładzie, to fakt, że kierując się zasadą wydzielania – bo właśnie mikroserwisy są filozofią podziału aplikacji – osiąga się możliwości, które w monolicie są trudne lub niemożliwe do realizacji.
Jakie są jeszcze korzyści wynikające filozofii mikroserwisów? Watro wspomnieć o stabilności i większym wachlarzu możliwych do wykorzystania technologii i różnorodności zespołów. Jeden zespół może być wyspecjalizowany w rozliczeniach księgowych, a drugi skupi się na rozwijaniu systemu logowania. Taki tryb pracy pozytywnie wpłynie na efekt końcowy. Jeśli aplikacja rozliczeniowa jest napisana w FORTRAN-ie, języku dedykowanym obliczeniom inżynieryjnym, to do implementacji systemu logowania lepiej wybrać inny język, na przykład C# lub Java. Opcji jest wiele, dlatego warto dobierać technologię do potrzeb, kierując się tym, do czego dana technologia nadaje się najlepiej.
Jednak technologia i cykl życia to nie jedyne ułomności monolitu. Co zrobić, jeśli aplikacja rozliczeniowa ma określone wymagania co do minimalnej ilości zasobów CPU i pamięci RAM na zainstalowanym hoście? W przypadku monolitu stanowi to problem, ponieważ funkcja logowania będzie “podkradać” te zasoby, co wpłynie na obniżenie wydajności procesu rozliczenia. Podział na dwie niezależne aplikacje rozwiązuje ten problem. Co więcej, narzędzie do logowania możemy zainstalować na innym komputerze niż aplikację główną. W ten sposób aplikacja rozliczeniowa będzie niemal oddzielnym bytem korzystającym w pełni ze swoich zasobów i możliwości, a w razie potrzeby będzie mogła współpracować z narzędziem do logowanie.
To tylko kilka z problemów, które rozwiązuje to stosunkowo nowe podejście. Jednak mówiąc o mikroserwisach, należy również wspomnieć o kosztach. Jednym z głównych wyzwań jest orkiestracja, czyli organizacja i zarządzanie wieloma pojedynczymi aplikacjami, których mogą być dziesiątki, a nawet setki. W tym zakresie stajemy przed poważnym wyzwaniem: jak i czym organizować nasze aplikacje, aby działały, automatycznie się wdrażały i by można było uzyskać informacje potrzebne do rozwiązania problemów. Zagadnienie orkiestracji to złożony i jeden z najważniejszych problemów dzisiejszych mikroserwisów. Przed podjęciem decyzji o przejściu na ten model warto rozważyć wszelkie za i przeciw, nie jest to model uniwersalny, ale w wielu przypadkach korzystny.
Zmierzając do podsumowania, mikroserwisy to podejście do architektury oprogramowania, które możemy określić jako podejście zindywidualizowane. Polega ono na podziale jednej dużej aplikacji na wiele mniejszych, niezależnych usług, z których każda specjalizuje się w jednej funkcjonalności.
W odróżnieniu od architektury monolitycznej, mikroserwisy pozwalają na większą elastyczność, lepszą skalowalność i niezależność w cyklach życia poszczególnych komponentów. Dzięki temu możliwe jest bardziej efektywne zarządzanie zasobami, dostosowanie technologii do konkretnych potrzeb oraz ograniczenie ryzyka i przerw w działaniu aplikacji. Są też oczywiście wyzwania. Jednym z głównych jest orkiestracja, czyli skuteczne zarządzanie i organizacja licznych, odrębnych usług.
Mimo to, mikroserwisy oferują znaczące korzyści, szczególnie dla rozbudowanych systemów informatycznych, które wymagają częstych zmian i elastyczności. Czy mikroserwisy to idealny model? Nie, bo nie ma modelu idealnego jednak, jeśli chcemy modyfikować i elastycznie zmieniać aplikacje nad którą pracujemy to rozwiązanie zdecydowanie ułatwi nam pracę.
Literatura:
pl.wikipedia.org/wiki/Mikroserwisy
www.rst.software/blog/architecture-based-on-microservices
pretius.com/blog/modular-software-architecture/
Literatura:
pl.wikipedia.org/wiki/Mikroserwisy
www.rst.software/blog/architecture-based-on-microservices
pretius.com/blog/modular-software-architecture/
