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

Inżynierowie z SimpleBank uważają, że mikroserwisy to najlepszy wybór, pozwala bowiem poradzić sobie ze złożonością dziedziny i być elastycznym wobec złożonych i zmieniających się wymagań. Przewidują, że w miarę rozwoju działalności firmy mikroserwisy zmniejszą ryzyko zmian w oprogramowaniu, prowadząc do lepszego produktu i zadowolenia klientów.

Załóżmy na przykład, że trzeba będzie przetwarzać każdą transakcję kupna lub sprzedaży, aby określić skutki podatkowe. Jednak zasady podatkowe w każdym kraju są inne i często się zmieniają. W aplikacji monolitycznej musielibyśmy wprowadzić skoordynowane zmiany, w odpowiednim momencie wydania całej platformy, nawet jeśli chcielibyśmy wprowadzić te zmiany tylko w jednym kraju. W aplikacji mikroserwisowej możemy budować autonomiczne usługi obsługi podatków (zależne od kraju, rodzaju podatku, rodzaju rachunku) i wdrażać je niezależnie.

Czy SimpleBank dokonuje właściwego wyboru? Wybór architektury oprogramowania zawsze wiąże się z napięciami między pragmatyzmem a idealizmem – równoważeniem potrzeb produktu, presją wzrostu i możliwościami zespołu. Złe wybory mogą nie być natychmiast widoczne, ponieważ potrzeby systemu zmieniają się w czasie jego istnienia. W tabeli 2.1 przedstawiono czynniki, które należy wziąć pod uwagę przy wyborze mikroserwisów.

Korzystając z tych czynników, można ocenić, czy mikroserwisy pomogą w osiągnięciu wartości dodanej w obliczu rosnącej złożoności aplikacji.

Tabela 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.

5

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!