Mikroserwisy – historia pewnej miłości

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.

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.

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.

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

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.

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?

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.

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.

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.

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.

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?

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.

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.

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ć.

Jak możemy pomóc?

W dzisiejszych czasach firmy żyją zmianami. Nowe kanały, nowi klienci, nowe produkty, to wszystko wymaga ciągłego dostosowywania narzędzi IT. Nasz zespół postawił sobie jeden cel – sprawić, żeby nasi klienci nie tylko przeszli przez te zmiany niepoturbowani, ale by jak najlepiej wykorzystywali technologie do realizacji swoich celów biznesowych.

Pomagamy liderom IT oraz ich zespołom w procesie przemian technologicznych:

• Opracowujemy nowe modele operacyjne, procesy i struktury.
• Wspieramy w uruchamianiu praktyk architektonicznych i planujemy wspólnie z nimi mapy drogowe rozwoju systemów.
• Prowadzimy również organizacje poprzez zwinne transformacje, wspierając w uruchomieniu wcześniej wypracowanych koncepcji strategicznych.

Zapraszamy do kontaktu.