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

Szymon Warda: I Szymon Warda. Wszystkie linki do odcinka Patoarchitekci.io i gdzieś w opisie, namierzycie. Dobrze, to na dowód tego, że właściwie już się trochę znamy i nie przygotowujemy się, nie pokazujemy sobie linków, ja zacznę, bo link, który jest dość ciekawy, Łukasz go ładnie uzupełni, powiedzmy sobie, później. Wiadomość dość świeża, a mianowicie to, że Redis wprowadza tzw. dual licensing. O co chodzi? Sytuacja jest prosta. Redis już chyba parę lat temu wprowadzał model taki, który utrudniał wykorzystanie jego wersji płatnej. Mianowicie tego, że po prostu duzi cloud providerzy brali Redisa i hostowali go nic nie płacąc Redis Labsowi. Teraz wprowadza jawne, że po prostu nawet nie mogą kodu wykorzystywać. No i moje przypuszczenie było bardzo proste, to już jest taki, za późno trochę tak naprawdę. Po pierwsze. Po drugie, Redis stał się takim utility jak woda, prąd, to nie jest coś, o czym się myśli tak naprawdę. On już nie jest tak krytyczny. Wydaje mi się, że ten ruch jest, co za chwilę Łukasz potwierdzi, jest za późny i nic nie zmieni.

Łukasz Kałużny: Wiesz co? Całość można powiedzieć, że to moje odczucie jest takie, standardowy proble, zarabianie na open sourcie jest trudne.

Szymon Warda: Nie mamy pomysłu na to w ogóle żadnego.

Łukasz Kałużny: Mam wrażenie, bo Redis ma swój Redis Cloud dostępny też w różnych chmurach, raczej w różnych, w trójce głównych dostawców, nie oszukujmy się, nie tam w różnych. W trójce głównych hyper skylerów jest sobie Redis Cloud dostępny. I mam wrażenie, że to jako produkt po prostu sobie nie idzie, patrząc na tę układankę, że nie idzie. I teraz ja przejdę od razu do drugiego linka. Co się okazało? Microsoft ma Redisa u siebie jako usługę, każdy cloud ma Redisa jako usługę. I przy tej zmianie teraz pokazało się open source o nazwie Garnet. Czyli Garnet is the new remote cache-store from Microsoft Research. I najważniejszą rzeczą, jest zgodny z protokołem, z paroma tam gwiazdkami oczywiście, ale jest. W podstawowej funkcjonalności jest zgodny z protokołem Redisa.

Szymon Warda: Łącznie z tym, że nawet, żeby nie było, jest zgodny z bibliotekami do wykorzystania StackExchange.Redis, czyli najpopularniejszego klienta do Redisa.

Łukasz Kałużny: Np. akurat po ekosystemie .Netowym. I całość jest o tyle, bo zmiana licencji powoduje to, że trzeba pod spodem silnik wymienić, bo po co płacić jakiemuś dostawcy open source jak można to przepisać przy tej skali i to się będzie opłacało.

Szymon Warda: I nawet w tym momencie kierować rozwojem zgodnie z tym gdzie się chce, a nie tym co robi dostawca, w sumie developer inny, bo tak trzeba na to patrzeć. Bo w tym momencie Reddit Labs nie jest dostawcą tak naprawdę, jest po prostu jakimś developerem. To, że to firma utrzymuje, to ok, ale inna bajka.

Łukasz Kałużny: Są tam jakieś wady oczywiście, np. nie ma obsługi bodajże skryptów LUA i innych takich rzeczy, ale w podstawowym zestawie funkcjonalności spokojnie sobie da radę i to też fajnie pokazuje. To jest ten sam ruch, który zrobił… Raczej AWS zrobił to bardziej bezczelnie z ELK-iem, jak zrobił Open Distro do Elastica. To już był w ogóle zupełnie, bo zrobili chamsko forka i jazda.

Szymon Warda: Wiesz co, trzeba zapytać czemu nie ma LUA? Bo to jest niebezpieczne do wykonywania na środowiskach, które masz współdzielone. Potencjalna dziura bezpieczeństwa. Więc tak, jak najbardziej, robią po prostu typowego SaaSa, który może być hostowany w chmurze bez większych problemów i będą się pod to optymalizowali. Za późno Redis, sorry wielkie. Dobrze, przejdźmy do kolejnego. Jak już Ty ruszyłeś temat ogłoszeń, to oczywiście też kolejne ogłoszenie, które mamy. Retina, kolejny projekt MS-a ogłoszony.

Łukasz Kałużny: To jest projekt, z którym mam częściowo problem, częściowo nie, bo nawet sobie go dotknąłem.

Szymon Warda: Poczekaj, na razie powiedzmy w ogóle co to jest. W dużym uproszczeniu to jest observability dla sieci na eBPF-ie od Microsoftu.

Łukasz Kałużny: Dla Kubernetesa.

Szymon Warda: Tak, na Kubernetesa. Można włączyć na żądanie, integracja z Prometeuszem, przechwytywanie pakietów i agnostyczny od providera chmurowego. Co jest ciekawe, nie jest w CNCF-ie.

Łukasz Kałużny: Jeszcze.

Szymon Warda: Tak, ale jeszcze nie jest. Licencja MIT. Tak, więc teraz lecisz ze swoją opinią.

Łukasz Kałużny: Dobra, całość, pierwsze, jakie mam skojarzenie, to słuchaj, Pixi.

Szymon Warda: A ja mam inne skojarzenia tak naprawdę, może to wynika z moich ostatnich walk.

Łukasz Kałużny: Dokładnie, ale pierwsze skojarzenie dla mnie to było, że jest to podstawka taka jak Pixi, bo ja patrzę, po co oni to robią. Trzeba… Oni muszą u siebie cały ten stos monitoringowy teraz… On się rozwija, a zużył cały stos monitoringowy do takiego Kubernetesa. I w tym miejscu, jeżeli popatrzysz na sposób, w jaki jest powiedziane o wizualizacji, czyli Grafana, Log Analytics ogólnie, wyrzuć to wszystko w sposób agnostyczny. Tylko z drugiej strony ta agnostyczność jest wspierana do wzięcia po stronie Azure’a, to jest po prostu building blog, który budują do swojego observability. I tutaj taka pierwsza rzecz, która mi się rzuciła właśnie to, że to jest tylko tool do wyrzucenia metryk i trace’ów, a nie ma tak, jak właśnie w Pixi, całej wizualizacji i innych rzeczy, że to jest konkretne narzędzie bardzo punktowe do całości.

Szymon Warda: Pixi ma, ale Pixi ma bardziej obserwacje gdzie pakiety płyną, żeby zbudować mapę serwisów. A co jest tutaj ważne dla mnie, krytyczne, to jest przechwytywanie pakietów. I teraz jaki mój tok myślowy jest? Debugowanie w AKS-ie jest możliwe, jest upierdliwe i jest trochę niebezpieczne. Żeby kogoś tam wpuścić, to sorry, to nie jest takie super łatwe. Kubernetes jako taki coraz więcej organizacji widzi, że on jest trudny, może nawet za trudny dla nich. I mamy, patrząc na to, co się działo w zeszłym roku odnośnie CAT container appsów i nie tylko, to jest takie ciśnięcie w kierunku generalnie: my będziemy to zarządzali, itd. Na container appsach np. jest jawnie na road mapie powiedziane, że nie będą i nie mają wspierania np. remote’a na konkretny kontener, po prostu nie, bo A, że to jest niebezpieczne, B, że to jest trudne, itd. Więc według mnie MS po prostu stwierdził, że brakuje narzędzi do debugowania, które byłyby na tyle bezpieczne, że można by to dać ludziom, a jednocześnie nie tworzyć wyrwy bezpieczeństwa dla środowisk, które będą po prostu utrzymywane na żądanie i które będą wielotenantowe tak naprawdę. Więc ja obstawiam, że po prostu MS buduje zestaw narzędzi, które będą mogły wspierać ładne, lepsze wykorzystanie tych wszystkich zarządzanych systemów tak naprawdę. To jest mój strzał i swoją drogą bardzo bym chciał, żeby tak się zadziało, bo tam trochę faktycznie brakuje.

Łukasz Kałużny: Dla mnie, patrzę na funkcjonalność, żeby dorobiło się to trace’ów. I zobacz, gdyby się ładnie wysyłały w open telemetry do takiego Tempo np.

Szymon Warda: Wydaje mi się, że w tym narzędziu nie, bo MS robi mniejsze, ale wydaje mi się, że coś powstanie, albo MS faktycznie weźmie Pixi, bo Pixi bardziej ten obszar przykrywa.

Łukasz Kałużny: Tak, bo zobacz, jest jedna rzecz, są flow logi, bo on łapie te flow logi, więc zrobienie, dlatego zrobienie trace’ów nie wydaje się tutaj takie aż problematyczne.

Szymon Warda: Na poziomie sieciowym nie, na poziomie takim generalnie aplikacyjnym, żeby rozumieć co tam siedzi i co przepłynęło gdzie, może być.

Łukasz Kałużny: No więc zobaczymy. Dobra, to jak jesteśmy przy open source to następna rzecz, nie wiem czy widziałeś, Graduation Open Telemetry.

Szymon Warda: Tak, widziałem. W sumie nic nowego. Znaczy nowe, że dzieje się tak naprawdę. Ale open telemetry już, przecież mówiliśmy parę odcinków temu nawet, że wersja już jest pozamykana, pracują nad nową, itd. Więc to taka formalność według mnie tak naprawdę.

Łukasz Kałużny: Tak, więc całość, jeszcze o co chodzi z Graduation? Czyli że projekt w ramach Native Foundation CNCF-u trafia do tych projektów, które już dojrzały, o tak. Pierwszym był takim Kubernetes i potem się po nim posypało dojrzałości. I tu wjeżdża open telemetry. I co słuszne, patrząc się na całą układankę rzeczy, ma to ręce i nogi w tym momencie.

Szymon Warda: Ja doprecyzuję jedną rzecz, wjeżdża standard open telemetry. Nie Open Telemetry w technologii. To jest bardzo, bardzo ważne, bo to wsparcie dla Open Telemetry w różnych platformach, itd…

Łukasz Kałużny: To jest już inna rzecz.

Szymon Warda: To jest zupełnie inna bajka, ona często jest bardzo kulawa i tam alfa betę popędza, tak swoją drogą. To może być pole minowe i zakres pokrycia, co jest, też jest bardzo różne. Tu chodzi tylko i wyłącznie o standard tak naprawdę, czy to, jak to w ogóle ma działać.

Łukasz Kałużny: Dobra, co z Twoich?

Szymon Warda: Z moich? Ostatnio dostałem feedback odnośnie naszego, że czasami brzmimy jak starsi ludzie, którzy reklamują OFE. Więc idąc tym torem myślowym tak naprawdę, jest fajny wpis, który trochę pokazuje to, że nam jest pod wieloma względami fajne to, że my pewne technologie rozumiemy, bo widzieliśmy jak one się zmieniały tak naprawdę, jak ewoluowały przez czas. Zaczynały od czegoś prostego, a potem coraz trudniej, coraz trudniej, coraz trudniej i to budowało się. Jest fajny wpis, który bazuje na prelekcji z zeszłego roku o tym jak działa AWS Lambda i jak co się zmieniało i co dochodziło i jak to się komplikowało. Fajnie, dlatego, że on odczarowuje jak to działa i też pokazuje jedną bardzo ważną rzecz, że chmura jest droższa potencjalnie niż goła VM-ka. Ale są uzasadnienia czemu, bo tam tego naprawdę jest dużo. To nie jest tylko odpalanie Dockera na VM-ce. Więc to będzie takie kilka punktów co się tam w ogóle działo, co punktuje. Np. po kolei szło - dodanie worker managera do zarządzania inicjalizacją maszyn i ruchem między nimi, dodanie availability zone i load balancera, żeby rozrzucać te wywołania powiedzmy synchroniczne. Nowy system do scentralizowania logów, jak już na wiele to rozrzuciliśmy zon. Mikro VM-ki, nie wiem czy pamiętasz jak to wychodziło tak naprawdę.

Łukasz Kałużny: Raczej tak, mikro, czyli całe Fire Cracker.

Szymon Warda: Fire Cracker był kolejnym poziomem, bo to były mikro VM-ki, a Fire Cracker umożliwiał tak naprawdę…

Łukasz Kałużny: Raczej to była implementacja.

Szymon Warda: Potem dalej, wykonywanie snapshotów do szybszej inicjalizacji, żeby był mniejszy code start. Dalej, wrzucenie cache’owania snapshotów pomiędzy wiele zon, wprowadzenie warstwowości cache’owania, żeby to się ładnie inicjalizowało.

Łukasz Kałużny: Raczej wiesz co, jedno powiem o tym, bo to jest mindfuck. Tutaj Szymon, to co mówi, to jest memory snapshot tej mikro VM-ki. To jest istotna rzecz. Czyli rozgrzewamy, odpalana jest Twoja lambda, czyli Twój serwer aplikacyjny do momentu, żeby wstał i następnie jest snapshotowany.

Szymon Warda: Tak, ale sporo tego dzieje. A na koniec w ogóle optymalizacje na poziomie systemu operacyjnego, żeby inicjalizacja i czytanie z plików było po prostu bardziej sekwencyjne a nie randomowe. To pokazuje fajnie tą drogę lambdy, co się działo i jak to wewnętrznie działa. Fajny artykuł, długi faktycznie, z dobrymi rysunkami, itd. Więc jakby ktoś chciał coś odczarować, to zdecydowanie polecamy.

Łukasz Kałużny: Dobra.

Szymon Warda: A co tam masz Ty?

Łukasz Kałużny: A ja trochę bardziej biznesowy wpis. To jest fajna rzecz pokazująca problem jeżeli ktoś pracuje, zobaczy ile wynosi Twoja stawka vs ile firma za Ciebie bierze.

Szymon Warda: Tak.

Łukasz Kałużny: To jest piękna rzecz, że nie rozumiemy przepływu pieniądza w firmach.

Szymon Warda: I kosztów.

Łukasz Kałużny: Nim zaczniemy tym… Kosztów, tak. I tutaj jest bardzo fajny przykład. Ktoś wrzucił na Reddicie i lata sobie screen z Reddita po Twitterze. Koleś zobaczył, że jego stawka jest… Jest bilowany do klienta za 5 razy tyle. I co zrobił? Wysłał do klienta maila, że może zacząłby pracować bezpośrednio, a tamten forwardną tego maila do jego szefa. To w ramach takich dowcipów, nierozumienia tego zupełnie.

Szymon Warda: Nierozumienia jak działa biznes, na czym zależy dużym firmom tak naprawdę. Już nie zależy na tym konkretnym developerze, tylko na płynności biznesu, na adresowanie ryzyk tak naprawdę w wielu sytuacjach. Tak, ale to jest wraz, z powiedzmy życiem uczymy się takich rzeczy, jak działa biznes i jak to jest wszystko księgowane ładnie.

Łukasz Kałużny: Spodobało mi się w tym wątku jeszcze, że ten szef nic nie robi, tylko rozmawia z klientem.

Szymon Warda: Widzę, że to co McKinsey zrobił odnośnie developerów, to widzę, że się szerzy w biznesie też, że nie powinniśmy rozmawiać w takim razie, powinien kodować.

Łukasz Kałużny: Kodować, tak, raczej po stronie developerów.

Szymon Warda: Tak, oczywiście, jedna opcja.

Łukasz Kałużny: Dobra, lećmy do tych…

Szymon Warda: Dobra, to u mnie w takim razie, artykuł wzięty z InfoQ, potem przekierowany na już konkretniejsze. Ale artykuł mówi o tym jak Zen Desk przenosi się z DynamoDB na MySQL-a ES3 i oszczędza 80% kosztów Łukasz. Normalnie takie zyski. Czyli musisz usunąć DynamoDB i lecisz na MySQL-a ES3 i będziesz zadowolony. Nabijam się z tego, bo taki click bait w tytułach zaczyna się szerzyć coraz bardziej i to zaczyna być upierdliwe. Nie każdy czyta te artykuły i po takim wpisie stwierdzi, że: nie, w ogóle to lecimy w tym kierunku, nie ma co myśleć. A artykuł jest o czymś zupełnie innym. O co chodziło? Oczywiście jest tam Kafka po drodze, wiadomo, zbierali logi z Kafki. I to było wrzucane do DynamoDB i koszty nagle DynamoDB zaczęły rosnąć. Co oni potem zaczęli robić? Potem zaczęli robić taki myk, że do MySQL-a wrzucają te logi, a potem batchem te logi z MySQL-a trzymają w S3 i robią query’owanie po metadanych na S3, żeby dane wyciągnąć. Oczywiście tam czasem na poziomie pół sekundy i tam w tych okolicach, więc to nie jest transakcyjne. To jest ewidentnie po prostu jakiś audyt, logi, odpytywanie.

Łukasz Kałużny: Raczej wiesz co, to jest standardowy problem, moim zdaniem, zapominania, że dokumentowe bazy albo column wide’y są dobrą bazą transakcyjną, a nie do diabła hurtownią.

Szymon Warda: W ogóle ustalmy to, nietrzymanie logów, trzymanie wiadomości z Kafki w bazie dokumentowej, gdzie Kafka trzyma to realnie rzecz biorąc w pliku, to po jaką cholerę awansujemy się w hierarchii do wyższej bazy? I okay, to mogło być na start dobre rozwiązanie. Ale myślmy zawsze o tym, które dane, gdzie powinny być, jaki mają czas i jakie mają wykorzystanie tak naprawdę. Więc A, że tytuł jest totalnie tragiczny, chociaż żeby nie było, Zendesk na swoim blogu ma już ładny, poprawny wpis, bez żadnego click baitu i wpis ogólnie jest sensowny, ładnie pokazuje architekturę, ładnie pokazuje przejścia, co zmienili, itd. I pokazuje, że patrzenie na tych S3 i co więcej, potem, bo oni robią taki myk, że sprawdzają czy tam user istnieje w danym pliku właśnie po metadanych plików czy bardziej blogów S3, pokazuje jak fajnie, że nie zawsze musimy query’ować po stronie bazy, możemy te rzeczy wziąć i przequery’ować po stronie klienta. Także ogólnie naprawdę dobry wpis, mimo strasznie click baitowego tytułu. Dobra, co tam Łukaszu masz? Coś jeszcze?

Łukasz Kałużny: Dobra, kolejny open source od Microsoftu, co nie zawsze coś wywali announcementów różnych. Było jeszcze parę innych, ale zostawmy je w spokoju, bo są tak naprawdę dokładaniem rzeczy do dojrzałej technologii. Ale przykuło moją uwagę coś, co się nazywa Fleet, czyli multi clastery. Rozwiązanie do Multi Claster Core, jak to ładnie określili. Czyli ma pozwolić na orkiestrację workloadów pomiędzy klastrami.

Szymon Warda: Kolejny tool z tej całej układanki.

Łukasz Kałużny: Kolejny tool do federacji. I teraz jakie mam wrażenie? Bo Microsoft ma coś takiego jak Fleet Manager, taką usługę w Azure, niewykorzystywaną, to jest też, przez większość, która pozwala na kilka różnych rzeczy. Jego podstawową zaletą jest możliwość update’owania, zrobienia sobie release trainu do update’owania klastrów. Plus oczywiście takie scenariusze networkingowe i mam wrażenie, że część pracy po prostu poszła teraz w open source, tak jak przy innych komponentach, które budowali, tak jak KeD-a np. Uważam, że to jeden z lepiej zrobionych projektów ostatnich lat, jeżeli popatrzymy.

Szymon Warda: Bo to jest agregacja wielu mikro projektów, tak naprawdę.

Łukasz Kałużny: Tak i tutaj Fleet, takie jedno założenie, że nie mówią tutaj o federacji, tylko o multi cluster solution that user uses to manage Kubernetes clusters. I całość takim głównym featurem tutaj wrzuconym, to jest to, że mamy hub cluster na którym deployujemy sobie workloady i potem one trafiają na member klastry które są podłączone do tego huba.

Szymon Warda: To się może ładnie spiąć z paroma rzeczami.

Łukasz Kałużny: I teraz tak, moja taka uwaga, większość z nas tego w ogóle nie potrzebuje.

Szymon Warda: Nie, nie, nie, to w ogóle. To jest dla dużych korporacji, które potrzebują mieć scentralizowane rzeczy.

Łukasz Kałużny: Raczej dużej korporacji, dużych produktów, bo korpo to też jest złe określenie, dużych produktów i systemów.

Szymon Warda: Dla mnie to jest tak, że organizacji, które muszą mieć scentralizowane pewne zachowanie, po prostu potrzebują tego z punktu widzenia regulacyjnego albo jakiegoś operacyjnego. Tak, ale to jest totalnie niszowe. Ewentualnie to będzie jak z samochodami Formuły 1, że pewne feature’y po prostu skapią na dół i będzie się łatwiej zarządzać tymi dwoma, trzema, pięcioma, dziesięcioma klastrami.

Łukasz Kałużny: Więc tak, ale jak sobie zobaczysz to, to bardziej to przypomina Ci przecież podejścia z Uberów, Netflixów czy Open AI-a jeszcze jak się chwalili, jak budują infra.

Szymon Warda: Tak, oczywiście Łukasz, ale wiesz, sam to powiedziałeś, wokoło KubeCona wylatują rzeczy, to musi być coś co będzie na hype’ie, teraz Multi Cluster jest na hype’ie, coś co będzie: O Jezu! Jakie fajne!

Łukasz Kałużny: Raczej to będzie, wiesz, zabrakło mi tutaj tylko, że jest to konieczne, żebyś zbudował dobre IDP. Tego mi zabrakło.

Szymon Warda: Tak, ale np. w kontekście IDP dla dużych organizacji, to naprawdę może jakieś tam zastosowanie mieć.

Łukasz Kałużny: Gdzieś tak, gdzieś tam mogłoby mieć, ale…

Szymon Warda: Mniejszości oczywiście.

Łukasz Kałużny: Tak, ale trzeba tutaj poszydzić. Dobra, to kończymy na dzisiaj.

Szymon Warda: Trzymajcie się. Hej!

Łukasz Kałużny: Hej!