Mikroserwisy — czym są i czy to rozwiązanie dla każdego?
Swego czasu popularność zyskał multitasking, czyli moda na robienie wielu rzeczy na raz. Okazuje się jednak, że efektywne działanie to takie, które jest zgodne z zasadą „Rób tylko jedną rzecz, ale za to dobrze” [i]. Na tej regule od przeszło dwudziestu lat architekci systemowi rozwijają styl projektowania aplikacji biznesowych z wykorzystaniem mikroserwisów. O skuteczności takiego podejścia świadczy fakt, że ponad 60% największych amerykańskich firm z rankingu Fortune 100, m.in. Netflix, Cloudflare, Uber, LinkedIn, czy New York Times, używa mikroserwisów w swoich aplikacjach biznesowych[ii].
Czym są mikroserwisy?
Mikroserwisy to proste, wąsko wyspecjalizowane komponenty, procesy lub usługi dostarczające określoną funkcjonalność w sposób całkowicie niezależny od pozostałych składowych systemu. Dzięki temu mogą być one rozwijane, wdrażane i utrzymywane w sposób autonomiczny. Każdy mikroserwis działa w ramach jednego obszaru biznesowego i jest zbudowany na eksperckiej wiedzy jego twórców. Dobrze zaprojektowany mikroserwis, nawet jeśli ulegnie awarii, powoduje wyłącznie niedostępność jednej obsługiwanej przez niego funkcji, a nie całej aplikacji, czy pozostałych mikrousług. Niektórzy specjaliści uważają także, że cechą charakterystyczną mikroserwisów jest także ich czas tworzenia liczony najwyżej w pojedynczych tygodniach. Każdy mikroserwis potrafi pobrać dane zapisane w jednym z dostępnych, wygodnych i adekwatnych formatów, przetworzyć je i zapisać w innym formacie zrozumiałym dla kolejnych mikroserwisów. Wybór stosu technologicznego do przetwarzania zadania w mikroserwisie jest zupełnie dowolny, niezależny od pozostałych mikrousług. Mikroserwisy można budować w popularnych framworkach javy lub PHP, każdym wygodnym i dostępnym narzędziem.
Ważnym składnikiem całej koncepcji mikroserwisów jest komunikacja pomiędzy nimi, która decyduje o końcowej niezawodności i wydajności aplikacji. Deweloperzy często wykorzystują do tego interfejs API REST, ale są też rozwiązania bazujące na lekkich magistralach komunikacyjnych oferujących dużo większą wydajność takich, jak Apache Kafka[iii], czy IMDG (In-Memory Data Grid).
Takie magistrale danych można tworzyć z wykorzystaniem zarówno infrastruktury dysków twardych lub SSD albo pamięci operacyjnej RAM tak, jak w przypadku IMDG. Zyskuje się w ten sposób na krótkim czasie dostępu do danych oraz przetwarzaniu równoległym. IMDG umożliwia także tworzenie struktur danych, takich jak mapy działające na zasadzie magazynu klucz/wartość, co również wpływa na szybkość przetwarzania danych.
Dlaczego oprogramowanie oparte o mikroserwisy staje się popularne?
Badanie „Microservices in the Enterprise, 2021” przeprowadzone wśród 1200 deweloperów i menedżerów IT z dużych i średnich firm, które korzystają lub planują wykorzystywać mikroserwisy[iv] pokazuje, że ponad 80% respondentów uważa, że warto było inwestować we wdrożenie tej technologii i ułatwia ona pracę wszystkim użytkownikom. Dla 77% respondentów mikroserwisy to sprawdzony i niezawodny sposób tworzenia aplikacji. W czym zatem tkwi siła mikroserwisów, skąd bierze się ich popularność?
Wygląda na to, że kluczem do sukcesu okazuje się luźnie powiązanie poszczególnych mikroserwisów i ich technologiczna niezależność. Prowadzi to do szybszego i lepszego spełniania wymagań stawianych przez biznes. Dobrym przykładem ilustrującym istotę sprawy jest przypadek Amazona[v], w którym mikroserwisy odegrały znaczącą rolę w przekształceniu całego biznesu i przełamały dominację architektury monolitycznej w systemach informatycznych.
Otóż wcześniej każda niezbędna zmiana kodu zabierała tygodnie, zanim była widoczna dla klientów. Amazon, zgodnie z wzorcami SOA (Service-Oriented Architecture), podzielił swój wielki monolit na pojedyncze aplikacje. Każda usługa miała swój dedykowany zespół deweloperski, który znał jej kod od podszewki, a to pozwoliło programistom wyszukać wąskie gardła, poznać ich charakter i przyśpieszyć działanie usługi. Na dodatek wdrożenia poszczególnych mikroserwisów następowały niezależnie od siebie i z punktu widzenia użytkowników praktycznie nie wpływały na dostępność systemu jako całości. Przebudowa monolitycznego rozwiązania na mikroserwisy zaowocowała powstaniem wszechobecnych rozwiązań takich, jak AWS (Amazon Web Services).
Mikrousługi idealnie nadają się do wdrożeń wykorzystujących nowoczesne i bardzo popularne technologie, takie jak chmura prywatna, publiczna, hybrydowa, przechowywanie obiektów w chmurze, kontenery Docker, Kubernetes i alternatywy pamięci RAM, takie jak pamięć trwała Intel Optane.
Dlaczego warto przejść z architektury monolitycznej na mikroserwisową?
O tym, czy warto przejść na architekturę mikroserwisową tak naprawdę decydują czynniki czysto biznesowe. Gdyby nie było to opłacalne dla organizacji, mikroserwisy pozostałby jedną z ciekawostek świata IT. Przykłady takich firm, jak Coca-Cola, Netflix, Spotify i wielu innych są aż zanadto wymowne[vi]. Mikroserwisy sprawdzają się tak dobrze, bo zdecydowanie łatwiej wdraża się nowe technologie wypływające z rosnących oczekiwań klientów. Małe komponenty łatwiej i taniej się testuje, a niezależny rozwój funkcjonalności także pozwala oszczędzać czas i pieniądze. Zachętą do przejścia jest także niezawodność całego rozwiązania wynikająca z redundancji poszczególnych komponentów – w razie awarii wypada tylko uszkodzony mikroserwis – reszta nadal działa. Z punktu widzenia użytkowników wyłączenie jednej z funkcji może przejść niezauważone, a niedostępność dużej monolitycznej aplikacji może być już katastrofą, nie tylko wizerunkową. Mikroserwisy idealnie sprawdzają się w architekturze typu serverless. Programiści nie muszą się martwić administrowaniem systemami operacyjnymi, skalowaniem serwerów wraz ze wzrostem obciążenia, a płatność za faktycznie wykorzystanie zasoby dla wielu organizacji oznacza wymierne oszczędności finansowe na kosztach infrastruktury IT. Jeśli mikroserwisy za 500 USD są w stanie zastąpić aplikację wartą 10 mln USD, to chyba sprawa jest bezdyskusyjna[vii].
Zalety i wady struktury mikroserwisów
Na zalety mikroserwisów można spojrzeć z punktu widzenia dewelopera, dla którego pojedyncze usługi są zdecydowanie łatwiejsze do zrozumienia, a liczba linii kodu do przeanalizowania odpowiednio mniejsza. Ułatwia to pracę nad nowymi funkcjonalnościami i ich testowanie, ale co równie ważne – usprawnia i przyśpiesza się wdrożenie nowych osób do pracy w ramach mikroserwisu. Do tego wymagana wiedza obejmuje jeden obszar biznesowy i nie jest konieczna znajomość wszystkich operacyjnych niuansów działania firmy. Każdy zespół programistów ma szansę poczuć odpowiedzialność za swój kod i powierzoną domenę biznesową. To z kolei wpływa na jakość i szybkość pracy wszystkich członków zespołu. Niezależność poszczególnych mikroserwisów daje cenną możliwość eksperymentowania i poszerzania wiedzy o nowych technologiach w ramach rozwijania nowych funkcjonalności. Takie możliwości bardzo pozytywnie wpływają na stabilność zatrudnienia w zespołach. Unika się także sytuacji, w których niezbędna wiedza jest skupiona w rękach pojedynczych osób, a ich absencja może wywoływać bardzo poważne problemy. Dzięki odpowiedzialności za poszczególne komponenty podzielonej na oddzielne zespoły, można łatwiej planować procedury awaryjne i znacząco skrócić czas przywracania sprawności aplikacji. Niedziałający mikroserwis wymaga jedynie przywrócenia jego poprzedniej działającej wersji, a nie ponownego długotrwałego restartu całego rozbudowanego systemu informatycznego.
Ponieważ nigdy nie ma nic za darmo, to i aplikacje zbudowane na mikroserwisach mają swoje wady związane przede wszystkim z wyższymi kosztami ich wytworzenia. Mikroserwisy wymagają zaawansowanej i wydajnej infrastruktury IT oraz specjalistów DevOps do jej utrzymania. Nie bez znaczenia jest również większe ryzyko niepowodzenia całego projektu – zbyt wiele zależy od prawidłowego zdefiniowania mikroserwisów i komunikacji pomiędzy nimi. Komunikacja jest kluczowa także na poziomie szefów zespołów, bo to na nich przenosi się odpowiedzialność z szczebla menedżerów i architektów. Taka autonomia ma swoje wymagania.
Dla deweloperów trudniejsza jest także implementacja funkcjonalności wymagającej bezwzględnej spójności danych, jak w przypadku obsługi np. przelewu bankowego. Obsługa operacji, które normalnie wykonuje system do zarządzania bazą danych tym razem spada na barki programistów. Do minusów związanych z mikroserwisami wypada także zaliczyć nieco większe trudności w testowaniu. Wydaje się na pozór, że testowanie małych komponentów jest prostsze, ale trzeba pamiętać, że rozproszenie logiki biznesowej na wiele usług utrudnia znalezienie przyczyn i wymaga analizy wielu logów. Na dodatek dodatkowym źródłem błędów mogą być punkty styku pomiędzy poszczególnymi mikroserwisami, przez co samo testowanie integracyjne nowych funkcjonalności jest bardziej skomplikowane ze względu na brak możliwości testowania całego systemu rozproszonego.
Jak przejść z architektury monolitycznej na mikroserwisy?
Przede wszystkim trzeba wybrać odpowiedni moment – rozwój produktu musi być ograniczony do minimum. Każdą zmianę trzeba nanosić i na działający monolit i na rozwijane mikroserwisy, co niepotrzebnie wydłuża migrację. Każdy większy komponent aplikacji musi zostać rozłożony na mniejsze składniki aż zostaną tylko takie, które są zgodne z przyjętą definicją mikroserwisu. Dużo w tym pracy planistycznej, organizacyjnej i czysto technicznej. Na początku warto skupić się na kilku wybranych mikroserwisach tak, aby nabrać doświadczenia i wypracować najlepsze i najskuteczniejsze metody tworzenia kolejnych mikrousług. Najczęściej wymaga się przy tym stworzenia odpowiednio szybkiego i zautomatyzowanego środowiska programistycznego do rozwijania mikroserwisów. Duże znaczenie ma wybór pierwszego mikroserwisu do dekompozycji[viii] i związana z tym dekompozycja bazy danych. Raz rozdzielona baza danych może być ekstremalnie trudna do złączenia. Wymaga to naprawdę dokładnego przemyślenia wszystkich za i przeciw, bo w praktyce jest to operacja jednokierunkowa. Docelowo, każdy mikroserwis powinien mieć swoją bazę danych, a rozdzielenie baz danych pozostaje najtrudniejszym z kroków w całym procesie migracji architektury. W żadnym momencie nie wolno zapominać o bezpieczeństwie danych i tak trzeba dobierać rozwiązania, narzędzia i technologie, aby ryzyka oraz wydajność były na akceptowalnym przez wszystkich poziomie.
[i] https://hive.com/blog/single-tasking/
[ii] https://javowiec.pl/kafka/czym-jest-kafka/
[iii] Ibidem.
[iv] https://www.ibm.com/account/reg/us-en/signup?formid=urx-49970
[v] https://www.divante.com/blog/10-companies-that-implemented-the-microservice-architecture-and-paved-the-way-for-others
[vi] Ibidem.
[vii] https://bulldogjob.pl/readme/serverless-czym-jest-i-jak-dziala
[viii] https://techblog.ing.pl/blog/jak-zdusic-monolit-i-przejsc-na-mikroserwisy-czesc-1
Porozmawiajmy!
a my pomożemy Ci wdrożyć najnowsze rozwiązania!
Podobne wpisy:
Hybrid Cloud – czy takie rozwiązanie będzie przydatne w przedsiębiorstwie?
Wdrożenie Kubernetes w przedsiębiorstwie – najczęściej zadawane pytania
Cloud Native prowadzi do innowacyjności
Która chmura obliczeniowa jest najlepsza?