Mikroserwisy – historia pewnej miłości

Artykuł

Mikroserwisy – historia pewnej miłości

Czym są mikroserwisy i jak je wykorzystać?

Architecture Hub | Blog o architekturze IT

Tematem, jaki poruszmy dzisiaj będą mikroserwisy. Koncept bardzo popularny, posiadający niemalże rangę Świętego Graala architektury. W przypadku mitycznego kielicha celem było samo poszukiwanie, czy tak samo jest z mikroserwisami?

Ostatnimi czasy odkrywam coraz więcej podobieństw między architekturą IT a architekturą wnętrz. Nie mówię tutaj o dobrym skądinąd trendzie do zwracania większej uwagi na User Experience, który dalej rozwijany jest w koncepty Customer Experience, czy nawet Human Experience. Nie, o tym porozmawiamy przy innej okazji.

Co ma wspólnego kanapa z kodem źródłowym?

Podobieństwo, które miałem na myśli to podatność na zmieniającą się modę. Pewnie zauważyliście już cykl naprzemiennej centralizacji i decentralizacji przetwarzania. Rozpoczynaliśmy od rozbudowanych mainframe. Mieliśmy do dyspozycji „głupie” terminale, które potrafiły jedynie przesłać komendę, (a czasami same znaki), do centralnego komputera. Później nastąpiła eksplozja komputerów osobistych i mainframe’y zastąpione zostały przez „grube” oprogramowanie klienckie, łączące się ewentualnie do zdalnej bazy.

Kiedy okazało się, że definiowanie logiki biznesowej na tysiącach niepowiązanych maszyn nie jest takie proste, z odsieczą przyszły rozwiązania serwerowe udostępniające „cienkiego” klienta, z którym większość z nas ma do czynienia, na co dzień. To oczywiście nie koniec cyklu, ponieważ na horyzoncie już widać pojawiający się przy okazji rozwiązań IOT wzorzec edge computing, gdzie przetwarzanie znów wyniesione jest do urządzeń końcowych.

Nie wydaje wam się to zbliżone do sytuacji, w której jednego roku urządzamy mieszkanie w duchu skandynawskiej prostoty tylko po to, żeby za dwa lata zamontować w nim złoty żyrandol i kryształowe klamki?

Powyższy przykład chciałem przytoczyć, ponieważ jest bardzo jaskrawy i nie wymaga wchodzenia w zbytnie szczegóły. Taka rozgrzewka była potrzebna, ponieważ dyskusja o mikroserwisach wymaga już bardziej dogłębnej analizy.

Mikroserwisy, czy też mikrousługi, powstały w odpowiedzi na skostnienie, jakie od lat trapi ekosystemy IT w dużych przedsiębiorstwach. Nie są oczywiście pierwszą i zapewne nie będą ostatnią próbą przyspieszenia i ułatwienia wprowadzania zmian w systemach.

O silosach nie tylko w rolnictwie

Na początku był silos. Dziesiątki tysięcy linii kodu składające się na system, który robił w organizacji wszystko. Oczywiście, był podzielony na moduły, programy czy metody, niemniej ten podział, a zwłaszcza granice między nimi, bardzo mocno zależały od zdolności kontroli nad kodem i doświadczenia poszczególnych programistów. Po kilku czy kilkunastu latach tego typu rozwiązania stanowiły nierozerwalny zbitek kodu, który tylko nieliczni mieli odwagę dotknąć. Wiele organizacji do dziś boryka są z problemem rozbicia tego typu silosów.

Rysunek 1 – Mikroserwisy -Przykład systemu silosowego

O charakterze silosów piszę nie bez powodu, w naszej dyskusji o mikroserwisach będą bardzo istotne.

Odpowiedzialność rozproszona

W końcu miarka się przebrała. Architekci stwierdzili, że skoro jeden system jest zły, to wiele systemów będzie lepszych. Jak pomyśleli, tak zrobili i oto narodziła się architektura rozproszona.

Architekturę rozproszoną można stworzyć na wiele sposobów, jednak najbardziej popularny był podział systemów na funkcje. Mamy, więc system CRM, ERP, billing, portal klienta i wiele innych. Systemy komunikują się między sobą przy pomocy API, które z kolei, może działać w czasie rzeczywistym lub nie. Wiodącą ideą jest tu jasna dekompozycja całości rozwiązania na (teoretycznie) łatwo wymienialne części.

Czym to się różni od metod i programów w silosach, zapytacie? Niczym i wszystkim. Z poziomu czysto programistycznego to, czy wywołuję inny program, czy korzystam z API innego systemu, nie będzie mieć dla mnie większego znaczenia. Oczywiście poza opóźnieniami, niedostępnością, koniecznością zabezpieczenia komunikacji, obsługi wyjątków, oczekiwania na odpowiedzi… no dobrze, może trochę ma. Ale w kontekście, o którym dyskutujemy, są to bardzo zbliżone podejścia.

Rysunek 2 Mikroserwisy - Przykład architektury rozproszonej (warstwowej)

Różnica leży… w ludziach. O ile stosunkowo łatwo jest mi się dogadać z kolegą, żeby zrobił dla mnie jakąś zmianę w swoim programie mainframe’owym, o tyle do wprowadzenia zmian w API potrzebny jest już najczęściej proces zarządzania zmianą. Oczywiście istnieją firmy, które tego procesu nie wdrażają i po kilku latach, jak łatwo możecie zgadnąć, kończą z wielką zbitką nierozerwalnego kodu.

Jeśli jednak mamy to zrobione dobrze i role systemów są przypisane sensownie, możemy stworzyć dobrze działające środowisko, w którym każdy system ma swoje zadanie w dobrze naoliwionej machinie korporacyjnej. Czego chcieć więcej?

Mikroserwisy, co to jest?

Na tym etapie większość z was się zastanawia, czy aby nie pomyliłem się w tytule artykułu i po co robię streszczenie 50 lat informatyki? Odpowiadam, więc – inaczej się nie dało.

Najpierw zobaczmy, skąd w ogóle wziął się pomysł mikroserwisów? Przyczyna jest bardzo prosta. Odkąd organizacje coraz bardziej opierają swój biznes na nowoczesnych technologiach, (choć można by dyskutować, czy coś, co powstało 50 lat temu, nadal zasługuje na to miano), coraz mniej są skłonne czekać kilka lub kilkanaście miesięcy, na wdrożenie nowej oferty dla swoich klientów.

Powstały oczywiście zwinne podejścia do zarządzania projektami, o których możecie przeczytać więcej na blogu „Zwinne organizacje”, jednak jeden element, który wdrożyły jest dla nas istotny. Są to zespoły zwinne. I tak, jak do tej pory, żeby zapisać dane klienta, musieliśmy angażować kilka zespołów (CRM, usług, integracji itp.), tak teraz mamy jeden zespół odpowiedzialny za całość obszaru. W takie podejście idealnie wpisują się mikroserwisy.

Bo czym jest w ogóle ten mikroserwis? Muszę was rozczarować – jedynie słusznej definicji nie ma. Z bardzo prostej przyczyny – mikroserwisy to koncept, nie formalny wzorzec architektury.

Mikroserwisy w swoim założeniu realizować miały Prawo Conway’a. Melvin Conway w 1968 roku na łamach magazynu Datamation stwierdził, że każda organizacja buduje systemy (w artykule rozumiane szerzej, niż tylko w zakresie IT), które odwzorowują jego strukturę komunikacyjną. Swoją drogą, warto o tym prawie pamiętać, przy okazji następnej dyskusji o wysokich kosztach IT w waszej firmie.

Pierwszy mikroserwis w akcji

Zastanówcie się chwilę, co to oznacza dla architektury systemów? Skoro prędzej czy później i tak będą odzwierciedlać one sposób wymiany informacji w organizacji, to może warto, żeby ich architektura wspierała ten fakt, a nie z nim walczyła? Tak narodził się pierwszy mikroserwis.

Rysunek 3 Mikroserwisy - Przykład architektury mikroserwisów

Mikroserwis w swoim założeniu ma grupować całość technicznych mechanizmów pozwalających na świadczenie dobrze zdefiniowanej… usługi. Wychodzi z założenia, że skoro najwięcej komunikacji przepływa w ramach komórki realizującej rdzeń usługi biznesowej, to pozwólmy tej komórce zawiadywać swoim oprogramowaniem. Jeśli informacja przekracza granice tej komórki, najczęściej jest ona wspierająca. Dla takich przypadków mamy dobrze zdefiniowane API.

Jest szereg zalet takiego podejścia. Z funkcjonalnego punktu widzenia, w szczególności, jeśli organizacja (z sukcesem) wdrożyła zwinne podejście projektowe, pozwala ono na względną izolację podejmowanych decyzji dotyczących systemu. Teoretycznie właściciel biznesowy może z systemem zrobić prawie wszystko, pod warunkiem, że nadal będzie dotrzymywał warunków kontraktów ustanowionych dla API. Drastycznie skraca to czas wdrażania nowych zmian i co do zasady jest dobre.

Od technicznej strony, bez wdawania się w szczegóły na temat tego, czym jest gałąź kodu w repozytorium i w jaki sposób się tymi gałęziami zarządza, można powiedzieć, że łatwiej wdraża się jeden spójny komponent, który modyfikuje tylko jeden zespół. Przecież w architekturze warstwowej jeden zespół też był odpowiedzialny wyłącznie za jeden system, powiecie. Zgoda, ale ten system obsługiwał dziesiątki, a czasem setki, usług biznesowych, które mogły zmieniać się zupełnie niezależnie od siebie, a czasami wchodzić ze sobą w konflikty. „Mikro” w nazwie mikroserwisu gwarantuje nam (a przynajmniej powinno), że funkcjonalność ta jest wąska. „Zaawansowana analityka” to nie jest dobrze zdefiniowany mikroserwis.

Mikroserwis dobrze określony

No właśnie, a jaki jest ten „dobrze zdefiniowany mikroserwis”? To jest chyba największa słabość tego stylu architektonicznego. Rozmawiając z architektami w różnych organizacjach można stwierdzić, że każda wypracowała sobie trochę inną definicję. Kiedyś uczyłem się (bardzo krótko się uczyłem) grać na gitarze i instruktor miał powiedzenie: „jeśli coś brzmi dobrze, to znaczy, że grasz to dobrze”. Jestem zwolennikiem podobnego podejścia do architektury. Jeśli coś się u ciebie sprawdza, to nie ma znaczenia czy jest to zgodne z definicją Jamesa Lewisa czy Martina Fowlera (jednych z głównych orędowników mikroserwisów). Działa, to działa.

Chyba, że nie działa. Wtedy możliwości są dwie. Usługa może być zdefiniowana zbyt wąsko. W tej sytuacji stanie się ona składową „głównych” usług i stanie się ich zależnością. Los każdej zależności jest taki, że nie może się już dowolnie zmieniać, ponieważ na jej funkcjonalności bazuje dużo innych komponentów. Bardzo często nie wiadomo, do czego konkretnie te komponenty wykorzystują daną funkcjonalność. W ten sposób zafundowaliśmy sobie bardzo kosztowną (ze względu na liczbę niezależnych modułów) sztywną architekturę z dyktatem usług końcowych.

Może być też odwrotnie – mikroserwis jest zdefiniowany zbyt szeroko. Wówczas może się bardzo szybko okazać, że uproszczone ramy zapewniania jakości i dostarczania kodu nie będą sobie mogły poradzić z czymś, co jest faktycznym silosem. W tej sytuacji wasz proces rozwoju, w najlepszym wypadku, utknie w miejscu. W najgorszym – będzie się toczył dalej i doprowadzi do chaosu.

Ale nawet idealnie zdefiniowany mikroserwis ma pewną konkretną charakterystykę. Dam wam czas do końca tego zdania na zastanowienie się, co to takiego, ponieważ niedawno ten temat poruszaliśmy. W swojej czystej postaci mikroserwis jest mianowicie małym silosem rozwijanym przez pojedynczy zespół. W miarę rośnięcia będzie się zamieniała w duży silos i wrócimy do punktu startu.

Hybrydy wśród mikroserwisów

Pewnym wyjściem z sytuacji może być zastosowanie specyficznego rodzaju hybrydy. Nie ma tak naprawdę żadnych przeciwwskazań, żeby mikroserwis korzystał z platform architektury warstwowej. Oczywiście purystyczne podejście mówi, że musimy być w stanie wdrożyć ją w całości, bez zewnętrznych referencji. Ale może wykorzystanie silnika BPMS może być pewnym kompromisem?

Rysunek 4 Mikroserwisy - Przykład mikroserwisu hybrydowego

Technologie CI\CD od dawna potrafią obsłużyć wiele kroków podczas wdrażania jednej paczki zmian, mogą, więc w jednym kroku skompilować kod Java, w drugim – opublikować nową konfigurację procesu. Silnik BPM musi posiadać API umożliwiające automatyczną publikację zmian, jednak znakomita większość technologii posiada to w standardzie.

Warto w tym miejscu zwrócić uwagę, że taka współdzielona platforma powinna mieć zespół, który się nią opiekuje od strony technologicznej. Ten zespół nie implementuje zmian – wtedy wrócilibyśmy do architektury warstwowej, jednak pilnuje on jakości dostarczanego kodu, służy radą i dba o to, żeby sama platforma działała dobrze.

Nie każdy musi być Netflixem

Teraz, kiedy już z grubsza wiecie, jaka jest specyfika mikroserwisów, możemy bezpiecznie poruszyć bardziej kontrowersyjne tematy. Mianowicie, ostatnio wśród architektów rozwija się ruch oporu przeciwko mikroserwisom.

Mikroserwisy, oprócz swoich niewątpliwych zalet, posiadają też wiele wad. Największą chyba jest kłopot, jaki sprawia zdefiniowanie zakresu pojedynczej usługi. W efekcie organizacje muszą tracić czas i pieniądze na zarządzanie setkami niezależnie rozwijanych „systemików” lub kończą z wielkim monolitem.

Jest to też dość kosztowna przygoda. Oprócz samej zmiany organizacyjnej, konieczne jest też zbudowanie rozwiązania zarządzającego API, warstwy mediacyjnej i modeli domenowych (o tych porozmawiamy przy innej okazji). Firmy latami budują swoje mikroserwisowe architektury i czasami im się to udaje, czasami nie. A bywa, że kończą „w rozkroku”.

Nie jest to, więc architektura dla wszystkich. Mikroserwisy najlepiej sprawdzają się w dynamicznych środowiskach, gdzie zmiany wdrażane są często i szybko. Dobrze też, jeżeli w organizacji istnieje rola właściciela biznesowego (czy właściciela produktu), który może samodzielnie podejmować decyzje na temat funkcjonalności. Przykładem takiej firmy jest Netflix, który jako jeden z pierwszych wdrożył architekturę mikroserwisową. Drugą jest Amazon. Jak widzicie, są to organizacje bardzo szybko reagujące na zmiany na rynku.

Z drugiej strony, jeśli wasza organizacja nie wdraża co miesiąc nowej usługi dla swoich klientów (albo można ją wpisać w zbudowane już ramy), architektura warstwowa może być dla was w zupełności wystarczająca. Można też rozważyć swoiste „IT dwóch prędkości”, w którym systemy niezmieniające się często, a wymagające dużej stabilności (na przykład centralne systemy bankowe), są zbudowane klasycznie, natomiast rozwiązania znajdujące się bliżej klienta są już oparte o mikroserwisy.

I co ja mam zrobić?

Jak we wszystkich aspektach życia, żaden ekstremizm nie jest ani dobry, ani zdrowy. Istnieją oczywiście organizacje, które muszą być w pełni mikroserwisowe i ich model biznesowy wspiera takie podejście, lub wręcz go wymaga. Jednakże wiele firm wdrożonego wstępnie zestawu mikroserwisów nie zmieni przez następnych kilka lat, warto więc zadać sobie pytanie, czy warto ponosić dodatkowe koszty takiego rozwiązania?

W większości przypadków konieczne będzie znalezienie złotego środka i po raz kolejny okaże się, że architekturze IT bliżej jest do sztuki, niż do nauki ścisłej. Niezależnie od tego, w jakiej organizacji pracujecie, warto krytycznie podchodzić do obowiązującej mody, żeby się nie okazało, że skończycie z wielkim kryształowym żyrandolem, którego nikt nie będzie chciał od was kupić.

Czy ta strona była pomocna?