menu

// MIKROSERWISY – SZYBKA ODPOWIEDŹ NA ZMIANY RYNKOWE

Rozmowa z DAVE’EM MORRISEM, Delivery Director w REWE Group i  Head of Engineering w REWE Digital

//JAKIE SĄ PODSTAWOWE ZALETY ARCHITEKTURY MIKROSERWISOWEJ ZARÓWNO Z PUNKTU WIDZENIA IT JAK I KORZYŚCI, JAKIE IT MOŻE WNIEŚĆ DO BIZNESU?
Przede wszystkim warto zauważyć, że zarówno mikroserwisy, jak i podejście monolityczne, są pełnowartościowymi rodzajami architektury mającymi swoje zalety i wady. Oprócz zmiany sposobu myślenia, zasadniczą różnicę widzę w przesunięciu złożoności z rozwoju do eksploatacji. Mikroserwisy są łatwiejsze w rozwoju i zmianie, jednak trudniej je wdrożyć i nimi zarządzać. W związku z tym, im lepsze narzędzia, większą wydajność i spójność ma się w testowaniu, wdrażaniu, wycofywaniu (rollback), logowaniu i innych kluczowych obszarach, tym cały proces będzie przebiegał płynniej i łatwiej. Szczerze mówiąc, chociaż zastrzeżenia dotyczące zarządzania mikroserwisami są uzasadnione, to sądzę jednak, że nieco się je „wyolbrzymia”.

Wybór mikroserwisów jest napędzany przez zmieniające się środowiska biznesowe. Jesteśmy bezustannie konfrontowani ze wstrząsami rynku i innowacjami. Nowe technologie otwierają nowe możliwości. Mikroserwisy umożliwiają dokonywanie w sposób ciągły niewielkich zmian, adaptacji i readaptacji modelu biznesowego. Zmiany te mogą dotyczyć funkcjonalności lub skalowalności – albo obu tych kwestii. Mogę niezależnie skalować dowolną z naszych usług, aby sprostać zwiększonej liczbie zleceń bez konieczności „dokładania kolejnego serwera”.

CZY MIKROSERWISY ZAWSZE OZNACZAJĄ CHMURĘ? CO BRAĆ POD UWAGĘ, PODEJMUJĄC DECYZJĘ O TYM, KTÓRE MIKROSERWISY WDRAŻAĆ W CHMURZE, A KTÓRE W MODELU ON-PREM?
Mikroserwisy nie zawsze są tożsame z Chmurą. Jest ona jedynie jedną z opcji wdrożeniowych. Prawdą jest, że istnieje powiązanie między zaletami Chmury i mikroserwisów. Mamy jednak do czynienia z korelacją, a nie związkiem przyczynowym. Można jednak również wdrożyć mikroserwisy w oparciu o model on-prem i istnieje wiele dobrych narzędzi pozwalających na zrobienie tego w obu środowiskach.

Gdy podjąłeś już decyzję o korzystaniu z mikroserwisów, możesz dodatkowo zapytać: „Czy jako firma przechodzimy do Chmury, czy nie?”. Same rozważania na ten temat nie są tutaj kluczowe (zależą od specyfiki danego biznesu oraz kwestii kosztów, bezpieczeństwa i danych). Najważniejsze, aby podjąć decyzję odpowiednio wcześnie i się jej trzymać. Ma ona pewien wpływ na rozwój, wdrożenie i wybór potrzebnych narzędzi, dlatego należy to ustalić na wczesnym etapie rozwoju usług.

JAK PODEJŚCIE API-FIRST ZMIENIA SPOSÓB MYŚLENIA O ŚRODOWISKU IT I INTEGRACJACH? CZY JEST W TYM RÓWNIEŻ WARTOŚĆ BIZNESOWA?
Myślę, że podejście API-first jest czymś, z czym nadal próbujemy się uporać. Wymusza ono dyscyplinę w twoim ekosystemie. Oznacza to, że zanim stworzysz swoje mikroserwisy, musisz zaprojektować publiczne API, które chcesz udostępnić. Dzięki temu będziesz mógł przedyskutować z interesariuszami cel i funkcjonalność udostępnianych funkcji zanim, kodując, znajdziesz się „w czarnej dziurze”, z której nie ma ucieczki. Ta interakcja pozwala budować historyjki użytkowników i atrapy usług, które tworzysz i zmieniasz. Dzięki temu zespoły mogą pracować równolegle.

API są zwykle: A) rozwijane po namyśle i/lub B) utrzymywane równolegle do rozwoju innych funkcjonalności. W gruncie rzeczy sądzę, że nadal poruszamy się w obszarze opcji „B)” w związku z presją na reagowanie na zmiany rynkowe i bycie na bieżąco z innowacjami.

CZY ZMIANA SPOSOBU MYŚLENIA O ROZWIĄZANIACH KOMERCYJNYCH – OD MONOLITU DO MIKROSERWISÓW – MA WPŁYW NA TO, JAK POWINNIŚMY POSTRZEGAĆ ZESPÓŁ PROJEKTOWY I KULTURĘ ORGANIZACJI?
Tak! Mikroserwisy są samowystarczalnymi wszechświatami (jako produkty). Zazwyczaj posiada je zespół, który pracuje równolegle nad swoją częścią wielu inicjatyw (projektów). Niektóre z nich są duże, inne małe. Zespoły rozwijają, wdrażają i URUCHAMIAJĄ (!) swoje usługi. W związku z tym nie ma potrzeby posiadania zespołu wsparcia aplikacji (Application Support) lub jest ona bardzo niewielka, by utrzymywać aplikację w weekend!

Monolitów nie da się tak podzielić, więc zwykle zespoły są zorganizowane pod kątem projektu. Często pracują one nad jednym projektem naraz, przekazując jedną dużą zmianę na Produkcję, gdzie zespoły wsparcia (Support i Application Support) układają elementy całej układanki. Oczywiście jest to opis czysto komiksowy, bo da się pracować na oba sposoby – jednak rozumiecie, o co mi chodzi.

JAK MOŻEMY SIĘ PRZYGOTOWAĆ NA OKRESY ZWIĘKSZONEGO RUCHU? CO ONE OZNACZAJĄ DLA WYDAJNOŚCI SYSTEMU, INFRASTRUKTURY, WSPARCIA ZESPOŁU PROJEKTOWEGO ITP.?
Architektura mikroserwisów oferuje właściwie gotowe rozwiązanie. Możemy reagować na skoki ruchu, uruchamiając dodatkowe usługi potrzebne do obsługi zwiększonego obciążenia. W tym sensie jesteśmy zabezpieczeni, ponieważ nie musimy „planować” skoków obciążenia. Po prostu reagujemy wtedy, kiedy musimy, czując się bezpiecznie, bo wiemy, że damy sobie radę.

HEADLESS – MÓWI O TYM RYNEK, DOSTAWCY NARZĘDZI COMMERCE I CX. CZY STOI ZA TYM PRAWDZIWA WARTOŚĆ, CZY JEST TO OBECNIE BARDZIEJ BUZZWORD?
Och, sądzę, że jest to coś więcej niż tylko buzzword. Podobnie jednak jak wiele rzeczy, może być ono nadużywane. Headless dotyczy po prostu jasnego rozgraniczenia zagadnień na te dotyczące klienta (i unikalności urządzenia) oraz serwera (gdzie znajduje się cała logika i wszystkie dane). Jeśli uda się osiągnąć pełen podział, nie ma potrzeby, aby urządzenie mobilne miało swoją bazę danych dla X albo Y, albo żeby kanał Web widział inny status zamówienia niż agent obsługi klienta. Jest tu zatem prawdziwa korzyść. Twardym orzechem do zgryzienia jest tutaj CMS. Moim zdaniem mamy jeszcze sporo do zrobienia w tym temacie.

NA KONIEC: JAKIE SĄ TRZY GŁÓWNE RADY DLA IT W ORGANIZACJACH, KTÓRE PLANUJĄ WDROŻENIE ARCHITEKTURY MIKROSERWISOWEJ W SYSTEMACH COMMERCE?

  1. Podejmujcie wcześnie decyzje o środowisku wdrażania i działania, w szczególności w zakresie chmury, wyboru narzędzi, orkiestracji. Zajmijcie się tym na wczesnym etapie, jeśli nie w pierwszej kolejności.
  2. Dążcie do spójnych standardów w obszarze kluczowych zagadnień, w szczególności logowania zdarzeń i monitoringu.
  3. Zamiast organizować się pod kątem projektu, stawajcie się zwinną samoorganizującą się grupą, która rozwija produkt.

A tak poza tym – dobrze się bawcie!

// Partnerzy