W IT dość często odkrywamy koło na nowo. Wywiad z Piotrem Gankiewiczem

Piotr Gankiewicz to inżynier oprogramowania na co dzień rozwijający systemy finansowe w oparciu o mikroserwisy. To także kilkukrotny zdobywca tytułu Microsoft MVP i zapalony zwolennik oprogramowania open-source. W naszej rozmowie zdradził swoje przemyślenia dotyczące współczesnego podejścia do architektury i koncepcji modularnego monolitu.

W swojej pracy zajmujesz się mikroserwisami — czy to ewolucja w temacie rzeczy, którymi zajmowałeś się wcześniej?

Faktycznie, mikroserwisy można uznać za pewną ewolucję jeśli rozmawiamy o wariancie systemu rozproszonego — niektórzy twierdzą, że jest to “SOA (Service Oriented Architecture) done right”. Bynajmniej nie jest to nic rewolucyjnego, ponieważ jak to w IT bywa, dość często odkrywamy koło na nowo, tzn. wykorzystujemy pomysły i przemyślenia (nierzadko sprzed kilkudziesięciu lat) wielu mądrych osób i dostosowujemy je do naszych realiów — w mniej lub bardziej zmienionej formule, oczywiście z odpowiednią dozą buzzwordów, żeby nadążyć za hypem.

Czy faktycznie w tym rozwiązaniu widzisz przyszłość dla firm IT i startupów?

Jako prawdziwy konsultant rzekłbym — to zależy.

Warto podkreślić, że jest to architektura „organizacyjna”, tzn. powinna być podyktowana m.in. przez strukturę naszej firmy, wymagania biznesowe, możliwość wydzielenia niezależnych procesów etc. a niekonieczne przez widzimisię „osób technicznych”, które chcą na start zaaplikować nowy framework oraz k8s z dziesiątkami pluginów dookoła, podczas gdy granice naszych potencjalnych usług nie zostały w ogóle zdefiniowane. W przypadku startupów raczej bym je odradzał na start, zwłaszcza gdy chcemy możliwie szybko zbudować MVP i zacząć dostarczać “ficzery”. Niestety, nierzadko mikroserwisy, podobnie jak np. AI, ML, Big Data, Blockchain itd., to zwykły bełkot, który ma na celu tylko pozyskanie/wyciągnięcie funduszy od nieświadomego inwestora, gdy potem faktyczna implementacja nie ma z tym wszystkim zbyt dużego wspólnego.

Czy architektura zaczyna być krytycznym punktem rozwoju każdej firmy? Jak widzisz to ze swojej perspektywy?

Myślę, że zawsze była, tylko te kilkanaście lat temu (czy znacznie wcześniej), aż tak dużo jak obecnie się o niej nie mówiło, co oczywiście jest powiązane z ogromną ilością spotkań, konferencji, webinarów, rozwojem open source i przykładowych projektów stanowiących referencję dla danego stylu architektonicznego itd. Z drugiej strony, zanim większość z nas przyszła na świat, powstało wiele fascynujących publikacji, które są nadal aktualne (polecam sprawdzić kto i kiedy opisał, czym jest Saga), mimo że moc obliczeniowa komputerów była wtedy o rzędy wielkości mniejsza, a internet dopiero raczkował.

Jakie trzy błędy są Twoim zdaniem najczęściej popełniane w kontekście budowania projektów od podstaw? Na co od razu warto zwrócić uwagę?

Niezrozumienie biznesu — tak, może to brzmieć trywialnie, ale prawdopodobnie jest to jedna z najczęstszych przyczyn opóźnień albo i całkowitego niepowodzenia projektu. My jako osoby techniczne nierzadko ignorujemy to co analitycy, eksperci domenowi itd. (w zależności od struktury ról w projekcie) próbują nam przekazać, myśląc tylko o technologicznych wodotryskach. Naprawdę, choćby jedna prosta sesja np. Event Stormingu potrafi tutaj dużo pomóc, aby odnaleźć wspólny język pomiędzy biznesem a programistami 🙂

Aplikowanie tej samej architektury/technologi/rozwiązań w każdym projekcie. Pamiętajmy, że domena, wokół której się obracamy, nierzadko ma różną złożoność — pewne klasy problemów będą wymagały wyrafinowanych rozwiązań, a inne można ogarnąć zwykłym CRUDem. Analogicznie z mikroserwisami — w większości przypadków (przynajmniej na start) nie będą one miały większego sensu.

Decyzje techniczne podejmowane przez osoby nieposiadające odpowiednich kompetencji. Niejednokrotnie, spotkałem się z przypadkami, gdzie zespoły np. Przepisywały projekt z języka A na B, albo rozwalały monolit na mikroserwisy, tylko dlatego, że jakiś menedżer usłyszał na konferencji same fajne rzeczy o danym podejściu/technologii i bez większych konsultacji z zespołem kazał je wdrożyć.

Czy mikroserwisy faktycznie zwiększają wydajność i pozwalają na późniejsze, łatwiejsze skalowanie pomysłu?

Zależy, o jakiej wydajności mówimy. Jeżeli chodzi o optymalizację aplikacji, to teoretycznie tak, gdyż możemy daną usługę zaimplementować w praktycznie dowolnym języku (np. C++ do HFT). Odnośnie wydajności zespołów również, ponieważ poszczególne osoby/zespoły nie wchodzą sobie w paradę, pracując nad osobnymi usługami w dedykowanych repozytoriach. Aczkolwiek, tutaj znowu wracamy do problemu wydzielenia granic naszych usług — jeżeli mikroserwisy (które miały być autonomiczne) są ze sobą mocno powiązane (tight coupling) na poziomie zapytań synchronicznych, to trafiliśmy w niefajne miejsce nazwane jako rozproszony monolit i wydajność leci na łeb na szyję.

Odnośnie skalowalności, to również jeden z koronnych argumentów przemawiających za wyborem mikroserwisów, ponieważ możemy zaaplikować tzw. asymetryczne skalowanie horyzontalne — jest to po prostu dodawanie kolejnych instancji naszej aplikacji za load balancerem (podobnie jak w monolicie), z tą różnicą, że skalujemy konkretne usługi niezależnie od siebie i np. w przypadku Black Friday, możemy dodać X instancji usługi odpowiedzialnej za obsługę koszyków lub zamówień jako krytycznych do sprawnego działania systemu, a następnie powrócić do stanu pierwotnego gdy szał zakupowy już minie.

Oferty pracy z

A z kolei, kiedy Twoim zdaniem mikroserwisy się nie sprawdzają?

Przede wszystkim, gdy pracujemy nad MVP i chcemy jak najszybciej dostarczyć konkretne „wartości biznesowe”, aby sprawdzić, czy nasz projekt w ogóle ma rację bytu. Nawet jeżeli zespół jest doświadczony w implementacji, wdrażaniu i zarządzaniu mikroserwisami to zapewne jest świadomy ogromnego narzutu dotyczącego infrastruktury i szeroko pojętego DevOps, aby możliwie szybko i sprawnie wdrażać usługi. Nierzadko, te początkowe tygodnie poświęcone na wyzwania związane z budowaniem mikroserwisów mogą być krytyczne w kontekście weryfikacji pomysłu na nowy projekt.

Gdyby mógł istnieć przepis na architekturę bez wad (a wiemy przecież, że takiego nie ma), to z których gałęzi czerpałby on najwięcej?

Oczywiście, takiego magicznego przepisu nie ma, aczkolwiek myślę, że złotym środkiem może być właśnie modularny monolit, który poniekąd czerpie z monolitu jak i mikroserwisów.

I tu na scenę wchodzi Modular Monolith. Dlaczego zainteresował Cię ten temat? Wiem, że zdecydowałeś się na nim skupić w swojej pracy.

Po kilku latach prac w obszarze systemów rozproszonych i mikroserwisów zastanawiałem się wspólnie ze znajomymi, jaką architekturę wybrać do własnych projektów, tak aby z jednej strony nie borykać się z narzutem infrastrukturalnym podyktowanym przez mikroserwisy, a z drugiej, posiadać możliwie niezależne od siebie moduły, które w razie potrzeby na przykład asymetrycznego skalowania będziemy w stanie przenieść do osobnych aplikacji (czyli dokonać przejścia w mikroserwisy). Modularny monolit wydaje się właśnie takim rozwiązaniem — pracujemy w obszarze aplikacji monolitycznej (pojedynczy artefakt wdrożeniowy), która zawiera autonomiczne moduły o dowolnej architekturze w zależności od klasy problemu.

Trzymając się pewnych żelaznych zasad jak na przykład:

• Enkapsulacja dostępu do danych (na przykład podział logiczny bazy przez schematy)
• Komunikacja tylko przez publiczne API danego modułu
• Asynchroniczna integracja przez zdarzenia (event-driven)można uzyskać podobny efekt faktycznej niezależności konkretnych części aplikacji jak przy mikroserwisach.

Co poradziłbyś firmom i zespołom, które notorycznie borykają się z długiem technologicznym? Jak najszybciej wyjść z takiej sytuacji?

Przede wszystkim sprawdzić, czy projekt posiada testy. Jeżeli nie, bądź jest ich mało, lub nie są zbytnio rozbudowane, w pierwszej kolejności skupić się na testach wyższego poziomu tzn. Integracyjnych oraz end-to-end, aby pokryć krytyczne procesy w aplikacji.

Następnie, dokonać powolnej refaktoryzacji z wykorzystaniem takich wzorców jak na przykład strangler fig lub branch by abstraction. Oczywiście na to wszystko musi być zezwolenie od biznesu — jeżeli go nie ma, i świadomie wszyscy tkwimy w szambie, to pozostaje tylko uciekać 🙂

Jak postrzegasz open-source? Opinie w środowisku IT na ten temat są różne. Widzę, że aktywnie udzielasz się w wielu projektach. Jak bardzo open-source i regularna kontrybucja wpływa na Twój indywidualny rozwój?

Otwarty kod źródłowy (co nie zawsze oznacza w pełni darmowy) to wg mnie jedna z najlepszych rzeczy, jaka mogła się przyczynić do rozwoju oprogramowania (i nie tylko). Na co dzień, jak i praktycznie każdy inny programista korzystam z dziesiątek pomocniczych bibliotek, które wykorzystuję w swoich projektach.

Dodatkowo całe platformy programistyczne i języki programowania tworzone w nurcie open source, pozwalają na wsparcie ich rozwoju przez społeczność (testowanie, usprawnienia, bezpieczeństwo) oraz znacznie szybszą adaptację jak i zdobycie zaufania (kto lubi korzystać z całkowicie zamkniętego oprogramowania we własnych projektach?). Moja przygoda z otwartym oprogramowaniem zaczęła się kilka lat temu w ramach konkursu Daj się poznać, i później już tak mi zostało, gdy zauważyłem, że faktycznie korzystają z tego osoby z całego świata. Aktualnie, poza dość dużą ilością przykładowych projektów opartych na architekturze mikroserwisów lub modularnego monolitu, który publikujemy na naszym GitHubie, rozwijamy również zbiór pomocniczych bibliotek jak na przykład Convey używany przez naprawdę duże firmy w ramach swoich projektów opartych na mikroserwisach. Na sam koniec warto również wspomnieć, że nierzadko open source owocuje naprawdę fajnymi (i co istotne intratnymi) ofertami jeśli chodzi o pracę czy szkolenia.

Możesz się pochwalić czterokrotnie zdobytym tytułem Microsoft MVP. Jakie drzwi otworzyło Ci to w karierze i przede wszystkim — jaka jest recepta na ciągły, powtarzający się sukces?

Posiadanie tytułu Microsoft MVP to na pewno swojego rodzaju zaszczyt i pewne wyróżnienie w CV. Natomiast warto pamiętać, że MVP to niekoniecznie odznaczenie za szczególne osiągnięcia techniczne/programistyczne — należy to traktować jako wkład w rozwój społeczności (open source, blog, tutoriale, konferencje itd.). Ja ze swojej strony zarówno lubię dzielić się swoim kodem jak i wiedzą, więc tak się akurat złożyło, że ten tytuł otrzymałem kolejny raz.

Dzięki wielkie za rozmowę!