Mikroserwisy w akcji. Отсутствует
2.1. Czynniki, które należy wziąć pod uwagę przy wyborze architektury mikroserwisowej
2.2.1. Ryzyko i inercja w oprogramowaniu finansowym
Przyjrzyjmy się, jak tworzą oprogramowanie konkurenci SimpleBanku. Większość banków nie jest nad kreską pod względem innowacji technologicznych. Występują tam elementy inercji, co jest typowe dla większych firm, chociaż nie jest to unikalne dla branży finansowej. Dwa główne czynniki ograniczające innowacyjność i elastyczność to:
■ awersja do ryzyka – firmy finansowe podlegają silnemu nadzorowi i mają tendencję do budowania odgórnych systemów kontroli zmian w celu uniknięcia ryzyka przez ograniczenie częstości i wpływu zmian oprogramowania;
■ oparcie się na starszych złożonych systemach – większość krytycznych systemów bankowych zostało zbudowanych przed 1970 r.; ponadto fuzje, przejęcia i outsourcing doprowadziły do powstania słabo zintegrowanych i dość zacofanych systemów oprogramowania.
Jednak ograniczanie zmian i poleganie na istniejących systemach nie zapobiegło problemom z oprogramowaniem, które mocno dotknęły klientów lub firmy finansowe. W 2014 roku The Royal Bank of Scotland został ukarany grzywną w wysokości 56 mln funtów, gdy przestój w działaniu spowodował problemy z płatnościami 6,5 mln klientów. To jeden z najwyższych wydatków spośród ponad 250 mln funtów, które co roku były wydawane na systemy IT.
Takie podejście nie doprowadziło również do lepszych produktów. Startupy w zakresie technologii finansowych, takie jak Monzo i Transferwise, budują funkcjonalności w tempie, o którym większość banków może tylko pomarzyć.
2.2.2. Zmniejszanie tarć i zapewnienie wartości dodanej
Czy możemy zrobić coś lepszego? Pod każdym względem branża bankowa jest złożoną i konkurencyjną dziedziną. Bank musi być zarówno sprawny, jak i elastyczny, nawet gdy okres eksploatacji systemu bankowego mierzy się w dziesięcioleciach. Rosnące rozmiary monolitycznej aplikacji są sprzeczne z tym celem. Jeśli bank chce wprowadzić nowy produkt, nie powinien być hamowany przez wcześniej wprowadzone wdrożenia5 lub wymagać nadmiernego wysiłku i inwestycji, aby zapobiec regresji w istniejącej funkcjonalności.
Dobrze zaprojektowana architektura mikroserwisowa może rozwiązać te problemy. Jak już wspomnieliśmy, ten typ architektury pozwala uniknąć wielu cech, które w monolitycznych zastosowaniach spowalniają rozwój. Poszczególne zespoły mogą iść naprzód ze zwiększoną pewnością, ponieważ:
■ cykle zmian są oddzielone między zespołami;
■ interakcja między współpracującymi komponentami jest ściśle określona;
■ ciągłe dostarczanie małych, izolowanych zmian ogranicza ryzyko pogorszenia funkcjonalności.
Czynniki te zmniejszają tarcie w rozwoju złożonego systemu, ale zachowują elastyczność. W związku z tym zmniejszają ryzyko, nie dławiąc innowacji przez biurokrację.
Nie jest to tylko rozwiązanie krótkoterminowe. Mikroserwisy wspierają zespoły inżynierów w dostarczaniu wartości dodanej w całym cyklu życia aplikacji dzięki umieszczeniu naturalnych granic w koncepcyjnej i wdrożeniowej złożoności poszczególnych komponentów.
2.3. Budowanie nowej funkcjonalności
Teraz, gdy ustaliliśmy, że mikroserwisy są dobrym wyborem dla SimpleBanku, przyjrzyjmy się, jak można wykorzystać je do budowy nowych funkcjonalności. Stworzenie prostej wersji produktu jest świetnym pierwszym krokiem do zapewnienia, że zespół rozumie ograniczenia i wymagania stylu mikroserwisowego. Zaczniemy od zbadania jednej z funkcjonalności, które SimpleBank musi zbudować, oraz wyborów projektowych, których zespół dokona, pracując w cyklu życia zilustrowanym w rozdziale 1 (rys. 2.2).
Rysunek 2.2. Kluczowe powtarzane etapy – projekt, wdrożenie, obserwacja – w cyklu życia mikroserwisu
W rozdziale 1 omówiliśmy, w jaki sposób usługi mogą współpracować, aby złożyć zlecenie sprzedaży. Przegląd tego procesu przedstawiono na rysunku 2.3.
Rysunek 2.3. Proces składania zlecenia sprzedaży aktywów z rachunku w SimpleBanku
Spójrzmy, jak podejść do budowania tej funkcjonalności. Musimy odpowiedzieć na kilka pytań:
■ Jakie usługi potrzebujemy zbudować?
■ W jaki sposób te usługi będą ze sobą współpracować?
■ W jaki sposób udostępnią swoją funkcjonalność dla świata?
Pytania te mogą być podobne do tych, które możemy sobie zadać przy projektowaniu funkcjonalności w monolitycznej aplikacji, ale mają różne implikacje. Na przykład wysiłek wymagany do wdrożenia nowej usługi jest większy niż stworzenie nowego modułu. W trakcie określania zakresu mikroserwisów musimy być pewni, że korzyści wynikające z dzielenia systemu nie zostaną zduszone przez dodatkową złożoność.
UWAGA Wraz z ewolucją aplikacji pytania te nabiorą dodatkowych wymiarów; później zastanowimy się również, czy dodać funkcjonalności do istniejących usług, czy wprowadzić podział usług; omówimy to w rozdziałach 4 i 5.
Jak już wspomnieliśmy, każda usługa powinna być odpowiedzialna za pojedynczą zdolność. Pierwszym krokiem będzie zidentyfikowanie różnych zdolności biznesowych, które chcemy wdrożyć, oraz relacji między tymi zdolnościami.
2.3.1. Identyfikacja mikroserwisów przez modelowanie domeny
Aby zidentyfikować oczekiwane zdolności biznesowe, musimy lepiej zrozumieć domenę, w której budujemy oprogramowanie. Zwykle jest to ciężka praca związana z tworzeniem produktu lub analizą biznesową: badania, prototypowanie oraz rozmowy z klientami, kolegami lub innymi użytkownikami końcowymi.
Zacznijmy od przeanalizowania przykładu składania zlecenia z rysunku 2.3. Jaką wartość chcemy dostarczyć? Patrząc ogólnie – klient chce móc składać zlecenia. Tak więc oczywistą zdolnością biznesową będzie możliwość przechowywania i zarządzania stanem tych zleceń. To jest nasz pierwszy kandydat na mikroserwis.
Kontynuując naszą eksplorację przykładu, możemy zidentyfikować inne funkcjonalności, które będzie musiała zaoferować aplikacja. Aby coś sprzedać, będziemy musieli to posiadać, a więc potrzebujemy sposobu reprezentowania bieżących zasobów klienta wynikających z transakcji, które nastąpiły na jego rachunku. Nasz system musi wysłać zamówienie do brokera – aplikacja musi mieć możliwość interakcji z tym podmiotem zewnętrznym. W rzeczywistości ta jedna funkcjonalność składania zlecenia sprzedaży będzie wymagać od aplikacji SimpleBank obsługi wszystkich następujących funkcjonalności:
■ rejestrowanie statusów i historii zleceń sprzedaży,
■ pobieranie opłat od klienta za złożenie zlecenia,
■ rejestrowanie transakcji na rachunku klienta,
■ składanie zlecenia na giełdzie,
■ wykonywanie wyceny udziałów i zleceń klienta
Nie oznacza to, że każda funkcjonalność będzie związana z jednym mikroserwisem. Musimy określić, które funkcjonalności są spójne – będą one ze sobą połączone. Na przykład transakcje wynikające ze zleceń będą
Do czego może to doprowadzić? Kiedyś spotkałem firmę produkującą oprogramowanie finansowe, która utrzymywała ponad 10 różnych monolitycznych baz kodów, a każda zawierała ponad 2 mln linii kodu!