Cześć!

Tym razem w nietypowy dzień, z nietypowego miejsca do Ciebie piszę. Aktualnie jadę Flixbusem do Krakowa, a przede mną siedzi koleś i jedzie potem. To znaczy teraz, w zasadzie to nie zagłębiajmy się w to za bardzo. Czemu piszę do Ciebie w niedzielę i czemu z Flixbusa? Tak jak wspominałem we wczesniejszych mailingach jadę na konferencję SegFault, gdzie jutro zadebiutuję w roli prelegenta. Nie chcąc, więc stracić okazji do napisania z Tobą, piszę dzisiaj. Co do samej konferencji, to jest to dla mnie wydarzenie, bo niby już mam pewne doświadczenie, ale jednak meetupy i warsztaty to nieco inne zwierzę. Jest wyzwanie, jest adrenalina. Kolejny element do kolekcji doświadczeń życiowych. Trzymaj proszę za mnie kciuki! W ciągu najbliższych 2 tygodni postaram się też zorganizować Webinar, aby też dać Ci możliwość obejrzenia i posłuchania na żywo tego co sądzę o “Blaskach i Cieniach Event-Driven Design”.

W zeszłym tygodniu rozpocząłem temat dzielenia systemów na mikroserwisy. Nieco sceptycznie odniosłem się do częstych motywacji technicznych z nich związanych. Podałem elementy, które wg mnie dają uzasadnienie, aby dzielić nasz system na mniejsze kawałki. Wyróżniłem:

• różnicę w ruchu w poszczególnych fragmentach aplikacji (np. moduł administracyjny nie potrzebuje tyle zasobów co np. moduł do wyszukiwania),
• możliwość dynamicznego zwiększenia przepustowości systemu przy pomocy skalowania horyzontalnego (poprzez np. dodanie większej liczby instancji serwisu sprzedażowego z okazji Black Friday),
• multi tenancy - czyli gdy nie chcemy, żeby działanie systemu u jednego klienta wpływało na działanie systemu u innego,
• multi region - gdy mamy system globalny i chcemy, żeby np. w USA działał nam tak szybko jak w Europie (pamiętajcie światłowody też mają opóźnienie).

Dzisiaj chciałbym włożyć jeszcze nieco więcej kij w mrowisko (czy też szprychy) i opowiedzieć o socjologicznej sferze użycia mikroserwisów. Często nasz wybór i sposób ich podziału nie wynika z czysto technicznych i biznesowych założen ale z “innych”. Jakich innych?

1. CV Driven Development, Hype Oriented Programming, Hipster As A Service - są to wzorce czy doktryny, które mówią nam aby używać jak najnowszych technologii, jak najbardziej modnych i podążać za “najnowszymi trendami”. Zwykle ślepo. Sam brałem udział w projektach, gdzie śmiałem się, że używamy tylko bibliotek, które nie mają więcej niż dwóch kontrybutorów, bo chcemy odkrywać młode talenty. Miałem też klienta wizjonera, który mimo, że chciał zrobić zwykły proces ETL, to nie chciał używać popularnych i wypróbowanych technologii (typu MSSQL Integration Services czy Reporting Services), bo były dla niego zbyt oklepane, a sam chciał być “odkrywcą” i zacząć jako pierwszy używać nowego przebojowego rozwiązania. Skończyło się to 3-4 krotnym przepisaniem od zera rozwiązania na coraz to dziwniejszym rozwiązaniu. Sami też (ja również) dobieramy często technologię, żeby mieć “fun”. Nie ma w tym nic złego o ile jest o zbieżne z “funem” klienta. Gorzej jak te 2 drogi wzajemnie się wykluczają. To jest przepis na katastrofę. Zabrzmi to nieprzyjemnie, ale to co system ma robić to po prostu zapierdalać. Ma przynosić pieniądze klientowi. Jeśli przynosi to nam również przyjemność z pracy to tym lepiej dla nas. Tylko nie zapominajmy “first things first”.
2. Aspekt rekrutacyjny - w naszej branży każdy chce robić rzeczy najnowsze, na najświeższych technologiach, najpopularniejszych frameworkach. Podobnie z mikroserwisami. Kilka razy się spotkałem w rozmowach z innymi, że mówili “no ja to uważam, że to nam nie jest potrzebne, ale bez tego nie nakłonię ludzi do pracy”. Wiadomo, jeśli mamy system napisany w Cobolu to znalezienie żyjącego programistę, który nam go będzie utrzymywał jest karkołomnym zadaniem. Powinniśmy wg mnie się zastanowić, czy my jako programiści często nie przesadzamy w poszukiwaniu fontanny młodości? Czy naprawdę musimy próbować wszystkiego? Nie mówię tutaj o minimalizmie i szukaniu stagnacji, ale o po prostu pragmatycznym i zdroworozsądkowym podejściu, którego często nam brakuje (mnie również).
3. Chęć nezależności i przywództwa - możliwość pocięcia serwisu na niezależne moduły zapala niektórym neon z napisem “to jest mój moment!“. Teraz mogę wreszcie mieć “swój moduł”, teraz mogę wreszcie odciąć sie od nielubianego zespołu, skupić się na swojej robocie, a im kazać się gonić. Jest w tym sporo prawdy i racji, ale jednak nie do końca. Pamiętajmy, że to co działa zawsze poza prawami Murphy’ego to prawo Conway’a - czyli, że wytwarzany przez nas system będzie odzwierciedleniem komunikacji w naszym projekcie (firmie). Sam fakt, że mamy niezależne mikroserwisy, nie sprawi, że będą one dobrym rozwiązaniem. Jeśli zespoły nie będą mogły się wzajemnie dogadać, to wytworzone przez nich mikroserwisy również. Często prowadzi to do skrajnej desperacji, którą nazywam “Wzorcem Negocjator”. Mamy dwa systemy, które nie potrafią się ze sobą dogadać, więc spróbujemy dorzucić trzeci, który skoordynuje ich działanie i sprawi, że zaczną współpracować i zaczną ze sobą rozmawiać. Zwykle kończy się to posiadaniem 3 systemów, które ze sobą nie gadają.

Wbrew pozorom te aspekty socjologiczne bywają dużo groźniejsze niż zły podział techniczny. Matthew Skelton i Manuel Pais nazwali to “Cognitive Load”, czyli obciążeniem poznawczym. Im ludzie mają wyższy próg do zrozumienia i więcej ich kosztuje poznanie zasad współpracy, tym większe ryzyko niepowodzenia naszego projektu. Z resztą, co ja będę za nich mówił - obejrzyj, naprawdę warto!

No dobra, póki co kończę, jadę dalej, Pan przede mną też. Jutro ważny dzień. Trzymaj za mnie kciuki!

Daj też proszę znać o tym co sądzisz o tym co napisałem, czy widzisz dookoła siebie podobne sytuacje?

Pozdrawiam serdecznie!

Oskar