Monolit czy mikroserwisy?

Dynamika zmian w świecie IT jest znana od dawna. Doskonalenie systemów wymaganie nie tylko nowych rozwiązań, ale także nieustającego poszerzania swojej wiedzy przez programistów. W dzisiejszym odcinku podcastu porozmawiamy o temacie mikroserwisów. Temat ten w ostatnich latach zyskuje na popularności i przyczynia się do wielu transformacji w IT. Nasz gość, Piotr Świderek, w swojej karierze zawodowej miał przyjemność pracować zarówno w architekturze monolitycznej, jak i przeprowadzać procesy przekształcania jej w architekturę mikroserwisową. W dzisiejszym odcinku porozmawiamy m.in.:
👉 o monolicie – czym jest, jak wygląda praca programisty w tej architekturze, jakie są jego wady i zalety
👉 o mikroserwisach – z czym wiąże się praca programisty w tym rozwiązaniu, co można zyskać, a co jest największym wyzwaniem
👉 o różnicach w powyższych podejściach
👉 o przyszłości tych rozwiązań – czy mikroserwisy zastąpią monolit?

Nikodem: Cześć, jestem Nikodem, a to jest podcast DEVision. Jest dzisiaj ze mną w studio Piotrek. Cześć, Piotrek (Piotrek: Cześć, Nikodem!). Będę dzisiaj chciał z Tobą porozmawiać o mikroserwisach i monolitach, ale zanim przejdziemy do sedna sprawy – mógłbyś powiedzieć kilka słów o sobie?

Piotrek: Jestem deweloperem od 5 lat, głównie pracuję w .NET / C# – technologie bardziej backendowe. Aktualnie od ostatnich dwóch lat pracuję z mikroserwisami. Wcześniej większość czasu pracowałem w projektach monolitycznych. Dzisiaj opowiem wam o moich doświadczeniach.

Czy możesz opisać krótko czym jest monolit?

To jest jedna duża aplikacja, w której zależności są zamknięte w ramach jednego projektu, np. logika jest utrzymana w jednym projekcie.

A czym są mikroserwisy?

To jest cały system. Tylko że, porównując do monolitu, to jest tak, że nie mamy jednego projektu, który za wszystko odpowiada. Przepływ informacji idzie przez cały projekt. Tutaj pojedynczy serwis ma swoją odpowiedzialność, która zajmuje się tylko wydzieloną domeną informacji i jest połączeniem wszystkich logik oraz działających “podprojekcików” w całym systemie.

A mógłbyś nam podać jakiś przykład?

Monolit można porównać do dużego sklepu wielobranżowego albo hipermarketu, do którego możesz sobie wejść i jak potrzebujesz bułki to tam są, młotek też się tam znajduje, ciuchy –  również. Możesz sobie wziąć cokolwiek, po prostu idziesz na odpowiedni dział i to kupujesz. Mikroserwis natomiast można porównać do galerii handlowej, która ma wydzieloną dużą ilość sklepów – porównując to do pojedynczych serwisów to każdy serwis odpowiada za jakąś inną logikę – tak jak sklepy. W jednym masz jakieś artykuły spożywcze, a w innym możesz mieć odzież. Każdy serwis ma swoją pojedynczą logikę i tylko ona odpowiada za ten produkt. Mogą one ze sobą współdziałać, tak jak powiedzmy cały monolit. Natomiast jednak pojedynczy sklep możesz sobie zamknąć, otworzyć i nie masz takiego wpływu jak na hipermarket.

Jakie są zalety monolitu?

Jeden projekt, w którym wszystkie zależności i cała logika jest w jednym miejscu. To może być też minus, bo się może nakładać bardzo dużo informacji i zależności. Natomiast jeśli chodzi o jakieś debugowanie czy przekazywanie informacji, to jest zdecydowanie szybsze. Kolejną rzeczą jest to, że nie potrzeba dodatkowo jakiegoś nakładu komunikacji pomiędzy tymi serwisami. Nie trzeba wydzielać tej logiki aż tak bardzo.

No tak, bo mamy jeden serwis, nie?

Tak. On się ze sobą bezpośrednio komunikuje, więc dlatego też jest zdecydowanie szybszy.

To z doświadczenia jeszcze mógłbym dorzucić tutaj, że sam proces deploymentu jest też łatwiejszy, no bo jak mamy jedną aplikację, to tak naprawdę deploy’ujemy jedną aplikację i nie musimy się przejmować zależnościami między serwisami. W takim razie jakie są zalety… albo nie – wady monolitu?

Minusem monolitu jest na pewno performance, czyli skalowalność. Jeśli chcemy ją poprawić, to musimy dołożyć trochę RAMu – lepszy procesor, lepsza maszyna, więc skalujemy tylko pionowo. A jeśli pisze się już kod, no to na pewno jest więcej zależności. Jeśli chcemy zmienić jakiś fragment kodu, to musimy przebudować cały projekt. Rzadko kiedy zdarza się, że jeden programista pracuje na monolicie, więc jeśli parę osób pracuje, to zdarzają się konflikty. Im więcej jest ludzi pracujących w tym monolicie, im więcej zależności pomiędzy podzespołami tego monolitu, to tym więcej problemów właśnie z takim spokojnym, częstym dyploy’em, wgrywaniem zmian. No i często  są problemy z szybkim przetestowaniem aplikacji.

To ja się z tym zgodzę, bo pracowałem przez parę lat z monolitami i właśnie tak jak mówisz – dużym problemem było to, że załóżmy chciałem zmienić tylko jedną linijkę w kodzie, a musiałem wykonać deploy całej aplikacji, który po drodze musiał uruchomić wszystkie testy. Testy zajmowały… kto wie ile czasu. 😉 A później się okazało na koniec, że i tak źle zmieniłem tę linijkę i musiałem jeszcze raz. Także to było problematyczne. Z kolei to, co później wspomniałeś – współpraca w zespole. Trzeba było się dogadać, że ktoś np. teraz wstawił swoją wersję aplikacji, więc trzeba było poczekać. To były takie dość nieprzyjemne aspekty monolitu.

No i jeszcze nawiązując do tego, co wcześniej powiedziałeś, czyli do procesu budowania – jak już monolit czasami narośnie, to ta przerwa, odkąd się wyłączy aplikację, żeby uruchomić kolejną, to coraz więcej się nakłada na to zależności, na cały ten rosnący projekt, zanim się to wszystko zbuduje. Więc czas się wydłuża, przez co trzeba te okienka techniczne jakieś wdrażać albo coś podobnego.

U nas było na tyle przyjemnie, że był klient wewnętrzny, także wystarczyło wysłać maila: “Słuchaj, za 15 minut będzie stało!”. Ale zgadzam się z tobą, że to nie zawsze musi być tak pięknie. Dobrze. A w takim razie jakie są zalety mikroserwisów?

Na całkiem skalowalnym poziomie możemy dokładać kolejne kontenery czy możemy sobie stawiać nasze serwisy, przez co nie musimy być tak zależni albo ograniczeni, jakie będziemy mieli maszyny. To też jest mała aplikacja, więc łatwiej ją utrzymać, jeśli chodzi o sam kod. Proces takiego wytwarzania, takiego pojedynczego mikroserwisu, nie jest łatwy. Natomiast jak już się ma cały komponent, to później wdrażanie każdego kolejnego staje się coraz prostsze, coraz łatwiejsze, no bo to już robi się według jakiegoś szablonu. W przeciwieństwie do monolitu – jest na pewno ten deploy albo jakieś testy; one są zdecydowanie bardziej wydajne w aspekcie takich małych aplikacji. Wstanie takiej aplikacji albo małego serwisu, który ma swoją jakość, funkcjonalność i jest czasami zależny, zajmuje przeważnie od paru sekund do paru minut. Więc porównaniu do monolitu w takich zrośniętych starszych technologiach to jest naprawdę ogromna różnica.

Ja od siebie jeszcze tylko dodam, że plusem, o którym bardzo często słyszałem w kontekście mikroserwisów, jest to, że możemy użyć do poszczególnych serwisów osobnych technologii. Powiedzmy, że napisałem jeden komponent w Pythonie (bo ja bardzo lubię Pythona :D), ale przyszedł kolega, który mówi: “Ja dużo lepiej go znam, albo Javę, i napiszę inny komponent w Javie”. Różnie to bywa z tymi plusami/minusami, bo to, że użyłem innych technologii jest fajne, bo pozwoliło mi osiągnąć lepszy performance, ale z kolei utrzymanie wielu serwisów, które są w różnych technologiach, może być problematyczne. Skoro o minusach mowa, to jakie byś wymienił minusy mikroserwisów?

To na pewno to, że próg wejścia jest troszeczkę większy niż monolit. Zbudowanie całej architektury czy jakiejś komunikacji pomiędzy tymi serwisami jest większe. Trzeba mieć trochę więcej wiedzy, trzeba się trochę zapoznać z tym, jakie mogą być problemy w tych komunikacjach.Najczęściej jest jakaś komunikacja asynchroniczna – nie czekamy na odbiór tych informacji, przez co zdarza się, że nałożą się niektóre informacje albo niekoniecznie przyjdą w tej samej kolejności, tak jak byśmy oczekiwali. To prowadzi do tego, że musimy mieć jakieś procesy testów integracyjnych, które nie miały i nie mają miejsca normalnie w monolicie.

Masz na myśli tutaj testy między serwisami już, tak?

Tak, albo połączenia. Jak masz wyizolowaną bazę, albo jakiś klaster, to zawsze musisz to sprawdzić – jak masz jeden serwis to w każdej aplikacji czy mikr serwisie musisz sprawdzić, czy on coś ci odpowiada. Nawet jeśli masz jakieś bardziej bezpośrednie połączenia, to też musisz sprawdzić, czy np. inna aplikacja w tym momencie nie jest przebudowywana albo czy nie ma jakiegoś problemu. Tego akurat nie było wcześniej w monolicie, bo jak coś, to monolit się cały wali. 😀

Albo działa wszystko, albo nic. 😀

Tak, więc to na pewno są takie minusy.

Czyli główny minus – komunikacja. Czy widzisz jeszcze jakieś inne?

Nawiązując do pytania o plusy i tego, jak mówiłeś, że są różne języki – to pozwala na różne technologie, i jeśli ktoś nie przemyśli danej decyzji, to może doprowadzić do jeszcze większego nieładu niż w monolicie, bo tutaj masz przynajmniej jakąś jedną technologię.

Tutaj też bywa z tym różnie.

Da się wszystko. Zawsze można dodać w jakiś sposób, ale to już jest ciężej niż w takich mikroserwisach.

Myślę, że w mikroserwisach łatwiej się pokusić o to, żeby wprowadzić nową technologię, bo możemy stwierdzić: “Wprowadzamy nową technologię albo język, będziemy testować coś nowego”. Faktycznie później takie coś może być problemem.

Warto dodać, że czasami, podczas deploymentu, ważna jest kolejność uruchamiania serwisów. Może to być problemem gdy wdrażamy nowe aplikacje albo jak procesy są nie do końca usystematyzowane.

Wspomniałeś, że pracujesz z mikroserwisami i jak rozumiem, pracowałeś też z monolitem. Jaka jest różnica z Twojego doświadczenia? W którym projekcie pracuje Ci się lepiej?

Przez pierwszy projekt (mniejszy, roczny) to było tylko paru developerów w tym projekcie, więc jako monolit pracowało się spoko. Nie było problemów i zależności. Jeszcze przed pandemią, jak wszyscy siedzieliśmy razem, to zawsze się dało dogadać, wszystko ustalić i na miejscu rozwiązać. Później, jak przechodziłem do kolejnej pracy, to trafiłem do monolitu. Ale to już była taka aplikacja dosyć spora, gdzie mieliśmy przeszło 20 deweloperów i tam już było trochę gorzej. Klient chciał wdrażać każdą zmianę jak najszybciej, według Scruma, co dwa tygodnie, jeszcze na niższych środowiskach, jeszcze częściej. Powiedzmy, że dwie osoby zostały odpowiedzialne za zgrywanie zmian. Wszystkie deploy’e to reszta 18 osób – tak szybko wygrywali te zmiany, że ciężko było dograć pomiędzy resztą zespołu tak, żeby nie było jakichś większych konfliktów, a czasami się zdarzało to, że ktoś komuś wycofał zmianę albo że miało coś pójść, a nagle nie poszło. Bywało z tym różnie. Samo pisanie kodu nie ma aż takiego wielkiego wpływu – to znaczy, ogólnie wpyłw ma, bo przy mniejszej aplikacji jest zdecydowanie łatwiej zrobić logikę.

Myślę, że jest też mniej konfliktów jeśli merge’ujemy coś czy spinamy ten kod.

W mikroserwisach jest o tyle dobrze, że masz mniej kodu, mniej logiki i łatwiej jest przeglądać cały projekt. Czasem możesz siąść w ciągu jednego dnia i przeglądnąć wszystkie zależności i już mniej więcej te podstawy znasz. Znasz cały przepływ tej informacji i logiki na wejściu i wyjściu. Natomiast tutaj, jak czasami masz jakieś większe zdanie, modyfikację czegoś albo uaktualnienie, to nie do końca wiesz, w którym serwisie. Albo czasami zmienisz coś w jednym serwisie i wydaje ci się, że już powinno działać dalej, a tu jeszcze gdzieś trzeba było zmienić. I to już jest takie trochę tricky, że tak powiem, bo musisz albo dopytać, albo już mieć wcześniej tę wiedzę.

 

Zauważyłem też u siebie, że czasami jest coś takiego, że projekt wymaga dużo wiedzy plemiennej, tak bym to określił. Czyli jest jakaś osoba, która po prostu wie, że dana informacja występuje w tych trzech mikroserwisach i żeby dostarczyć funkcjonalność, trzeba poprawić te trzy mikroserwisy. Natomiast w monolicie wszystko było prostsze, można było wykrepować, wyszukać.

Jak nie szło w jakimś edytorze, to zawsze można było po prostu przeglądać bezpośrednio. Przynajmniej z mojego doświadczenia, łatwiej jest o modyfikacje. Wcześniej wspominałeś o wydzielaniu różnych języków w mikroserwisie, natomiast ja się spotykam z tym, że czasami była stara aplikacja albo jakiś monolit był tworzony i powiedzmy, że ta aplikacja globalnie, jako cała, powstała 5 lat temu. 5 lat temu te technologie już się różniły, nawet wersje danej części. Czasami jest czas, a czasami nie ma czasu, żeby podnosić wersję danego języka. Jeśli w porę nie podniesiemy tej wersji, to później czasami się pojawiają takie problemy, że czegoś już nie ma czy coś nie jest wspierane. A teraz chcemy tego oczekiwać, że będzie, na przykład, już wdrożona. Albo później chcemy coś poprawić i nagle jest tak, że nam się wywala. Niby prosta zmiana, a tu się wywala połowa projektu, bo zależności się pomiędzy różnymi bibliotekami pozmieniały.

To prawda, mieliśmy kilka razy taki przypadek, że  w monolicie bardzo ciężko było podbić wersję konkretnej biblioteki, bo powstawało dużo konfliktów. Natomiast w mikroserwisach zawsze to jest jednak prostsze zadanie.

Taki jest cel, że w razie czego łatwiej jest przepisać fragment mikroserwisu pojedynczego.

 

Kiedyś słyszałem takie hasło, że odpowiednia wielkość dla mikroserwisu powinna być taka, żeby dało się go przepisać w przeciągu, powiedzmy, 4 tygodni, i że to jest odpowiednia wielkość. No bo faktycznie takie mikroserwisy łatwiej jest utrzymywać.

Z jednej strony się zgodzę, chociaż domyślam się, że na pewno znajdą się jakieś wyjątki.

Myślę, że nie każdy mikroserwis jesteś w stanie ścisnąć do takiego rozmiaru.

Czasami nie jesteśmy w stanie tego ograniczyć aż tak, żeby to było małą aplikacją.

Jakie jest największe wyzwanie, jakie Cię spotkało, odkąd pracujesz w architekturze mikroserwisów?

Z mojej perspektywy, największym wyzwaniem było tak zaprojektować mikroserwis, żeby mógł działać współbieżnie – żeby zlikwidować jakieś ograniczenia, które mieliśmy w danej aplikacji przechodząc, na przykład, z monolitu – żeby zdecydowanie poprawić tę wydajność. I tutaj następują te problemy, że czasami może ci się wiadomość powtórzyć albo musisz obserwować dokładnie te serwisy czy one sobie nie wchodzą w drogę, żeby później nie okazało się tak, że masz dwa rekordy pisane, które odpowiadają za to samo. 

Na Facebooku albo Twitterze działą to tak, że jedna osoba może tam szybko wykrzykiwać ileś tam wiadomości. No ale zawsze ktoś później może to komentować. I jest tak, że cała ta aplikacja musi zarządzić, kto i kiedy był pierwszy – tak szybko to musi działać, że w monolicie by to nie miało możliwości bytu. Natomiast tutaj to jednak trzeba rozwiązać. Celem takich mikroserwisów jest to, żeby to działało super szybko, ale też musi działać tak, żeby to pokazywało rzeczywiste dane, a nie tak, że weźmiesz komentarz i nagle pojawią się twoje trzy albo trzy takie same, czy coś podobnego.

Albo nie pojawi się żaden. 😉

Dokładnie. 😀

 

Chociaż jakbym sobie tak nabił jeden like, a wyskoczyło ich 5 – super sprawa! Dobrze. A czy miałeś w monolicie podobnego typu wyzwania?

Tak jak już wcześniej wspomniałem – najbardziej takim męczącym dla mnie doświadczeniem była taka sytuacja: dostajemy nowego taska, chcemy dodać jakiś feature i wybraliśmy już do tego fajną bibliotekę. Mamy, sprawdzamy, jest wsparcie, jest wszystko fajnie. Natomiast wychodzi na to, że, na przykład, dana wersja ma jakiś błąd. No i później nagle się zaczyna: chcemy wdrożyć ten feature, no ale musimy przez to przebudować wszystkie zależności i dane w projekcie, bo musimy podnieść wersję o jeden punkt albo dwa. To w teorii jest niewiele, natomiast z tego mogło wyjść naprawdę dużo zmian. I później się wiąże to z tym, że niby jakaś drobna zmiana, a jednak później jest kupa testowania, kupa jakiejś weryfikacji tego, czy to działa, czy nie działa. No i raczej, jak ja się spotykałem, to w większości przypadków to jednak były manualne testy. Jednostkowe były, natomiast jeśli chodzi o takie globalnie, żeby sprawdzić funkcjonalności czy najważniejsze ścieżki pokryte, to jednak wszystko to przechodziło ręcznie.

 

Najgorzej, jeżeli się jeszcze okazało, że jednak nie będzie działać i trzeba przywrócić starą bibliotekę. 

No, tak też się zdarzało… albo trzeba było jakoś tam przeczekać, przekombinować i dobrze obejść to w jakiś sposób, taki niezbyt ładny. 😀 Jak ma się tę jedną technologię, to jest jednak trochę ograniczenie. Wydaje mi się, przynajmniej z perspektywy czasu, że to podejście mikroserwisowe do tego, że np. w jednym serwisie możesz korzystać z danej wersji, starszej, a w drugim – z drugiej, na przykład nowszej – to jest dosyć dużą zaletą.

 

Tak, ale to też to, o czym teraz wspomniałeś – samo takie podbijanie wersji jakiejś biblioteki w danym serwisie. Jest później łatwiej to przetestować, bo tak jak tu mówisz, masz duży monolit, zmieniłeś jakąś małą rzecz i mówisz, że potrzebujesz przeprowadzić dużo testów manualnych, to tak naprawdę masz dużo funkcjonalności do przetestowania. Gdzie w takim mikroserwisie pewnie z reguły będzie ich mniej.

Przeważnie się skupiamy na jednym celu tego mikroserwisu, więc łatwiej jest znaleźć jakąś osobę za to odpowiedzialną. Natomiast tutaj – nie wspominając już o tej wiedzy plemiennej – to wystarczy, że jak masz rozbudowany cały system, to ktoś nowy przyjdzie i zajmie się częścią tego projektu. Tak samo jak jest kilku, kilkunastu developerów, np. odnośnie tego monolitu, to wtedy rzadko kiedy bywa, że jest jeden tester, bo po prostu nie dałby rady wszystkiego sprawdzić w takim czasie.

 

Więc jeśli chodzi o jakieś takie przekazanie wiedzy, to jesteśmy ludźmi – zawsze zapominamy; powiemy to, co ostatnio robiliśmy, natomiast zapomnimy o czymś, co było wcześniej. I czasami jest tak, że wcześniej to działało i nie było ruszane – i nagle taka drobna zmiana konfiguracji czy bibliotek, czy czegoś podobnego wpływa finalnie na ścieżkę. Tych rotacji w IT trochę jest, więc bywa czasami ciekawie w takich monolitycznych aplikacjach.

 

Co sądzisz o testowaniu? Którą z aplikacji wolałbyś testować? Łatwiej się testuje monolit czy mikroserwisy?

Jeśli chodzi o takie testy jednostkowe, to je się pisze bardzo podobnie – w jednym i w drugim. Troszeczkę wydaje mi się, że na plus jest testowanie mikroserwisów, bo jest mniej tych zależności. Natomiast idąc coraz wyżej, mało jest testów integracyjnych w monolicie – porównując do mikroserwisów – no bo tam nie ma tej komunikacji pomiędzy, nie ma jakichś tam dodatkowych warstw, tej całej budowy systemu, więc tego nie musimy sobie jakoś tak często weryfikować przy monolicie. Natomiast w mikroserwisach to jest sedno sprawy – jeśli wszystkie serwisy działają, ale sama komunikacja gdzieś tam padła, to i tak nic u nas nie działa, więc cały system już po prostu nie ma sensu bytu. 

 

A idąc znowu w kierunku takich testów, czy regresyjnych, czy takich typowo biznesowych, trochę od strony użytkownika – łatwiej jest to utrzymać po stronie mikroserwisów, bo raczej jeden mikroserwis nie ma aż tak rozbudowanej logiki. Zawsze te przypadki testowe możesz opisać w dokumentacji czy otworzyć jakieś scenariusze testowe w testach automatycznych. Natomiast jeśli chciałoby się zrobić tak, by pokryć cały monolit testami automatycznymi, które będą sprawdzać wszystko end-to-end, to jednak trzeba zwrócić uwagę na dwie rzeczy. Jedna jest taka, ile tych scenariuszy jest w tym monolicie, a druga jest taka, że każda drobna zmiana jednego kodu może wpłynąć np. na kilkadziesiąt przypadków tych testowych. Więc jednak jak masz ten jeden mikroserwis, to tam nawet nie masz w pełni kilkudziesięciu przypadków.

 

W sumie jak teraz o tym wspominasz, to przypomina mi się praca przy monolicie. Faktycznie tam bardzo często moja praca polegała na tym, żeby poprawiać testy, bo było ich na tyle, że jednak mała zmiana w kodzie wymagała poprawy wielu testów. Jakie było twoje pierwsze zetknięcie z mikroserwisami?

Pierwsza styczność w ogóle to myślę, że była już parę dobrych lat temu. Jak pojechałem na konferencję i tam opowiadali o tych wszystkich zaletach, o których wcześniej wspomniałem, typu “skalowalność, różne języki, można sobie wdrażać szybko, tyle wdrożeń można robić (no bo tyle tych serwisów), wiele osób może sobie tam pracować, każdy może sobie to zrobić”. Do tego jeszcze wtedy było tak, że ta konteneryzacja wchodziła, więc “później wszędzie to możesz odpalić”, więc po prostu cuda na kiju były opowiadane. Natomiast w rzeczywistości, żeby to zrobić tak jak się naprawdę chce; jakąś rozbudowaną aplikację, która ma sens, to schodzi trochę więcej czasu na takich ustaleniach.

 

To ja też chciałbym powiedzieć o moim pierwszym doświadczeniu, nawiązać do tego, co tutaj wspomniałeś, że na konferencji przedstawiają wszystko w superlatywach, obiecują gruszki na wierzbie – miałem podobnie. 😉 Też mi obiecali jakie te mikroserwisy są super, gadali o wszystkich wspaniałych zaletach – jedna mi bardzo utkwiła w głowie. Mianowicie to, że można każdy serwis napisać w osobnej technologii. I na początku myślałem, że to jest super, ale jak dostałem pierwszy mikroserwis, którym trzeba było zarządzać i były trzy serwisy, każde napisane w innym języku, to myślałem, że rzucę tym projektem i się zwolnię (śmiech).

(śmiech) Powiedzmy, że jesteś Java Developerem i stwierdzasz, że wchodzisz w mikroserwisy. Wchodzisz na projekt i dzieje  się tak: jeden projekt – coś tam ruszony fragment w Javie, tu masz Go, tu Pythona i coś tam jeszcze. 😀

 

No, bywa tak. Problemem przez mieszanie różnych technologii bywa większy próg wejścia do projektu. Powiedzmy, że szukamy nowego programisty do zespołu. I jak napisać ogłoszenie? Jeżeli wiemy, że mamy serwisy w czterech różnych technologiach, to ciężko znaleźć takiego człowieka orkiestrę.

No, trochę tak jest. Powiedzmy, że nie zacząłeś pracę 15-20 lat temu i siedzisz przez ostatnie 10 lat w jednej pracy. Cały czas jesteś w jednym projekcie, który tam zacząłeś pisać 10 lat temu; przez parę pierwszych lat go aktualizowałeś, natomiast teraz masz już taką bardziej utrzymaniową pracę. To wygląda trochę tak, przynajmniej z mojej perspektywy, że siedzisz w jakiś tam starszych rozwiązaniach, a jednak te mikroserwisy są takie, że jak mogą, to aktualizują na najnowsze – zmieniają jedną wersję, albo bibliotekę, albo komunikację. Więc jednak jest taki próg, że musisz być w miarę przez te ostatnie parę lat na bieżąco z kilkoma technologiami, żeby komunikować się między tymi serwisami.

 

Żeby łatwiej było się przerzucić z pracy w jednym mikroserwisie na kolejny.

Tak. Żeby napisać, tak jak wcześniej mówiłeś, jakieś tam pipeline’y to jednak zmienia się to z czasem.

 

To też zauważyłem po sobie, że odkąd pracuję w mikroserwisach, to trzeba mieć bardziej otwarty umysł. Trzeba być bardziej chętnym do uczenia się nowych rzeczy, bo cały czas jest coś nowego. Gdy mieliśmy starsze aplikacje, a zwłaszcza jeżeli chodziło o aplikacje, które się już głównie utrzymuje, to człowiek mógł siedzieć i nie uczyć się nowych rzeczy. Wystarczyło mu to, co umiał.

Ja miałem taką styczność, że skupiałem się bardziej na tym, jak to działa – jakaś tam logika, co za co odpowiada, która część projektu, albo gdzie coś zmienić. Natomiast tutaj ważne jest to, jaką dany mikroserwis ma odpowiedzialność. I w sumie to cię najbardziej obchodzi. Nie obchodzi cię to, jak ten model wygląda w danym momencie. Dlatego też pozwala to na wykorzystanie różnych języków. Mnie nie obchodzi ta technologia. Teraz przechodzimy trochę w server-less, albo coś podobnego. No i jednak ta technologia kilka czy kilkanaście lat temu w ogóle prawie nie istniała lub była po prostu w tak początkowym stanie, że nie była dla nikogo ważna, bo nikt nie mógł się jej nauczyć w profesjonalny sposób.

 

Myślę, że narzędzi było na tyle mało zaawansowanych, że nie opłacało się jej używać.

Ale wiesz, to była taka garstka ludzi, takich pionierów, którzy w tym siedzieli. Natomiast reszta tych osób, które pracowały w IT, pracowała właśnie w takich projektach, które na pewno część z nich jeszcze widziały i wszystkie tak samo działają albo podobnie działają, jak wcześniej – mam na myśli technologie i jakieś bazy. Natomiast część z nich już jest przenoszona na jakieś nowe rozwiązania. I nie idąc tym biegiem czasu, czyli przechodząc z takich, powiedzmy, nowszych języków czy naszych rozwiązań, to się zaczyna troszeczkę od początku. Bo jednak te technologie i logika zostaje. Natomiast może się zmienić całkowicie język. Wcześniej cię interesowało to, jak sobie zarządzać pamięcią czy wątkami w danym języku, a teraz już wolimy troszeczkę dołożyć jakiejś pamięci albo po prostu jakoś inaczej to obsłużyć, niż aż tak bardzo angażować się w tę taką bardzo drobną logikę.

 

Weźmy za przykład takiego pracownika, który od kilku, nawet kilkunastu lat pracuje z monolitem. Powiedzmy, że miał do czynienia głównie z utrzymaniem, tak jak podawałeś w tym przykładzie. I taka osoba chciałaby zmienić pracę. Chciałaby odżyć trochę i przerzucić się na mikroserwisy. Co byś poradził takiej osobie? Na czym powinna się skupić? Czego się douczyć? Na co zwrócić uwagę, żeby płynnie zmienić działkę z monolitu na mikroserwisy?

Według mnie, podstawową rzeczą jest to, żeby zobaczyć, zobrazować i zrozumieć dlaczego się przeszło z monolitów w stronę mikroserwisów, żeby później zrozumieć jakiś projekt. Trochę jest tych zależności, że wcześniej, na przykład, bezpośrednio łączyłeś się do bazy danych miałeś tę komunikację – ktoś uderzał do ciebie na jakiś endpoint no i miałeś już te dane. Natomiast tutaj czasami masz inaczej działające te serwisy; one działają w tle i nie możesz sobie tego tak dywagować od początku do końca tak, jakbyś tego oczekiwał w monolicie. Więc na początku na pewno zacząłbym od rozeznania się, jak one są budowane, zacząłbym pisać małe aplikacje i próbował je komunikować. Włączyłbym jakiś najprostszy tutorial, żeby zobaczyć, jak to połączenie działa.

 

Gdybyś stworzył teraz jakąś aplikację, to na które z tych podejść byś się zdecydował: monolit czy mikroserwisy?

Jak miałbym zaczynać, to zacząłbym od monolitu – mała aplikacja, mało zależności, mało kodu, więc łatwo też jest ją utrzymać. Wraz ze wzrostem tej aplikacji starałbym się wydzielać jej jakieś mniejsze części albo powiedzmy, że tę większą część, która byłaby bardziej uciążliwa starałbym się jakoś odseparować do osobnego serwisu. Oraz to, co byłoby aktualnie nieruszane od jakiegoś czasu, czyli na przykład serwis, który jest już dojrzały i możemy tylko korzystać z jego funkcjonalności, a niekoniecznie go modyfikować. Myślę, że wraz ze wzrostem tej logiki, wydzielałbym kolejne części – czyli na początku dzieliłbym sam projekt, później na przykład jakąś komunikację, później cały proces. Wszystko zależy od tego, jak by ten projekt rósł.

 

Czyli mówisz, że dobrym podejściem byłoby zaczynać projekt od monolitu, a dopiero z czasem przechodzić na mikroserwisy.

Tak, na pewno. Jest też plus taki, że od razu widzisz rezultat w monolicie. I tutaj możesz sobie zacząć czymkolwiek, jak choćby gotowy szablon projektu, i on sam ci narzuca już dużo funkcjonalności, można z tego skorzystać.

 

Nie trzeba się skupiać na konfiguracji wszystkich tych mikroserwisów.

Nie musisz się angażować w to jak to działa, gdzie to trzymać, gdzie to wszystko uruchomić. I jednak jest zdecydowanie prościej, bo nie korzystasz z dodatkowych miejsc, tylko po prostu możesz sobie to zrobić w jakimś edytorze. Wystarczy, że jeden projekt odpalisz, nie musisz odpalać kilku. I to już jest ten plus.

 

Czy to nie jest tak, że każdy monolit, który będzie się rozbudowywał, w pewnym momencie będzie musiał przejść na podejście mikroserwisowe?

Czasami jest tak, że biznes nie pozwala albo nie chce przenosić tych projektów, w ogóle nie chce pracować w sposób mikroserwisowy czy agile’owy. Może mieć ku temu różne powody. Jedno to jest to, że np. nie chce przechowywać danych w chmurowych rozwiązaniach, gdzieś pośredniczyć czy przesyłać, tylko chce po prostu mieć w jednym miejscu pełne informacje. Natomiast inną stroną może być też to, że organizacja też nie jest do końca przygotowana – nie chce teraz migrować do mikroserwisu, bo jednak stare podejście waterfallowe do mikroserwisów nie jest dobrym rozwiązaniem – w ogóle sam waterfall nie jest dobrym rozwiązaniem, ale podejście takie na tyle nie pozwala. Na przyklad, wykorzystamy daną technologię orazz wybierzemy bazę relacjną lub nierelacyjną i później to nie jest tak prosto ich podmienić. Jednak jak się zaczynało monolitem i ma się jakieś stałe założenia, to jest to trochę łatwiejsze do modyfikacji. 

 

No i są też aplikacje, które chyba bardziej nie warto, niż że się nie da migrować z monolitu do mikroserwisów, bo powiedzmy, że one spełniają swoją funkcjonalność i nie interesują nas super modyfikacje, tylko jakieś takie drobne, utrzymaniowe sprawy, które cały czas działają produkcyjnie i zadowalają klienta.

 

Czyli po prostu koszt byłby tutaj większy niż zyski? 

Tak. 

 

Czy sądzisz, że mikroserwisy nadają się do każdego rodzaju aplikacji?

Jeśli to ma być jakaś prosta aplikacja, która ma ograniczone możliwości rozbudowy, to raczej bym się skupił na tym, żeby to był jakiś monolit, ewentualnie jakieś troszeczkę nowsze wersje – modularny monolit albo coś podobnego. Natomiast mikroserwis sprawdza się na pewno jako bardzo rozbudowany serwis w całych systemach, gdzie jest parę zespołów odpowiedzialnych za różne produkty i trzeba to wszystko razem połączyć. Wtedy jest fajnie w jakiś sposób podzielić ludzi na np. zespoły interdyscyplinarne, w których każdy zajmuje się swoim serwisem od początku do końca i każdy jest odpowiedzialny za niego na produkcji. Porównując do takiego monolitu – ta odpowiedzialność jest jednak rozmyta. Więc jak masz mniejszy zespół, to ten cały monolit jest jednak trochę sprawniej utrzymać dzięki mniejszej liczbie ludzi. Natomiast jak już masz więcej ludzi, to trochę tworzy się problem.

 

No tak, to już wspominaliśmy na początku. 

Dzięki Piotrek, że zgodziłeś się wpaść do nas i opowiedzieć co nieco o monolitach i mikroserwisach.

Dzięki, Nikodem.

 

Dziękuję także wszystkim widzom. Z Wami również żegnam, ale zachęcam Was do subskrypcji, do polajkowania filmiku. Jeżeli masz jakiś ciekawy temat, który chciałbyś, żebyśmy poruszyli – daj nam znać w komentarzach!

 

______________________________________________________________
Podcast DEVision to polski podcast IT dla programistów, którzy chcą rozwijać swoją wiedzę, posłuchać o ciekawych projektach oraz zainspirować się innymi. A to wszystko w przyjemnej formie rozmowy, której możesz słuchać w tramwaju, na siłowni, a nawet w pracy 😉 💌 Zapisz się do naszego newslettera: https://bit.ly/37TTNCK 🌏
Więcej o nas przeczytasz na stronie: https://bit.ly/3Pttiox

Obserwuj nas na social media: 🚀
LinkedIn: https://bit.ly/3PxlHFQ
🎧 Spotify: https://spoti.fi/39xU0fm
🎧 iTunes: https://apple.co/3PsjhrQ