Od monolitu do mikrousług – migrować czy nie migrować?

29/08/2018

Mikrousługi (ang. microservices) to styl architektoniczny zorientowany na szybkość rozwoju oprogramowania, rozumianą jako  liczba funkcjonalności tworzonych w jednostce czasu oraz czasochłonność całego procesu wytwórczego – od koncepcji do wdrożenia (time to market). Coraz większej popularności podejścia mikrousługowego sprzyja obecna wysoka zmienność otoczenia biznesowego, co zmusza firmy do szybkiego reagowania celem uniknięcia sytuacji kiedy  dobre rozwiązanie wdrożone zbyt późno staje się złym rozwiązaniem.

Większość funkcjonujących obecnie systemów klasy enterprise posiada architekturę monolityczną. Ich niezaprzeczalną zaletą jest oczywiście to, że działają i zapewniają posiadającym je organizacjom przychody lub oszczędności. Architektura monolityczna powoduje jednak, że wraz z rozrostem tych systemów stopniowo maleje tempo ich rozwoju. Właściciele biznesowi muszą coraz dłużej czekać na zamówione funkcjonalności. Co gorsza, skalowalność procesu tworzenia oprogramowania okazuje się być daleka od liniowej. Angażowanie do pracy przy takich systemach kolejnych ludzi lub zespołów, przynosi coraz mniejsze korzyści. Wprowadzanie nowych pracowników trwa coraz dłużej, a obecni tracą motywację i żądają dodatków za pracę w trudnych warunkach lub zaczynają rozważać ścieżkę kariery poza organizacją. Takie symptomy wskazują wyraźnie, że architektura systemu przestała spełniać wymagania przedsiębiorstwa. Rozwiązaniem problemu niedostatecznego tempa rozwoju systemu jest zastosowanie architektury ewolucyjnej – mikrousług.

Aby zobrazować efekt zastosowania podejścia mikrousługowego możemy posłużyć się pewną metaforą. Załóżmy, że chcemy zbudować i utrzymać stację kosmiczną. W tym celu będziemy potrzebowali regularnie dostarczać na orbitę różnego rodzaju ładunki: ludzi, materiały, sprzęt itp. Obecnie jedyną dostępną formą transportu, są loty kosmiczne, które pomimo ostatnich osiągnięć firm takich jak SpaceX, są bardzo drogie i wymagają czasochłonnych przygotowań. Możemy więc spróbować opracować inne rozwiązanie – windę kosmiczną. Nakłady na jej budowę z pewnością będą wielokrotnie większe od kosztu pojedynczego lotu, ale każdy kolejny transport będzie możliwy w zasadzie od ręki i praktycznie za darmo (w porównaniu do kosztów lotu).

Powyższa metafora, oprócz zobrazowania wizji świetlanej przyszłości, jaką obiecują nam mikrousługi pozwala poczynić inną istotną refleksję. Mianowicie wdrożenie takiego podejścia jest sporym wyzwaniem i wymaga znaczącej inwestycji. A więc zanim zaczniemy budować windę kosmiczną powinniśmy się upewnić, że potrzebujemy dostać się na orbitę i że będziemy się tam wybierać często. W przeciwnym razie całe przedsięwzięcie stanie się jedynie sztuką dla sztuki.

Migrować czy nie migrować?

Przed podjęciem decyzji o zastosowaniu podejścia mikrousługowego należy rozważyć kilka kwestii:

Moment, w cyklu życia systemu, w którym te kryteria zostaną spełnione jest optymalnym do podjęcia decyzji o zastosowaniu podejścia mikrousługowego.

Pamiętać przy tym należy, że podejście mikrousługowe ma swoje granice stosowalności – przykładowo nie należy go stosować w przypadku systemów czasu rzeczywistego.

Architektura mikrousługowa

Sam Newman, powszechnie uznawany za twórcę koncepcji architektury mikrousługowej, sformułował następującą jej definicję:

“small autonomous services modelled around business domain that work together

Wynika z niej, że podstawowym elementem konstrukcyjnym w tym podejściu są usługi, które będziemy wyodrębniać stosując dekompozycję według obszarów (zdolności) biznesowych (ang. business capabilities). Usługi te mogą być niezależnie rozwijane i wdrażane, ale muszą ze sobą współpracować w celu realizacji procesu biznesowego.

Anatomia usługi

Jeśli komponent, będący częścią systemu, tylko przechowuje dane, to zasadniczo jest bazą danych, jeżeli zawiera samą logikę – nazywamy go funkcją. Usługa natomiast z założenia zawiera oba te elementy –  logikę i dane. Takie połączenie jest właśnie podstawą autonomii na którą zwraca uwagę Sam Newman. Podchodząc do problemu dekompozycji systemu, warto jest mieć tę definicję z tyłu głowy.

Linie podziału

Poszczególne style architektoniczne różnią się między sobą sposobami wyodrębniania komponentów. Istotną cechą architektury mikrousługowej jest zorganizowanie funkcjonalności usług wokół zdolności biznesowych (ang. business capabilities), co pozwala zapewnić ich wewnętrzną spójność (ang. high cohesion) oraz stabilność uzyskanego podziału. Taką metodę okiełznania złożoności logiki biznesowej spopularyzował Eric Evans pod nazwą “Domain Driven Design”. Opisuje ona sposób podziału dziedziny na poddziedziny a następnie wyodrębnienia w nich kontekstów ograniczonych, które posłużą nam jako granice usług.

Praktyczną techniką identyfikacji kontekstów ograniczonych jest “Event Storming” zaproponowany przez Alberto Brandolini’ego. Jej pierwszy krok polega na zidentyfikowaniu zdarzeń zachodzących w domenie biznesowej. Takie podejście pozwala zorientować proces modelowania na zachowanie zamiast skupiać go na statycznej strukturze przetwarzanych informacji. Ta, z pozoru subtelna  zmiana perspektywy, jest kluczowa dla architektury mikrousługowej, ponieważ umożliwia zaprojektowanie systemu cechującego się niskim sprzężeniem i dużą autonomią jego usług składowych (ang. loose coupling).

Wyznaczając granice usług trzeba pamiętać, że staną się one granicami transakcji i silnej, natychmiastowej spójności (ACID). Dla operacji angażujących kilka usług system będzie posiadał charakterystykę BASE (Basically Available, Soft state, Eventual consistency), która oferuje gwarancję żywotności (ang. liveness) ale nie gwarantuje bezpieczeństwa (ang. safety). W odróżnieniu od ACID, BASE oznacza, że system osiągnie w końcu spójność, ale nie wiadomo, jak będzie ten stan wyglądał ani, jak będzie się system zachowywał w międzyczasie. Istnieje możliwość uzyskania gwarancji bezpieczeństwa (strong eventual consistency) w modelu BASE, bez wykorzystywania tradycyjnych mechanizmów kontroli współbieżności. Wymaga to jednak zastosowania tak zwanych CRDT (conflict-free replicated data types).

Świat rzeczywisty nie jest transakcyjny. Użytkownicy stosunkowo rzadko wymagają natychmiastowej spójności. Za przykład może tu posłużyć domena finansów, która wydawałoby się, powinna stawiać najwyższe wymagania dotyczące spójności. Wszyscy jednak jesteśmy przyzwyczajeni do faktu, że realizacja przelewów międzybankowych trwa godziny lub nawet dni, a w trakcie operacji nie wiadomo co się dzieje ze środkami – nie widać ich ani na rachunku źródłowym, ani docelowym.

Często sami inżynierowie oprogramowania wykazują tendencję do forsowania natychmiastowej spójności tam, gdzie nie jest ona konieczna, a czasami może być wręcz szkodliwa. Zetknąłem się kiedyś z pewnym rozbudowanym systemem do zarządzania przedsiębiorstwem. W momencie przyznania klientowi statusu VIP w module CRM, podsystem logistyczny generował automatycznie zlecenie wysyłki butelki szampana, która miała dodatkowo podkreślić wyróżnienie. Cała operacja była wykonywana w jednej transakcji. Spowodowało to, że w momencie wyczerpania zasobów magazynowych szampana próba złożenia zlecenia wysyłki kończyła się błędem, cała transakcja była odwijana i w efekcie nie można było ustawić klientowi statusu VIP. Podzielenie operacji na dwie transakcje i zastosowanie wzorca sagi, byłoby w tym przypadku, lepszym rozwiązaniem.

Reasumując, należy więc zweryfikować, jakie gwarancje spójności są wymagane dla poszczególnych funkcjonalności i upewnić się, że ustalone granice zabezpieczają te wymagania.

Przygotowanie

Wprowadzenie architektury mikrousługowej niesie ze sobą szereg wyzwań, które należy zaadresować przed rozpoczęciem procesu transformacji. Tworzony w ten sposób system wymagać będzie automatyzacji procesów budowania, konfiguracji, testowania i wdrażania. Niezbędne staną się również narzędzia do gromadzenia i agregacji logów oraz metryk a także analizy zachowania (śledzenia, profilowania, etc) w środowisku rozproszonym.

Na wczesnym etapie procesu transformacji konieczne jest ustalenie sposobu integracji i koordynacji usług, architektury danych, metod zapewnienia spójności transakcyjnej i niezawodności, konfiguracji, service discovery oraz innych aspektów wskroś-funkcjonalnych. Wprowadzanie lub zmiana tych rozwiązań na późniejszych etapach transformacji będzie znacznie kosztowniejsza niż na jej początku.

Wspomniane powyżej zagadnienia są na tyle istotne i szerokie, że zasługują na poświęcenie im osobnego artykułu . Zaniedbanie zwłaszcza obszaru integracji może skutkować brakiem autonomii usług i spowodować, że w efekcie zamiast spodziewanej architektury mikrousługowej otrzymamy rozproszony monolit.

Ewolucja czy rewolucja?

Kiedy mamy już wyznaczone granice usług, które będą tworzyły docelową strukturę rozwiązania musimy zdecydować, w jaki sposób przeprowadzić transformację: czy będziemy modernizować system etapowo, stopniowo wydzielając kolejne komponenty, czy stworzymy cały system od od podstaw i przekażemy do eksploatacji po zakończeniu całej operacji. Drugi wariant jest z pewnością dużo łatwiejszy i bardziej kuszący, jednak w praktyce, w większości przypadków nieakceptowalny. W warunkach silnej konkurencji i dużej dynamiki rynku niewiele firm jest w stanie sobie pozwolić na wstrzymanie rozwoju systemu informatycznego, od którego zależą kluczowe procesy biznesowe, na dłuższy okres czasu. Jeśli przy okazji modernizacji architektury, chcielibyśmy dodatkowo zmienić technologię lub kluczowy framework, to  pierwsze podejście również nie będzie miało zastosowania. W takiej sytuacji możemy zastosować podejście nazywane zaduszaniem (ang. strangler pattern).

Transformacja

W jaki sposób możemy wykonać stopniową transformację do architektury mikrousługowej?

Jako punkt wyjścia dla tego procesu przyjmijmy system o strukturze monolitycznej:

From Monolith to Microservices

Pierwszym krokiem jest częściowe logiczne rozdzielenie interfejsu użytkownika od warstwy usług. Obsługa poleceń logiki biznesowej jest delegowana do warstwy usług, a zapytania służące do zasilenia widoków są kierowane bezpośrednio do bazy danych. Na razie nie modyfikujemy samej bazy danych:

From Monolith to Microservices

Drugi krok to pełna separacji logiczna interfejsu użytkownika:

From Monolith to Microservices

W trzecim kroku należy wykonać separację fizyczną interfejsu użytkownika a po stronie backendu udostępnić API i wykorzystać je do komunikacji pomiędzy rozdzielonymi komponentami:

From Monolith to Microservices

Czwarty krok polega na stopniowym wydzielaniu kolejnych usług. Tym razem wykonujemy pełną separację – do poziomu bazy danych włącznie. Jeżeli organizacja nie stosowała wcześniej architektury mikrousługowej dobrze jest rozpocząć dekompozycję od obszaru małego i prostego do wyodrębnienia . To pozwoli zespołowi w krótkim czasie i przy relatywnie niskim ryzyku zdobyć niezbędne doświadczenie.

From Monolith to Microservices

Ostatnim krokiem jest dekompozycja frontendu, którą również możemy wykonywać etapowo – stopniowo wyodrębniając kolejne fragmenty interfejsu użytkownika:

From Monolith to Microservices

Niewątpliwą zaletą tego procesu jest jego ewolucyjny charakter. Za jego pomocą możemy zmieniać architekturę stopniowo, bez całkowitego zatrzymywania rozwoju systemu, dostosowując tempo zmian do wymagań biznesowych i dostępnych zasobów.

Kontekst

Architektura systemu nie dryfuje w próżni. Jest silnie powiązana z procesem wytwórczym oraz strukturą i kulturą organizacji. Kluczową cechą architektury mikrousługowej jest jej ewolucyjność. Oznacza to, że wybór tego podejścia przyniesie największe korzyści w organizacji zbudowanej z małych, autonomicznych zespołów stosujących zwinne metodyki tworzenia oprogramowania. Brak tych cech nie powinien nas jednak powstrzymywać przed wyborem tej architektury. Możemy je zaadoptować równocześnie z procesem modernizacji architektury. Nie możemy natomiast ich zupełnie zignorować. Zgodnie z prawem Conwaya:

“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

Jeśli zatem wprowadzimy podejście mikrousługowe w silnie scentralizowanej, hierarchicznej organizacji istnieje ryzyko, że z biegiem czasu architektura naszego systemu zacznie ponownie dążyć w stronę monolitu. Dlatego też proces modernizacji architektury systemu powinniśmy rozpocząć od przeprowadzenia tzw. Odwróconego Manewru Conwaya (ang. Inversed Conway Maneuvre), czyli stworzenia struktury organizacyjnej izomorficznej z oczekiwaną docelową architekturą systemu. Kiedy usuniemy tradycyjne silosy funkcjonalne (frontend dev, backend dev, dba, qa, ops, etc), a w ich miejsce powołamy skupione wokół strumieni wartości (ang. value streams) i zdolności biznesowych (ang. business capabilities) samodzielne zespoły wielofunkcyjne (ang. cross-functional teams), znacznie łatwiej będzie nam w analogiczny sposób zdekomponować system a następnie utrzymać uzyskaną architekturę.

“Design the organisation you want, the architecture will follow (kicking and screaming).”

Evan Bottcher, ThoughtWorks

Kryteria sukcesu

Kiedy zakończymy proces transformacji, warto sprawdzić, czy udało się nam uzyskać zakładany efekt. Czy to co osiągnęliśmy można nazwać sukcesem. Celem wdrożenia architektury mikrousługowej, jest przede wszystkim usprawnienie procesów związanych z rozwojem i utrzymaniem oprogramowania. Możemy to zmierzyć za pomocą kilku prostych wskaźników, np:

Porównując wartości tych charakterystyk dla starej i nowej charakterystyki możemy ocenić efekt przeprowadzonej transformacji. Wymienione powyżej wskaźniki możemy monitorować również w trakcie procesu transformacji.

Tu, w Altkom Software & Consulting, jako inżynierowie fascynujemy się rozwiązaniami, które pozwalają udoskonalać otaczającą nas rzeczywistość. Mamy jednak świadomość, że każda zmiana, to inwestycja, która musi się zwrócić.

Autor: Robert Kuśmierek, Lead Software Engineer, ASC LAB

Zarejestruj się na webinar:

Wyrażam dobrowolnie zgodę na przetwarzanie moich danych osobowych dla potrzeb procesu realizacji zgłoszenia (pokaż więcej) przez Altkom Experts sp. z o.o. oraz Altkom Software & Consulting sp. z o.o. (ul. Chłodna 51, 00-867 Warszawa), zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych („RODO”). Mam świadomość, iż podanie powyższych danych osobowych jest dobrowolne, ale konieczne do obsługi zgłoszenia oraz że posiadam prawo dostępu do treści swoich danych i możliwość ich poprawiania a zgoda może być odwołana w każdym czasie. Kontakt do inspektora ochrony danych osobowych w Altkom: iodo@altkom.pl

Wyrażam dobrowolnie zgodę na przetwarzanie moich danych osobowych w celach marketingowych (pokaż więcej)przez Altkom Experts sp. z o.o. oraz Altkom Software & Consulting sp. z o.o. (ul. Chłodna 51, 00-867 Warszawa)oraz otrzymywanie informacji handlowych drogą elektroniczną na adres e-mail i numer telefonu podany przeze mnie, zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych („RODO”), oraz Ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną. Mam świadomość, iż podanie powyższych danych osobowych jest dobrowolne oraz że posiadam prawo dostępu do treści swoich danych i możliwość ich poprawiania a zgoda może być odwołana w każdym czasie. Kontakt do inspektora ochrony danych osobowych w Altkom: iodo@altkom.pl

 

Watch for free

Enter your contact details to receive a link to the recording:

I voluntarily consent to the processing of my personal data for the purposes of the application process (show more) by Altkom Experts sp. z o.o. and Altkom Software & Consulting sp. z o.o. (51 Chłodna Street, 00-867 Warsaw), in accordance with Regulation 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of individuals with regard to the processing of personal data and on the free movement of such data ("RoDO"). I am aware that providing the above personal data is voluntary, but necessary to handle the request, and that I have the right to access the content of my data and the possibility of correcting it, and that my consent may be revoked at any time. Please contact the Altkom Data Protection Officer: iodo@altkom.pl.

I voluntarily consent to the processing of my personal data for marketing purposes (show more)by Altkom Experts sp. z o.o. and Altkom Software & Consulting sp. z o.o. (ul. Chłodna 51, 00-867 Warsaw) and receiving commercial information by electronic means to the e-mail address and telephone number provided by me, in accordance with Regulation 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of individuals with regard to the processing of personal data and on the free movement of such data ("RODO"), and the Act of 18 July 2002 on the provision of electronic services. I am aware that providing the above personal data is voluntary and that I have the right to access and correct my data and that my consent may be revoked at any time. Please contact the Altkom Data Protection Officer: iodo@altkom.pl.

 

Zarejestruj się na webinar:

Wyrażam dobrowolnie zgodę na przetwarzanie moich danych osobowych dla potrzeb procesu realizacji zgłoszenia (pokaż więcej) przez Altkom Experts sp. z o.o. oraz Altkom Software & Consulting sp. z o.o. (ul. Chłodna 51, 00-867 Warszawa), zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych („RODO”). Mam świadomość, iż podanie powyższych danych osobowych jest dobrowolne, ale konieczne do obsługi zgłoszenia oraz że posiadam prawo dostępu do treści swoich danych i możliwość ich poprawiania a zgoda może być odwołana w każdym czasie. Kontakt do inspektora ochrony danych osobowych w Altkom: iodo@altkom.pl

Wyrażam dobrowolnie zgodę na przetwarzanie moich danych osobowych w celach marketingowych (pokaż więcej)przez Altkom Experts sp. z o.o. oraz Altkom Software & Consulting sp. z o.o. (ul. Chłodna 51, 00-867 Warszawa)oraz otrzymywanie informacji handlowych drogą elektroniczną na adres e-mail i numer telefonu podany przeze mnie, zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych („RODO”), oraz Ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną. Mam świadomość, iż podanie powyższych danych osobowych jest dobrowolne oraz że posiadam prawo dostępu do treści swoich danych i możliwość ich poprawiania a zgoda może być odwołana w każdym czasie. Kontakt do inspektora ochrony danych osobowych w Altkom: iodo@altkom.pl

 

Zarejestruj się na webinar:

Wyrażam dobrowolnie zgodę na przetwarzanie moich danych osobowych dla potrzeb procesu realizacji zgłoszenia (pokaż więcej) przez Altkom Experts sp. z o.o. oraz Altkom Software & Consulting sp. z o.o. (ul. Chłodna 51, 00-867 Warszawa), zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych („RODO”). Mam świadomość, iż podanie powyższych danych osobowych jest dobrowolne, ale konieczne do obsługi zgłoszenia oraz że posiadam prawo dostępu do treści swoich danych i możliwość ich poprawiania a zgoda może być odwołana w każdym czasie. Kontakt do inspektora ochrony danych osobowych w Altkom: iodo@altkom.pl

Wyrażam dobrowolnie zgodę na przetwarzanie moich danych osobowych w celach marketingowych (pokaż więcej)przez Altkom Experts sp. z o.o. oraz Altkom Software & Consulting sp. z o.o. (ul. Chłodna 51, 00-867 Warszawa)oraz otrzymywanie informacji handlowych drogą elektroniczną na adres e-mail i numer telefonu podany przeze mnie, zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych („RODO”), oraz Ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną. Mam świadomość, iż podanie powyższych danych osobowych jest dobrowolne oraz że posiadam prawo dostępu do treści swoich danych i możliwość ich poprawiania a zgoda może być odwołana w każdym czasie. Kontakt do inspektora ochrony danych osobowych w Altkom: iodo@altkom.pl

 

Zarejestruj się na webinar:

Wyrażam dobrowolnie zgodę na przetwarzanie moich danych osobowych dla potrzeb procesu realizacji zgłoszenia (pokaż więcej) przez Altkom Experts sp. z o.o. oraz Altkom Software & Consulting sp. z o.o. (ul. Chłodna 51, 00-867 Warszawa), zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych („RODO”). Mam świadomość, iż podanie powyższych danych osobowych jest dobrowolne, ale konieczne do obsługi zgłoszenia oraz że posiadam prawo dostępu do treści swoich danych i możliwość ich poprawiania a zgoda może być odwołana w każdym czasie. Kontakt do inspektora ochrony danych osobowych w Altkom: iodo@altkom.pl

Wyrażam dobrowolnie zgodę na przetwarzanie moich danych osobowych w celach marketingowych (pokaż więcej)przez Altkom Experts sp. z o.o. oraz Altkom Software & Consulting sp. z o.o. (ul. Chłodna 51, 00-867 Warszawa)oraz otrzymywanie informacji handlowych drogą elektroniczną na adres e-mail i numer telefonu podany przeze mnie, zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych („RODO”), oraz Ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną. Mam świadomość, iż podanie powyższych danych osobowych jest dobrowolne oraz że posiadam prawo dostępu do treści swoich danych i możliwość ich poprawiania a zgoda może być odwołana w każdym czasie. Kontakt do inspektora ochrony danych osobowych w Altkom: iodo@altkom.pl