Krok 2: Zadbaj o właściwą organizację zespołów

Do tego momentu mogło się wydawać, że tworzenie mikrousług jest przede wszystkim kwestią techniczną. Trzeba podzielić bazę kodu na wiele usług, wdrożyć właściwe wzorce, które pozwolą sprawnie obsługiwać awarie i przywracać działanie usług po wystąpieniu problemów z siecią, rozwiązać kwestię spójności danych, monitorować obciążenie usług itp. Będzie trzeba poznać wiele nowych zagadnień. Prawdopodobnie jednak najważniejszą rzeczą, której bezwzględnie nie wolno zignorować, jest konieczność zmiany podejścia do organizacji zespołów.

Prawo Conwaya działa i można je zaobserwować we wszelkiego rodzaju zespołach. Jeśli zespół odpowiedzialny za tworzenie oprogramowania składa się z zespołów pracujących nad backendem i frontendem oraz zespołu operacyjnego, które funkcjonują niezależnie, będzie on zawsze dostarczał monolity frontendu i backendu przerzucane po prostu do zespołu operacyjnego, który wdroży je w środowisku produkcyjnym. Tego rodzaju struktura zespołów nie sprawdzi się w przypadku mikrousług, ponieważ każdą usługę należy potraktować jako odrębny produkt, który musi zostać dostarczony niezależnie od innych.

Zamiast tego tworzy się więc niewielkie zespoły DevOps posiadające wszystkie kompetencje wymagane do opracowania i utrzymania usług, za jakie odpowiadają. Taka organizacja pracy zespołów przynosi wiele korzyści. Po pierwsze, programiści lepiej rozumieją wpływ tworzonego przez siebie kodu na środowisko produkcyjne, co pozwala im opracowywać lepsze wydania i zmniejszyć ryzyko pojawienia się błędów u klientów. Po drugie, wdrożenia stają się rutynowym elementem pracy poszczególnych zespołów, które wspólnie pracują nad udoskonalaniem kodu oraz automatyzacją pipeline'u wdrożeniowego.

Krok 3: Podziel monolit, aby stworzyć architekturę mikrousług

Gdy już wyznaczysz granice swoich usług i opracujesz sposób reorganizacji zespołów, możesz przystąpić do podziału monolitu w celu stworzenia mikrousług. Na tym etapie musisz przemyśleć kilka zagadnień, które przedstawiamy poniżej.

Uproszczenie komunikacji między usługami dzięki interfejsowi API REST

Jeśli jeszcze nie korzystacie z interfejsu API REST, to dobry moment na jego wdrożenie. Jak wyjaśnia Martin Fowler, potrzebujesz „inteligentnych punktów końcowych i głupich rur”. Oznacza to, że protokół komunikacji między usługami powinien być możliwie jak najprostszy i umożliwiać jedynie przesyłanie danych bez ich przekształcania. Cała magia dzieje się w samych punktach końcowych — otrzymują one żądanie, przetwarzają je i przesyłają odpowiedź.

W architekturach mikrousług nacisk kładzie się na maksymalne uproszczenie, pozwalające uniknąć ścisłych powiązań komponentów. W niektórych przypadkach możesz zdecydować się na korzystanie z architektury opartej na zdarzeniach wspomaganej asynchroniczną komunikacją bazującą na wiadomościach. Jednak w tej sytuacji również warto przyjrzeć się podstawowym usługom obsługującym kolejkę wiadomości, takim jak RabbitMQ, aby uniknąć niepotrzebnego komplikowania wiadomości przesyłanych za pośrednictwem sieci.

Podział danych na ograniczone konteksty i domeny danych

Aplikacje monolityczne wykorzystują jedną bazę danych do obsługi wszystkich funkcji biznesowych aplikacji. Gdy monolit zostanie podzielony na mikrousługi, ta pojedyncza baza danych może utracić sens. Centralna baza danych staje się w ten sposób wąskim gardłem w procesie skalowania ruchu. Jeśli konkretna usługa zyska dostęp do bazy danych i znacznie ją obciąży, może spowodować zakłócenie dostępu innych usług do tej bazy. Ponadto jedna baza danych może stać się wąskim gardłem z perspektywy współpracy, gdy wiele zespołów będzie równocześnie próbowało zmodyfikować schemat. Może to być argument za podziałem bazy danych lub wprowadzeniem dodatkowych narzędzi do przechowywania danych w celu zaspokojenia potrzeb związanych z obsługą danych mikrousług.

Reorganizacja monolitycznego schematu bazy danych może być delikatną operacją. Ważne, aby precyzyjnie wskazać zbiory danych potrzebne poszczególnym usługom i pokrywające się obszary. Do takiego planowania schematu można wykorzystać konteksty ograniczone, będące wzorcem zaczerpniętym z podejścia „domain-driven design”. Ograniczony kontekst wyznacza samodzielny system, z uwzględnieniem elementów, które mogą wchodzić do tego systemu i go opuszczać.

W takim systemie, gdy użytkownik otworzy zamówienie, zobaczy w tabeli dane klienta, które można wykorzystać również do uzupełnienia faktury zarządzanej przez system rozliczeń. Może się to wydawać logiczne i proste, jednak w przypadku mikrousług usługi nie powinny być ze sobą połączone, aby można było korzystać z faktur nawet w przypadku awarii systemu składania zamówień. Ponadto takie rozwiązanie umożliwia optymalizowanie lub doskonalenie tabeli faktur niezależnie od innych. Ostatecznie każda usługa może posiadać magazyn danych, który umożliwi jej dostęp do potrzebnych danych.

To rodzi nowe problemy, ponieważ niektóre dane będą dublowane w różnych bazach danych. Ograniczone konteksty pozwalają wskazać najlepszą strategię obsługi współdzielonych lub zdublowanych danych. Można przyjąć architekturę opartą na zdarzeniach, aby ułatwić synchronizację danych na poziomie wielu usług. Przykładowo usługi rozliczeń i śledzenia dostaw mogą nasłuchiwać zdarzeń generowanych przez usługę konta, gdy klient zaktualizuje swoje dane osobowe. Po otrzymaniu zdarzenia usługi te zaktualizują odpowiednio swój magazyn danych. Taka architektura oparta na zdarzeniach umożliwia uproszczenie logiki usługi konta, ponieważ nie musi ona „znać” innych usług zależnych. System otrzymuje po prostu od tej usługi informację o dokonanej czynności, a inne usługi nasłuchują i podejmują odpowiednie działania.

Można również zdecydować się na przechowywanie wszystkich danych klienta w usłudze konta, a w usłudze rozliczeń i dostaw dodać jedynie odwołanie do obcego klucza. Wówczas usługi te będą nawiązywały interakcję z usługą konta, aby pobrać odpowiednie dane klienta, zamiast dublowania istniejących rekordów. Nie ma uniwersalnego sposobu rozwiązania tych problemów, dlatego musisz przyjrzeć się każdemu z przypadków z osobna i ustalić, jakie podejście będzie najlepsze.

Przygotowanie architektury mikrousług na awarie

Omówiliśmy już, jakie korzyści mogą przynieść Ci mikrousługi w porównaniu z architekturą monolityczną. Są mniejsze i bardziej wyspecjalizowane, dzięki czemu łatwiej je zrozumieć. Są rozłączne, co oznacza, że możesz zmodyfikować usługę bez obaw o uszkodzenie innych komponentów systemu lub spowolnienie prac innych zespołów. Dodatkowo zapewniają one programistom większą elastyczność, ponieważ mogą bez obaw sięgać po różne technologie, gdyż nie są ograniczeni potrzebami innych usług.

Krótko mówiąc, architektura mikrousług ułatwia opracowywanie i utrzymywanie rozwiązań obsługujących poszczególne obszary działalności. Jeśli jednak przyjrzymy się usługom razem oraz sposobowi, w jaki wchodzą one we wzajemne interakcje w celu wykonania czynności, sprawa zaczyna się komplikować. Twój system jest teraz rozproszony, przez co powstaje wiele punktów potencjalnych awarii — należy brać to pod uwagę. Musisz uwzględnić nie tylko przypadki, w których usługa nie odpowiada, ale także konieczność radzenia sobie ze spowolnionymi odpowiedziami sieci. Odzyskiwanie po awarii również bywa problematyczne, ponieważ musisz uważać, aby przywrócone usługi nie zostały zalane oczekującymi komunikatami.

Gdy zaczniesz wyodrębniać obszary funkcjonalne z systemów monolitycznych, musisz od początku zwracać uwagę, aby Twoje projekty były tworzone z myślą o awarii.

Nacisk na monitorowanie w celu ułatwienia testowania mikrousług

Testowanie jest kolejną wadą mikrousług w porównaniu z systemem monolitycznym. Skonfigurowanie i uruchomienie środowiska testowego dla aplikacji utworzonej w oparciu o jedną bazę kodu nie jest trudne. W większości przypadków wystarczy uruchomić serwer backendowy połączony z bazą danych, aby móc zainicjować swój pakiet testów.

W świecie mikrousług nie jest to takie łatwe. Testy jednostkowe nadal będą przebiegały dość podobnie, jak w monolicie, i na tym poziomie raczej nie odczujesz większych trudności. Jednak testowanie integracji i systemu jest już znacznie trudniejsze. Może zajść konieczność uruchomienia kilku usług jednocześnie, przygotowania różnych magazynów danych i uwzględnienia w konfiguracji kolejek wiadomości, co nie było konieczne w przypadku monolitu. W związku z tym przeprowadzanie testów funkcjonalnych jest znacznie droższe, a więcej ruchomych elementów bardzo utrudnia przewidywanie różnych rodzajów awarii, do jakich może dojść.

Monitorowanie pozwala wychwycić problemy na wczesnym etapie i stosownie zareagować. Musisz zrozumieć podstawy działania różnych usług i reagować nie tylko wówczas, gdy przestają działać, ale także wtedy, gdy zachowują się w sposób nieoczekiwany. Zaletą przyjęcia architektury mikrousług jest jednak to, że system powinien być odporny na częściowe awarie. Jeśli więc zaczniesz dostrzegać nieprawidłowości w usłudze śledzenia dostaw aplikacji Pizzup, konsekwencje nie będą tak poważne, jak w przypadku systemu monolitycznego. Nasza aplikacja powinna być zaprojektowana tak, aby wszystkie inne usługi reagowały właściwie, a klienci mogli dalej zamawiać pizzę, podczas gdy my będziemy przywracać funkcję śledzenia na żywo.

Opanowanie ciągłego dostarczania w celu ograniczenia konfliktów przy wdrożeniach

Ręczne wydawanie systemu monolitycznego do produkcji jest żmudnym i ryzykownym zajęciem, ale da się to zrobić. Naturalnie nie zalecamy tego podejścia i zachęcamy każdy zespół zajmujący się tworzeniem oprogramowania do wdrożenia ciągłego dostarczania w odniesieniu do wszystkich rodzajów prac rozwojowych, jednak na początku projektu swoje pierwsze wdrożenia możesz wykonać samodzielnie za pośrednictwem wiersza poleceń.

Gdy rośnie liczba usług, które trzeba wdrażać wiele razy dziennie, takie podejście przestaje mieć sens. Dlatego tak ważne jest, aby w ramach przejścia na mikrousługi opanować ciągłe dostarczanie, a tym samym zmniejszyć ryzyko nieudanych wydań oraz dać zespołowi możliwość skoncentrowania się na tworzeniu i utrzymaniu aplikacji, a nie jej żmudnym wdrażaniu. Praktykowanie ciągłego dostarczania oznacza również, że usługa przeszła testy akceptacji przed przekazaniem do produkcji. Błędy będą się oczywiście pojawiać, jednak z czasem stworzysz niezawodny pakiet testów, dzięki któremu zespół zyska większą pewność co do jakości wydań.