Przyszłość infrastruktury opartej o mikroserwisy i konteneryzacje

# Modern Architecture

Przyszłość infrastruktury opartej o mikroserwisy i konteneryzacje

21.03.2023

Pojawienie się mikroserwisów i kontenerów swoim znaczeniem, zasięgiem i rolą w rozwoju technologii IT przypomina przełom, jaki dokonała teoria kwantów w fizyce. W istocie mikroserwisy są nowym jakościowo połączeniem koncepcji tworzenia oprogramowania ze szczególnym uwzględnieniem odwzorowania potrzeb biznesowych, czyli Domain Driven Design (DDD) z budową systemów informatycznych zorientowanych na usługi, gdzie sprawdzone komponenty są współdzielone pomiędzy wieloma aplikacjami, co zwykle bywa nazwane Service-Oriented Architecture (SOA). Odejście od aplikacji monolitycznych i wejście w świat mikroserwisów wymaga zmian nie tylko oprogramowaniu, ale i w infrastrukturze IT.

Mikroserwisy i konteneryzacja – nowe podejście do infrastruktury

Mikroserwisy i kontenery jako metoda wdrażania architektury mikroserwisów pojawiły się 2012 roku za sprawą pracującego w Netflix Adriana Cockcrofta[i]. Z kolei pojawienie się na rynku Dockera i Kubernetes zapewniło niezbędne narzędzia do tworzenia aplikacji i zarządzania nimi.

Kontenery zarządzane w ramach jednej platformy upraszczają komunikację mikroserwisów, a to ułatwia projektowanie i budowanie wydajnej architektury sieciowej. W sferze bezpieczeństwa kontenery izolują mikroserwisy i aplikacje, co radykalnie zmniejsza ryzyko rozprzestrzeniania się zagrożeń w całej firmowej infrastrukturze IT.

Każdy z mikroserwisów można traktować osobno, skalując je i dostosowując ich wydajność do bieżących potrzeb biznesowych. Narzędzia do orkiestracji mikroserwisów ułatwiają także automatyzację uruchamiana poszczególnych komponentów, a to umożliwia zastosowanie podejścia „blue-green deployment” do metod wprowadzania zmian w oprogramowaniu biznesowym.

Jednak płynne przejście od rozwiązań monolitycznych do mikroserwisów, mimo bezdyskusyjnej atrakcyjności tych drugich, wymaga nowego i precyzyjnego podejścia do całej infrastruktury IT. Szczególnej uwagi wymaga komunikacja pomiędzy poszczególnymi elementami, aplikacji, które działając niezależnie od siebie, w bardziej złożonych konfiguracjach mogą generować opóźnienia w sieci, wydłużony czas przetwarzania i ogólne problemy z wydajnością. Oczywiście automatyzacja, zwinne metodyki i podejście Cloud Native DevOps mogą zredukować skalę problemu, ale już widać, że cała infrastruktura IT musi być nastawiona na pełne wykorzystanie największej zalety mikroserwisów, czyli ich wyjątkowej wydajności.

Tę zależność od infrastruktury można zminimalizować. Właśnie w tym celu opracowano model infrastruktury sieciowej Service Mesh, czyli sieć połączonych ze sobą, globalnie konfigurowanych pośredników ruchu proxy. Dzięki temu developerzy mogą skupić się na tworzeniu nowych funkcjonalności, bez konieczności dopasowywania wszystkich założeń do wymagań infrastruktury. Dostawcy chmur publicznych udostępniają Service Mesh dla mikroserwisów na ich platformach, np. Google Kubernetes Engine czy Azure Kubernetes Service.

Również w środowisku chmury obliczeniowej wyraźnie widać, że łatwiejsze staje się skalowanie poszczególnych funkcji aplikacji niezależnie od siebie. Tworząc aplikację z mikroserwisów nie ma konieczności uzależniania się od jednej technologii, czy dostawcy, można wybierać takie rozwiązania, które najlepiej pasują do konkretnych zastosowań i potrzeb biznesowych.

Ogólnie, mikroserwisy są chyba najlepiej dostosowane do wykorzystania architektury typu serverless, co w wielu zastosowaniach pozwala na znaczne oszczędności na kosztach infrastruktury, szczególnie w nowych projektach.

Mikroserwisy i konteneryzacja, a dług technologiczny

Dług technologiczny powstaje, gdy organizacja stosuje nieoptymalne rozwiązania techniczne tak, aby jak najszybciej zaspokoić swoje potrzeby biznesowe. Najczęściej skutkiem takich decyzji są aplikacje utrudniające bądź uniemożliwiające realizację przyszłych celów firmy i jej rozwój. Jak to zwykle bywa – prowizorka często okazuje się najtrwalszym składnikiem organizacji. Do trudniejszych przypadków należy sytuacja, gdy istniejąca kluczowa aplikacja monolityczna jest naprawdę dobra, użytkownicy ją znają i lubią, a przede wszystkim się do niej przyzwyczaili. Bywa, że takie systemy pracują nieprzerwanie kilkanaście lat, a ci który znali ich kod i architekturę już dawno zmienili pracę, narzędzia i zapomnieli, co w trawie piszczy. W takiej sytuacji dług technologiczny jest naprawdę poważny i z reguły trzeba słono zapłacić za odzyskanie zdolności do modyfikowania i rozwijania takich rozwiązań informatycznych. Nawet dostosowanie aplikacji do aktualnych wersji systemu operacyjnego, czy nowych protokołów szyfrowania w przeglądarkach internetowych może wymagać nie tyle miesięcy co lat pracy doświadczonych developerów, którzy znają wiekowe platformy i mają na tyle wiedzy, aby na nowo skonstruować aplikację z mikroserwisów.

Bezpieczeństwo, niezawodność oraz wzrost wydajności przetwarzania danych

W organizacjach, gdzie mogą działać setki i tysiące mikroserwisów problemem do rozwiązania staje się ich zabezpieczenie przed nieuprawnionym dostępem oraz wzajemna komunikacja pomiędzy nimi. Można oczywiście używać metod zabezpieczania ruchu pomiędzy usługami bazujących na mechanizmach zaimplementowanych we wspólnym kodzie bibliotek programistycznych, ale generuje to dodatkową pracę. W podejściu Service Mesh można na poziomie mikroserwisów określać, których metod dostępu mogą używać konkretni klienci, a które z nich mogą być wykorzystywane bez ograniczeń. Środowisko samo egzekwuje politykę bezpieczeństwa.

W odróżnieniu od aplikacji monolitycznych, mikroserwisy tworzą dynamiczne, stale zmieniające się środowisko, które siłą rzeczy generuje ryzyko. Dobrze zaprojektowany i zaimplementowany mikroserwis musi być przygotowany na awarię nie tylko swoją, ale także otoczenia. Developerzy muszą przewidzieć różnego typu mechanizmy obronne i sposoby ponawiania zapytań o zasoby, ale dzięki temu stworzenie aplikacji w architekturze mikroserwisów pozwala podnieść jej ogólną niezawodność. Aplikacja nie odmówi posłuszeństwa, nawet jeśli jedna z jej funkcji okaże się wadliwie zaprojektowana lub natrafi na nieoczekiwane problemy. W przypadku bardziej złożonych aplikacji możliwe jest wykorzystanie zasad ciągłego wdrażania i integracji CD/CI – Continuous Deployment – Continuous Integration.

Kontenery, w których działa kod mikroserwisów, umożliwiają działanie aplikacji udostępniając bezpośrednio zasoby systemu operacyjnego serwera, na którym są uruchomione. W konsekwencji uruchamiają się one szybciej niż maszyny wirtualne i zapewniają wysoką wydajność, przy jednoczesnym obniżeniu kosztów działania infrastruktury. Duże znaczenie dla uzyskania odpowiedniej wydajności przetwarzania danych ma wybrana platforma orkiestracji mikroserwisów. Nie wolno także zapominać o prawidłowej alokacji i dystrybucji zasobów na potrzeby mikroserwisów o krytycznym znaczeniu biznesowym. Kategoryzacja i priorytetyzacja mikrousług w ramach ekosystemu musi odpowiadać ich znaczeniu i wartości dla całej działalności organizacji. Dopiero wtedy ujawnią się wszystkie zalety mikroserwisów i konteneryzacji.

Kiedy warto stosować architekturę opartą o mikroserwisy?

Architektura aplikacji biznesowych zbudowana z mikroserwisów sprawdza się przede wszystkim tam, gdzie często trzeba tworzyć i dodawać nową funkcjonalność. W systemach monolitycznych wymaga to odnalezienia odpowiedniego miejsca w kodzie, spełnienia wymagań interfejsów pośrednich, czy dojścia do warstwy widoków, zatem sprawa się komplikuje w miarę wzrostu złożoności kodu. Lekarstwem na tę bolączkę są właśnie mikroserwisy, czyli małe programy z interfejsem do komunikacji.

Mikroserwisy pojawiają się także tam, gdzie problemem jest skalowalność. Nie od dziś wiadomo, że aplikacje monolityczne są trudno skalowalne, bo z reguły wymaga to kosztownego skalowania całości. W architekturze opartej o mikroserwisy można zająć się skalowaniem tylko tych serwisów, które mają największe obciążenia, a to redukuje koszty utrzymania takiej aplikacji.

Dzięki mikroserwisom organizacja może pokonać ograniczenia wynikające z używania konkretnego stosu technologicznego w aplikacjach monolitycznych, gdzie czasami bardzo trudno dokonać migracji do nowych wersji języków, bibliotek, czy frameworków. Przynajmniej w teorii, każdy mikroserwis może być napisany w innym języku programowania dobranym w zależności od zadania i obsługiwanego procesu biznesowego. Zatem bez większych trudności można aktualizować technologie mikroserwisów, nie martwiąc się o to, że można zburzyć działanie całego systemu.

Zalety i wady mikroserwisów i konteneryzacji

Aplikacja zbudowana z mikroserwisów ma niewątpliwą przewagę nad klasyczną konstrukcją monolityczną. Wynika to przede wszystkim ze znacznej redukcji ryzyka zatrzymania pracy całego systemu z powodu drobnego błędu w jednym obszarze[ii]. Za wzrostem stabilności takiej aplikacji idzie także możliwość dużo szybszego i częstszego wdrażania nowych wersji, testowania nowych funkcjonalności i badania reakcji użytkowników. Podział złożonego systemu na wiele łatwych w zarządzaniu elementów pozwala niezależnie skalować każdą z usług z osobna oraz lepiej kontrolować poziom długu technologicznego. Przy okazji, każdy z takich elementów jest łatwiejszy do zrozumienia, zaprojektowania i bieżącego utrzymania. Liczą się także względy psychologiczne – zespół programistów koncentruje się tylko na funkcjonalności mikroserwisu, sam wybiera technologię i sposób realizacji usług. W konsekwencji budowa i wdrożenie aplikacji przebiega sprawniej i szybciej. Nawet, gdyby się okazało, że trzeba wykonany mikroserwis wyrzucić do kosza i przepisać na nowo, nie wiąże się to z dużymi kosztami, to tylko niewielki fragment dużej układanki.

Oczywiście nic nie jest idealne – architektura mikroserwisów i konteneryzacja nie jest opłacalna przy wdrożeniach małych projektów, wymaga dogłębnego rozumienia specyfiki biznesowej oraz doskonałej organizacji pracy i komunikacji pomiędzy zespołami. Bardziej skomplikowana architektura i obecność warstwy sieciowej w komunikacji między komponentami aplikacji utrudnia testowanie i namierzanie błędów w aplikacji, szczególnie w sytuacji, gdy analizowany proces korzysta z usług wielu mikroserwisów.

Mimo tych niedoskonałości, według raportu “2022 Service Mesh Adoption Survey”[iii] 85% firm planuje przebudowę swoich systemów w architekturze mikroserwisów, a 53% już teraz używa kontenerów Kubernetes do obsługi co najmniej połowy ich obciążeń produkcyjnych.

[i] https://bykowski.pl/mikroserwisy-wprowadzenie-i-praktyczny-przyklad/

[ii] https://itreseller.com.pl/mikroserwisy-idealne-rozwiazanie-na-wzrost-i-rozwoj-biznesu-dlaczego-wyszly-z-mody-monolityczne-pakiety-aplikacji/

[iii] https://www.solo.io/resources/report/2022-service-mesh-adoption-survey/