Mikroserwisy, jako możliwość przekształcenia istniejącego środowiska IT

Architektura oparta na mikroserwisach staje się coraz popularniejsza. Jej zalety wydają się liczniejsze od dotychczas zidentyfikowanych wad. Gdy zdecydujemy się na korzystanie z takiego podejścia do próby podjęcia transformacji istniejących monolitycznych rozwiązań, konieczne jest zadbanie o ciągłość funkcjonowania istniejących środowisk oraz zapewnienie możliwie sprawnego ich przekształcenia.

Operacja zmiany monolitycznego rozwiązania w system oparty na mikroserwisach nie odbędzie się w czasie zbliżonym do zera. Oprócz więc perspektywy projektowanego rozwiązania, warto zadbać o wymiar zależności między planowanymi pracami a innymi inicjatywami w naszej organizacji.

Czy warto wdrożyć architekturę mikroserwisów?

Zacznijmy od tego, co chcemy uzyskać? Jeśli zdecydujemy się obrać stworzenie architektury opartej na mikroserwisach jako jedyny cel, tylko dlatego że słyszeliśmy, iż to modne, dobre dla każdego – lepiej spożytkować energię na inne zadania. Weryfikacja osiągnięcia sukcesu, ze względu na ogólną definicję mikroserwisów, jest nieco utrudniona. Niewątpliwie jest to łakomy kąsek dla zwolenników szukania przyczynków do propagandy swego sukcesu, ale uważam, iż lepiej zadbać o głębszy sens ewentualnej transformacji.

Zatem, co nadaje sens ewentualnym pracom? Przede wszystkim są to istotne korzyści dla całej organizacji. Jeśli ich nie będzie, agitatorom transformacji zostanie przypięta maska technokratów oderwanych od realiów otoczenia biznesowego. Aby nie przesadzić w drugą stronę, nie zapominajmy przy tym, że przykładowo skrócenie czasu dostarczania zmian w środowiskach i zmniejszenie ilości błędów im towarzyszącym, to korzyść nie tylko dla IT. Bardzo możliwe, że przyniesie spore oszczędności finansowe.

Istotnym wymiarem – przy decydowaniu się na tak sporą zmianę – jest gotowość obecnego IT oraz organizacji. Jeśli obecnie funkcjonujące procesy dostarczania zmian są w dużym stopniu oparte na czynnościach manualnych, przejście na nową architekturę może być trudniejsze. Jeżeli jest taka możliwość, w ramach transformacji należy zapewnić automatyzację w obszarach testów i wdrożenia. Potrzebne są też testy, możliwie najszersze, aby skutecznie zapobiec regresji, przy jak najmniejszym zaangażowaniu ludzi. Konieczne jest również wdrożenie, aby móc sprawnie i częściej wprowadzać zmiany. Dzięki temu lepiej odczujemy korzyści zmiany. Warto wziąć pod uwagę potencjalne minusy architektury opartej na mikroserwisach. Zwiększanie rozproszenia i rozdrobnienie serwisów może przysporzyć więcej prac utrzymaniowych. Sam rozwój, mimo wielu niezaprzeczalnych zalet, także wiąże się z dodatkowymi – w stosunku do monolitu – sprawami do przemyślenia.

Metodyka wdrożenia mikroserwisów

Jak podjąć decyzję? Wystarczy uczciwie spisać charakterystykę stanu obecnego. Co funkcjonuje źle, a co dobrze. Następnie spróbować osadzić to w realiach architektury docelowej. Zastanowić się, co może – dzięki zmianom – ulec poprawie. I czy na pewno ulegnie poprawie? Niektóre, zwłaszcza proste środowiska funkcjonują bardzo dobrze, jako monolit, i niewiele zyskamy, a stracimy na narzutach złożoności, specyficznych dla architektury opartej na mikroserwisach. Czasem wystarczy dobra modularyzacja monolitu. Jeśli jednak przeważają zyski, należy oszacować nakład prac oraz sprawdzić, czy i kiedy mają one szansę się zwrócić.

Jest też prawdopodobne, że inicjatywa – w ramach której planowana jest transformacja architektury – będzie miała polegać na wprowadzaniu innych zmian, np. funkcjonalnych. Może to zaciemnić nieco obraz tworzony na potrzeby podjęcia decyzji, ale w niektórych organizacjach będzie to jedyna okazja do przeprowadzenia transformacji. Ponadto warto zdawać sobie sprawę, że w zależności od obecnego, podlegającego zmianom środowiska – mogą one mieć charakter radykalnej przebudowy (a wręcz budowy „od zera” całego rozwiązania), a niekiedy może się okazać, iż zmiany będą niemal „kosmetyczne”.

Gdy upewnimy się, że warto przeprowadzić transformację i że nasza organizacja jest gotowa na taką zmianę, a także sprawia wrażenie, iż będzie jej sprzyjać, pora na wybór metodyki, którą będziemy się wspierać. Czynników wpływających na tę decyzję jest sporo, lecz mając wolną rękę, preferowałbym podejście zwinne. Jest ono “odporniejsze” na różnego rodzaju niespodzianki, o które łatwo przy kompleksowej zmianie architektury nietrywialnych środowisk. Istotną sprawą jest to, że pod pojęciem zwinności nie rozumiem podejścia (jak to złośliwi przeciwnicy zwykli przedstawiać) pozbawionego planowania i projektowania, lecz – przede wszystkim – iteracyjność i nastawienie na ciągłe doskonalenie rozwiązania. Po prostu dobrze współgra to z mikroserwisami. Oczywiście – można zastosować kaskadę, o ile mamy stalowe nerwy, perfekcyjnie rozpoznane środowisko oraz… przekonanie o nieomylności członków zespołu.

Projektowanie rozwiązania

W pierwszej kolejności należy dokonać agregacji istniejących serwisów oraz zastanowić się, czy zachować ją w architekturze docelowej, czy podejść do tematu inaczej. Jedną z naturalnych podstaw partycjonowania jest funkcjonalność, ale może także nią być na przykład wymiar wydajnościowo-dostępnościowy, który bezpośrednio odwzorowuje się na osadzenie mikroserwisów w warstwie infrastrukturalnej. Jeśli istniejący monolit był podzielony na różne zespoły projektowe – można próbować odzwierciedlić ich przypisanie w nowej rzeczywistości. Mamy również możliwość grupowania hybrydowego, tj. połączenia wielu podstaw podziału, z których każda będzie stanowiła osobny wymiar.

Grupowanie takie warto wykonać od razu. Ułatwi to osadzanie części merytorycznej w rzeczywistości projektowej. W zależności od wybranej metodyki, wstępny podział dokonywany jest na sprinty, sfazowaną kaskadę itp. Nawet jeśli nasza transformacja ma być jednofazową kaskadą – kończącą się „big-bangiem” – wykonanie wspomnianego podziału pomoże lepiej śledzić postępy prac.

Jeżeli zdecydujemy się na model zmian, w ramach którego w trakcie trwania transformacji będziemy przeprowadzać zmiany w środowisku produkcyjnym, dodatkowym wyzwaniem będzie zapewnienie odpowiedniego przepływu i spójności danych – zwłaszcza, gdy granice zmiany iteracji, fazy nie będą się pokrywały z modelem danych (co jest wysoce prawdopodobne w starym świecie). Pomijając aspekt organizacyjny, agregacja pomoże zapanować merytorycznie nad serwisami.

Dekompozycja serwisów monolitycznych

Popularnym sposobem na zdefiniowanie dobrego mikroserwisu jest nawiązanie do reguły pojedynczej odpowiedzialności (Single Responsibility Principle), dotyczącej projektowania klas w programowaniu obiektowym. Pojęcie odpowiedzialności jest określane jako powód do zmiany stanu. Jedna klasa powinna mieć nie więcej niż jeden powód do modyfikacji. Jeśli jest ich więcej – należy ją rozbić na mniejsze. Warto zwrócić uwagę na niebezpieczeństwo prób minimalizacji zakresu odpowiedzialności „na siłę”. Łatwo wówczas wpaść w pułapkę ciągłego dążenia do atomowości odpowiedzialności, gdy rozwiązanie tego nie wymaga, co prowadzi do nadmiernego, sztucznego namnożenia mikroserwisów, bez korzyści, lecz ze sztucznym narzutem. Dopóki serwisy są ze sobą mocno powiązane, także należy więzy „obcinać” inaczej, nasze serwisy będą mikroserwisami tylko z nazwy.

W ramach prac transformacyjnych prawdopodobnie szybko się okaże, że projekt nie ograniczy się do rozbijania serwisów na mniejsze, ale konieczna będzie ich przebudowa – zwłaszcza w środowiskach słabo zaprojektowanych. Mamy jednak tę przewagę nad autorami poprzedniego rozwiązania, że wiemy, jak ono sprawdza się w praktyce i gdzie niedomaga. Wykorzystajmy tę wiedzę przy transformacji. Koniecznie też stwórzmy politykę wprowadzania – w projektowanych mikroserwisach – przyszłych zmian na poziomie API. Jeśli konsumentem mikroserwisu będzie fragment oprogramowania rozwijany przez inny zespół, bądź nawet ten sam, ale w innym czasie, to niezbędne jest wybranie któregokolwiek sposobu wersjonowania, a najlepiej zachowania wstecznej zgodności API.

Zmiana architektury monolitycznej na mikroserwisową – mimo wielu potencjalnych zalet – nie zawsze będzie stanowiła gwarancję korzyści. Dlatego każdy przypadek należy rozważać indywidualnie. Jeśli podejmiemy decyzję o przeprowadzeniu transformacji, należy przede wszystkim pamiętać, aby w pełni wykorzystać potencjał zmiany. Najprawdopodobniej będzie dotyczyć on nie tylko produktu w postaci projektu i wdrożenia oprogramowania, lecz także zmiany procesów i organizacji pracy wielu komórek IT.