Читать книгу Mikroserwisy w akcji - Группа авторов - Страница 13

Wiele udanych przedsięwzięć jest opartych na monolitycznym oprogramowaniu – przykładami są Basecamp3, Stack-Overflow i Etsy. W aplikacjach monolitycznych istnieje bogactwo ortodoksyjnych, długoletnich praktyk i wiedzy dotyczącej tworzenia oprogramowania. Dlaczego warto wybrać mikroserwisy?

TECHNICZNA HETEROGENICZNOŚĆ PROWADZI DO MIKROSERWISÓW

W niektórych firmach techniczna heterogeniczność sprawia, że mikroserwisy są oczywistym wyborem. W Onfido zaczęliśmy budować mikroserwisy, gdy wprowadziliśmy produkt oparty na uczeniu maszynowym – niepasujący do naszego oryginalnego Ruby! Nawet, gdy nie jesteśmy w pełni przekonani do podejścia mikroserwisowego, zastosowanie tych zasad daje większy wybór technicznych rozwiązań w celu uporania się z problemami biznesowymi. Niemniej jednak nie zawsze jest to tak jednoznaczne.

IM WIĘKSZY WZROST SKOMPLIKOWANIA SYSTEMU, TYM BARDZIEJ NARASTAJĄ TARCIA W TRAKCIE JEGO ROZWOJU

Wynika to z natury złożonych systemów. Na początku rozdziału wspomnieliśmy, że programiści starają się tworzyć efektywne i ponadczasowe rozwiązania złożonych problemów. Ale systemy oprogramowania, które tworzymy, są z natury skomplikowane. Żadna metodologia ani architektura nie może wyeliminować istotnej złożoności w sercu takiego systemu.

Ale to nie jest powód, by wpadać w przygnębienie! Możemy spowodować, że wybrane przez nas podejścia programistyczne będą skutkować dobrymi złożonymi systemami, bez przypadkowej złożoności.

Poświęćmy chwilę i zastanówmy się, co chcemy osiągnąć, będąc programistami oprogramowania dla firmy. Dobrze ujął to Dan North:

Celem rozwoju oprogramowania jest zrównoważone minimalizowanie czasu oczekiwania na pozytywny wpływ na działalność.

Najtrudniejszą częścią złożonych systemów oprogramowania jest dostarczanie trwałych wartości w obliczu zmian – tak, aby nadal je dostarczać zręcznie, w odpowiednim tempie i bezpiecznie, nawet gdy system staje się większy i bardziej złożony. Dlatego uważamy, że dobry złożony system to taki, w którym w całym cyklu jego życia są minimalizowane dwa czynniki: tarcie i ryzyko.

Ograniczają one szybkość i zwinność, a tym samym zdolność do wpływania na biznes. Gdy monolit rośnie, następujące czynniki mogą prowadzić do tarć:

■ cykle zmian są ze sobą powiązane, co prowadzi do większych barier w koordynacji i wyższego ryzyka regresji;

■ niejasne wzorce i granice kontekstu wprowadzają chaos w niezdyscyplinowanych zespołach, prowadząc do ścisłych lub nieoczekiwanych sprzężeń między komponentami;

■ sam rozmiar także może być bolesny – ciągłe zadania związane z integracją i tworzeniem nowych wersji, a także lokalne uruchamianie aplikacji stają się wolniejsze.

Te cechy nie są prawdziwe dla wszystkich monolitów, ale niestety są prawdziwe dla większości, z którymi się zetknęliśmy. Ponadto tego typu wyzwania są typowym wątkiem w historiach o firmach, o których wspomnieliśmy.

MIKROSERWISY ZMNIEJSZAJĄ TARCIE I RYZYKO

Mikroserwisy pomagają zmniejszyć tarcie i ryzyko na trzy sposoby:

■ izolując i minimalizując zależności w czasie kompilacji;

■ umożliwiając programistom generowanie spójnych pojedynczych komponentów zamiast całego systemu;

■ umożliwiając ciągłe dostarczanie małych, niezależnych zmian.

Izolowanie i minimalizowanie zależności podczas kompilacji – czy to między zespołami, czy w istniejącym kodzie – pozwala programistom na szybsze działanie. Rozwój może się odbywać równolegle, przy mniejszej długoterminowej zależności od wcześniejszych decyzji podejmowanych dla monolitycznej aplikacji. Zaszłości technologiczne w naturalny sposób ograniczają się do granic usług.

Mikroserwisy są pojedynczo łatwiejsze do zbudowania i bardziej zrozumiałe niż aplikacje monolityczne. Jest to korzystne dla produktywności w rozwijającej się firmie. Zapewnia także przekonujący i elastyczny paradygmat do radzenia sobie z coraz większą skalą lub łatwym wprowadzaniem nowych technologii.

Małe usługi są również doskonałym sposobem na wprowadzanie częstych zmian. Wdrożenia w dużych aplikacjach mogą być ryzykowne i obejmować cykle regresji i weryfikacji. Wdrażając mniejsze fragmenty funkcjonalności, łatwiej można izolować zmiany w działającym systemie, zmniejszając potencjalne ryzyko wynikające z wdrożenia.

W tym momencie dochodzimy do dwóch wniosków:

■ rozwój małych, autonomicznych usług może zmniejszyć tarcie w rozwoju długo istniejących, złożonych systemów;

■ dostarczając spójne i niezależne elementy funkcjonalności, można zbudować system, który jest elastyczny i odporny na zmiany, co pomaga uzyskać zrównoważony wpływ na biznes przy zmniejszonym ryzyku.

To nie znaczy, że każdy powinien budować mikroserwisy. Byłoby cudownie, gdyby istniała obiektywna odpowiedź na pytanie „Czy potrzebuję mikroserwisów?”, ale niestety można tylko odpowiedzieć „To zależy” – od naszego zespołu, od naszej firmy i od charakteru budowanego systemu. Jeśli zakres naszego systemu jest trywialny, to jest mało prawdopodobne, że uzyskamy korzyści, które przewyższą dodatkową złożoność wynikającą z budowania i obsługi tego typu aplikacji. Ale jeśli napotkamy którekolwiek z wyzwań, o których wspominaliśmy wcześniej w tej części, to mikroserwisy są przekonującym rozwiązaniem.

Opowieść ku przestrodze

Słyszeliśmy kiedyś historię o nieudanej implementacji mikroserwisów. Istniejący proces zaczął się rozrastać, CTO zdecydował zatem, że jedynym rozwiązaniem jest przebudowanie aplikacji na postać mikroserwisów. Jeśli nie przejmujesz się tym stwierdzeniem, to lepiej zacznij!

Zespół inżynierów rozpoczął przebudowę aplikacji. Zajęło im to pięć miesięcy, podczas których nie wydali żadnych nowych funkcjonalności ani żadnego mikroserwisu do produkcji. Zespół zaczął uruchamianie nowej aplikacji mikroserwisowej w najbardziej krytycznym miesiącu dla biznesu, powodując absolutny chaos i konieczność wycofania się do pierwotnego monolitu.

Ten rodzaj migracji przysparza mikroserwisom złej sławy. Niewiele firm może sobie pozwolić na luksus zamrożenia funkcjonalności na kilka miesięcy, a także na uruchomienie nowej architektury. Mimo że zestaw przypadków jest niewielki, najbardziej udane migracje do mikroserwisów, które obserwowaliśmy, były fragmentaryczne, równoważąc wizję architektoniczną z potrzebami biznesowymi, priorytetami i ograniczeniami zasobowymi. Chociaż potrwa to dłużej i będzie wymagać więcej wysiłku inżynierskiego, miejmy nadzieję, że nigdy się nie zdarzy, że nasz zespół będzie wspominany w opowieściach ku przestrodze!