Szymon Warda: Oceniamy trochę taką realność tego, co właściwie organizacja chce. Bo czasami jest coś takiego, że dostajemy komunikat, że chcemy tego, potem rozmawiamy z ludźmi i okazuje się, że trochę czego innego potrzebują. Blisko, ale nie do końca ta sama bajka. Nazwanie i uwidocznienie wymagań jest bardzo potężnym narzędziem, bo to też jest wartość sama w sobie, bo organizacja nagle widzi, ok, czego oni realnie potrzebują, a co może nie do końca. Na papierze ta usługa wygląda świetnie pod ten problem, ale tylko na papierze. Jak się wchodzi w detal, to to partycjonowanie, które jest narzucone i tak dalej, i tak dalej, i tak dalej nie do końca i brak przy tym wsparcia dla Table Spaces totalnie u tego klienta nie miało sensu. I czemu to zrobiliśmy? Potem, żeby klient nie manipulował, albo żebyśmy nawet my też nie manipulowali sztucznie wynikiem. I potem do tych kryteriów była ocena każdej usługi i potem była suma ważona, która usługa wygrywa. Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. A ja się bałem, że będą kluski z rosołem Szymonie, ale wszystkie linki do tego odcinka znajdziecie gdzieś tutaj, na dole, na dole znajdziecie lub na Patoarchitekci.io.

Szymon Warda: Łukasz, a czy wiesz, że kluski w rosole wychodzą lepiej tym, którzy subskrybują nasz kanał?

Łukasz Kałużny: Tak?

Szymon Warda: Tak, poważnie, polecamy. Lajkowanie też działa.

Łukasz Kałużny: Więc ku chwale algorytmu zalajkujcie, zasubskrybujcie, a jeszcze lepiej jak jesteście na YouTubie, zostawcie komentarz, randomowy komentarz, który zawiera osiem słów, będzie super. Dobra, to jeszcze dwa drobne ogłoszenia. Zerknijcie na szkolenia.

Szymon Warda: Czekaj, ale Łukasz, jeszcze temat, co robisz 16 czerwca?

Łukasz Kałużny: Wiesz co, będę się wymądrzał na temat nie AI-a.

Szymon Warda: O, a gdzie?

Łukasz Kałużny: Na naszej konferencji z okazji dwusetnego odcinka, więc zerknijcie na detale, a przy okazji też zerknijcie na nasze szkolenia.

Szymon Warda: Dokładnie. Dobra, lecimy z tematem. Dzisiaj taki trochę, wejście w to, co właściwie też robimy w Protopii, co się u nas odbywa, bo czasami robimy takie analizy wszelkiej maści, różne audyty. I tak trochę pomyśleliśmy sobie, że damy Wam taki mały przegląd, jak to wygląda i co tam właściwie robimy.

Łukasz Kałużny: Dobra, to Szymon, powiedzmy sobie, kiedy to się odbyło? To który masz odcinek, bo to są pewne rozważania sprzed X czasu i jakbyś nadał temu w ogóle cały kontekst całej sytuacji.

Szymon Warda: Powiedzmy sobie to jest temat, który się dział połowa zeszłego roku. To jest dość ważne, jeżeli chodzi o też decyzje, jakie były i też pochwaląc się, jak słuszne decyzje podjęliśmy. Ale to zobaczycie, o co chodzi. Jaki jest kontekst? Mówimy o dużym kliencie, nie będziemy tu go nazywali, który rozważał naprawdę dużą, taką bardzo zacną skalę dla przechowywania danych. Mówimy tutaj o dziesiątkach terabajtów. Wcześniej rozmawialiśmy z tym klientem, jak to w ogóle na poziomie architektury rozwiązać, jak na poziomie samego hostowania. A potem nadszedł temat: ok, skoro już wiemy, że będziemy to trzymali w Postgressie, wiemy mniej więcej jak to będzie wyglądało, jak to podzielimy, jak będziemy obsługiwali skalę i tak dalej, to w takim razie gdzie to w ogóle trzymać? Bo wiemy, że będziemy w Azure. Więc usług mamy trochę do wyboru. Którą wybrać?

Łukasz Kałużny: Szymon i chyba dodałbym jeszcze jedną kluczową rzecz przy całości tam, która może nie być, jest istotna moim zdaniem, znając temat, to, że była tam drobnica bazodanowa. Czyli że to mimo że o dużym wolumenie, to też jest duża ilość oddzielnych baz danych, shardów, tenantów, w zależności jak to sobie nazwiesz w tej architekturze.

Szymon Warda: Które są dodatkowo jeszcze, tak każdy Sharp ma kilka baz danych, one są nierówne rozmiarowo, niektóre są większe, niektóre są mniejsze. Jest tego. Więc takim jednym na przykład z problemów, które zostały zidentyfikowane nawet przez klienta, to był po prostu narzut na utrzymanie tego, zarządzanie i tak dalej, i tak dalej. Dobra, no to teraz tak…

Łukasz Kałużny: I teraz ważne, zmiana architektury nie wchodziła w tym miejscu w grę. Rozmawiamy teraz o hostingu, nie przepisywaniu aplikacji. To jest chyba też bardzo istotne.

Szymon Warda: Aplikacja powstała w sumie tylko trochę od zera generalnie, więc to było takie, że oni już wiedzieli, co mają. Sama aplikacja, dochodziły kolejne fragmenty, już część powstała, kolejne dochodziły, więc to był taki trochę schemat, jak w ogóle podejść do dalszych fragmentów i do dość długofalowego mimo wszystko rozwoju tej aplikacji, bo jest kluczowa dla tej organizacji, nie wchodząc w jakieś inne szczegóły. No dobra, to teraz byśmy Wam powiedzieli mniej więcej, jak taki temat w ogóle wygląda, jak go bierzemy, no nie? Przede wszystkim pierwszym obszarem to jest w ogóle identyfikacja takich stakeholderów, mówiąc to ładnie po angielsku. Czyli kto w ogóle ma w tym temacie coś do powiedzenia? Kto będzie odpowiedzialny? Jak to będzie wyglądało? I z ewentualnie kim mamy porozmawiać? No bo wiadomo, że część wiedzy jest plemienna i część wiedzy wychodzi w różnych rozmowach, część wiedzy jest w dokumentach i tak dalej. Czyli my zbieramy dokumenty, ustawiamy rozmowy, jakieś tam wywiady, często są grupowe, czasami jeden na jeden, różnie to bywa tak naprawdę. I próbujemy dzięki temu ocenić kilka rzeczy. Jaki jest stan obecny, jeżeli chodzi o dojrzałość technologiczną? Jaki jest stan obecny, jeżeli chodzi o dojrzałość operacyjną? Bo to, co mówiliśmy wiele razy, technologie wybieramy pod możliwość organizacji. I też to jest takie, co mamy tu teraz, gdzie możemy być i w jakim czasie. Bardzo ważne. Oceniamy trochę taką realność tego, co właściwie organizacja chce. Bo czasami jest coś takiego, że dostajemy komunikat, że chcemy tego, potem rozmawiamy z ludźmi i okazuje się, że trochę czego innego potrzebują. Blisko, ale nie do końca ta sama bajka. A potem oceniamy, gdzie jest ta granica między chcę a realnie potrzebuję. Bo potrzebuję, to jest w określonych momentach, a chcę, to jest takie fajnie byłoby, ale no może niekoniecznie. Wiele tu się nie wysila.

Łukasz Kałużny: Ale dobra i to jest trochę Szymon też powiedzenie sobie rzeczy, które gdzieś tam się przewija w różnych odcinkach, czyli…

Szymon Warda: Brutalny realizm.

Łukasz Kałużny: Urealnienie potrzeb, o tak.

Szymon Warda: Tak. Czemu to jest ważne? No bo każda potrzeba ileś będzie kosztowała organizację. Czy w kosztach usługi, czy w osobogodzinach, czy w narzucie czasowym, czy w czymś innym, będzie to realnym kosztem. Więc problem jest taki, jak czasami widzimy załóżmy takie opcje od konkurencji, że ktoś mówi i daje, potem mówi: wszystko możecie, a potem daje na koniec cenę taką, że klient mówi: a nie, to ja w ogóle tego nie chcę. Tak to nie do końca. Dobra. Więc co nam wyszło po tych wszystkich wywiadach, rozmowach i tak dalej? W Protopii robimy tak, że spisujemy to, potem robimy spotkanie z klientem, prezentujemy, co nam wyszło. Z reguły jest takie stwierdzenie: no faktycznie. O części wiedzą, o części nie wiedzą.

Łukasz Kałużny: Ewentualnie zaczyna się konflikt interesów w tym miejscu. W tym przypadku chyba go nie miałeś, z tego co pamiętam.

Szymon Warda: Nie, to było bardzo płynne.

Łukasz Kałużny: To było spójne. Niektórzy po przedstawieniu, bo chyba trzeba, warto dodać Szymon, że kiedy przedstawiasz takie coś, jest zawsze, wymagania, zdarzają się sytuacje, że niestety trzeba pogodzić grupy interesariuszy i spływają przeciwstawne potrzeby z organizacji.

Szymon Warda: Często jest koszt versus to, co potrzebujemy realnie. Tak, ale są to… Raczej nazwanie i uwidocznienie wymagań jest bardzo potężnym narzędziem, bo to też jest wartość sama w sobie. Bo organizacja nagle widzi, czego realnie potrzebują, a co może nie do końca. Dobra, mamy tą serię wymagań. Potem co my z tego, co tam w ogóle nam wyszło? Tak żeby omówić bardziej na przykładzie. Przede wszystkim mówimy o terabajtach danych, więc oczywiście, że możliwość wyjścia z usługi zarządzanej, bo to rozważaliśmy, jest ważnym elementem. Jest to usługa, która ma możliwy downtime, że tak powiem, ale on nie jest długi i na migrację terabajtów to z całym szacunkiem backup, a potem recovery, no nie zadziała. Nie ten scenariusz. Co dalej idziemy? Idziemy w terabajty, więc koszty, koszty i koszty będą ważne i zarządzanie kosztami. Niekoniecznie musi to być tanie, ale musimy umieć zarządzać kosztami, bo będziemy trzymać te dane relatywnie długo. A nawet gdyby nie, no to terabajty. Dalej, jeżeli mówimy o kosztach, to bardzo prosta opcja, bo mowa o Postgressie, table spaces, możliwość przechowywania różnej świeżości baz danych. Bo akurat usługa jest tak zbudowana, że dane starsze są dużo rzadziej odpytywane, więc zależałoby, żeby mieć właśnie dane świeże na dyskach lepszych, a potem idziemy degradacja jakości czy też może wolniejsze dyski im dalej jesteśmy w czasie, jak najbardziej tutaj sprawdzałoby się super. Wysoka dostępność, dlatego, że w czasie kiedy usługa jest potrzebna, jest naprawdę realnie potrzebna. To tutaj nie ma dyskusji. Ona po prostu musi w pewnych momentach dnia działać, koniec kropka. Kolejna opcja to jest to, co nam wyszło, ciekawa właśnie rzecz nam wyszła w kontekście rozmowy z osobami, które by to utrzymywały, prowadziły, DevOpsami, że OAuth jest bardzo dla nich ważny, bo zarządzanie hasłami, dostępami w tej ilości serwisów jest już obecnie zmorą. Na przykład to nie było początkowo zwerbalizowane kompletnie, ale okazało się, że OAuth jest kluczowym tu elementem. Co było ważne w momencie, jak to robiliśmy, wtedy jeszcze Postgress nie wspierał w pełni. I ostatnie, które nam wyszło, które było naszą rekomendacją bardzo mocno, to jest replikacja wieloregionowa albo możliwość generalnie odtworzenia się w wielu regionach potencjalnie, no bo duże dane, jeszcze moce obliczeniowe, tutaj element jakby region padł albo czkawka, to nie zatrzymamy biznesu. Więc taka rzecz. Ostatnim elementem z racji na niewielki zbiór zespołu łatwość monitorowania, po prostu, żeby z tym się żyło prosto. To nie jest firma, która kręci się wokół bazy danych, tylko firma, która robi biznes na czymś zupełnie innym. Dobra, i mamy taki zestaw. Też go prezentujemy, jak to wygląda, mówimy, co będziemy oceniali. Klient mówi: tak, zgadza się, czasami się zaskoczą. No to co, idziemy przez to, co w ogóle omawialiśmy. Łukasza rozbawiłem.

Łukasz Kałużny: Wiem, co będziesz omawiał, więc dobra, idź.

Szymon Warda: Pierwsza rzecz, która w ogóle poszła przy tej skali i to jest ten element, gdzie się ucieszyliśmy, że generalnie nie, to oczywiście jest Cosmos DB for Postgress. A czemu się ucieszyliśmy? Bo jak tą analizę pisaliśmy, to on był jeszcze ok. Teraz już jest usługą wycofywaną. Na papierze ta usługa wygląda świetnie pod ten problem, ale tylko na papierze. Jak się wchodzi w detal, to to partycjonowanie, które jest narzucone i tak dalej, i tak dalej, i tak dalej, nie do końca i brak przy tym wsparcia dla table spaces. Totalnie dla tego klienta to nie miało sensu. Kosztowo kosmos, że tak powiem. Ale się zrymowało. Więc dużo czerwonych flag. Usługa odrzucona i bardzo dobrze. W sumie cieszymy się z tego bardzo mocno. Najmocniejszym…

Łukasz Kałużny: Ale inaczej, trzeba też Szymon powiedzieć jedną rzecz, ona padnie przy reszcie usług zarządzanych, że jest problem z backupem, taki realny problem z prawdziwym backupem i z prawdziwą replikacją, z którą mogą być problemy.

Szymon Warda: Znaczy tak, Cosmos to było to, że jest usługa, fajnie jak się wchodzi. Nie do końca tam było scenariuszy wyjścia z niej w ogóle w sposób ucywilizowany. Jedyny, który był, to był taki migracja czysto aplikacyjna, co byłoby horrorem kompletnie. Backupy, to wiadomo, że tego nie zrobimy, nie odtworzymy, to już z tym się trzeba pogodzić. Jak załóżmy takie usługi właśnie, gdzie mamy replikację, możemy z punktu widzenia Postgressa zrobić na przykład do innej usługi, do innego Postgressa, tam też tego nie ma. Sam sharding fajnie, kosztowo średnio i możliwość, też granularność zasobów, które można było dobierać, średnio to wyglądało bardzo mocno, dlatego kompletnie nie. Najlepszym konkurentem w tym momencie chmurowym wchodził Flexible Server for Postgress. Tam kilka rzeczy naprawdę było fajnych. Przede wszystkim zarządzana usługa, mały opsy, to było to, że jeszcze jak to rozważaliśmy nie było OAutha, który miał się pojawić w wersji 18, więc to bardzo fajne. Skalowanie, które miało być tam near zero downtime, czyli poniżej 30 sekund, fajnie. I można było konfigurować logiczną replikację pomiędzy nawet różnymi bazami z poziomu Postgressa jako takiego. Więc tam było kilka elementów, które wtedy były fajne. Z bardzo dużych minusów, to brak table spaces. Sorry, kosztowo, długofalowo niekoniecznie. Ta myśl, że są ograniczenia odnośnie tego co możemy włączyć, które komponenty, pluginy i tak dalej, ale do przeżycia.

Łukasz Kałużny: Lista pluginów jest… Inaczej, w tym przypadku była sobie do przeżycia.

Szymon Warda: Była do przeżycia, tak, ona jest imponująca i cały czas przede wszystkim rosła. To było bardzo ważne i widać było, że Microsoft to rozszerza, rozszerza, rozszerza. Więc tam tam było tego dużo.

Łukasz Kałużny: Tak i przy tej skali trzeba sobie powiedzieć znowu backupy - realne, prawdziwe. Inaczej, bo teraz powiedzmy sobie, jeżeli masz disaster recovery, to być może chciałbyś się odtworzyć poza tą chmurą i wyciągnąć te backupy.

Szymon Warda: Tak, tam było kilka strategii, bo tam w ogóle, jeżeli chodzi właśnie o samo HA, tam jedną z naszych rekomendacji było to, żeby trzymać, właśnie móc przełączać, żeby HA było między wieloma potencjalnie regionami, a przynajmniej wieloma klastrami różnymi, żeby przełączanie było bardzo różne, tak że na tym nam zależało. Recovery do wielu chmur potencjalnie, ale przede wszystkim to, żeby trzymać backupy też między innymi na on premie. Więc tam parę rzeczy się komplikowało. Nie było takie to bardzo płynne wejście. Tak, problemem tu był to, że replika musi być w tym samym regionie. Czyli co u nas w tym momencie by ograniczało nas praktycznie do jednego czy też maksymalnie dwóch regionów. Ale przede wszystkim to, że jak padłaby część tego systemu, to by padła i byśmy nie otworzyli tego.

Łukasz Kałużny: Tam zabawa, tak. Druga sprawa, możesz… W ogóle inaczej, możesz próbować się replikować do innych miejsc, możesz się zreplikować asynchronicznie też do on premu przykładowo w ogóle albo poza Azure’a. Tam… Inaczej, tylko to jest trochę, jest to bardzo ręczna dzierganina, o tak, to nie jest coś, że zrobisz to sobie z poziomu clouda, tylko to jest jakbyś sobie sam poszedł rzeźbić pod spodem. I to jest logical replication.

Szymon Warda: Tak. I rzecz, która nie była idealna, ale fajnie byłoby, gdyby było, to było kilka rzeczy. To było tak, promocja repliki jest manualna, czyli nie mamy takiego HA, takiego ładnego, płynnego, pięknego i żeby to działało po prostu bez operatora. No trochę to jest zrozumiałe, bo potencjalnie dane możemy stracić. I tworzenie repliki tworzy nową instancję. To też było problematyczne, jeżeli chodzi właśnie o to, jak odtwarzać i cały proces disaster recovery. Nie było idealnie. To co mówiliśmy, nie było wtedy jeszcze dostępnej wersji 18, miała być w GA, to się miało pojawić, ok. Dobrze, idziemy teraz w ostatni element, który klient miał i który też rozważaliśmy, to był operator na AKS-ie. Zaczął klient, korzystał już generalnie, miał wdrożoną jakąś próbę z Cloud Native PG na AKS-ie. No i jak to teraz tam wyglądało? Bo kilka elementów było fajnych. Po pierwsze, table spaces, czyli możemy sobie rozłożyć. Czemu? Doskonale wiemy. Elastyczność, spoko, możemy też mieć granularność jeżeli chodzi o zasoby, compute i tak dalej. Jeszcze był jeden, Flexible Server, tam była niezła ta granularność, można było całkiem fajne rzeczy wybierać. Jednak znowu granularność na poziomie dysków mogłaby być trochę lepsza, że tak powiem. Nie było to super, zdecydowanie sam AKS z siebie daje dużo, dużo więcej. Tak, jeżeli chodzi o narzut utrzymywania na Cloud Native PG. On wbrew pozorom nie wyszedł tak bardzo dużo większy. Dużo ta usługa robi sama z siebie, jeżeli chodzi o monitorowanie, nie samo wsparcie, operatory, to (…) AKS, nawet dashboardy, które są dodawane, to jest i jest ładnie zbierane, tu trzeba bardzo mocno pochwalić. Co dalej? Rozszerzalność, replikacja, pełna kontrola przez CRD, czyli Custom Resource Definition w Kubernetesie. To bardzo mocno ułatwiło i też ułatwiło operations na trzymaniu spójności między wieloma klastrami, kolejna rzecz, która tu jest. Oczywiście też nam ułatwiało to sieciówkę pomiędzy wieloma klastrami, żeby można było przepinać. Nie ma oczywiście tutaj i nie będzie tego przełączenia całkowicie automatycznego, jeżeli mamy pomiędzy wieloma klastrami. Bo jeżeli jesteśmy w jednym klastrze, to przełączenie między masterem a (…) jest automatyczne i to jest super. Tylko nam to niby daje, klaster się złoży, to się złoży.

Łukasz Kałużny: Inaczej i teraz trzeba sobie tylko jeden element powiedzieć, żeby… Inaczej, w porównaniu do tych scenariuszy, te Cloud Native PG… Inaczej, tak, jest zajebiste, to trzeba bez dwóch zdań. Przy tej skali jest i tak narzut operacyjny, który jest duży na przykład z upgrade’ami. To będzie i to jest największy chyba ból tyłka tego całego rozwiązania.

Szymon Warda: Jest, chociaż nad tymi update’ami też pracują, one też się zmieniają. Bo faktycznie on umie robić te rolling update’y i tak dalej. Tam faktycznie zmieniło się dość dużo i widać, że nakład na to jest, więc też był nakład. Największy minus też to było to, wersja, którą rozważaliśmy, nie wspierany był Postgress 18, więc przez to opcji na OAutha nie było jeszcze, ale miał być, że tak powiem. Więc finalnie na czym się w ogóle skończyło? Skończyło się właśnie na operatorze. Zdecydowanie przy tej skali opcje wyjścia, koszty operacyjne niewiele wyższe. Jak policzyliśmy to kosztowo powiedzmy… Bo jak to rozważaliśmy? Tu i teraz co robić, co robić za 3 do 6 miesięcy i skala na rok, bo to są zupełnie inne skale, jak to będzie wyglądało. Bo przede wszystkim, bo to, co mówiliśmy nawet w wielu odcinkach, budujemy kompetencje, czyli to, co wybieramy na 3 do 6 miesięcy, to jest okno kiedy budujemy kompetencje, możemy coś zmienić, przygotowujemy się do zmiany i potem długofalowy na to, z czym my docelowo chcemy żyć. I wyszło, że w ogóle bez myślenia, Cloud Native PG jako długofalowy to jest ten wybór słuszny. Kosztowo się spina i tutaj nawet daje miejsce na kilka etatów. Krótkofalowo Flexible Server może, ale jak już klient ruszył z Cloud Native PG, nie było to sensu, więc został na Cloud Native PG, tylko tam jeszcze z sugestiami jak to zrobić właśnie w kontekście disaster recovery, w kontekście HA i takie drobne zmiany, jeżeli chodzi właśnie o jak sobie poradzić z OAuthem do czasu wyjścia wersji 18 i tak dalej. Czyli taki trochę worek drobnych sugestii, żeby żyło się lepiej i przyjemniej. Ale to prowadziło też, czemu ten odcinek w ogóle powstał, jeden to właśnie jest taki sneak peak odnośnie tego, jak działamy, czym się właściwie zajmujemy. Wydaje mi się, że jest wartościowy, dajcie znać w komentarzach, mailach, cokolwiek, na Discordzie może być.

Łukasz Kałużny: Dzisiaj wyszedł Twój monolog, ale nie miałem co się wtrącać w to. Ja bym też jedno powiedział, taką matrycę decyzyjną, która sobie powstała, bo to chyba fajnie byłoby powiedzieć, że zagregowaliśmy to do czterech dużych punktów, czyli koszty, łatwość zarządzania, elastyczność i strategia wyjścia.

Szymon Warda: Tak, bo żeby było, to zanim w ogóle przedstawiliśmy jakiekolwiek wyniki ustaliliśmy z klientem, jakie są wagi dla poszczególnych kryteriów. I czemu to zrobiliśmy? Potem, żeby klient nie manipulował, albo żebyśmy nawet my też nie manipulowali sztucznie wynikiem. I potem do tych kryteriów była ocena każdej usługi i potem była suma ważona, która usługa wygrywa. I to wyszło. Czemu? Operujmy na liczbach tam, gdzie możemy i tak dalej. Swoją drogą jest odcinek kiedy Łukasz mi się wcina. Co za sukces!

Łukasz Kałużny: Wiesz, tutaj nie mam co się… Inaczej, zauważ, że jak dyskutowaliśmy, sam Ci powiedziałem, że trzeba rozborować Cloud Native PG mocno.

Szymon Warda: Tak, jest dobry. Znaczy, też odrzuciliśmy, w ogóle jest drugi operator od, od…

Łukasz Kałużny: Boże, z Zalando wyrzuciliśmy, od Zalando, tak. Zalando, no niestety, Cloud Native PG przebił, o tak. Inaczej, osoby, które były u mnie na szkoleniach, to jest istotna rzecz, bądź słuchały starych odcinków, zauważ, że jeszcze parę lat temu byśmy powiedzieli: nie próbuj tego hostować na Kubernetesie.

Szymon Warda: Taka była (…) w ogóle.

Łukasz Kałużny: Tak. I teraz chyba dwie tutaj jeszcze na koniec, dwie ważne rzeczy. Te kompetencje na przykład u klienta Kubernetesowe były. To jest istotny element. Były. I wiecie, i teraz jest jedna rzecz, której zawsze, trzeba sobie zawsze popatrzeć i z którą ja mam troszkę problem. Bądźmy szczerzy, słowo pod tytułem zbudujemy kompetencje potrafi być mitem wielu. Zanim dojdziemy… Inaczej, managersko ktoś pomyśli, że wysłał na dwa szkolenia i ma już zbudowane kompetencje. Może być takie przeświadczenie. Wiesz Szymon, że są takie przeświadczenia: wysłaliśmy Was na szkolenie, to już umiecie.

Szymon Warda: Łukasz, ja powiem tak, kompetencje może ludzie zbudowali, ale nie zbudowali procesów wokół tego. To jest ważne. Kompetencje muszą się łączyć z procesami organizacyjnymi.

Łukasz Kałużny: Tak i nie było doświadczenia.

Szymon Warda: Tak, i nawet to jest wszystko nie ułożone generalnie, ta rzecz potrzebuje trochę czasu. Ale ten cały temat trochę zmusił mnie do takiej refleksji, ogólnie rzecz biorąc, właśnie też temat zacząłeś. Jaka jest przyszłość usług zarządzanych i kiedy brać usługi zarządzane kontra właśnie operatorzy, operatory w Kubernetesie? Bo mimo tego, że mimo naszych rekomendacji, to ja bym powiedział, że usługi zarządzane dalej mają miejsce, one dalej mają sens w wielu obszarach.

Łukasz Kałużny: Ale wiesz co, trzeba zobaczyć… Inaczej, wiesz co, tak, trzeba sobie popatrzeć, to dla mnie, wiesz, tak jak kończymy taką myśl, bo moglibyśmy się rozgadać teraz, to jest w sumie dobry temat na odcinek i chyba go zaadresujemy za 3, 4 odcinki. Ale moja myśl przewodnia będzie Szymon taka, że wraz ze wzrostem skali i potrzeb taniej zrobić to na Kubernetesie w części rzeczy. Nie wiem czy chciałbym hostować kolejną Kafkę czy kolejkę na przykład na Kubernetesie. Od strony teraz operatorów, które mamy na bazach danych, nie ma tutaj tragedii.

Szymon Warda: Tak, też taki obszar jest, właśnie to, co powiedziałeś, jeżeli mamy kompetencje albo potrzebujemy, bo koszty nas dojadą, to operatory są super i że mamy kompetencje już Kubernetesowe i tak dalej, umiemy z tym bazami. Jednak, jeżeli mam małą skalę, nie potrzebujemy tego systemu wydelegować, usługi zarządzane są dalej bardzo fajne, więc to jak najbardziej. Dobrze, chyba tyle monologu.

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

Szymon Warda: Na razie.