Mikroserwisy w akcji. Отсутствует

      UKIERUNKOWANIE

      Wreszcie, bardzo ważne jest, aby swoje wysiłki na rzecz rozwoju ukierunkować w sposób właściwy. Powinniśmy dążyć do uporządkowania swoich usług, a więc i swoich zespołów, zgodnie z koncepcjami biznesowymi – doprowadzi to do większej spójności.

      Aby zrozumieć, dlaczego jest to ważne, rozważmy alternatywę. Wiele tradycyjnych SOA wdraża warstwy techniczne aplikacji oddzielnie: interfejs użytkownika, logikę biznesową, integrację, dane. Na rysunku 1.4 porównano architekturę SOA i mikroserwisową.

      Takie użycie horyzontalnej dekompozycji w SOA jest problematyczne, ponieważ spójna funkcjonalność zostaje rozproszona w wielu systemach. Nowe funkcjonalności mogą wymagać skoordynowanych wydań dla wielu usług i mogą być niedopuszczalnie połączone z innymi na tym samym abstrakcyjnym poziomie technicznym.

      Z kolei architektura mikroserwisowa powinna być zorientowana na pionowy rozkład; każda usługa powinna być dostosowana do jednej funkcjonalności biznesowej, obejmując wszystkie odpowiednie warstwy techniczne.

      Powinniśmy także pamiętać o konsumentach swoich usług. Aby zapewnić stabilny system, musimy mieć pewność, że rozwój odbywa się spokojnie i zachowuje kompatybilność wsteczną – jawnie lub przez uruchamianie wielu wersji usługi – aby nie zmuszać innych zespołów do aktualizacji lub zerwania skomplikowanych interakcji między usługami.

      Praca zgodnie z tymi pięcioma zasadami pomoże nam dobrze rozwinąć mikroserwisy, prowadząc do systemów, które są wysoce podatne na zmiany oraz skalowalne i stabilne.

      Rysunek 1.4. SOA vs. architektura mikroserwisowa

      1.1.3. Kto używa mikroserwisów?

      Wiele firm pomyślnie zbudowało i wdrożyło mikroserwisy w różnych obszarach: w mediach (The Guardian), dystrybucji treści (SoundCloud, Netflix), transporcie i logistyce (Hailo, Uber), e-commerce (Amazon, Gilt, Zalando), bankowości (Monzo) i mediach społecznościowych (Twitter).

      Większość z tych firm przyjęła podejście monolityczne2. Zaczęto od zbudowania pojedynczej dużej aplikacji, a następnie stopniowo przenoszono ją do postaci mikroserwisów w odpowiedzi na pojawiające się presje. Przedstawiono je w tabeli 1.1.

      Tabela 1.1. Presje powodujące rozwój systemu informatycznego

      Na przykład firma Hailo chciała rozszerzyć działalność na skalę międzynarodową, co byłoby wyzwaniem dla ich oryginalnej architektury, ale również zwiększyłoby tempo dostarczania funkcjonalności. SoundCloud chciał być bardziej produktywny, ponieważ powstrzymywała go złożoność ich pierwotnej monolitycznej aplikacji. Czasami zmiana zbiegała się ze zmianą priorytetu biznesowego – Netflix przeszedł z fizycznej dystrybucji DVD na streaming treści. Niektóre z tych firm całkowicie wycofały już swój pierwotny monolit. Ale dla wielu jest to proces ciągły, z monolitem otoczonym konstelacją mniejszych usług.

      Gdy architektura mikroserwisowa została spopularyzowana – i pierwsi użytkownicy udostępnili źródła, tworzyli blogi oraz prezentowali praktyki, które okazały się dla nich skuteczne – zespoły coraz częściej zaczęły tworzyć nowatorskie projekty przy użyciu mikroserwisów zamiast budować najpierw pojedynczą aplikację. Na przykład Monzo użył mikroserwisów jako części swojej misji budowania lepszego i bardziej skalowalnego banku.

      1.1.4. Dlaczego mikroserwisy to dobry wybór?

      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.

---

Скачать книгу