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

Szymon Warda: I Szymon Warda. Wszystkie linki tego odcinka oczywiście na Patoarchitekci.io lub gdzieś w opisie na dole, to ogarniacie. Wierzymy w to, że dacie sobie radę. To co Łukaszu w nowym roku?

Łukasz Kałużny: Tak, tak. W nowym roku w sumie to drugi odcinek, ale pierwszy short w nowym roku, czyli poświąteczna posucha. Ale coś się udało znaleźć. Dobra, to zaczynaj, co masz pierwszego, co z tych czytanek Ci się trafiło.

Szymon Warda: Jeżeli idziemy o posuchę, to to może pokazywać dwa ciekawe artykuły, które się ze sobą zbiegły. One raczej nie są z sobą w ogóle powiązane. Ale pierwsze to jest temat dalej quantum komputerów, itd. i algorytmów się dalej rozwija. Google właśnie ogłosił, że swój projekt Willow który ma 105 kubitów, więc prowadzą oczywiście fajne wykresy, itd. Ale nie to mnie zaciekawiło, ponieważ drugi artykuł, który mi bardziej do tego pasuje, to jest to, że AWS ogłosił swój plan migracji i prac do przygotowania się na algorytmy postkwantowe. I opublikowali cały artykuł, co tam robili, podzielić na cztery fazy. Strumień pierwszy to jest inwentaryzacja istotnych systemów, identyfikacja i opracowanie nowych standardów, testowanie oraz planowanie migracji. Strumień drugi, integracja algorytmów do PQC policzy na punktach końcowych AWS’a. Potem integracja algorytmów podpisu PQC w usługach kryptograficznych AWS. PQC to jest Postquantum Computing.

Łukasz Kałużny: Wiesz co, zdaje się, że kiedyś już to też poruszaliśmy, bo wyszukałem teraz, to już prawie dwa lata temu, CloudRH pierwszy na poważnie do tego tematu podszedł.

Szymon Warda: To nie jest computing, tylko cryptographic. I w sumie czwarte, to jest integracja algorytmów do podpisów PQC w usługach AWS umożliwiające wykorzystanie postkwantowych podpisów do uwierzytelniania sesji takich jak walidacja, certyfikacja serwera i klienta. Czemu ten artykuł i ta seria właściwie? To fajnie pokazuje, jak siedzenie i opieranie swoich usług na barkach gigantów typu Google, Microsoft, jak wiele rzeczy ułatwia. Teraz wyobraź sobie zaplanowanie tej pracy totalnie na on-premie, posiadając wielkie data center. Trochę sporo pracy.

Łukasz Kałużny: Wiesz co? Sporo, wiesz, teraz tak: czy kwantowa kryptografia się wydarzy? Sądzę, że pod koniec naszej kariery będzie czymś, co jest must have.

Szymon Warda: Okej, jak tak to ująłeś to bym się zgodził.

Łukasz Kałużny: Tak, bo wiesz, teraz patrz się, zobacz, że mamy dopiero, bo teraz… Problem jest z kubitami taki, że nadal to jest research.

Szymon Warda: Tak.

Łukasz Kałużny: To jest research.

Szymon Warda: Tak, to są do kupienia chipy gotowe, ale prawie nikt tego nie kupuje, tylko to właściwie jest publikowane, że są, itd. Inaczej, jak to się wydarzy, to nie będzie tak jak przywidywaliśmy, że tak nagle na serwerze po prostu pojawi się i wszystko padło, i nasze konta do banków są pootwierane i w ogóle wszystko się złamało. Ale fajnie, to będzie ewolucyjne mimo wszystko, mimo tej takiej opowieści, jak to miało wyglądać. Ale przygotowanie się na to w takiej długie perspektywie jako powolny proces ma sens realny.

Łukasz Kałużny: Tak, Ty wiesz, ja sądzę inaczej, że te algorytmy jeszcze z trzy razy się wyłożą.

Szymon Warda: Pamiętamy historię algorytmów bezpieczeństwa chociażby do WIFI, do SSL’a, itd.

Łukasz Kałużny: W sensie, czekamy na moc obliczeniową, kiedy zacznie być dostępna dla wszystkich. Bo trzeba popatrzyć, że algorytm jest tak, że na dzień dzisiejszy jedyne, co wiemy, że z perspektywy informatyki jako nauki, computer science, to trzeba powiedzieć, że będzie to miało coś wspólnego z kryptografią, że tam powinno być optymalne. Drugi element, przez to trenowanie AI, jeżeli już będzie moc obliczeniowa, też będzie wydajniejsze. I dużo różnych dziwnych algorytmów matematycznych i statystycznych, które w teorii o wiele szybciej będą się liczyć. Ale tak naprawdę dla wszystkich jest to nadal… To są rozważania akademickie, do czego my wykorzystamy tak naprawdę kwantową moc obliczeniową.

Szymon Warda: Czyli ustalmy, jak to się pojawi w sensownym zakresie i możliwości, to znajdą się problemy, które by się tym rozwiązywały. To też tak będzie działało, jak z każdą nową technologią. No ale ciekawe, fajny plan. Dobra. Co u Ciebie?

Łukasz Kałużny: Dobra, to zacznijmy sobie od rzeczy, która zawsze mnie zastanawia, czyli zbudujmy sobie samodzielnie toola.

Szymon Warda: Miałem kilka takich artykułów i po prostu już zaczynam już powoli je wycinać, jeżeli to jest tylko na zasadzie chwalenia się kto co zbudował.

Łukasz Kałużny: Wiesz co, ale tu jest… To chwalenie jest ciekawe, ponieważ Reddit, bo o nim mowa, pokazał to w miarę w deepdive’owy sposób, taki zarys HLD i wymagań. To, co zbudowali, to zbudowali sobie self-hosting code scanning. I teraz zawsze się zastanawiam, po co, dlaczego, ale to zostawmy, w jaki sposób. Zawsze jestem ciekaw prawdziwej motywacji pod spodem, bo wynika ona, raczej: chcemy coś zbudować sami.

Szymon Warda: Ktoś chce się pobawić. Znaczy, ustalmy, Reddit jest widoczną stroną, ale to nie duża firma.

Łukasz Kałużny: 700 developerów.

Szymon Warda: Ludzi w IT, bym chyba tak to nazwał, może.

Łukasz Kałużny: Wiesz, pytanie ile, tak, więc pytanie ile by kosztowały, nie wiem, Snyk, GitHub Patch, GitHub Enterprise.

Szymon Warda: W Snyka to już nie idźmy, dobrze?

Łukasz Kałużny: Pytanie, być może, dobra, jakościowo być może byłoby lepsze od tego, ale to, co zbudowali, to jest pokazane cały pipe, który z jednej strony pokazuje cały sposób obsługi takiego pipeline’u skanowania oparty o open source’owe narzędzia. Dwie takie rzeczy, które pokazują, to jest OSV Scanner oraz coś, czego nie znałem, więc to jest ciekawa rzecz, TruffleHog.

Szymon Warda: Widzę, że też automatycznie ESBOM-a generują.

Łukasz Kałużny: Tak, i automatycznie też… To jest jako what’s next, to jest ich akurat roadmapa, czyli w tym. W całość, ale jest pokazany cały flow, co chcą zrobić, czyli integrację potem z Semgrepem, OSV-em, dorobienie skanowania licencji. I wykorzystują GitHub’a, i tutaj PR Check, blocking, jeżeli tego nie przejdzie. Czyli wygląda jakby ktoś powiedział, że: choć się pobawimy, zbudujemy sobie superskaner.

Szymon Warda: I jestem ciekawy, co będzie się dalej wokół tego działo i czy coś więcej… Mnie ten ESBOM bardzo cieszy, bo narzędzia, które automatycznie generują ESBOM-a, są albo gówniane, albo bardzo drogie. Szczególnie w klimacie właśnie wokoło githubowym. Także jakby coś wypuścili, to byłbym bardzo szczęśliwym człowiekiem.

Łukasz Kałużny: Nie, to oni, powiedzmy, do ESBOM-a pewnie któryś z open source’ów wezmą, bo jak popatrzy się…

Szymon Warda: One są kulawe często, powiem Ci tyle.

Łukasz Kałużny: Tak, ale githubowy za to daje radę.

Szymon Warda: Githubowy daje radę, ale on opiera się na tych labelach githubowych i on nie wszystko ładnie sczytuje. Jego skuteczność nie jest aż tak wysoka, wbrew pozorom, wiesz? To jest trochę problematyczne przy nim.

Łukasz Kałużny: Tak, ale sam wpis polecam zobaczyć. Architektura dobrze zobrazowana, pokazany cały scheduling, taki podstawowy. Oczywiście znalazła się Kafka, wrzucanie do BigQuery i inne takie rzeczy, więc można zobaczyć.

Szymon Warda: Okej, dobra. To ja tym razem coś krótszego tak naprawdę. Artykuł, który, nic odkrywczego, ale mimo wszystko. Opowiada o tym… Po pierwsze polemika wokół tego. Nasze zdanie jest dość czytelne odnośnie mierzenia wydajności developerów przez ilość PR’ów, czy ilość linii kodu, itd. To z reguły się nie sprawdza, ale to jest dość ciekawe, ponieważ on pokazuje trochę inną perspektywę na to. I taka myśl mi wokół tego poszła, że mierzenie ilości PR-ów jest trochę jak używanie BMI. Odnoszenie BMI do pojedynczej osoby nie ma żadnego sensu, bo to nie za bardzo, ale do grupy społecznej albo do całych zespołów, itd., to już zaczyna jakiś tam trend pokazywać. Artykuł fajnie pokazuje właśnie podejście praktyczne do mierzenia PR-ów. Chociaż takie moje krytyczne spojrzenie to jest to, że często tę ilość PR-ów w zespole to generuje jedna albo dwie osoby, które faktycznie dużo ich robią, a reszta, powiedzmy, leci tym jednym PR-em na tydzień tak naprawdę. Inna bajka, faktycznie fajnie jest mierzyć drożność PR-ów, powiedzmy, od stworzenia do zakomitowania, bo ja widzę często, że problemami są to, że po prostu PR-y wiszą, wiszą, i wiszą, i mało kto chce review robić tych PR-ów. Niestety.

Łukasz Kałużny: Wiesz, tylko problem, jak powiedziałaś z tym review, najczęściej wynika z toksyczności tego review. I to jest… Jak już znajdzie się czas potem.

Szymon Warda: To jest tak, że często wymaga to pracującego systemu i to często zajmuje bardzo dużo czasu i się skupia albo na zasadzie, że przejdźmy, żeby było, albo na zasadzie, że wytknijmy błędy, literówki, stylistyczne.

Łukasz Kałużny: Inaczej, wszystko, co powinno być linterami, autocheckami.

Szymon Warda: Dokładnie.

Łukasz Kałużny: Realnie, wiesz, jak o tym mówisz, to jedna to jest toksyczność. Druga rzecz, zauważ, że w części korporacyjnej naszej branży nadal trunk-based development i małe pull-requesty nie istnieją. To jest mit. Poza produktami, które są takie na żywo. Zobacz, że wielkość… Zresztą Szymon, nie oszukujmy się, wymiotować się chce, jak widzisz dużego PR’a, który leci w setki linii kodu.

Szymon Warda: W setki to jest mało. Ale z drugiej strony, Łukasz, jeżeli wdrażamy nowego feature’a dużego, itd., to robienie tego znowu małymi krokami i wszędzie obudowywanie tego feature flagami, przyłącznikami, IF-ami…

Łukasz Kałużny: To jest masakra.

Szymon Warda: Też nie działa.

Łukasz Kałużny: Tak, jest masakrą.

Szymon Warda: Dokładnie. Jeżeli masz system, który jest rozwinięty, nie tylko to musi być koreporacyjny, po prostu działa na produkcji od iluś tam lat, powiedzmy, to nowe funkcjonalności będą dużymi PR-ami, bo baza kodu jest duża po prostu.

Łukasz Kałużny: I tyle.

Szymon Warda: Tak. My pokazujemy rozwiązania, które działają, a nie te, które wyglądają ładnie na prezentacjach godzinnych maksymalnie. Dobrze. Co Ty masz dalej?

Łukasz Kałużny: Wiesz co? Jak popatrzymy, to pierdoła, która cieszy, a może dwie, żeby szybko poleciało. Pierwsza to Microsoft rzucił taki wraper dopythonowy, który ze względu na GenAI, którego męczymy, Mark It Down. Czyli wrzucanie PDF-ów, PowerPoint-ów, Word-ów, Exceli, obrazów, audio, HTML-a, tekstowych do Markdowna.

Szymon Warda: Markdown powinien być wszędzie używany.

Łukasz Kałużny: Ale tak, jest ten. Właśnie i to jest ciekawe, bo to jest dropowanie wszystkiego do Markdownów, które jak teraz popatrzymy przy budowie RAG-ów, pozwalają pokazać, lepiej go przygotować, zrobić bardziej zrozumiałe. I tutaj leci mój drugi przykład, który jest, małe przyjemne kawałki, sample kodu, które pokazują… Tytuł jest oczywiście z pupy: “Supercharge your RAG app with agentic hybrid search”. Można byłoby troszkę bardziej clickbait-owo jeszcze to zrobić, ale pokazuje na bazie langchaina samplami, jak wygląda takie podejście agent, to, co nazywamy tym podejściem agentowym z wykorzystaniem langchain’a i narzędzi, żeby złapać prawidłowo dane, żeby odpowiedzieć dobrze na querry użytkownika.

Szymon Warda: Fajnie wpisuje się w to, co mówiliśmy w odcinku poprzednim odnośnie czym co jest, tak że jakby ktoś nie wiedział, to zapraszamy.

Łukasz Kałużny: Tak, świetnie to też pokazuje te podejście i kawałki kodu, które są prawdziwe. O tak, nie jest to aż tak wymyślone. Nie jest to pseudo kodzik.

Szymon Warda: To ja z kolejnego, mały artykuł, który cieszy. SLI, SLE, KPI, OKR, SLO, itd. Fajny artykuł z bloga, który już parę razy polecaliśmy właśnie w okolicy SLI, SLO. Ale czemu go wybrałem? Bo mamy pytania często o brak zrozumienia między właśnie KPI a OKR a SLI a SLO. I on fajnie pokazuje na przykładach, co jest bardzo ważne, jak się jedne różnią od drugich. I na przykładzie, tak żeby wyciągnąć esencję. Np. mamy przykład taki, że cel: utrzymanie wysokiej dostępności systemu. Kluczowe rezultaty, czyli OKR, mamy takie osiągnięcie: 99,95, skrócenie średniego czasu odpowiedzi, zmniejszenie liczby krytycznych incydentów o ileś procent. Teraz budujemy wokół tego KPI-e, czyli schodzimy warstwę niżej. Procent czasu, w którym API jest dostępny i poprawnie działa. Czas odpowiedzi API na żądania. Liczba istotnych incydentów wpływających na dostępność API. Okej, teraz schodzimy jeszcze poziom niżej, czyli konwersja tego na SLI i SLO. To dostępność oparta na czasie, to SLI, SLO liczymy 99,95. SLI: latencja oparta na zdarzeniach. SLO: 95, opóźnienie żądań powinno wynosić mniej niż 200 milisekund. I SLI: liczba incydentów niekrytycznych oparta na zdarzeniach. SLO dla tego: 90% incydentów z ostatnich 90 dni nie jest krytycznych. No nie? Fajne ćwiczenie, które pokazuje właśnie jak te wszystkie rzeczy ułożyć, ustrukturyzować i rozbić. Jeszcze jedna jest bardzo super ważna rzecz, która tam jest wspomniana i jest dość ważna. To jest to, że SLO powinno mieć swojego właściciela, który ma możliwość zarządzania całością tego obszaru, a nie że komuś przypisujemy: a Ty się w ogóle tym zainteresuj, a pracownik: ale to nie jest w ogóle w moim obszarze. Co też widujemy dość często jako jedną z patologii.

Łukasz Kałużny: Tak. Całość i tak KPI stają się, OKR-y stają się malowaniem trawy na zielony.

Szymon Warda: Widywałem sytuacje, gdzie to było zrobione dobrze.

Łukasz Kałużny: Nie, inaczej. Są, tylko ja się przyzwyczaiłem do tego, że okej, bo masz cały problem, że jak zaczynasz coś mierzyć, to jest inna rzecz. W przypadku tej części dostępności nie da się tego inaczej zrobić. I tu nie da się inaczej. Nie da się do końca grać na to, żeby grać na KPI tak zwane. Czyli co zrobić, żeby spełnić KPI malując trawę na zielono.

Szymon Warda: Tak, to mówisz, że do każdej rzeczy, którą mierzymy, musimy mieć kontrmetrykę, która będzie mierzyła, czy nie występują nam sytuacje patologiczne. Złe patologiczne, oczywiście. I tu zaczyna się cała zabawa, jak to wszystko zbudować. Jest to potrzebne? Artykuł fajnie opisuje, jak to rozbić, bo często mają ludzie z tym problemy po prostu.

Łukasz Kałużny: Tak, polecam ten diagram na temat ownerów, stateholderów, który jest tam gdzieś pod koniec samego, rozbija sobie, co, gdzie, w którym miejscu występuje.

Szymon Warda: Taki flowchart, dokładnie tak, jest niezłe. W ogóle cała seria o właśnie SLI, SLO od niego jest całkiem niezła.

Łukasz Kałużny: Tak, kiedyś już ją polecaliśmy. Dobra. Kolejna pierdoła i ciekawie wyglądała od strony LinkedIna, to ogłoszenie nowego feature dla GitHub Copilota, VS Code. Czyli dostajemy tam 50 wiadomości, 2000 uzupełnień kodu za free, czyli pierwsza dawka narkotyku i uzależnienia. A dowcipnie pokazuje miejsce GitHub’a w portfolio Microsoft’u, bo na LinkedInie Satya ogłaszał to, co GitHub, share’ował tę wiadomość.

Szymon Warda: Wygląda, że taka jest hierarchia organizacyjna. Ja jeszcze dożucę, bo to jest ważne: studenci, ludzie w edukacji i osoby utrzymujące open source mają oczywiście unlimited za darmo.

Łukasz Kałużny: Tak, pełnego, ale to było już od jakiegoś czasu, ale dobre dopowiedzenie.

Szymon Warda: Wrzucam, że jest po prostu, żebyśmy to pamiętali.

Łukasz Kałużny: Dobrze.

Szymon Warda: Co tam dalej jeszcze? Ja mam teraz jeden dłuższy artykuł od osoby, o której dawno nie wspominaliśmy, od Oskara o platformach. A że o platformach mówiliśmy dość sporo i Oskar też zahaczył o obszary, które my, czyli o Dora, Rapport, itd., to naprawdę dobry artykuł, który właśnie mówi o platformach. Oskar trochę skupia się na tym, znaczy skupia się na tym, zaczął trochę, takim punktem zahaczenia jest to, że co mówiliśmy w naszym omówieniu raportu, to było to, że wydajność firm, które mają platformy, spada mniej więcej po tam, po roku, roku, dwóch jest peak, a potem jest spadek. I Oskar wchodzi w taką ciekawą polemikę, czemu to się w ogóle dzieje. Jego teoria jest taka, że wynika to z tego, że zaczynamy… Pierwsze dwa lata platformy budowaliśmy, a potem dorzucamy feature’ów, jak dorzucamy feature’ów to wszystko obrasta, trudniej się tego używa, itd. Po prostu jest to trudniejsze i dzięki temu przez to zwalniamy, bo mamy bardziej skomplikowane rozwiązania. Ja bym się z tym nie zgodził, bo wydaje mi się, że mimo wszystko to bardziej wynika z tego, że bardziej obudowujemy tą platformę w procesy i zespoły zaczynają grabiami takimi albo widłami długimi przerzucać ten system do platformy tak naprawdę.

Łukasz Kałużny: Wiesz co, tylko aktualnie pojęcie, jak patrzysz na to, o czym Oskar pisze i ogólnie, to jest problem, i to, co my widzimy, to zauważ, że większość… Inaczej, masz dwa światy platform, Internal Development Platform. Pierwsze to są, tak jak jeden z naszych klientów: o, to my zbudowaliśmy IDP. To na zasadzie: mamy już to od lat, w pewnym sensie i ciągle się rozwija. Druga rzecz, to jest teraz: platform engineering jest modny, oszczędzimy na tym. Nie będę wskazywał, ale jak widzę pewne posty na LinkedInie pewnego kolegi, który mówi: ile to oszczędzisz na używaniu platformy i innych rzeczy? I pojawia się marketing i inne rzeczy. I to jest coś, co w ogóle z tym… Jest tam jeden talk, który Oskar wskazuje, jest dobry. I właśnie dwie, które tutaj są, rzeczy, które się zawsze pojawiają: running too much software, writing too much software. I zobacz, że większość platform jest o to, żeby robić, a nie zrobić.

Szymon Warda: Zgadzam się. Parę punktów z wpisu Oskara, które może chciałabym znać, może tak zróbmy. Faktycznie, często zespoły platformowe są traktowane i postrzegane jako ta elita elit. I niestety, co ja widziałem naocznie, nagle jak myślą, że są elitą, to nagle zaczynają narzucać innym zespołom, jak mają robić, a szczególnie zespołom developerskim, gdzie z reguły się oni na tym nie znają, jak to powinno wyglądać. I to jest w ogóle droga do absolutnej porażki. Że platform obrastra featureami, tak, to jest problematyczne bardzo. To jest ta opcja, że często trzeba platformę podzielić na kilka różnych mniejszych platform do utrzymania i powiedzieć, że: no sorry, od tego są standardy. Jeżeli chcecie robić coś inaczej, możecie, ale w tym momencie to jest poza platformą i pewnych rzeczy po prostu nie utrzymujemy. Ale ustandaryzowanie, o czym mówiliśmy wiele razy, jest kluczowe. Nie zrobi się platformy bez standardów, albo zrobi się jakiegoś potwora, tudzież zestaw różnych helperów i sposób na upchanie tego w coś, co nie będzie działało. Jest jedna świetna rzecz, wydaje mi się, taki cytat jest: “I’ve fallen into this trap myself, creating classes with 14 generic parameters or pipelines that claimed “zero config”.“I to jest też, co ja też widuję. Czyli takie jak często da się inteligentnych ludzi, to oni chcą zrobić magię taką, że: a, tylko dasz tutaj i to samo wszystko wykrywa i działa. Magia w platformach, i w ogóle, nie działa. Czytelność zawsze jest lepsza, zawsze jest wyższa. Niestety trzeba też ludzi pilnować po to właśnie, żeby nie dodawali tej całej magii. Fajne są w ogóle podsumowania, podsumowanie to Oskara generalnie wychodzi na koniec: ode mnie kilka rzeczy: standardy, standardy i jeszcze raz standardy. Nie ma platformy bez standardów, tego po prostu się nie zrobi. Na pewno to będzie sposób myślenia i droga, jak to robi, to musi cały czas ewoluować, a nie zrobiliśmy i teraz spychamy. Nie musi, nie będzie pokrywać nigdy niczego w 100%, to nie da rady, bo będziemy mieli masę różnych platform, albo platform, które utrzymują jeden typ systemu. Tak to będzie wyglądało. Realnie to nie ma większego sensu. W rzeczywistości z Oskarem się nie zgadzam generalnie, albo tak go inaczej rozumiem. On też pisze taką opcję, że: zaangażuj wiele zespołów w utrzymanie tych mniejszych narzędzi, aby wszyscy brali udział w usprawnianiu i dzielili się doświadczeniami. Tak, dalej ownership jest bardzo ważny.

Łukasz Kałużny: Czy wiesz co, to jest cały ten problem, który był tak zwanego wewnętrznego open source’u, który się zaczął, ta książka bodajże, ale chyba PayPal, od PayPal’a była ta książka na temat Internal Open Source.

Szymon Warda: Tego już pamiętam. Nieważne.

Łukasz Kałużny: Nieważne, to jest… Inaczej, to jest mit.

Szymon Warda: Zawsze musi być konkretny zespół, który utrzymuje konkretne narzędzie. Jeżeli nie, skończymy z forkami, pierdolnikiem, bałaganem i porzuconymi narzędziami i ludźmi, którzy narzekają, że: tego nie będziemy używali, bo to jest ta, Reddit nie utrzymuje.

Łukasz Kałużny: Albo PR, który dodaje logikę, której potrzebuje jeden zespół.

Szymon Warda: Tak, taką biznesową, załóżmy IF’a, że jeżeli mamy ten paramet, to zachowuj się inaczej.

Łukasz Kałużny: Znaczy tak, klasyka kurde gatunku.

Szymon Warda: Jest dużo takich rzeczy. Ownership jest super ważny, platformy, zespoły są ważne. Jeszcze jeden element, który wchodzi, Oskar trochę, jak go rozumiem, to jest to, żeby pewne rzeczy biznesowe, każmy system płatności przenosić trochę do platformy. I ja tutaj bym powiedział: nie, od tego są inne zespoły. Platformy, jak trzymałbym wyraźnie w kontekście technicznym. Problem powstaje taki, jak w tym momencie nakłonić tych ludzi, żeby jednak nie odlecieli na Marsa i dalej trzymali się z tym, co pozostałe zespoły developerskie potrzebują. I tu wchodzimy bardziej, ja dużo bardziej preferuję właśnie włączanie ludzi z platformy w inne zespoły i jawną komunikację i częstą komunikację, jak to wygląda.

Łukasz Kałużny: Raczej platformowo, słuchaj Szymon, to zawsze chyba będzie trzeba powtarzać, że kluczem do sukcesu będzie zawsze minimalizm.

Szymon Warda: Minimalizm, ale też komunikacja z innymi, czego oni właśnie potrzebują.

Łukasz Kałużny: Wiesz, jak popatrzysz na… Bo śmiałem się przez całą moją karierę, coś, co nazywamy usługowym podejściem do IT wewnątrz organizacji, kurde, ciągnie się odkąd pamiętam. I odkąd pamiętam, rozbija się dokładnie na tych samych problemach, czyli zamiast wystandaryzować coś i zrobić rozsądny proces, próbujemy zamiast cofnąć się i zastanowić się, jak to powinno wyglądać i minimalizować te wszystkie edge-case’y, to wszyscy na siłę próbują zbawić cały świat i zbudować kolejny Opus Magnum.

Szymon Warda: Łukasz, ale to jest to, o czym mówiliśmy na starcie, że dajemy tam inteligentnych ludzi i oni myślą, że są mądrzejsi od całej reszty i oni tutaj zrobią taką generyczną klasę, która wszystko sama ogarnia. I pojawia się tutaj problem taki, że jeżeli coś nie pasuje do ich rozwiązania, nad którym siedzieli przez trzy miesiące, to będą teraz próbowali udowodnić, że to tamci są w błędzie. Tak nie powinno to wyglądać. Dlatego to jest ważne, zebranie standardów, zebranie jak wygląda stan obecny i dopasowanie kawałek po kawałku tej platformy, rozszerzanie i powiedzenie sobie też, gdzie mówimy stop, gdzie coś już powinno wyglądać inaczej. To co mówiliśmy parę razy, już robiliśmy to u naszych klientów, że okey, część platformy to są, powiedzmy, app service’y, a część to są funkcje Azure’owe np. To są zupełnie dwa inne światy, bo mają inne potrzeby. Nie wpychamy wszystkiego do jednego, dlatego że serverless brzmi super fajnie. No nie ma to sensu większego. Ale ogólnie artykuł przeczytajcie, naprawdę warto i w ogóle pozdrawiamy Oskara w tym momencie, bo dobra robota bym powiedział. Mimo że gdzieniegdzie się nie zgadzamy, ale bardzo dobry artykuł.

Łukasz Kałużny: Dobra. Ostatnią rzecz na dzisiaj, już luźniejszą, to w międzyczasie wyszedł sobie Kubernetes 1.32. I w sumie znajduje się tam… Oczywiście jak zawsze, to już jest produkt, w którym pojawiają się jakieś pierdoły albo konkretne zastosowania. Tam jedną z takich rzeczy jest Dynamic Resource Allocation, głównie jak współdzielić sprzęt i inne takie rzeczy. Całość, w większości tego nie dotkniemy, o tak, jak sobie popatrzymy. Ale rzeczą, którą na taką podśmiechujkę na sam koniec, co mnie przyciągnęło w tytule na InfoQ tego podsumowania, to jest, i bym na to w ogóle nie zwrócił uwagi, na to wydanie za bardzo, to było: Graceful Shutdown of Windows Nodes. I mam dla Was takie pytanie: czy ktoś z Was korzysta na produkcji z windowsowych workerów i mógłby nam wyjaśnić, jaki z tego jest benefit?

Szymon Warda: Ja słyszałem, raz rozmawiałem z osobą, która korzysta faktycznie z windowsowych kontenerów do przeniesienia na prostu takich naprawdę starych systemów, z których korzystali, ale to są śladowe.

Łukasz Kałużny: Wiesz…

Szymon Warda: Łukasz, wiemy, co się tam pojawiło.

Łukasz Kałużny: Wiemy, bo musiało.

Szymon Warda: Klient korporacyjny zapłacił dużo i wymagał, więc się pojawiło i tyle.

Łukasz Kałużny: Bo musiał być innowacyjny.

Szymon Warda: Tak, klient musiał zrobić, przenieść się do któregoś dostawcy chmurowego, node’y [niesłyszalne 00:27:14]…

Łukasz Kałużny: I musiał być to Kubernetes, bo jest natywny.

Szymon Warda: Tak, tak to działało, tak to powstało. Sukces był? Był.

Łukasz Kałużny: Był. Żebyście jeszcze wiedzieli dlaczego, skąd wynika taka szydera. Jeżeli mamy ciężkie aplikacje windowsowe napisane na IIS-a w starym .Net Frameworku pełnym, to w większości przypadków, tak zupełnie szczerze, taniej jest napisać dobre skrypty PowerShell-owe do automatyzacji VM-ek. Inaczej, naprawdę to było przez… Tą rzecz wbrew pozorom, Windows nie jest klikalny, da się go bardzo pięknie automatyzować dla tych, którzy nie utrzymywali tego produkcyjnie. Naprawdę łatwo się go automatyzuje z PowerShellem.

Szymon Warda: Jeszcze jak DS-a dorzucisz, to już w ogóle super to działa.

Łukasz Kałużny: Tak. Desired State Configuration, czyli taki papet dla PowerShella. Dla ludzi, którzy tego nie kojarzą, czyli opisujecie, że chcecie osiągnąć taki stan konfiguracji serwera i wtedy PowerShell próbuje to osiągnąć. Ale wracając do całości, stąd są te podśmiechujki, bo większość tych aplikacji nie jest przygotowana na to, że będzie zmieniała node’a, będzie shutdownowana, wyłączana, nie rozumie livenessów, readinessów. Jak ktoś miałby do tego dopisać te probe’y, to mógłby się złapać za głowę, jak w ogóle to pogodzić z resztą kodu. Więc w większości przypadków lepiej po prostu dobrze zautomatyzować i będzie to tak samo wydajne. Albo z drugiej strony, może pora przejść po prostu na .Net Core’ay na zwykłe, na coś, co teraz określamy już jako zwykłym normalnym .Netem.

Szymon Warda: Zgadza się. To są, a inna sprawa to jest to, że te kontenery będą są wielkie. To będziemy mówili o kontenerach, które mają po parę gigabjtów, tak te parę wyższe wartości tak bardziej, to będzie bliżej dyszki niż jedynki, bym powiedział, no nie?

Łukasz Kałużny: No, dokładnie.

Szymon Warda: Wiesz, dużo rzeczy nie ma większego sensu. Ale wiem, jak to się wydarzyło. Wydarzyło się, jest, klient potrzebował, to powstało. Klient zapłacił. Dobrze, koniec narzekania naszego.

Łukasz Kałużny: Dobra.

Szymon Warda: Kończymy?

Łukasz Kałużny: Tak. Trzymajcie się.

Szymon Warda: Trzymajcie się.