Ten cały hype związany z mikroserwisami nie jest przypadkowy. Mikroserwisy , że wydają się być jedyną słuszną drogą, jeżeli nasz projekt ma nie powodować niekontrolowanego wybuchu śmiechu lub też wyrazów politowania na twarzy innych, którzy podążają za trendami i dawno mają już kilkanaście serwisów z których każdy oczywiście korzysta z osobnej bazy danych.

Dlaczego ten entuzjazm w temacie mikroserwisów należy brać z dystansem?

Ceną zalet które uzyskujemy (a opisałem je we wpisie: Mikroserwisy – wprowadzenie i dlaczego chcesz je mieć ) jest spora lista wad:

1. Podróż w nieznane.

Tytuł tego punktu jest celowo przekolorowany aczkolwiek jest w nim sporo prawdy. Musimy się liczyć z mniejszym zrozumieniem tematu pośród developerów. Mimo całego zamieszania wokół mikroserwisów w ostatnich latach, mimo wszystko architektura monolityczna jest dominującym sposobem tworzenia oprogramowania i często czynnikiem limitującym wprowadzenie takiej architektury może być brak odpowiednich kompetencji. Gdy sam zaczynałem swoją pracę nad projektem wykorzystującym mikroserwisy musiałem niemalże z dnia na dzień przestawić się na całkiem inne myślenie. Nie mając wcześniej styczności z tą architekturą chłonąłem wiedzę na jej temat niemalże z wypiekami na twarzy. Decydując się na tą architekturę trzeba być świadomym, że każdy z developerów będzie musiał wyruszyć w tą podróż i tu rodzi się pytanie czy każdy z nich będzie zdolny i wystarczająco zmotywowany by brnąć tą drogą.

2. Testowanie

Testowanie systemu jest utrudnione poprzez fakt, że trudniej nam odtworzyć stan systemu z chwili wystąpienia błędu. Patrząc pod innym kątem łatwiej testować problemy jeżeli są wyizolowane i dotyczą tylko i wyłącznie jednego mikroserwisu. Logowanie pozwala na złagodzenie problemów z testowaniem, aczkolwiek monolit tutaj wygrywa.

3. Kolaboracja między zespołami i inne implikacje wynikające z prawa Conway’a

Prawo Convey’a zgrubsza mówi o tym, że architektura systemu dąży do odzwierciedlenia struktury organizacyjnej ludzi ją tworzących.

Implementacja funkcjonalności wymaga kolaboracji pomiędzy różnymi serwisami może wymagać kooperacji między różnymi zespołami. Podział odpowiedzialności za mikroserwisy pomiędzy zespoły może wywoływać problemy gdy implementacja funkcjonalności przebiega na pograniczu wielu mikroserwisów. Nie jest może to do wielka wada, ale raczej wyzwanie i rzecz na którą warto zwrócić uwagę.

4. Dodatkowa złożoność związana z tworzeniem rozproszonego systemu

Z natury jeżeli mamy do czynienia z monolityczną architekturą, a komunikacja odbywa się wewnątrz procesu, unikamy konieczności martwienia się o to czy inny mikroserwis jest akurat dostępny, czy dane na których operujemy są wystarczająco aktualne (synchronizacja pomiędzy mikroserwisami) i wiele innych.

5.  Mikroserwisy od początku trwania projektu mogą być ryzykowne

Tworzenie architektury zorientowanej na mikroserwisy od zera może przynieść więcej strat niż pożytku. Mając ograniczoną więdzę nt. wymagań odnośnie tworzonego systemu (kto się z tym nie spotkał?) możemy dokonać błędnych decyzji nt. podziału funkcjonalności na mikroserwisy co niesie za sobą dużo większe konsekwencje niż w wypadku monolitu. Dlatego też często zalecaną praktyką jest tworzenie monolitu z luźno powiązanymi modułami, a następnie rozbijanie go na mikroserwisy gdy kształt systemu się wykrystalizuje. Unikamy wtedy przerzucania kodu pomiędzy różnymi mikroserwisami, a nawet pomiędzy różnymi zepołami!

6. Konieczna większa wszechstronność zespołów

Więcej umiejętności DevOpsowych wymaganych od zespołów rozwijających i utrzymujących mikroserwisy. Często wymaganiem jest aby zespół przeprowadził proces rozwijania mikroserwisu od implementacji do deploymentu i utrzymania. W monolitycznej architekturze mniej z tych obowiązków spoczywa na programistach. Wypuszczanie wersji zazwyczaj jest dużo rzadsze i często są obsługiwane przez dedykowanych ludzi.

7. Infrastruktura

Przy mniejszych systemach duży narzut tworzenia i utrzymywania infrastruktury, który niekoniecznie musi się opłacać.

8. Trudna kontrola niezawodności systemu.

W monolicie pula spraw które mogą pójść nie tak jest mniejsza niż przy mikroserwisach. Oczywiście jeżeli monolit leży to leży wszystko. W przypadku mikroserwisów często jesteśmy w dużym stopniu uzależnieni od infrastruktury sieciowej, dostęności zależnych mikroserwisów, szyny wiadomości i innych. To wszystko sprawia, że musimy być w stanie reagować na problemy w każdym z tych obszarów gdyż jeżeli mamy kilka komponentów z których każdy jest krytyczny dla działania systemu to prawdopodobieństwo, że system jest w pełni dostępny w danej chwili jest iloczynem prawdopodobieństwa dostępności każdego z tych komponentów.

Można złagodzić tutaj wymaganie dostępności poprzez komunikację asynchroniczną i architekturę zorientowaną na zdarzenia.

9. Krytyczność posiadania monitoringu i logowania

Jest to poniekąd implikacja kilku poprzednich punktów. Wiele miejsc w systemie wymaga uwagi więc kluczową sprawą jest posiadanie monitoringu i logowania. Nie zliczę ilości razy gdy załamywała mnie tymczasowa niedostępność logowania w systemie w którym musiałem zdebugować jakiś błąd. Nagle złożoność takiego problemu zwiększa się kilkakrotnie. Podobnie brak monitoringu sprawia, że błądzimy po omacku.

Podsumowanie

Każda w wymienionych cech systemów opartych o mikroserwisy powoduje, że warto dwa, a nawet trzy razy zastanowić się nad wprowadzeniem ich do naszego systemu. Mądzej czasami jest wstrzymać się z taką decyzją jak już będziemy ich pewni, nie dlatego, że jest to modne, ale dlatego, że przyniesie to wymierne korzyści w naszym konkretnym projekcie.