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

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka - patoarchitekci.io/100. Więc taka trochę równa, nierówna liczba. Będzie jeszcze równiejsza, coś jeszcze więcej konkretnego zorganizujemy. No ale zaczynamy od parafiałek, czyli szkolenia.

Szymon Warda: A czemu? Bo widzimy, że jesteście zainteresowani, więc też promujemy. 21.02.2024 - modelowanie danych nie tylko w SQL-u. Czyli ja się chwalę, opowiadam różne historie i uczę jak modelować dane, żeby to działało w bazach relacyjnych, nie relacyjnych, ale głównie skupiamy się na tym, jak modelować dane. A 22.02.2024, czyli dzień później, Łukasz będzie Was męczył z Kubernetes The Hard Way, czyli żebyście zrozumieli jak działa Kubernetes i potem, żeby było lepiej.

Łukasz Kałużny: Nie tylko po to.

Szymon Warda: Tak, co nieco więcej.

Łukasz Kałużny: Tak, co nieco więcej, low level. Dobra, kurde, setka.

Szymon Warda: To już ten wiek, można powiedzieć.

Łukasz Kałużny: Tak, jest ten wiek.

Szymon Warda: Dobrze, jak mówimy o ładnych liczbach, itd., to zaczniemy od czego? Od OpenTofu? Bo wyszło OpenTofu i wyszło… Ja mam bardzo mieszane uczucia co do tego jak wydali, bo wyszła wersja 1.6.0 i w ogłoszeniach prasowych bardzo ogólnie opisywali co tam się wydarzyło. Np. lepsza integracja z S3. I trzeba się doszukać nieźle co tam właściwie tym S3 zrobili. Chodzi o to, że przerzucili się na nowe API tak naprawdę. Więc tak ładnie marketingowo, ale mało mięsiście. Podorzucali trochę nowych proper do integracji z obiektami, głównie Amazonowymi tak naprawdę. A rzeczy fajne, które zrobili? To jest faktycznie lepsze testowanie konfiguracji i modułów, żeby moduły teraz miały osobne testy.

Łukasz Kałużny: Ale tylko czy to przypadkiem nie było w Terraformie 1.16? Nie chcę tego szukać, ale przecież testowanie też było w ostatnim tym.

Szymon Warda: Coś tam się chwalili, też to by się zgadzało generalnie. Ale ok, niech będzie, krok w dobrym kierunku dla mnie. Ale dla mnie jest… Powiemy sobie w ogóle o wersji 1.7, co ma być, ale rzeczy, jeszcze co tak kronikarsko, co tam się wydarzyło? Nowe providery i nowy registry do ich modułów, który, uwaga, stoi na R2 Cloudflare’a. Tak, to jest ciekawostka. Ale ta wersja jest ok, ale wersja 1.7 jest fajna. Jeden feature jest świetny, enkrypcja po stronie klienta pliku stanu.

Łukasz Kałużny: Tak, to jest ciekawe, bo ja wkleiłem sobie linka też do 1.7, go wrzuciłem właśnie, że też wyszło.

Szymon Warda: Ma wyjść.

Łukasz Kałużny: Raczej, czekaj…

Szymon Warda: 1.6 wyszło, a 1.7 ma wyjść.

Łukasz Kałużny: Wczoraj było, jak nagrywamy, wczoraj było GA Szymon.

Szymon Warda: 1.6?

Łukasz Kałużny: 1.7. U mnie w feedzie już się pojawił news o 1.7, więc już wyszło.

Szymon Warda: Dobrze.

Łukasz Kałużny: Ilość informacji jest za duża, która leci w tym świecie teraz, tyle można sobie powiedzieć. Ale fakt, ten Plains Side to jest rzecz, na którą zwróciłem uwagę.

Szymon Warda: Będę się upierał, 1.6 wyszło jako GA 10 stycznia.

Łukasz Kałużny: To NewsTuck ma jakiś błąd u siebie w takim razie.

Szymon Warda: Możliwe, że tak, dokładnie. To jest moje pytanie do Ciebie, bo teraz jeżeli plik stanu będzie zaszyfrowany, to czy w tym momencie nie musimy robić tego, całych hocków, klocków wokół trzymania pliku stanu w wewnętrznym subnecie i żeby nie udostępnił, itd. To taki największy ból dupy. Bo to jest kuszące, w sensie dalej powinno być.

Łukasz Kałużny: Wiem, żeby sobie uprościć. Nie, inaczej, to rozwiązuje jeden duży problem z plikiem stanu, ale nadal jego wersjonowanie, backupy, cała zabawa zostaje.

Szymon Warda: Zgadza się jak najbardziej. Bardziej martwi mnie ten cały wokół governance’u jego żeby to tam bezpiecznie leżało.

Łukasz Kałużny: Ale wiesz co? To będzie na zasadzie… Bo zobacz jak pracujemy. Tam, gdzie, tak jak sobie porównasz, mamy, z naszej codziennej pracy w Protopii, mamy 2 takie typy klientów. Mamy takich only cloud, którzy nie mają zwykle swoich prywatnych workerów, nawet nie mają sieci biurowej, innej rzeczy, istniejącej serwerowni. Czyli to jest taki jeden typ, który mamy, z którym wiesz o tym, że trzeba sobie, jak zaczynasz robić naprawdę bezpieczne środowisko, to dużo trzeba wytłumaczyć, pokazać, setupować. I masz taki typ enterprise’owy, gdzie wszystko, firewalle, runnery, CI/CD, to wszystko jest często w onpremie i sobie leży. I u tego drugiego, jak zrobisz networking, to reszta już jest prosta.

Szymon Warda: Zgadza się. Znaczy wydaje mi się, jak teraz trochę nad tym na gorąco myślę, że ta enkrypcja po stronie klienta to będzie fajna rzecz, żeby bezpiecznie zacząć szybko, ale potem i tak trzeba będzie sieciówkę dorobić.

Łukasz Kałużny: Tak, tylko zobacz, jeżeli sobie popatrzysz, teraz nazwijmy to, cały ten start up mode, online mode, który lecisz, to zobacz, wygenerujesz sobie klucze, wrzucisz go sobie do jakiegoś Key Vaulta, czy czegokolwiek, ręcznie postawionego i taki GitHub korzystając z Federation Identity ładnie sobie ściągnie kluczyk, odpalisz i działa, czy nawet wkleisz klucze do secretów w GitHubie i też to będzie działać. Problem, który widzę, który jest większy, Szymon, tak zupełnie szczerze, to zarządzanie tymi kluczami do szyfrowania.

Szymon Warda: Wiesz co? Klucze, klucz, generalnie będzie zawsze problem z zarządzaniem nim. To nie jest inny klucz niż powiedzmy klucz do np. szyfrowania plików na Blob Storage’u, itd. Dalej klucz, którym trzeba zarządzać.

Łukasz Kałużny: Właśnie. I teraz jak sobie popatrzysz, tak będzie trzeba, tylko że wiesz, ja patrzę sobie, że zarządzanie kluczami jest gorszą rzeczą, bo potem kto miał ten klucz, kto ma dostęp? Wiesz o co chodzi.

Szymon Warda: Mnie jedna rzecz martwi, że tak to będzie wyglądało. Jestem pewien, że ten klucz wyląduje w repo GitHubowym. Dobrze o tym wiemy.

Łukasz Kałużny: I poczekaj, jeszcze się okaże, że ktoś Bloba ustawił na public albo bucket.

Szymon Warda: Tak, jestem prawie pewien, że ten klucz wyląduje jako plik w repo gitowym, żeby było łatwiej i potem tam zostanie.

Łukasz Kałużny: Więc inaczej, dla mnie jest to taki, na zasadzie bardziej taki fajny feature checkboxowy, o który dużo osób pytało. I co lepsze, kiedyś chyba dla S3, w ogóle kiedyś było, taka część, żeby szyfrować w tym.

Szymon Warda: Tak ale to było dla S3, a to jest po stronie klienta, więc trochę inna bajka.

Łukasz Kałużny: Tak, ale kiedyś była w ogóle enkrypcja pliku stanu, raczej secretów, nie całego, a secretów było. Więc ciekawe. Ja bardziej jestem ciekaw jak to będzie wyglądało. Tak jak mówię, ten rok dla mnie jest zagadką. Moje osobiste zakłady jest tak, patrząc się na rynek, to się specjalnie nie przejmuję w tym momencie.

Szymon Warda: Wiesz, a właśnie nawet w tym kontekście, bo pamiętasz Twoją prognozę, że to generalnie umrze? Przeglądałem repo GitHubowe projektu, nawet się to tam kręci, bym powiedział.

Łukasz Kałużny: Nie, że kręci się, wiesz, tylko pamiętaj, że to jest też… OpenTofu ma jedną dobrą motywację, to jest kasa projektów, które żyją z terraforma.

Szymon Warda: Tak, a jest ich trochę mimo wszystko.

Łukasz Kałużny: Jednak masz tam ludzi od groundworka, od Spacelifta. Jest to w Linux Foundation, więc tam jakiś pieniądz przepływa, więc bardziej ciekawi mnie jaka będzie adopcja.

Szymon Warda: Zobaczymy.

Łukasz Kałużny: Bo krzyk na rynku się już zmniejszył, jeżeli apropos Terraforma, jak sobie popatrzysz, że trzeba się uciekać i w ogóle.

Szymon Warda: Tak, wiadomo, każda histeria potem za chwilę przygasa. Co tam masz dalej Łukaszu?

Łukasz Kałużny: Ponabijajmy się z Microsoftu.

Szymon Warda: Dobrze, bo ja się będę nabijał z Google’a za chwilę.

Łukasz Kałużny: Więc tak, wyważymy to. Dzisiaj rano otwieram sobie maila i co widzę? Action required for Azure Firewall Deployment in the West Europe region. I poszedł sobie mail do klientów pod tytułem: Uważaj na swojego firewalla w West Europe i go nie wyłączaj. A o co chodzi? To jest taka ciekawa rzecz z rynku, jeżeli popatrzycie, West Europe ma coraz większe problemy z pojemnością, czyli dosłownie brakuje tam mocy obliczeniowej. I dostaję informację, że spróbuj jednego z tych pięciu czy sześciu regionów, między innymi Poland Central, bo tam powinno być więcej zasobów, a w West Europe, jeżeli już używasz, to uważaj z dealokacją. Jeżeli zrobisz zastopujesz, skasujesz swojego, bo możesz mieć problem z odpaleniem na nowo firewalla.

Szymon Warda: West Europe przez długi czas to był domyślny region de facto dla Europy.

Łukasz Kałużny: Tak.

Szymon Warda: Jak się tylko otworzył, to szło wszystko tam. Ale przerażający news, bym powiedział.

Łukasz Kałużny: Jak ktoś powie publicznie o dostępnościach… Może znajdę LinkedIna to zobaczycie która duża firma miała z tym w Polsce problemy i to takie grubsze jazdy ma z dostępnością zasobów. Ale jest to przerażające. I to się zaczęło odkąd Open AI wjechał, problemy z capacity.

Szymon Warda: Ja pamiętam jak dawno temu robiliśmy szkolenie z Kubernetesa, nie wiem czy pamiętasz, to była opcja jak stawiliśmy Kubernetesa od zera, to zanim MS ogłosił, że Teamsy są darmowe dla uczelni, to postawienie QEDM-em mniej więcej było 3 minuty. Potem wjechały Teamsy - 7.

Łukasz Kałużny: Tak, to był ten moment, nie darmowe tylko początek COVID-u. Tylko tam dowozili hurtowo ten sprzęt wtedy, bo co tydzień dostępność się zwiększała. Ale tak. I teraz jeden mit marketingowy pada przez takie maile i takie informacje i rekomendacje.

Szymon Warda: Że chmura jest zawsze skalowalna?

Łukasz Kałużny: Tak.

Szymon Warda: To jest… Ten mit zawsze będzie. Też MS rozumiem. Nie może być takiej sytuacji, że wszyscy deplpoyują się do jednego regionu, cała Europa.

Łukasz Kałużny: Jest tak, ale wiesz, tak wyglądało. Słuchaj, jest problem, że jak podane te regiony tam, które są, jak sobie popatrzysz np. na zestaw usług, to w tych innych datacenter, może poza North Europ, które jest, reszta regionów ma problem z ilością dostępnych usług. I np. to też jest Microsoft, sam sobie ukręcił tego bata, bo większość deploymentów idzie do West Europe, nowych usług.

Szymon Warda: Bo tam jest najwięcej maszyn, najbardziej dojrzała załoga jest.

Łukasz Kałużny: Tak i nawet private preview. Private preview, public preview to wszystko startuje w West Europe, mówię: testujcie tam. I dochodzi do takiej paranoi, że sami tam nakręcili tą metodą, w jaki sposób to działa. I wiesz np. firma, o której myślę, która chciała wystartować nowy projekt, słuchaj, potrzebujesz w sumie na usługach gdzieś z 1000 core’ów. To jest rzecz, która w teorii w Cloudzie powinna być zrobieniem sobie pstryk i masz. Rozumiem, robiłem np. projekty, gdzie testowaliśmy HPC parę lat temu i rozumiem, że 10 000 core’ów było problemem, żeby zapalić cluster.

Szymon Warda: I szczególnie jeszcze cluster do HPC, czyli musisz mieć specjalne karty sieciowe, itd. To nie jest taki…

Łukasz Kałużny: Tak, w sensie żeby odpalić kilka klastrów w ramach tego z infinity bandem i innymi zabawkami. OK, rozumiem, że te capacity musi być przygotowany inaczej. To jest zupełnie inna rzecz, kiedy takie coś odpalasz, duże klastry. Ale sorry, 1000 core’ów rozgrzanych po kilku usługach brzmi słabo, w tym momencie naprawdę słabo.

Szymon Warda: To jeszcze jedną rzecz wyprostuję, bo Ty mówisz 1000 core’ów. Ktoś może powiedzieć: o Jezu, co to za wielka aplikacja! Ale pamiętajmy, że Łukasz, to będzie mówić 1000 core’ów w kontekście po różnych usługach, czyli np. firewall. Za tym też są jakieś core’y. Za każdą usługą są jakieś core’y. Więc o to tutaj chodzi.

Łukasz Kałużny: Ja tutaj myślę np. Cosmos DB, SQL-e, AKS Service Base, czyli tam jakiś event hub i wszystko na najwyższych tierach, żeby zapewnić wydajność. Więc te 1000 core’ów, jak masz publiczną dużą aplikację, która jest publiczna, to się spokojnie uzbiera. Jak dodasz jeszcze wysoką dostępność, 3 zone’y i inne takie elementy, to spokojnie.

Szymon Warda: I jeszcze kilka środowisk, pamiętajmy jeszcze o tym.

Łukasz Kałużny: Tak, to się spokojnie nazbiera, w ogóle bez żadnego problemu przy dużych rozwiązaniach.

Szymon Warda: Tak. Dobra, to żeby wyrównać trochę hejtu, Google usuwa opłatę za wyjście z GCP, wyjściową. I co ważne, namawia innych, żeby też tą opłatę usunęli. Ja mam do wszystkich milionerów, żeby po prostu rozdali więcej pieniędzy. Czyli wszystko fajnie i ok. Faktycznie, w MS-ie taniej, to jest w ogóle strzał w kierunku MS-a bardzo mocno. MS, faktycznie rzeczy Windowsowe są tańsze w chmurze Azure’owej, faktycznie. Chodzi też o opłatę generalnie też ruchu wyjściowego i MS ma swoich partnerów, gdzie tani jest ten ruch wyjściowy, z kim się sparujemy.

Łukasz Kałużny: Tak, możesz się z CloudFlarem np. sparować i wychodzą grosze, jak masz CloudFlare Enterprise’a.

Szymon Warda: Tak, dokładnie. I wiadomo, teraz żeby dać trochę tak do ziemi na liczbach: GCP ma około 10% rynku obecnie, to jest ostatni kwartał 2023. MS ma około 21-22%. AWS ma 32%. Z całym szacunkiem, to jest taki typowy ruch marketingowy, namawianie, że: tak, zróbmy, fajnie. Czemu? Bo generalnie zależy, żeby właśnie GCP, żeby ludzie przychodzili do nich tak naprawdę, więc trochę takie…

Łukasz Kałużny: Ja wiem, to jest takie sztuczne. Poza tym jak tam się chyba zobaczy w detale to masz 30 dni tylko na tą migrację, więc… A nie, przepraszam, 60 dni masz na to, tej darmowej opłaty. Realnie, jeżeli klient jest prawdziwie multi cloud, jeżeli chce być prawdziwie multi cloud, albo zrobił duże wejście w GCP, nie wierzę, że 60 dni wystarczy. Wiesz o tym, że to są projekty na miesiące.

Szymon Warda: To są projekty na miesiące. Czemu? Bo takie multi cloud realnie robią duże organizacje, bo mają na to ryzyko. A druga kwestia, mało się wydarzy w 60 dni tak naprawdę i to jest kwestia organizacyjna też.

Łukasz Kałużny: Jak nie masz jednego tylko produktu i systemu, to sorry. Zajebiste dla startupów, które się rozrosły, nic więcej.

Szymon Warda: Więc fajny ruch marketingowy GCP, ale… Super, dobrze. Co tam Łukaszu masz?

Łukasz Kałużny: Dobra. Ja będę miał dzisiaj jeszcze tylko 3 newsy AI-owe, ale sobie polećmy. Pierwszy, Microsoft wydaje i update’uje ciągle swoją bibliotekę auto gen właśnie do samodzielnie działających agentów tak zwanych. Czyli mamy instancje, piszemy sobie kod, który… Budujemy sobie robota, Można to nazwać, nie mylić proszę serwera. I co lepsze, teraz ta biblioteka dość fajnie się rozrasta w kierunku, żeby te roboty też ze sobą rozmawiały. Czyli powierzamy im funkcje i inne rzeczy i na bazie LLM-ów, nie tylko Open AI-a, że pozwalamy rozmawiać im ze sobą i dajemy im np. dostępy do API, jakieś operacje i inne rzeczy kodujemy. Więc to jest dość ciekawa rzecz, którą można zbudować całkowicie. Czyli trochę inne podejście do połączenia tego ze sobą wszystkiego.

Szymon Warda: OK, ciekawe.

Łukasz Kałużny: Wiesz co, jest to przy automatyzacjach, jeżeli teraz mówimy o prawdziwym wykorzystaniu, nie piszemy promptu i kolejnego chatbota, tylko faktycznie budowy czegoś, żeby zaczęło działać, to wygląda dość ciekawie w całości, że pozwalamy wtedy systemowi żyć w jakiś sposób.

Szymon Warda: I co więcej, to wygląda jak projekt całkiem ładnie rozwijany. Nie jest to taki pojedynczy strzał MS-u, jak czasami się zdarza.

Łukasz Kałużny: Nie, to nie .NET Aspire.

Szymon Warda: Trzymasz w pamięci dalej?

Łukasz Kałużny: Raczej, bo się próbuje rozwijać. Z ciekawostek, AspireTec przerobili i shop on container na .NET Aspire, więc jak wejdziesz to się przestraszysz.

Szymon Warda: O boże, ale bym musiał zobaczyć. Dobrze, to ja znowu mam dzisiaj taki trochę marudzący odcinek, po prostu dużo głupich rzeczy zobaczyłem w internecie. Lastminute.com opublikowali artykuł odnośnie tego jak przejście na mikroserwisy poprawia wydajność. W sumie super tak naprawdę. Jak się wejdzie, doczyta, to okazało się, że stary system miał problemy ze skalowaniem. A czemu? Bo w starym systemie wiele zapytań do systemu generowało potem n+1 zapytań do dalszych systemów i mikroserwisy rozwiązały ten problem. I okazało się, że z artykułu wynikałoby jakby żadne inne podejście nie mogło problemu n+1 rozwiązać. Dla niewiedzących n+1 to jest wynik, to jest problem taki, że dla jednego zapytania, np. mamy gdzieś listę, odpytujemy n zapytań. Czyli dla każdego zapytania z elementu z tej listy dodajemy [niesłyszalne 00:15:40]. Tak, często problem przy zapytaniach SQL-a, jak się używa źle ORM-u. I idziemy dalej. Dzięki temu też mogą używać teraz RabbitMQ i dzięki temu teraz ich system ma lepszą niezawodność, bo jest odporny na wdrożenia, a dodają tylko mikroserwisy. Tak jakby nie mogli użyć przy dobrym monolicie nawet, albo systemie, powiedzmy dwóch systemach, nie, wcale nie mikro, tylko serwisach, użyć komunikacje asynchronicznej. Bo to, co opisują, to są plusy komunikacji asynchronicznej i zapisywania jakichś tam jobów, jakichś zadań do zrobienia na później. Zwykłe serwisy do po prostu rozbicia tego http na wiele etapów, to po prostu dają. A nagle mówimy, że: tak, tylko dzięki mikroserwisom.

Łukasz Kałużny: Wiesz co, ja bym inaczej popatrzył. Ktoś chyba spaprał modelowanie logiki biznesowej.

Szymon Warda: Ktoś zakodował w jednym monolicie absolutnie wszystko, łącznie jeszcze tam jakieś pluginy mieli, itd. I teraz stwierdzili, że: mikroserwisy, to wszystko uratuje. Naprawdę, nie musi być wcale mikroserwis, można z tych elementów korzystać osobno. I kurde to jest złe monitorowanie kodu i tyle.

Łukasz Kałużny: Raczej ja się uprę przy modelowaniu, bo jeżeli popatrzysz, to oni mają standardowy problem, czyli lastminute.com, czyli booking. I standard, masz 4 problemy takie duże, domeny, bo masz wyszukiwanie…

Szymon Warda: Integracje mają z integracjami z różnymi klientami.

Łukasz Kałużny: Ale to co powiedziałeś to jest proces wyszukiwania, bookowania, w którym potem masz tą subdomenę integracji i bilingi i account management. Upraszczam to, ale to są takie 4 duże bounded konteksty.

Szymon Warda: Tak, generalnie to nie jest jakaś taka domena, która jest po prostu, Jezus, Maria i problemy, które wypisali, to nie jest takie znowu kolejne coś po prostu, tylko mikroserwisy, itd. Więc nazywajmy rzeczy po imieniu. To są problemy złego zamodelowania kodu i tu wcale mikroserwisy nie są rozwiązaniem. Mogą pomóc i robiąc mikroserwisy musimy wprowadzić… Znaczy musimy, znam takich co się uparli, że nie zrobili tego, wprowadzenie komunikacji asynchronicznej. Ale komunikację asynchroniczną można mieć też przy monolitach, nie ma problemu, po prostu piszemy request, wrzucamy na kolejkę i potem coś to przyjmuje.

Łukasz Kałużny: Inny moduł to obsługuje. Dziękujemy.

Szymon Warda: Dokładnie, koniec kropka. Nie musi być mikroserwisów.

Łukasz Kałużny: Albo w zależności od tego korzystamy czegoś do jak end service bus, czy inna technologia.

Szymon Warda: Tak, a usunięcie n+1 jest nawet łatwiejsze w monolitach niż w mikroserwisach. Tam to jest realne zagrożenie. Więc tyle. Ale potem będę miał jeszcze jedno, gdzie pochwalę generalnie jedną rzecz.

Łukasz Kałużny: To jest dzisiaj rzadkie, dobra. Następna rzecz, która jest ciekawa to Open AI. Został usunięty po cichu, oczywiście jak zawsze po cichu jest, mogliby równie dobrze po prostu to ogłosić i by było tyle, na użycie rozwiązań Open AI-owych przy rozwiązaniach do użytku wojskowego.

Szymon Warda: I to jest ważne i ciekawe, ponieważ nie wiem czy pamiętasz, parę lat temu, z 5, 6 lat temu, jak pracownicy Google’a, MS-u, AWS-a…

Łukasz Kałużny: Zaczęli protestować.

Szymon Warda: Dokładnie. Masowe wyjście generalnie, żeby firmy nie były wykorzystywane.

Łukasz Kałużny: Z drugiej strony jego mać. Microsoft w wielu miejscach był od dawna.

Szymon Warda: Co ciekawe, pamiętajmy generalnie, że jak się, gdzieś tam jakiś dokument widziałem odnośnie w kooperacji między MIT i Berkeley, a rządem amerykańskim, właśnie armią w kontekście właśnie zimnej wojny. Amerykanie wygrali ten cały taki stand off w kontekście tego, że właśnie mieli dobrą współpracę naukowców i teoretyków i firm biznesowych w kontekście wojska.

Łukasz Kałużny: Wszyscy na tym zarobili.

Szymon Warda: Zarobili i ogólnie generalnie trochę dzięki temu teraz nie mówimy po rosyjsku. Nie jest źle bym powiedział. Obecna sytuacja polityczna jest jaka jest, szczególnie w kontekście AI-a, więc to nie dziwi kompletnie.

Łukasz Kałużny: Skąd to się wzięło? Bo zaczęli pracować z DoD, czyli amerykańskim Ministerstwem Obrony.

Szymon Warda: Departament Obrony. Dokładnie. Dobra, to ja teraz pochwalę jedną rzecz - Kafka w CloudFlarze. I teraz Kafka brzmi niebezpiecznie, cluster brzmi bardzo fajnie. Fajna prezentacja i naprawdę jest co przeglądać, jest co oglądać. Fajne wnioski wyciągnęli, nic super odkrywczego, ale dobre 45 minut. Dobrze jest ustandaryzować bibliotekę do połączeń do Kafki, bo dzięki temu można dodawać, w ogóle do połączeń asynchronicznych tak naprawdę, może dodawać takie rzeczy infrastrukturalne typu właśnie trace’y, spany, metryki, wiadomości, czyli takie metadane wokół wiadomości, to jest jako wniosek. I to jest to, o czym my mówiliśmy już od dawna, że to jest element platformy, to powinno być.

Łukasz Kałużny: Tak i to jest rzecz, która observability leży zawsze, czyli prawidłowa obsługa asynchroniczności.

Szymon Warda: Jak tego nie zrobimy wcześniej, to potem będziemy musieli modyfikować kontrakty tej wiadomości tak naprawdę i leżymy, tego już nie zrobimy. Więc używamy czegokolwiek, klienta do rzeczy asynchronicznych. Dodajmy małą bibliotekę, która to obsługuje, żeby to było ustandaryzowane. Kolejne, wprowadzenie wcześniej metryk, też dość oczywiste, bo wtedy po prostu pokazywali fajnie, że im się to nieźle zeskalowało. Jedną rzecz, którą sobie chwalili bardzo mocno, ja się z tym zgodzę, bo do końca nie rozumiem, czemu ludzie robią inaczej, że jeden kontrakt na topic, wtedy dzięki temu mają lepszą widoczność.

Łukasz Kałużny: Inaczej to jest piękna, jasna rzecz.

Szymon Warda: Ja poważnie nie rozumiem, czemu ludzie robiliby inaczej. Nie ogarniam tego. Jest to poza moimi możliwościami pojmowania.

Łukasz Kałużny: Inaczej, dla mnie jest pojmowanie tak - jedna rura, jeden rodzaj wiadomości. Koniec.

Szymon Warda: Potem myślisz właśnie w kontekście pub/suba. Tamto jest logiczne i oczywiste, bo z oczywistym podejściem.

Łukasz Kałużny: Inaczej, bo Kafka jest kurde pub/subem.

Szymon Warda: Nie, Kafka jest strumieniem, ale jest używany jako pub/sub.

Łukasz Kałużny: Ale jako pub/sub. Więc wiesz, ja patrzę, jak używasz tego do streamingu eventów, to możemy się kłócić, że jest inaczej.

Szymon Warda: Wtedy to rób jak chcesz, tak dokładnie.

Łukasz Kałużny: Rób co chcesz. Ale sorry, jeżeli używasz tego jako pub/suba, to jest to pub/sub, dziękujemy.

Szymon Warda: Tak, dokładnie. Jeżeli używasz jako szyny komunikacyjnej.

Łukasz Kałużny: To jest dobre określenie.

Szymon Warda: Co jeszcze dalej pokazują? Że ten jeden kontakt na topic to właśnie lepsza widoczność kto co produkuje, generalnie lepsza dokumentacja i jest to czytelniejsze. Oni właśnie fajnie pokazują, że to simplicity, ta prostota jest dużo lepsza niż superkonfigurowalność. CloudFlare, warto ich posłuchać po prostu, bo faktycznie mają realny przypadek.

Łukasz Kałużny: Mnie się jedna z tego artykułu, jedna rzecz podoba.

Szymon Warda: Tylko?

Łukasz Kałużny: Ale nie, poza tym co wymieniłeś. Jest jedna taka rzecz - too many abstraction. Na poziomie CloudFlare’a też doszli do tego, że abstrakcje ciekną i mają problemy wydajnościowe. Raczej nie dziwi mnie, że to odkryli, tylko ten punkt poleciał im na początku pandemii.

Szymon Warda: Dla mnie to jest fajne. To jest to, że z reguły te prezentacje o takich dużych, dużych, ale dużych firmach, a CloudFlare jest dużą firmą, może nie [niesłyszalne 00:22:14], ale zakres i skala.

Łukasz Kałużny: I skala, skala robi dużo.

Szymon Warda: Tak, to one są z reguły takie oderwane totalnie od życia, znaczy są mało aplikowalne najczęściej dla organizacji średnich i małych. Ta prezentacja jest bardzo praktyczna, taka bardzo przy ziemi po prostu. No nie? Więc dobre praktyki faktycznie nie tam wychodzące, wynikające z trylionów wiadomości na sekundę, tylko po prostu tak powinno to być.

Łukasz Kałużny: Pokazują po prostu co się zadziało i jakby dla normalnego człowieka, to nazwijmy.

Szymon Warda: Tak. Coś jeszcze Łukaszu masz?

Łukasz Kałużny: Wiesz co, ja mam jedną rzecz.

Szymon Warda: To leć.

Łukasz Kałużny: Microsoft to jest też znowu copiloty i te elementy. To copilot w teorii jest już, jeszcze nie sprawdziłem, nie kliknąłem w portalu office’owym, ale w teorii każdy może teraz kupić copilota.

Szymon Warda: Coilota mam i ja!

Łukasz Kałużny: Tak, żeby nie było copilota do Office’a 3.6.5, bo zrobili teraz tam copilot pro i też dla copilota dla zwykłych i jest dostępność dla każdego rodzaju biznesu.

Szymon Warda: Fajnie, mam nadzieję, że to zrealizuje tą prezentację, w której by było, przypomnijmy to, że ten copilot dla Office’a robił największe wrażenie na prezentacjach.

Łukasz Kałużny: Raczej najbardziej czekam, bo to też się pojawiły teraz już te copiloty dla Fabrica, czyli dla platformy analitycznej. To jest rzecz, którą najbardziej czekam z tego, bo w organizacjach, kiedy dane będą, i teraz rzecz, którą powiem, jest brutalna, kiedy dane będą leżały w tym Fabricu i raporty dobrze przygotowane i wysprzątane, to te copiloty tam w takiej analizie biznesowej dla biznesu naprawdę pomogą. Na zasadzie po co mi dashboard, jak mogę zapytać data?

Szymon Warda: Tak, to może być mega ciekawe. Dobra, ja jeszcze jedną rzecz, trochę teraz pohejtuję, tym razem AWS-a. Jakoś tak mi się złożyło ładnie, AWS ogłosił fajny feature. Mianowicie wprowadzili jakiś czas temu możliwość pluginów do swojego postgresa i odnosił możliwość wprowadzenia PG Active. Czym jest PG Active? Jest pluginem do postgresa, który daje możliwość zrobienia klastra active-active z asynchroniczną replikacją, bardzo ważne, do 16 baz równolegle. Czyli ma 16 baz active-active? Brzmi fenomenalnie. Problem jaki z tym mam, to jest to, że i tutaj pochwalę bardzo mocno InfoQ. Dając to zacytowało od razu projekt open source’owy, właśnie PG Active, gdzie napisane jest wyraźnie: żeby wprowadzić PG Active wymagane są zmiany w aplikacji. Nie wprowadzaj tego bez zmian w aplikacji, bo mimo, że brzmi jakby nie było, aplikacja musi być świadoma tego, że pisze do potencjalnie wielu instancji aktywnych i ma replikację asynchroniczną. Na stronie, AWS-u z tym ogłoszeniem nie ma tej informacji. I wydaje mi się, że to podejście jest nieetyczne, bo ono tworzy takie złudne, że generalnie włączę, dodam i będę miał teraz, będę mógł sobie skalować moje zapisy i odczyty na 16 instancji i będzie wszystko pięknie. Nie będzie. Tego typu rzeczy wymagają świadomości aplikacji, abyśmy się nie okłamywali.

Łukasz Kałużny: Ale to tak jak sobie popatrzysz na całość, za to akurat w Microsofcie jest z drugiej strony, trochę szanuję pod tym względem, bo zobacz, że w Cosmos DB np. masz całe informacje o Conflict Resolution Policy, że dostajesz przy active-active takie rzeczy, ale jest tutaj, że domyślnie masz dwa typy, jak robisz active-active, albo ostatni wygrywa, jest to na zegarach atomowych, albo robisz customa i robisz logikę do tego, w jaki sposób mają być konflikty. Bo całość, chodzi o to, że jak spaprasz aplikację, to dla słuchaczy, którzy może trochę mniej siedzą w danych, przy takich rozwiązaniach, macie zawsze jakieś indexy, unikalne identyfikatory i inne rzeczy. I co się stanie, jeżeli dwie instancje spróbują z update’ować ten sam rekord, albo dodać z tym samym numerkiem rekord, bo macie jakąś sekwencję i trzeba ten konflikt rozwiązać?

Szymon Warda: Albo zapisałeś do jednej instancji i jeszcze się nie zreplikowało, bo aplikacja jest asynchroniczna i czytasz z drugiej i nie ma danych.

Łukasz Kałużny: Wyszła consystency, to jest już bardziej znany problem.

Szymon Warda: Tak. Żeby było, AWS faktycznie o tym, że jak jest rezolucja konfliktów, to napisał, ale te informacje, że wymagana zmiana w aplikacji i podejście inne w aplikacji, nie ma informacji. I tu sorry, to jest dla mnie nierozsądne i potem będzie generował problemy dla samej usługi, więc trochę nie rozumiem takiego podejścia.

Łukasz Kałużny: Wiesz co, jest trochę startupowe, bo zobacz dużo startupików, jakichś mniejszych firemek wykorzystywało sobie MySQL-a active-active od lat. Zobacz, że tam podejście, normą było: użyj active-active MySQL-a, będzie dobrze w PHP-ie.

Szymon Warda: Tak, dokładnie. Ciekawe generalnie, tak to wygląda. I co, tyle Łukaszu, chyba kończymy?

Łukasz Kałużny: Zawijamy. Do usłyszenia za tydzień.

Szymon Warda: Na razie.