Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io/33. Dobra panie Łukaszu, zacznijmy od linków, a potem będziemy podsumowywali. Co tam wyszukałeś?

Łukasz Kałużny: Wpis może nie do końca świeży, ale bardzo dobry. Na blogu z cloud’a Googlowego, o MLOps-ie i tak naprawdę o takich podstawowych fundacjach, fundamentach, wymaganiach, żeby ten MLOps miał sens. Bo im bardziej patrzę na, raczej tak, na machine learning i IT, to jakby to były dwa zupełnie różne światy.

Szymon Warda: Ja mam wrażenie, że cały ML tak naprawdę, wygląda jak raportowanie sprzed 10, 20 lat, czyli dajcie nam dostęp do produkcji i nie zadawajcie pytań.

Łukasz Kałużny: Dokładnie, a jest bardziej kluczowy niż w niektórych miejscach raportowanie. Albo ludzie chcą, żeby był kluczowy.

Szymon Warda: Tak.

Łukasz Kałużny: W szczególności kiedy chcą zacząć tworzyć modele gdzieś nie wiem czy batchowe, online’owe, które będą realnie wspierać systemy, a nie tylko robić jakieś predykcje i pokazywać trendy.

Szymon Warda: Bo z raportów często korzystają tylko tacy biznesowi, finansujący użytkownicy, a z ML-a często ci frontend użytkownicy. Więc jak tam będzie wtopa, to może być nieciekawie.

Łukasz Kałużny: Więc dokładnie. Ja mam trochę podejście, że jeżeli tworzysz kod, to obowiązują Cię te same zasady jak cały kod w IT. I mam dokładnie tą samą pretensję gdzieś do no code’ów, low code’ów, tych rozwiązań, że one nie mają cyklu życia. I to też dobrze pokazuje takie rzeczy, że oprócz na przykład MLOps-a, oprócz Continuous Integration pojawia się pojęcie, czy Continuous Tradingu, czy walidacji danych, czy testowania tak samo, ale pojawia się też jedna piękna rzecz, o której ludzie nie mówią, czyli audytowalności, rozliczalności tego, co robimy po tym, jak to odpalamy. Więc…

Szymon Warda: Ale tu rozliczalności będą pewnie zmieniały regulacje Unii Europejskiej. Bo tam był ruch, żeby to było tłumaczalne, to trochę umarło, ale ten temat wróci.

Łukasz Kałużny: Wrócił, tak jak nagrywamy, nasz kraj, nasi wysłannicy zablokowali to przez słowo gender teraz, wetują, próbują zawetować tą inicjatywę, bo znajduje się tam gender, bias czy coś takiego. Ale nie kontynuujmy tego tematu.

Szymon Warda: Nie, błagam, nie polityka.

Łukasz Kałużny: Dobra, a co po Twojej stronie?

Szymon Warda: Po mojej stronie kontynuacja tematu, który już raz mówiłem. Mianowicie cały trend, w jaki sposób rozliczać chmurę. I tu wysunął się całkiem ciekawy wpis i produkt od Spotify. Spotify jak wiemy, generalnie chodzi na Google Cloudzie i Spotify ma cały produkt backstage.io, który, co ważne, jest w CNCF-ie, więc to nie jest coś, co oni mają…

Łukasz Kałużny: Już w CNCF-ie.

Szymon Warda: Tak, już jest w CNCF-ie. Jest oczywiście pewnie na GitHubie i tak dalej, i tak dalej. Ale co zrobili? To jest taka platforma, gdzie oni obserwują swoje systemy. Można przez system pluginów dodawać różne możliwości. I teraz dodali bardzo ciekawy plugin do rozliczalności kosztów chmury. I tam jest kilka rzeczy takich ciekawych. Przede wszystkim graf w generalnie do monitorowania cost, kosztów kontra biznesu, czyli które procesy jak kosztują. Wcześniej mówiliśmy o tym w kontekście generalnie ML i OPS-ów, a teraz mówimy w kontekście procesów biznesowych. I to jest super. Kolejne, dodali jako KPI dla zespołu, czy koszty chmurowe zespołu są poniżej założeń biznesowych. Fenomenalne! Naprawdę super.

Łukasz Kałużny: Wiesz co, ja na backstage’a jeszcze z innego, bo ja backstage’a śledzę już trochę czasu, trochę z innego powodu, jako dość ciekawy serwis, katalog.

Szymon Warda: Tak też to mają. Naprawdę.

Łukasz Kałużny: Bo z tego to wyrosło, z serwis katalogu i takich dashboardów operacyjnyc, od tego się tam zaczęło, tych service definition i service catalogu. I powiem Ci, że wygląda to, od tej perspektywy, wygląda to dobrze. I druga sprawa, że jest napisana w języku, który dla większości firm, które nawet chcą używać open source, jest ok, bo jest wszystko w JavaScripcie, TypeScripcie. 94% kodu to jest TypeScript. I to też dla mnie jest taką ciekawą rzeczą, że może to być dla niektórych osób, które potrzebują takiego stosu narzędziowego, o, inaczej, potrzebują takiego stosu narzędziowego, to może być ciekawa rzecz. Nie powiem, że dla każdego.

Szymon Warda: Dla mnie jest to naprawdę ciekawy produkt pod względem generalnie, bo mamy cały service mapy i tak dalej. A tu mamy taki bardziej biznesowy, takie bardziej menedżerskie spojrzenie na cały ekosystem i system. Naprawdę, po pierwsze, cieszy mnie ruch w kierunku rozliczalności tej chmury, bo między innymi nie będziemy robili over engineering i over optymalizacji. A po drugie, jako produkt backstage naprawdę warty rzucenia okiem.

Łukasz Kałużny: Jedna ciekawostka, którą ludzie będą nienawidzić albo kochać, opis komponentów, na przykład API i innych rzeczy. To są YAML-e… Ale raczej YAML, ja się śmieje, że YAML. Chodzi o format zapisu kontraktu, jest Kubernetesowy. Czyli jest jak Custom Resource Definitions Kubernetesa, jest API version, Kind, metadane, specka.

Szymon Warda: To już powoli będzie standardem generalnie.

Łukasz Kałużny: Ja się śmieję, ale dlatego widziałem już to, coraz częściej się pojawia sposób taki opisu konfiguracji i tylko się śmieję, że dlatego niektórzy mogą go hejtować, bo przypomina coś Kubernetesa. Dobra.

Szymon Warda: Niech się przyzwyczają. Lecimy do naszego głównego tematu. Podsumowujemy serię odcinków, która się trochę rozciągnęła nam, o mikroserwisach. I…

Łukasz Kałużny: Może wiesz co, można też powiedzieć, że z pierwotnym planem nawet trochę skróciła, żeby się…

Szymon Warda: Tak, zdecydowanie się skróciła. I mamy takie dwa obszary generalnie. Po pierwsze, pogadamy sobie czego zabrakło, a potem przejdziemy przez opinie, uwagi zebrane z tych wszystkich odcinków. Więc Łukaszu, zacznijmy od czego zabrakło? Pierwszy temat.

Łukasz Kałużny: Pierwszy, service discovery, z którym się nie zgadzałeś, żeby nagrywać odcinka, a się okazuje, że wpasowuje się tutaj idealnie w tą serię. Bo przy mikroserwisach powinniśmy sobie porozmawiać też o toolingu i service discovery. Kompletnie to olaliśmy tutaj.

Szymon Warda: Tak, olaliśmy i ja się zgodziłem, ponieważ o service discovery mówiliśmy wcześniej w innych odcinkach i ten temat już trochę wałkowaliśmy i mówiliśmy, jak to powinno wyglądać. Dlatego dla mnie to jest takie fajnie, ale nie róbmy rebrandingu materiału tylko po to, żeby umieścić to w kontekście mikroserwisów.

Łukasz Kałużny: Tak, więc zabrakło nam mikroserwisów, raczej service discovery w tym zupełnie świadomie.

Szymon Warda: Tak.

Łukasz Kałużny: Bo jest. I tak naprawdę to, co moglibyśmy powiedzieć, to jest hej, wykorzystaj jakieś popularny tooling, bo reszta, która się znalazła, ona jest niezależna. Jeżeli popatrzymy, czy to samo, czy to jest firma i robimy jakiś SOA service discovery, czy tylko nasz system. Sorry, to się nie różni jakoś za bardzo, mimo jakbyśmy chcieli. To jest tylko biblioteka, którą użyjesz w swoim kodzie. Nic więcej.

Szymon Warda: Tak. Kolejnym elementem, który też ja byłem za tym, żeby wywalić, to jest cały monitoring, bo o monitoringu mieliśmy całe trzy odcinki, całkiem niezłe odcinki, więc totalnie wylatuje. Ale żeby nie było, monitoring dalej jest krytyczny w mikroserwisach tak naprawdę, w każdej akcji serwisowej.

Łukasz Kałużny: Tak więc tutaj zapraszamy wstecz, mamy trzy odcinki Observability podzielone na tak naprawdę trzy jego główne kategorie jakie występują. Więc można się cofnąć wstecz i to jest uniwersalne. W szczególności distributed tracing.

Szymon Warda: Zgadza się. Konieczne jak najbardziej. Nie mówimy, że jest nieważny. Jest super ważny, ale już o tym gadaliśmy. Nie ma sensu. Kolejny element.

Łukasz Kałużny: Dobra i to jest taki dla mnie, zabrakło skalowania, o tak, powiedzmy sobie, w ogóle to totalnie. Bo to jest taki często selling point mikroserwisów, będziemy mogli się łatwiej skalować. Ale to jest trochę jak z rozmiarem: hej, jeżeli piszesz poprawnie aplikację, to ona się da w ten czy w inny sposób wyskalować. Więc po co o tym rozmawiać.

Szymon Warda: Tak, przy czym nie zawsze skalowanie ma tylko jedną gwiazdkę. I tak pewnie najwolniejszym elementem będzie Twoja baza danych. Mało który system widziałem, żeby był przyblokowany przez tą warstwę aplikacyjną. Więc to jest takie zawsze: zobaczymy jak to będzie wyglądało. Raczej bardzo… A ciężki compute można rozrzucić na wiele node’ów jak nie tyka bazy.

Szymon Warda: Dokładnie tak. To o czym mówiłeś generalnie, że jak jest napisany dobrze, można porozrzucać, przeżyjemy.

Łukasz Kałużny: Można byłoby zrobić o wzorcach architektonicznych, które wspierają skalowanie. I to nie są mikroserwisy, tylko to jest każda aplikacja.

Szymon Warda: To możemy o tym pomyśleć generalnie, jak to zrobić. To może być dobry pomysł. Kolejne, to jest martwienie się na przyszłość o byciu mocno agnostycznym i rozszerzalnym. Nie było o tym. Dla mnie osobiście to cała taka idea martwienia się na przyszłość i tak dalej, jak zobaczymy ile średnio obecnie żyje system informatyczny, kiedyś on żył około 20-paru lat, obecnie średnio system żyje około 7 lat. Ta przyszłość…

Łukasz Kałużny: Wiesz co, czwarty, piąty rok ludzie zaczynają go często przepisywać.

Szymon Warda: O tym właśnie mówię generalnie. Dokładnie. Ta przyszłość, o której myślimy, my myślimy kategoriami sprzed 20 lat, a te systemy z reguły nie żyją aż tak długo. Kolejna rzecz, która wyleciała i też maczałem przy tym rączki, to Łukaszu, co wyleciało?

Łukasz Kałużny: CI/CD.

Szymon Warda: Bo to nudne jest.

Łukasz Kałużny: Raczej, czy wiecie, jeżeli na to popatrzymy, CI/CD, tak, właśnie, żałujcie, że nie widzicie teraz miny Szymona jak się dusi ze śmiechu, ale CI/CD to jest po prostu narzędzie, które niczym się nie różni. Jedyną rzeczą, która jest skomplikowana, to jak zrobimy sobie rozproszony monolit i musimy skoordynować kadencję wydawniczą. To jest jedyna rzecz, która jest wtedy tam bardzo problematyczna. A drugie, pierwszy release zero całego środowiska może być problematyczny. Ale to nie jest rzecz, to nie są wzorce, tylko to jest rozwiązywanie po prostu bolączek, jakie występują.

Szymon Warda: Tak, dobrze zrobione środowisko mikroserwisowe powinno mieć generalnie release każdego serwisu osobno i generalnie nie martwimy się niczym więcej. A potem wchodzi synchronizacja i koordynacja wydawnicza i tutaj nie ma za bardzo co nagrywać. Ogarnijmy się.

Łukasz Kałużny: Raczej nie, to jest per projekt i organizacja, bo każdy ma inny cykl życia swojego wewnętrznego i to jest, sorry…

Szymon Warda: Tak.

Łukasz Kałużny: Tym jest to narzucane.

Szymon Warda: Ale o cyklach życia mówiliśmy dużo, między innymi przy danych, bo to nam…

Łukasz Kałużny: Tak i przy kontraktach.

Szymon Warda: Tak, czyli widzieliśmy generalnie, gdzie ta synchronizacja będzie, jak będzie występowała i to nam całego CI/CD-ka implikuje po prostu.

Łukasz Kałużny: Dobrze Szymonie, to teraz druga rzecz.

Szymon Warda: Mój konik.

Łukasz Kałużny: Twój konik, który jest odkładany.

Szymon Warda: Jest odkładany generalnie, bo ciężko… To jest temat mocno wizualny. Mianowicie komunikacja między usługami, czyli ja to nazywam zawsze wzorcami w komunikacji synchronicznej i wzorcami w komunikacji asynchronicznej. I cały czas tak się zbieramy, chyba Łukasz od startu w ogóle pomysłu na Patoarchitektów, zbieramy się, żeby to nagrać. I pytanie do Was: nagrywać, nie nagrywać? Dajcie znać.

Łukasz Kałużny: Tak. A samo czemu tutaj zabrakło? Znowu to nie jest rzecz w ogóle mikroserwisowa, to jest… Komunikacja jest zupełnie uniwersalna. Zresztą trochę o komunikacji było, bo też zobacz, że mieliśmy cały odcinek poświęcony Circuit Breakerowi.

Szymon Warda: Tak, który powoli wciskam to pojęcie do Twojej głowy i powoli się udaje.

Łukasz Kałużny: Tak, tak, nie jest to keep it simple stupid, więc masz problemy z tym. Dobra.

Szymon Warda: Tak.

Łukasz Kałużny: Czyli tak, komunikacja, podsumowując, ona jest niezależna od systemu. Ona istnieje. Po prostu w mikroserwisach mamy jej więcej, mamy jej wewnątrz. Zamiast wołać do modułów jak w monolicie.

Szymon Warda: Ja mam wrażenie, że przez problemy w mikroserwisach te wzorce projektowe wzorców komunikacji nagle przypomnieliśmy sobie o nich. I to jest dużo nowych nazw, więc hype train w tym kierunku poszedł. Bywa, tak jest.

Łukasz Kałużny: Dokładnie.

Szymon Warda: Łukasz, ostatnie.

Łukasz Kałużny: Organizacja pracy, bo to jest taka ciekawa rzecz, bo zdarza nam się to poruszać, a mikroserwisy niby narzucają, że może przydałoby się tak zagłębić ten temat, zobaczyć o co chodzi, jak to poukładać. I w wielu pewnie odcinkach mogliście zobaczyć, że gdzieś tam do tego piliśmy, pokazywaliśmy to, coś tam robiliśmy, pstryczki wrzucaliśmy. Ale jest jedna istotna rzecz, którą już o mikroserwisach sobie trochę powiedzieliśmy, bo zwykle, jeżeli mamy mikroserwisy, to mamy Agile na sztandarach.

Szymon Warda: Wiadomo.

Łukasz Kałużny: Zazwyczaj. I był taki ciekawy odcinek, pierwszy zresztą w kontekście architektury, dlatego też to pozostawiliśmy. I pierwszy nasz odcinek był Agile vs architektura. I tam troszeczkę można znaleźć pewnych rzeczy, które pewnie z naszej perspektywy, jak byśmy nagrywali, pewnie by się nie zmieniły za bardzo, bo nadal te nasze przekonania są tam aktualne.

Szymon Warda: Tak, w ogóle organizacja pracy to jest taki motyw, o którym nie robimy odcinka, ale my, to jest temat, który poruszamy w większości odcinków, znowu o danych, o kontraktach.

Łukasz Kałużny: O repo.

Szymon Warda: O repo.

Łukasz Kałużny: Nawet o repozytoriach.

Szymon Warda: Tak, więc jest. Ale żeby cały odcinek o tym zrobić? To jest bardzo specyficzne per reorganizacja tak naprawdę.

Łukasz Kałużny: Czy wiesz co, nawet jeden to jest ten biznes kontekst, a drugi nawet ludzie, którzy tam pracują. Czasami najprościej pary porozsadzać do różnych mikroserwisów, żeby się ze sobą nie komunikowali bezpośrednio.

Szymon Warda: Bywa, chociaż to tak nie jest najlepszy pomysł.

Łukasz Kałużny: To jest antywzorzec, ja wiem, ale pozwala czasem coś ruszyć do przodu. Dobra, Szymonie, teraz przejdźmy sobie, gdybyś rzucił swoje wrażenia, tak jak poczytałeś komentarze i całość tą, jakbyś tak powiedział, co Cię trochę wkurza w tych mikroserwisach? Co jest dla Ciebie patologiczne?

Szymon Warda: Łukasz, ja bym powiedział, że nie trochę, to bardzo wkurza, mnie strasznie denerwuje i wydaje mi się, że to jest jeden z problemów tego, czemu teraz zaczyna się wylewać powoli fala hejtu na mikroserwisy, to jest to, że akcent mamy na mikro, w całych mikroserwisach. Dla mnie to jest architektura serwisowa. To, że chcemy użyć słowa klucz i użyć tutaj “mikro”, to jest główny problem. Zamiast dobre serwisy, które dobrze się komunikują, to skupiamy się na tym jak bardzo to powinno być mikro. I o tym dyskusję też mieliśmy: mikro, nano, piko i cała seria generalnie, jakie inne słowo klucz może załapać. Cieszy mnie to, że spodobało się określenie, którego użyliśmy, że jak nie umiesz monolitu, to nie pchaj się w mikroserwisy. To jest prawdziwe.

Łukasz Kałużny: Czy wiesz co, ja się tak wtrącę, bo tak mam takie teraz, bo mi się to też podoba, ale mam takie przemyślenie, że całość tak naprawdę to jest tylko kod, tworzysz system.

Szymon Warda: Myślenie o tym, jak patrzę, w którym kierunku idzie myślenie o architekturze systemów, to wydaje mi się, że przy mikro powinniśmy generalnie dać sobie trochę luzu na poziomie architektury jednego serwisu, a skupić się dużo bardziej generalnie na całym systemie. I za bardzo zaczynamy się brandzlować nad tym, jak powinien wyglądać ten mały kodzik wewnątrz i tak dalej. To jest kupa. Mikroserwisy to jest też sposób na podzielenie kupy na mniejsze kupy, żeby dało się tymi kupami zarządzać. Będzie mniejsza, większa kupa, różnie bywa. Jeżeli działa, to działa. Skupmy się na całym systemie, a nie na pojedynczych mikroserwisach. To nie ma większego sensu.

Łukasz Kałużny: A tak naprawdę jak chcesz się skupiać, bo są osoby, sorry, niektóre osoby dają większą wartość wokół, że tak powiem, rzeczy niż dostarczanie kodu biznesowego. Jeżeli już musisz, to skup się tak naprawdę na czymś, co będzie reużywalne, czyli jakiejś bibliotece albo części do toolingu wokół tego co macie, a nie szlifowaniu tego jednego serwisu.

Szymon Warda: Albo ważnie na systemach, które się często zmieniają. Jeżeli jakiś serwis zmieniasz generalnie przez 4 godziny w miesiącu, tam może być pierdolnik jaki chcesz. Obojętne. Jeżeli coś zmieniasz generalnie przez 120 godzin w miesiącu i będziesz to zmieniał, to tam to faktycznie kodzik powinien ładnie wyglądać. A Ciebie co wkurza?

Łukasz Kałużny: Mnie najbardziej CI/CD o dziwo, jak sobie tak pomyślę. Bo to jest… Raczej to jest cały trend, który gdzieś występuje, rzeczy, której nienawidzę. Ona się kryje pod nazwą DevOps Engineer.

Szymon Warda: Wiem o czym mówisz. Tak.

Łukasz Kałużny: Tak, to jest DevOps Engineer. Jest to taki problem, że developerzy zaczynają być trochę jak lekarze, jak sam stwierdziłeś, że zaczynamy się i też w wielu miejscach zaczynamy się już aż za bardzo specjalizować i zapominamy o high level overview. I problem jest dla mnie taki, że developer powinien robić CI/CD i powinien umieć swoją aplikację zdeploy’ować od swojej stacji tak naprawdę, od swojego środowiska developerskiego, aż po środowisko testowe. I to, co mnie ewidentnie, naprawdę mnie to boli, żeby nie używać innych słów już, że ten człowiek nie potrafi wejść i skonfigurować CI/CD i nie potrafi odpalić poza laptopem swojej aplikacji, jeżeli ma na przykład już dostarczoną platformę.

Szymon Warda: A to się dopytam w tym temacie. Przez CI/CD rozumiesz czy ten developer pisze też YAML-e Kubernetesowe?

Łukasz Kałużny: Czy może? Stary, nie oszukujmy się, jeżeli mówimy w kontekście jednego serwisu. Jeżeli ktoś już to zbootstrapował, nazwijmy to, że masz przykład w organizacji jak to masz robić, to dockerfile jakiś czy ten YAML Kubernetesowy czy kawałek terraforma, one nie są, sorry, nie gryzą. Przydałoby, żebyś wiedział gdzie działa Twoja usługa.

Szymon Warda: Te podstawy, podstawy powinny być, bo inaczej mamy efekt posiadania długich grabi i przerzucania przez płot.

Łukasz Kałużny: Nie, nie, bo brakuje takich dla mnie, dlatego mnie to naprawdę denerwuje, że nie ma pewnego zrozumienia, co tam się dzieje za płotem po tym jak wypchnę mój kod do repo. I to jest trochę i to jest ten syndrom: u mnie to działa, który jest chyba pogłębiany, zamiast iść w drugą stronę.

Szymon Warda: Pamiętajmy o tym, że im później buga wykryjemy, tym on jest droższy. I to nie jest tak o półtorej droższy, tylko jest kilkukrotnie droższy, nawet kilkudziesięciokrotnie. Więc debugowanie rzeczy generalnie na jakimś teście, środowisku testowym gdzie on tu już chodzi w Kubernetesie albo chodzi w serverlessie czy gdziekolwiek indziej i dopiero wtedy wychodzi błąd, że coś nie działa, jest złym pomysłem i drogim pomysłem. Więc zgodzę się z Tobą w zupełności. Ta cała idea, taka właśnie ownershipu, ona była na sztandarach i totalnie umarła.

Łukasz Kałużny: Wiesz, zastanawiałem się jeszcze, czy wrzucić tu testowanie, albo na przykład jego braki czy zupełnie inne podejście. I kurde, mam z tym mieszane, miałem z tym bardzo mieszane uczucia, bo to powinno być, testowalność powinna być pewną higieną pracy. Tylko pytanie, jak to wszystko testować i w jakim podejściu?

Szymon Warda: A ja na to mam dość prostą odpowiedź, jak bardzo będzie Cię bolała dupa, jak to wybuchnie? Proste.

Łukasz Kałużny: No i ja tutaj mam… Wiesz co? Zgadzam i nie zgadzam się z Tobą zarazem, bo tak, jest to taka decyzja po prostu zwykłego risk assessmentu. Tylko czy developer ją powinien robić i zespół developerski?

Szymon Warda: Tak, jeżeli będziesz dobrze ten zespół developerski napychał i dawał feedback generalnie z błędami z produkcji. Jeżeli nie będą ignorowane i: są te errory, proszę naprawić. Ma nie rzucać errorami i proszę to zrobić. Jak zaczniesz to robić, to nagle okazuje się, że monitoring jest przydatny, nagle logi zaczynają ładnie wyglądać, nagle, kurczaki, da się zrobić.

Łukasz Kałużny: I słuchaj i tutaj trafiasz do tego, co nie chciałem w ogóle mówić, czyli takie bardzo stare z 2006-7 słowa? You build it, You run it. I wiesz, to jest takie pytanie właśnie, bo ten DevOps to miała być współpraca w ogóle. Jak popatrzymy mikroserwisy, to DevOps jest taką rzeczą bardzo często, jako praktyka powinna występować, nazwijmy to, tylko ludzie zapomnieli, że tam jest dev i ops.

Szymon Warda: Tak, zgadza się.

Łukasz Kałużny: Nawet na tych, na tej całości. Więc to zostawmy to jako wkurzające. Mnie brakuje podejścia do CI/CD, w szczególności od strony osób, które wytwarzają ten kod.

Szymon Warda: Tu bym się zgodził.

Łukasz Kałużny: Dobra Szymonie, bo zadaliśmy na social mediach pierwszy raz Patopytanie odnośnie co Cię wkurza, co Ci się podoba, o czym ludzie nie mówią w ramach mikroserwisów? I wybraliśmy sobie dla nas najciekawsze komentarze. Jakbyś Szymonie zaczął od tego Tobie, co wpadło w oczy.

Szymon Warda: To co mi się przewija w komentarzach, to jest dużo uwag o tym, że nie poruszaliśmy tematu serverlessa. Ponownie, serverless był tylko w starych odcinkach. Ja myślę, że słusznie, bo serverless zdejmuje bardzo dużo problemów z mikroserwisami. Oczywiście nowe wprowadza. Ponownie, stare odcinki, tu się niewiele zmieniło i ja się z tym w zupełności zgodzę. Nie ma tego, świadomie pominięte, bo bardziej skupiliśmy się na ogólnych problemach. Bo większość rzeczy, o których mówiliśmy, dalej zostają i tyle praktycznie. Świadome pominięcie, jak najbardziej. Co u Ciebie Łukaszu?

Łukasz Kałużny: Wiesz co, mi się tak całość podoba, że dojrzewamy, bo praktycznie nic nie było o narzędziach. Było o technikach. O technikach i bolączkach. Czyli był taki fajny, był feedback, a tam praktycznie chyba poza takim serverlessem…

Szymon Warda: Nie było za dużo.

Łukasz Kałużny: Jak sobie popatrzę, był jeden tam, był jeden komentarz, chyba Marcin Wojtczuk. Gdzie tutaj… Tak, tak, bardzo fajne określenie. Chyba za dużo z Javą miał wspólnego, w sensie negatywnym. “Spring Boot jebnąć prądem” to jedyny komentarz, który gdzieś narzędzia tak jawnie wskazuje po całości. Więc to mnie cieszy, że było bardziej o, albo było o hype’ie, czyli ten hype CV Driven Development i hype, bo przyszedłem z konferencji. Albo właśnie to, co powiedzieliśmy o dojrzałych rzeczach i problemach, które są realnie.

Szymon Warda: Może dlatego, że w tym roku konferencji za bardzo nie było.

Łukasz Kałużny: Nie było. Ty, to jest ciekawa analiza rynku.

Szymon Warda: Mam dzisiaj dobry dzień.

Łukasz Kałużny: Dzień dobry.

Szymon Warda: Dobra, to ja się teraz wtrącę generalnie z komentarzem od Radka Maziarka. Bardzo fajna uwaga, trochę w kontekście tego, co pominęliśmy świadomie, co się zbieramy, mianowicie o komunikacji, że jak wygląda komunikacja między serwisami, jak to jest przemyślane i jak wygląda komunikacja na poziomie technicznym, to jest bardzo, bardzo istotne i na poziomie biznesowym. I że to jest często omijane i że tu jest często ta pięta Achillesa, jeżeli chodzi o podział systemów na architekturę serwisową. Już nawet pomijam tutaj mikro, bo to już uniwersalny jest. I tak, zgadzamy się. Trochę na ten temat, mówiliśmy w kontekście generalnie baz, kontraktów i tak dalej. Ale ludzie nie umieją tego kompletnie robić i myśleć o komunikacji, a komunikacja jest kluczem. Fajne raz było stwierdzenie, pamiętam, że jak chcesz się nauczyć architektury mikroserwisowej, to weź książkę o wzorcach integracji między systemami, bo to jest dokładnie to, tylko w innej skali, dużo większej.

Łukasz Kałużny: Wiesz co, zastanawiam się, czy Cię, kur**, przepraszam, polecanie tej książki, jeżeli mówisz o Enterprise Integration Pattern mam różnie, mam bardzo mieszane uczucia i nie wiem czy Cię nią nie walnąć.

Szymon Warda: Żeby nie było, przeczytaj. Nie mówię, że zawsze stosuj.

Łukasz Kałużny: Przeczytaj. Bo wiesz, za to przyjadę do Ciebie z tą książką.

Szymon Warda: Mam ją , nie musisz z nią przyjeżdżać. Nie martw się. Bo to jest tak, przeczytaj, tam dużo tej wiedzy jest. To, czy stosować niektóre rzeczy, które nie stosować, to jest zupełnie inna bajka. Ale świadomość, że pewne rzeczy były, ponownie, nie wymyślajmy wszystkiego ciągle od nowa.

Łukasz Kałużny: Może inaczej, popatrz na wzorce i pamiętaj, że tamta książka była pisana pod ciężkie SB.

Szymon Warda: Zgadza się, więc trzeba to odchudzić, jak najbardziej tak. To jest ta gwiazdka, którą trzeba jak najbardziej mieć myśląc o wzorcach projektowych w architekturze serwisowej, lżejszej, nazwijmy to tak.

Łukasz Kałużny: Dobra, z mojej strony komentarz Michała Franca, który mi się spodobał i bardzo słusznie. “Mnie nic nie wkurza”, ale bardzo dobrze zauważył to, co mnie akurat wkurza, czyli że trzeba okiełznać DevOpsa.

Szymon Warda: Tak.

Łukasz Kałużny: I to nie jest, że to nie jest i sorry, to nie jest po prostu no go. Musisz to zrobić i koniec, nie ma. Ale też bardzo ważna rzecz, że bardzo fajnie powiedział, że to jest, większość osób ma za mało wiedzy i doświadczenia, by przyznać, że to jest to zależy. To mi się spodobało w tym komentarzu i podejściu, bo Michał właśnie powiedział: każda osoba, która nadmiernie chwali albo nadmiernie hejtuje ten kierunek, ma po prostu za mało wiedzy i doświadczenia, by przyznać, że to zależy.

Szymon Warda: Ale oczywiście to jest… Czemu przechodzimy z technologii do technologii? Dlatego, że z reguły pojawia się hype na coś, zaczynamy wszyscy tego używać nie rozumiejąc jak to działa i potem używamy tego źle i zaczyna się fala hejtu i potem kolejne rzeczy.

Łukasz Kałużny: Jedna rzecz. Druga sprawa, kompetencje. Na przykład łatwiej było nam zbudować w X, przejść na Y, bo łatwiej nam pozyskać kompetencje na rynku albo ludzie są tańsi. Słyszałem już takie stwierdzenie, że weźmiemy Javę, bo można znaleźć ludzi na kontenery. Więc są takie pomysły na to. Dobra, Twój następny?

Szymon Warda: Krzysztof Hałasa. Bardzo ciekawe stwierdzenie, też trochę odwołujące się generalnie do tego, co Radek powiedział, że wepchanie systemu to… Inaczej, pęd we wpychanie systemu w mikroserwisy, bo teraz jest tak, że często widziałem takie cele, że chcemy mieć architekturę mikroserwisową jako organizacja. Czemu nikt nie pisze czemu, ale generalnie chcemy, ale chcemy mieć.

Łukasz Kałużny: Tak znajduje się w strategiach obok kontenerów.

Szymon Warda: Tak, dokładnie. O ile taki pęd w kierunku chmury w zupełności rozumiem, bo to jest faktyczny zysk biznesowy, oszczędności, to wpływa na organizację. Te mikroserwisy? Może niekoniecznie. Ale komentarz, że te systemy wypchane w mikroserwisy to są tykające bomby utrzymaniowe, które wybuchną za 3, 4 lata, gdzie nagle biznes powie: to zmieńcie tą jedną ikonkę, a my powiemy ok, 3 tygodnie. Bo tak będzie generalnie, ponieważ te granice są złe, są źle zbudowane, niektóre systemy nie powinny być podzielone po prostu.

Łukasz Kałużny: Wiesz co, ja widzę, nazwę to patologią, że bardzo często przez ten cały hype software house’y próbują w ten sposób zamiast zbudować coś od razu mówią, że zbudujemy Ci mikroserwisowe i rachunek za billowanie godzin, bo bardzo często są w time material, żeby ryzyko przelać na klienta.

Szymon Warda: Wiadomo.

Łukasz Kałużny: Że jest budowany system i architektura, o której powinien zdecydować klient, a nie dostawca.

Szymon Warda: Co więcej, często te architektury są w ogóle w ofercie wysyłane, gdzie oferta jest z reguły budowana na bazie dokumentu klienta, który ma 3, 4, 5 stron. Więc tak, wiem, jak to się kończy.

Łukasz Kałużny: Tak jak mówisz o tej bombie, która leci. Moim zdaniem dostawcy, sorry, nie powinni… Raczej inaczej, jeden grzech klientów, że pytają od razu, by default zakładają architekturę mikroserwisową.

Szymon Warda: Tak.

Łukasz Kałużny: W ogóle nie podchodząc. Jeżeli ktoś zakłada i na przykład chciałby sourceować Cię do napisania serwisu czy przygotowania pod to platformy, backgroundu, to jest super. Ale jeżeli zakładasz, że bez analizy cały system jest mikroserwisowy, to jest ciekawa rzecz. I drugi grzech, to jest tak naprawdę dostawców softu, a raczej software house’ów, bo nie oszukujmy się, że chodzi o to, że dostarczają te mikroserwisy na siłę, bo będzie łatwiej rozwijalne, skalowalne i lecimy całym bullshit trainem z konferencji.

Szymon Warda: Tak, tak, tak, tak, tak, tak. Niestety to są bomby. One wybuchną za jakiś czas i będzie ciekawie bym powiedział. Dobrze Łukaszu, co u Ciebie?

Łukasz Kałużny: Ostatni komentarz, który mi tak wpadł, bo wpadło dużo, ale żeby też nie przedłużać, ostatni, który mi wpadł to Bartłomiej Klimczak. I dość fajnie wspomniał czym tak naprawdę są mikroserwisy i czy rzeczywiście chodzi, by było można je przepisać w dwa tygodnie. No i to jest dobre. Wspomniał jeszcze tak naprawdę o modularnym monolicie i problemach z komunikacją i monitoringiem, bo to jest standardowy problem. Ale właśnie, czym tak naprawdę są mikroserwisy i czy rzeczywiście musimy to przepisywać co dwa tygodnie? Sorry, przepraszam, zadam Ci tak pytanie, ile razy spotkałeś się z tym, że zrealizowano to w ciągu pierwszego roku życia przepisywaniem mikroserwisu od zera, jakiejś części, że była skasowana i wstawiamy nowy, albo nawet w innej technologii?

Szymon Warda: Okrągłe zero. I była, widziałem wymianki na gotowe systemy, jak najbardziej tak. Ale żeby customa przerobić na swojego customa? Nie. Żeby zrobić od zera, a nie zrobić refaktoringu. Bo z reguły, sorry, nie mamy aż tak super. Ten poziom wiedzy o tym jak ten serwis powinien wyglądać, on idzie falami. To nie jest tak, że nagle budzimy się i zeszło z nieba: już teraz wiem jak to powinno wyglądać. Nie, to z reguły idzie falami i z reguły tak to idzie przez refaktoringi po prostu.

Łukasz Kałużny: Wiesz co? Tak. I to właśnie ja też to najczęściej widuję. Raczej czy widziałem zamiany? Inaczej, widziałem, że w cyklu życia coś zostało wygaszone.

Szymon Warda: To kilka razy, jak najbardziej.

Łukasz Kałużny: I to jest właśnie najciekawsze, bo to jest piękno wtedy tej architektury, że zmieniały się wymagania biznesowe i nikt tego nie refaktorował, tylko zaczął po prostu pisać nową usługę, a część kodu zrobił amazonowego copypasta tylko tych rzeczy, które potrzebował, ale zaczął tworzyć w ogóle znowu od nowa, znowu nową usługę, która już będzie dostosowana do nowych realiów, zamiast refaktorować stare. I takie rzeczy się zdarzają i tu jest zajebista wartość tego, jeżeli zrobimy to poprawnie.

Szymon Warda: Tak, ale znowu to jest architektura serwisowa. To mikro nie musi być, to nie musi być wcale w temacie tej genezy zespołu od pizzy w dwa tygodnie. Mi się przypomina temat, który rzuciłeś chyba dwa odcinki temu, że to wszystko wynika z tego, że po prostu, że jeżeli zespół jest mały i krótko wytwarza, to można łatwo go zamienić na inne. Traktowanie tych developerów po prostu jak prąd.

Łukasz Kałużny: Commodity.

Szymon Warda: Tak,.

Łukasz Kałużny: Tak. Dobra, to wrapujemy.

Szymon Warda: Co Ciebie ucieszyło?

Łukasz Kałużny: Wiesz co, ogólnie mało narzędzi, bo nie było w tych komentarzach… Może inaczej, patrząc się na całe komentarze, znowu się powtórzę, tu nie było stricte ktoś poza jednym tym Spring Bootem, nie padały narzędzia, ale padały rzeczy z poziomu tak naprawdę organizacji architektury.

Szymon Warda: Naprawdę ja się, aż łezka w oku się kręci, jestem dumny z naszych słuchaczy generalnie.

Łukasz Kałużny: Nie było narzędzi, mimo że sami też mocno poruszaliśmy w niektórych miejscach.

Szymon Warda: Bo gdzieniegdzie narzędzia sporo zmieniają. Ale to nie jest, że zaczynamy od młotka i potem myślimy gdzie go użyć, co zupełnie się nie zgodzę.

Łukasz Kałużny: A co po Twojej stronie?

Szymon Warda: Bo moje przemyślenie bardziej takie. Bo widzę, że zaczyna się fala, taka powolna fala hejtu w kierunku mikroserwisów, bo tak wygląda cykl życia każdej technologii. Co mnie dziwi? To na horyzoncie nie widzę niczego kolejnego. I…

Łukasz Kałużny: Wiesz co? Bo równocześnie był hype’owany serverless, który jest też wariantem architektury serwisowej, tylko nazwijmy takiej funkcyjnej.

Szymon Warda: Tak, i te tematy generalnie tak naprawdę stoją w miejscu przez ostatni rok.

Łukasz Kałużny: Jak nie dłużej. Dochodzimy do momentu racjonalizacji pewnych rzeczy. Bardzo mnie ciekawi właśnie to, że w kontekście serverlessa, to o czym gadaliśmy jeszcze przed nagraniem, to, że ten, w którym kierunku iść, czy serverlessa, czy Kubernetesa i tak dalej. Po roku tej odpowiedzi dalej nie mamy, to dalej jest dokładnie w tym samym miejscu, w którym było tak naprawdę. Ciekawe, dwa koegzystujące, fala hejtu się powoli wylewa, nic na horyzoncie. Może to jest finalna architektura systemów jaką będziemy mieli.

Łukasz Kałużny: Ktoś coś wymyśli, potem dojdziemy, potem pójdziemy dokładną computingu i odkryjemy świat na nowo.

Szymon Warda: Tak, odkryjemy monolit generalnie na nowo.

Łukasz Kałużny: Na nowo.

Szymon Warda: Dobrze, kończymy Łukaszu chyba.

Łukasz Kałużny: Kończymy. Na razie.

Szymon Warda: Na razie. Trzymajcie się.