Architektura mikroserwisów i wielozespołowe piekło?

Wprowadzenie do odcinka i problematyki mikroserwisów

Odcinek 64. Architektura mikroserwisów i wielozespołowe piekło? Nawet 20% budżetu technologicznego w firmie zmarnowane na sprzątanie bałaganu po starych systemach. Nie na innowacje, nie na rozwój, na gaszenie pożarów, które same sobie wywołały. To efekt cyfrowego zadłużenia, czy też tak zwanego długu technologicznego, którego głównym źródłem są przestarzałe, często też monolityczne systemy. Trudne w utrzymaniu, wolne we wdrażaniu zmian, blokujące albo przynajmniej utrudniające skalowanie. Dlatego polski biznes konsekwentnie skręca w stronę mikroserwisów.

Mikroserwisy – realne korzyści i drugie dno

Według badania Microservices in the Enterprise, aż 80% deweloperów i menedżerów IT z dużych i średnich firm twierdzi, że mikroserwisy ułatwiają pracę wszystkim użytkownikom. I mają rację, ale to jest niestety tylko jedna strona medalu. Mikroserwisy mogą dać realne przyspieszenie, ale pod warunkiem, że są dobrze zaprojektowane i rozwijane w odpowiednim modelu. Dlaczego mikroserwisy, chociaż miały uprościć architekturę i przyspieszyć wdrożenia, czasem prowadzą do jeszcze większego chaosu? Zostań do końca, by dowiedzieć się o pułapkach, które czyhają, a często wychodzą na jaw dopiero wtedy, gdy przychodzi czas na integrację systemów i finalizację wdrożenia. Nie przedłużając, serdecznie zapraszam. Cześć, dzień dobry, z tej strony Grzegorz Tabor, a to jest podcast IT i biznes, gdzie jako dyrektor technologiczny pomagam przedsiębiorcom i menedżerom realizować projekty IT, które wspierają cele biznesowe skutecznie i w terminie. Jeśli napotykasz na swojej drodze wyzwania i potrzeby wsparcia twojego biznesu świadomie z użyciem technologii, ten podcast jest dla ciebie. Cześć, dzień dobry, witam was serdecznie w odcinku, w którym porozmawiamy sobie o tym, jak działać z mikroserwisami. Na start opowiedzmy sobie pokrótce, czym są te dwa trudne pojęcia, które wymieniłem, czyli monolity i mikroserwisy.

Monolit vs. mikroserwisy – porównanie na metaforze osiedla

Wyobraźmy sobie takie małe osiedle, na którym jest jeden duży dom. Duży dom, gdzie wszystko się dzieje, mamy kuchnię, łazienkę, różne pokoje i w tym domu też pracują różne osoby zdalnie. Jest to rodzina z dziećmi, mają wszystko czego im potrzeba, generalnie wszystko działa sprawnie w ich życiu. Te dzieci zaczynają dorastać, mieć nowe potrzeby, potem okazuje się, że są już dorosłe, zakładają swoje rodziny, rozbudowują się znowu ich potrzeby. No i w skrócie potrzeba więcej miejsca, więcej możliwości nowych rzeczy, więc budują swoje kolejne domy. I potrzeba kolejnych domów, które będą lepiej dopasowane do tych konkretnych osób, tych konkretnych nowych rodzin. No i w ten oto sposób powstaje nam osiedle domów. I teraz ta sytuacja pierwsza, kiedy mieliśmy jeden dom, który służył wszystkim jako całej rodzinie, to jest w pewnym sensie właśnie monolit. Czyli taka sytuacja, w której wszystkie odpowiedzialności, wszystkie kwestie, które się dzieją w naszym życiu biznesowo-technicznym, czy też w tym wypadku rodzinnym, są w jednym konkretnym miejscu. Ale kiedy nasza rodzina rozbudowuje się, analogicznie nasz biznes rośnie, wtedy potrzeba kolejnych domów, gdzie możemy mieć też kolejne odpowiedzialności i funkcjonalności zaopiekowane. Tutaj właśnie analogia do tego osiedla.

Outsourcing mikroserwisów do wyspecjalizowanych zespołów

No i teraz coraz częściej poszczególne mikroserwisy, o których tutaj sobie rozmawiamy, tworzą różne firmy zewnętrzne. I to nie jest przypadek. Firmy świadomie korzystają z zespołów wyspecjalizowanych w konkretnych typach rozwiązań. Czyli często jest np. wdrożony mikroserwis do zarządzania magazynem, czyli system klasy WMS. Trafia do z reguły firmy, która od lat wdraża systemy tego typu właśnie np. WMS-y w branży, czy to produkcyjnej, czy dystrybucyjnej. Z kolei moduł np. do obsługi ERPA powierza się zespołowi znającemu specyfikę procesów produkcyjnych, czy jakichkolwiek innych, gdzie tego ERPA chcemy wdrożyć i w ogóle specyfikę planowania zasobów. Te różne specjalizacje sprawiają, że wdrożenia w teorii są szybsze, bardziej dopasowane i mniej ryzykowne. Zamiast uczyć się od zera, każdy robi to, na czym zna się najlepiej. To przyspiesza całą pracę i przyspiesza rozwój biznesu, ale oczywiście ma też swoją cenę. Każdy mikroserwis to kolejny punkt, który trzeba zintegrować z całością. Im więcej wyspecjalizowanych zespołów, tym więcej zależności i większe wyzwania w koordynacji technicznej i biznesowej. Więc zanim w ogóle pomyślimy o wdrożeniu kilku zespołów pracujących równolegle nad kilkoma projektami, musimy mieć solidną roadmapę i przemyślaną architekturę systemu.

Dezintegracja architektury przy zbyt wczesnym wdrożeniu mikroserwisów

Odwołując się do tego porównania z początkłości odcinka, wyobraźmy sobie, że od razu tą taką naszą świeżą rodzinę, gdzie dzieci jeszcze dorastają, są nastolatkami, od razu przekładamy, że tak powiem w cudzysłowie, do różnych domów. No i to by powodowało, że niekoniecznie ta rodzina dobrze by się ze sobą komunikowała, nie spędzałaby ze sobą czasu, co by powodowało, że być może szłaby w złym kierunku. I trochę też tak jest z systemami, to znaczy jeżeli te mikroserwisy zdarzy się na zbyt wczesnym etapie, to często się to okazuje takim wydatkiem, jak ja to mówię, na zasadzie strzelania z armaty do muchy, gdzie nie potrzebujemy jeszcze tego do skalowania, nie potrzebujemy tego do rozwoju biznesu.

Modularny monolit – elastyczna alternatywa na start

Więc to nie jest tak, że monolit jest zawsze zły i niedobry, absolutnie nie. Bardzo często jest to bardzo dobre rozwiązanie, szczególnie na start, a już w ogóle modularny monolit, czyli taka sytuacja, w której tak jakbyśmy sobie z domu chcieli w pewnym momencie kuchnię odłączyć i zrobić z niej taki osobny budynek i możemy to wtedy zrobić w łatwy sposób, to w taki właśnie sposób można przygotowywać też architekturę systemów i takie modularne monolity budować. Ale w tym odcinku na tym modularnym monolicie, czy w ogóle na zwykłym monolicie nie będziemy się aż tak mocno skupiać. Skupimy się na tym mikroserwisie, czyli na tej sytuacji, kiedy rodzina już dorosła, czy osoby, członkowie tej rodziny dorosłe mają swoje domy i mamy takie osiedle rodzinnych domków.

Znaczenie wspólnej architektury i roadmapy projektowej

No i teraz, kiedy już wracamy do tematu roadmap’y, przemyślanej architektury systemu, to bierzmy pod uwagę to, że jest to w pewnym sensie klucz, by każdy zespół wiedział dokąd zmierza całość, czyli wszelkie te rozwiązania, które mamy w ramach takiej architektury zaplanowane, jak praca tego konkretnego zespołu pracujący nad jednym z tych domków, jednym z tych projektów faktycznie wpisuje się w całość. Nie może być tak, że dany zespół, czy każdy w ogóle z nich działa w kompletnej izolacji. Zespoły muszą mieć tutaj określone jasno cele biznesowe i klarowną, wspólną architekturę, ale w taki sposób, żeby rozumieli z którymi innymi systemami ich mikroserwis będzie się łączył. Muszą wiedzieć kiedy i z kim współpracować, np. podczas testów integracyjnych, czy w ogóle podczas wdrożeń.

Ryzyko braku koordynacji między mikroserwisami

Teraz wyobraźmy sobie sytuację, kiedy zespół odpowiedzialny za mikroserwis, np. obsługujący magazyn, zmienia sposób zarządzania stanami magazynowymi, ale nie informuje o tym np. zespołu pracującego nad ERP-em. Efekt? No totalna masakra. No i oczywiście problemy podczas integracji, które skutkują opóźnieniami i dodatkowymi kosztami. Najważniejsze tutaj jest precyzyjne rozgraniczenie odpowiedzialności. Wobec tego powstaje bardzo często efekt ping-ponga, gdzie problemy są zrzucane między zespołami, a klient zostaje zdezorientowany. No i każdy musi wtedy wiedzieć, która część jest moja, za którą ja odpowiadam, ale jak ona też wpływa na całość wszystkich systemów, jakie działają w ramach architektury u danego klienta w danym biznesie. W przeciwnym razie, owy klient, zamiast uzyskać szybką pomoc, trafia na kolejne etapy procedur, a czas reakcji i dojście do sedna często wydłuża się.

Efekt ping-ponga między zespołami – przykład z życia

Mieliśmy nawet taką ostatnią sytuację, która świetnie pokazuje, jak ważne jest to jasne rozgraniczenie odpowiedzialności. W firmie, dla której projektujemy rozwiązanie, które ma na celu połączyć obecnie działające systemy, które zostały notabene przełączone na rynek polski z rynku zagranicznego, mają wspomóc te systemy w rozliczeniach różnych kwestii związanych z polskim prawem podatkowym, wystawianiem faktur, tego typu rzeczy. Działa tutaj jeszcze jedna firma, która pracuje też nad tym wdrożeniem, ale od strony właśnie tej zagranicznej, tego systemu, który tutaj do Polski jest przełączany. No i zadzwoniła do nas pani z działu księgowości, którą skierowała właśnie do nas ta druga firma, z pytaniem o szczegóły dotyczące informacji na dokumencie, który był generowany, uwaga, nie przez naszą aplikację, tylko przez tą taką główną, główną aplikację, która obsługuje cały proces i za którą odpowiada ta druga firma. I teraz zobaczcie, po pierwsze, gdybyśmy z jednej strony nie wiedzieli w ogóle jak to wszystko funkcjonuje w ramach architektury klienta, to absolutnie nie bylibyśmy w stanie pomóc tej pani jakkolwiek, przynajmniej ją skierować we właściwe miejsce i coś poodpowiedzieć, jak porozmawiać z tą drugą firmą. A po drugie, zobaczcie jaki paradoks, że tak naprawdę my odpowiadający za swoją część musieliśmy wskazywać i pomagać tej drugiej firmie z zagranicy w tym, żeby faktycznie rozwiązać problem, który powstawał, który był właśnie na dokumencie generowany po stronie tamtej firmy, tamtej aplikacji. Nie mówię tego dlatego, żeby nas jakoś turbo pochwalić, tylko bardziej chodzi mi o to, że tym wszystkim to naprawdę pokazuje, że takie drobne rzeczy, typu właśnie to, że na dokumencie są niewłaściwe jakieś informacje, a które powinny być i które były omawiane z tamtą firmą, tylko zmienił się project manager, który nie przekazał informacji. Zwyczajny taki błąd ludzki spowodował pewne zamieszanie, chaos, które trzeba było ogarnąć. Teraz gdybyśmy nie mieli tutaj sprawnej komunikacji zarówno na linii my, pani księgowa, jak i pani księgowa, ten drugi zespół i my, ten drugi zespół, to nie wyjaśnilibyśmy tej sprawy szybko.

Potrzeba roli CTO lub architekta integrującego zespoły

I teraz taki model, generalnie współpracy, gdzie te zespoły ze sobą faktycznie rozmawiają, rozmawiają, a nie tylko się tak komunikują w formie ping-ponga, jest trudny do wprowadzenia, bardzo często jest wręcz niemożliwy, kiedy nie ma się na pokładzie osoby, która myśli o tym całym architektonicznym, wysokopoziomowym, nie ma takiego architektonicznego, wysokopoziomowego podejścia i nie patrzy na całość tak strategicznie, nazwijmy to, czyli nie łączy tych różnych zespołów i nie nadaje priorytetom też, jeżeli chodzi o wdrożenie. Czyli takiego kogoś, kto będzie pełnił rolę takiego łącznika, koordynatora, dbając o to, by wszystko współgrało sprawnie i żeby w tych systemach, które są wdrażane jednocześnie i jednocześnie wśród tych zespołów, które za te systemy odpowiadają. No bo teraz tutaj też dochodzi czynnik ludzki, to znaczy, no każdy dba o swoje podwórko, więc wiadomym jest, że jeżeli te odpowiedzialności sobie odpowiednio podzielimy, no to każdy będzie o swoje podwórko faktycznie dbał. Natomiast jeżeli źle podzielimy te odpowiedzialności, no to każdy będzie się jednak przepychał zespół między sobą, że to nie jest jego rola, nie jest jego odpowiedzialność. Dlatego tak ważne jest, by to dobrze wyznaczyć już na samym początku tego typu współpracy. No i dlatego też coraz więcej firm, kiedy nie ma takiej osoby w organizacji, decyduje się na współpracę z kimś w roli np. CTO, czyli takiego dyrektora IT, dyrektora technologicznego, czy architekta rozwiązań, czy przynajmniej technicznego product ownera. I tego typu osoba to jest inwestycja w spójność, szybkość wdrożeń, no i przede wszystkim w jakość finalnego rozwiązania.

Kiedy mikroserwisy nie są dla każdego

No i to jest też powód, dla którego mikroserwisy nie będą dla każdej firmy. Oczywiście są one elastyczne, są skalowalne, pozwalają działać szybciej, no bo siłą rzeczy, jeżeli pracuje kilka ekip budowlanych przy różnych domach, które mogą być zupełnie osobne, a połączone są tylko jakimiś podziemnymi korytarzami, no to podobnie tutaj będzie, jeżeli chodzi o te mikroserwisy, że te prace zwyczajnie można realizować równomiernie, czy równolegle bardziej, bo równomiernie to niekoniecznie, ale równolegle przynajmniej, w każdym z tych systemów, przynajmniej oczywiście do pewnego etapu, kiedy je trzeba zintegrować, czyli właśnie wybudować te tunele wewnętrzne. No i teraz te mikroserwisy z pewnością wymagają też dojrzałości takiej organizacyjnej i technicznej, bo bez niej mogą zamienić się w taką cyfrową dżunglę, gdzie każdy mikroserwis będzie w pewnym sensie ciągnął swoją stronę, czy bardziej zespół odpowiadający za dany mikroserwis, a ta firma zamiast tak naprawdę zyskać na elastyczności, zgubi się w tej własnej architekturze. Dlatego, jeśli myślisz o mikroserwisach, a przede wszystkim o współpracy z kilkoma firmami nad tymi mikroserwisami, zadbaj o te rzeczy, o których za chwilkę Ci opowiem. I tutaj o tym, jak sprawnie łączyć zespoły IT wewnętrzne i zewnętrzne mówiłem też w odcinku 46, więc jeżeli masz taką sytuację, że masz np. zespół IT wewnętrzny i chcesz dodatkowo włączyć zespół zewnętrzny, to w odcinku 46 opowiadam w jaki sposób można do tego podejść.

5 zasad skutecznego zarządzania architekturą mikroserwisów

A teraz wracając do tematu mikroserwisów.

1. Po pierwsze, upewnij się, że masz przemyślaną wizję architektury.

Mikroserwisy nie powinny być traktowane po prostu jak zwykłe małe aplikacje, tylko oprócz tego jako elementy większej układanki. Każdy mikroserwis musi mieć jasne miejsce w systemie, określony zakres odpowiedzialności, takiej techniczno-funkcjonalnej i zaplanowane też takie punkty styku, punkty integracji. Brak wspólnej wizji będzie prowadził do sytuacji, w której zespoły zdublują funkcjonalności, stworzą być może konkurujące ze sobą rozwiązania, czy co gorsza podwoją odpowiedzialności i wówczas cała architektura zacznie przypominać taki ala patchwork, czego absolutnie powinniście unikać.

2. Po drugie, zadbaj o odpowiednią koordynację i rozdzielenie odpowiedzialności, czyli kiedy nad systemem będzie pracowało wiele zespołów, czy nawet to będą zewnętrzne firmy, to ktoś musi zarządzać komunikacją i takim wspólnym planem działania. Każdy zespół powinien tutaj wiedzieć, co dokładnie jest zrealizowane, jak ten dany mikroserwis, nad którym ten zespół pracuje, wpływa na pracę innych zespołów pracujących nad innymi mikroserwisami, kto i w jaki sposób będzie realizował testy integracyjne i kiedy będzie się trzeba zsynchronizować z tymi innymi zespołami. Po trzecie, myśl nie tylko o kodzie, ale też o procesach dokumentacji i komunikacji, bo tutaj właśnie te ludzkie rzeczy najczęściej wykładają projekty, a niekoniecznie sam kod, czyli brak dobrego obiegu informacji, niejasny flow wdrożeń, nieaktualne diagramy w dokumentacji, to wszystko może prowadzić do dużych nieporozumień.

3. I to, co jest ważne, to to, żeby ustalić sobie wspólne rytuały, na przykład taki cotygodniowy, codwutygodniowy call, taki crosszespołowy, w ramach którego przedstawiciel każdego z zespołów, przynajmniej jeden per dany mikroserwis, jeżeli tak to jest podzielone w firmie, że za każdy mikroserwis odpowiada inny zespół, to przynajmniej jedna osoba z danego zespołu pojawi się na takim callu, opowie pokrótce, co zostało wdrożone, nad czym są prowadzone prace i dzięki temu pozwoli to też potwierdzić, gdzie ewentualnie jeszcze jakieś punkty styku mogą się pojawić na linii tych różnych mikroserwisów. Warto wprowadzić też wspólną taką tablicę z zależnościami między mikroserwisami i tam dodawać potencjalne ryzyka, potrzeby, czy, no głównie te kwestie tak naprawdę, potrzeby i ryzyka, tak żeby też właśnie o nich w ramach takiego na przykład cotygodniowego, czy codwutygodniowego calla można było porozmawiać. Po trzecie warto mieć też, że opracowany scenariusz, testów integracyjnych i tak też testować wdrożenie, zanim trafiono na produkcję, czyli nie tylko z perspektywy danego mikroserwisu, ale też z perspektywy całości, jak dana zmiana wpływa na pełne flow działania systemu z różnymi danymi, które przez niego przechodzą i też w każdej większej zmianie warto pisać część logi i informować zespoły zależne, ale to wynika też nam z testów integracyjnych, które powinny być w taki sposób właśnie organizowane.

4. Po czwarte wybierz partnera, który potrafi współpracować z innymi. W projektach mikroserwisowych nie chodzi tylko o to, żeby dowieźć swój kawałek kodu, tylko chodzi o takie wspólne patrzenie na cel biznesowy, ale jednocześnie skupianie się na swoim kawałku, który na ten cel biznesowy wpływać będzie. To oznacza współpracę, koordynację działań i elastyczność i nie każdy zespół to potrafi.

5. Szukaj partnera, który myśli systemowo, a nie tylko o swoje module. Rozumie zależności między mikroserwisami i potrafi o nie zadbać. Działa w pełni transparentnie, bo bez tego nie ma szans działać nad mikroserwisami w kilka różnych zespołów i potrafi rozmawiać, także z innymi firmami i zespołami biorącymi udział w projekcie, bo okazuje się, że w IT to wcale nie jest tak często spotykana sytuacja, że zespoły jeszcze z różnych firm potrafią się ze sobą dobrze skomunikować. I po piątem ustaw wspólne narzędzia i standardy. Każdy zespół może mieć swoje preferencje technologiczne, ale w projekcie wielozespołowym brak ujednolicenia z reguły kończy się źle.

Jak będzie wyglądać proces testów integracyjnych? Jak dokumentujemy zmiany, na przykład w API? Kto i kiedy zatwierdza zmiany w kontraktach między mikroserwisami? Jak wygląda przekazywanie informacji o błędach? Wspólne tablice z zadaniami, wykorzystywanie tego samego narzędzia do trzymania tablicy, na przykład JIR-y. Centralna dokumentacja techniczna, na przykład na confluence. Wspólne flow i ICD i jeden kanał na przykład do zgłaszania i rozmawiania o problemach to rzeczy, które z pewnością sprawią, że zwyczajnie łatwiej będzie się współpracowało wszystkim zespołom ze sobą jednocześnie, jeżeli faktycznie w taki sposób do tego będziemy podchodzić, że narzędzia będą wspólne.

Podsumowanie i zaproszenie do kolejnego odcinka

No i to jest takie pięć głównych punktów, na które zwróciłbym tutaj uwagę. A teraz, gdy już wiesz, że mikroserwisy to nie jest tylko technologia, ale też sposób na zwinne i skalowalne budowanie rozwiązań dopasowanych do biznesu i to do takiego biznesu, który już jest na tym etapie, że potrzebuje faktycznie tej skalowalności i szybszego osiągania swoich celów biznesowych, to zapraszam Cię też na kolejny odcinek. Opowiem w nim o tym, jak jeden z naszych klientów zaplanował współpracę z wieloma zespołami i dlaczego jego podejście może sprawdzić się również u Ciebie. I subskrybuj ten kanał, żeby nie przegapić kolejnego odcinka. A ja dziękuję bardzo za wysłuchanie dzisiejszego, 64. odcinka podcastu IT Business i do usłyszenia za tydzień.

Cześć!