Łukasz Kałużny: Dawanie tego ludziom to jak dawanie dziecku brzytwy, żeby pobiegało sobie po placu zabaw.

Szymon Warda: Tylko to jest takie podejście na zasadzie, że jak damy, to ktoś popsuje. Oczywiście, że popsuje. Widzieliśmy przykład Customize’a, z którym ja walczyłem i zgodzisz się, że tam też było nadziergane jak tylko można było.

Łukasz Kałużny: Jeszcze dodam jedną straszną rzecz, którą kurde ileś razy widziałem i zawsze widzę ją z problemami, to jeżeli ktoś próbuje zrobić Master Helma, który zainstaluje całe środowisko z logiką warunkową.

Szymon Warda: I potem prowadzi do tego, że całą logikę jakby na serwis mamy gdzie? Mamy tam nadpisywaną, a potem w sumie nikomu nie zależy na tym, żeby to przemigrować do głównego, bo rozwali wszystkim innym. Cześć. Słuchacie, o dziwo, Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka na Patoarchitekci.io albo tutaj na dole. Nie po boku, nie po prawo, góra, tylko na dole.

Szymon Warda: Dobrze Łukaszu, to co tam dzisiaj?

Łukasz Kałużny: Przypomnijmy szkolenia, bo znalazły się już na stronie, bo dużo z Was płakało, marudziło albo było niezadowolonych z tym, że proces wydawania budżetów szkoleniowych w firmie jest długi, więc wrzuciliśmy już terminy szkoleń na początek przyszłego roku, różnych. Z moich jest jedno nowe, to taki sneak peak, Agentic AI the Hard Way, czyli napisz agenta od zera, bez żadnego frameworku, bez żadnego Lang Chaina. A na 16 grudnia zostały też miejsca na Kubernetes The Hard Way. Szczegóły możecie znaleźć sobie na stronie. Dobra, a jak jesteśmy przy hard wayu, to dzisiaj rzecz, po której ja się z Tobą totalnie nie zgadzam, bo dawanie tego ludziom to jak dawanie dziecku brzytwy, żeby pobiegało sobie po placu zabaw, czyli Helm versus Customize. Czyli odwieczny problem czego powinniśmy użyć do templatingu, przygotowywania deploymentów na Kubernetesa, bo tak to można określić.

Szymon Warda: Dobrze, to może małe wprowadzenie co jest czym. Customize umożliwia nam zmiany yamla mówiąc bardzo prosto i modyfikację przez tam wiele poziomów. Mamy bazowy obraz i go tam modyfikujemy różnymi overlay’ami.

Łukasz Kałużny: Raczej trzeba powiedzieć po prostu robimy… Inaczej, robimy patche, można tak to określać, patchujemy, robimy nakładkę, nakładki na czyste yamle, czyli nazywamy to overlay’em. Czyli to są nakładki, czyli bierzemy i robimy nakładki.

Szymon Warda: Czyli modyfikujemy to, mówiąc bardzo prosto.

Łukasz Kałużny: Tak, w prosty sposób.

Szymon Warda: Z tym prostym… Modyfikujemy go, z tym się możemy zgodzić. Dobrze, teraz Helm. Helm natomiast jest takim enginem template’owym do Yamla. Czyli generalnie mamy Yamla, a tam elementami mamy jakieś while, ify i tak dalej. I na koniec tego Yamla wygenerujemy i całość przedstawiamy jako paczkę i masz, instaluj sobie i jasno określamy, które wartości można rozszerzać.

Łukasz Kałużny: Dobra i teraz jak sobie popatrzymy, najważniejsza dla mnie różnica jest taka i to co powiem to jest w kontekście tego, co oglądam na rynku. Bo ja Helmem nie gardzę, gardzę sposobem użycia i to jest bardzo istotna różnica.

Szymon Warda: Już się nie broń.

Łukasz Kałużny: Poczekaj, zaraz do tego przejdziemy. Dobra i Helm pierwotnie, to też jest bardzo ważne, jest package managerem. I tego jego pierwsze takie przeznaczenie, takie bardzo szerokie, to jest Packet Manager i mamy coś, co nazywamy Artifact Hub, na którym znajdziemy różne rzeczy do instalacji jako paczki na Kubernetes. Weźmy owianego sławą Prometheusza jakieś operatory. Third party softy teraz przychodzą enterpriseowe w postaci helma, więc jest tego, jest to sposób dystrybucji manifestu do Kubernetesa, żeby zrobić produkt do instalacji.

Szymon Warda: Tu się zgodzimy, Helm jest świetny do dystrybucji produktów.

Łukasz Kałużny: Tak, i to jest jedna rzecz. A Customize powstał po to, żeby bez narzędzi, bo jest wbudowany w kubectl’a, już w tym momencie w pełnej kompatybilnej wersji. Więc Szymon musisz odświeżyć wiedzę o ostatnich update’ach, jak to wygląda od jakiegoś czasu.

Szymon Warda: Ale ja tutaj nie twierdziłem nic innego.

Łukasz Kałużny: To pozwala Wam w prosty sposób po prostu zmienić manifest w jakiś sposób, albo dodać do niego elementy, podmienić po prostu pisząc kawałek Yamla, bądź wpisując komendę JSON patcha, którego Szymon nienawidzi. Dobra, i to są takie elementy, które posiadamy. Jak popatrzymy ze strony wsparcia narzędziowego, czy od strony tego, jak to robimy z pipeline’ów, czy jak to robimy z GitOpsa typu Argo, oba są pierwszymi obywatelami, zachowują się dokładnie tak samo.

Szymon Warda: Tak, i tu dam małą gwiazdkę, że mówimy oczywiście o Helm w wersji 3 i wyżej, pomijamy wersję 2, żeby uprościć, żeby nie było wytykania.

Łukasz Kałużny: Tego już nie powinno być. Dobra. I teraz słuchajcie, jakie są problemy z Helmem takie moje? Pierwsze, to jest ludzie robią tam nadmierną logikę. Czyli ja bym powiedział, że próbują dopieprzyć tam całą logikę biznesową, albo co jeszcze gorsza, zaczynają budować instrukcje warunkowe, drzewa warunkowe, czyli rzeczy, które powinny być konwencjami, zaczynają tam robić taką ifologię stosowaną. I to jest jeszcze pół biedy, bo nagle się okazuje, że przez to, że tam są GO template’y, które pozwalają na bardzo sporo logiki, zaczynają pisać własne funkcje. Czyli tam jest, zaczynają tworzyć własne reużywalne funkcje i inne rzeczy, wyrzucać je, współdzielić i zaczyna tworzyć się małe piekło, które nie wiemy dlaczego tak się dzieje.

Szymon Warda: Dobrze.

Łukasz Kałużny: I Szymon, pewnie spotkałeś się z tym, że developer zaczyna wymyślać jak się pokaleczyć, bo na tym środowisku powinna być jakaś specyficzna rzecz, która nie jest jawnie deklarowana.

Szymon Warda: Łukasz, zgodzę się, tylko to jest takie podejście na zasadzie, że a jak damy, to ktoś popsuje. Oczywiście, że popsuje. Widzieliśmy przykład Customiza, z którym ja walczyłem i zgodzisz się, że tam też było nadziergane jak tylko można było. Ale odpowiadając, czy ifologia ta może być? Tak, ifologia może być. Drugim podejściem, które jest dużo lepsze w tej sytuacji, to jest po prostu jawne dawanie obszarów, które można rozszerzać przez extended załóżmy labele, i tak dalej, całą tą opcję, żeby jednak mimo wszystko ten Helm był rozszerzalny. Zgodzę się, że ifologia jest zła. Można to zrobić inaczej tak naprawdę, jawnie przekazywać pewne parametry i zrobić bez ifów. Można to uporządkować.

Łukasz Kałużny: Dobra i teraz jeżeli popatrzymy o pisaniu dobrego Helma, jak mówimy. Bo zobacz, że sytuacja, kiedy dostarczamy coś już w ten sposób, jeżeli będziemy używać właśnie patrząc na te problemy, to pod tym względem Helm, tak jak powiedziałeś, one powinny być jawnie deklarowane. To jest rzecz, którą ludzie nie lubią bardzo często, że nie powinniśmy stosować tak naprawdę, w mojej ocenie, te wszystkie elementy, ten cały lukier składniowy, który tam leci, do wewnętrznych rzeczy nie powinien być w ogóle stosowany, tylko powinny być albo konwencje, czyli coś, co jest przewidywalne, albo jawnie zadeklarowane w valuesach jako parametry.

Szymon Warda: Bym się z tym zgodził. Dla mnie kolejna siła… Znaczy, ja może dam mój główny argument, czemu ja jestem zwolennikiem Helma. Customize powoduje to, że jak mamy, bo to jest taki koronny argument, tak, mamy mikroserwisy to używajmy Customize’a. Ja powiem właśnie: nie, bo w tym momencie mówimy, że każdy mikroserwis jest do siebie w miarę podobny i tylko będziemy to modyfikować. A przy Helmie mówimy inną opcję: drogi zespole, twoją odpowiedzialnością jest dostarczenie pakietu, dostarczenie sposobu instalacji i mnie w sumie nie interesuje. Jak chce inny zespół użyć, to też po prostu dostaje plik values i ma go użyć. Więc to jest jawne budowanie pewnego zbioru abstrakcji. Tu się zgodzisz, że Helm fajnie buduje abstrakcję. Buduje proste wersjonowanie i mówi: to jest Twoja bajka, masz się tym zająć i to ma działać dobrze.

Łukasz Kałużny: To dobra. I teraz taka rzecz, tak jak powiedziałeś, powiedziałeś wersjonowanie, płachta na byka. Mało kto poprawnie używa wersjonowania w Helmie.

Szymon Warda: Łukasz, zgodzę się, ale…

Łukasz Kałużny: I teraz…

Szymon Warda: Jest łatwiejsze do zrobienia. I jak się ustali co i jak, a nie jest trudne ustalenie co i jak, to jest łatwiejsze niż z Customize.

Łukasz Kałużny: Pod tym względem ok, tutaj wiesz… Inaczej, mówię, bo mamy, do czego piję, żebyście też wiedzieli, mamy chart version, czyli to jest manifest i app version, czyli wersja aplikacji. I powinniśmy, jeżeli podbijamy app version, czyli tylko aplikację, to będzie image tak naprawdę naszego release’u, to powinniśmy podbijać tylko app version. Jeżeli zmieniamy coś w Helmie, powinniśmy podbijać chart version. I to jest taka rzecz, której ludzie nie do końca akceptują.

Szymon Warda: Znaczy, ja powiem tak, przeglądając coraz więcej rep odnośnie właśnie instalacji Helma, to już stało się standardem, że naprawdę… Inaczej, dobre praktyki w Helmie weszły i już zagościły i są.

Łukasz Kałużny: Ale tylko patrzysz to z produktów. Teraz bardzo ważne. Patrzysz to z dużych produktów open source’owych.

Szymon Warda: Łukasz, tak, ale kiedyś produkty open source’owe miały pierdolnik i ludzie się nauczyli z tego pierdolnika. A obecnie już się rynek uporządkował, więc to też spływa na dół i jednak te zasady są już, jak robić to dobrze, zostały ustalone.

Łukasz Kałużny: Tak, ale są nieużywane dalej, bo lecimy z brzytwą. To tak z mojej perspektywy. Czy będziemy używać Helma z Kubernetesem? Zawsze. Ale to będą dla mnie, pierwszą rzeczą, to są pakiety ze świata zewnętrznego, zero customize’ów i innych rzeczy. Uważam, że to co przychodzi z open source’u, weźmy to Argo, Prometheusza, jakieś Ingresy i inne rzeczy, to wszystko powinno być instalowane Helmem. I tutaj w ogóle nie ma…

Szymon Warda: Nie mamy dyskusji, oczywiście, że tak.

Łukasz Kałużny: Tak. Jeżeli dostarczasz swój software jako produkt i ktoś będzie go instalował na klastrze i to jest zupełnie poza Tobą, tutaj również jest to Helm w 100%.

Szymon Warda: Dobrze. Teraz wchodzimy w to ważne, jaka jest definicja produktu? Czy zespół dostarcza swój system pod system, zbiór serwisów, mikroserwisów?

Łukasz Kałużny: Nie, ja patrzę jako produkt poza firmę zupełnie.

Szymon Warda: Ok.

Łukasz Kałużny: Czyli że nie masz w ogóle kontroli nad infrą i innymi rzeczami, zupełnie wypychasz to od siebie.

Szymon Warda: Ogólnie rzecz biorąc, jeżeli coś pakujesz i ktoś ma faktycznie jak produktowo na to patrzeć, to się zgadzamy, Helm jest jak najbardziej świetny.

Łukasz Kałużny: Tak i teraz wlatujemy w rzecz, w której ja preferuję, czyli nasze wewnętrzne aplikacje, które zespół own’uje jakoś, dostarcza, w zależności jak patrzymy, wewnątrz firmy, czyli gdzieś, gdzie mamy na to w teorii wpływ. Słowo “w teorii” jest tutaj kluczowe. Dlaczego preferuję tutaj, w tym miejscu? Dlaczego w tym miejscu preferuję…

Szymon Warda: Customize.

Łukasz Kałużny: Customize? Ponieważ w większości przypadków tam samo to, w jaki sposób aktualnie działa Customize… Co tutaj mam na myśli? To w jaki sposób podchodzi do wrzucania i robienia sobie nakładek na przykład per środowisko definiowania tego. Dla mnie Szymon na przykład bardzo ważną zaletą Customize’a są dwie pierdoły, które działają bardzo dobrze w postaci generatorów. Mamy Configmap Generator i Secret Map Generator, które w locie generują Ci, czy z SOPS-ów i innych rzeczy generują Ci Configmapy i Secrety. I teraz ważna funkcjonalność, która się w środku znajduje, to dla Was, jeżeli to będziecie robić, to Secret Map Generator i Configmap Generator potrafi wziąć te pliki .envy i inne takie, czy JSON, whatever, w czym trzymacie te configi. Wylicza sobie z zawartości hasha i generuje z tego, teraz to jest istotne, wylicza sobie hash i dokleja go do nazwy obiektu. Jeżeli w deployu na przykład odwołujecie się do Configmapy, weźmy tam config mojej aplikacji, to on w deployu podmieni nazwę tej Configmapy, czyli to będzie config mojej aplikacji i numerki i hash i tak samo będzie się nazywała Configmapa i przykładowo zrobi pierdołę, z którą jest, jak wiesz, zawsze problem. Czyli jeżeli nie zmieniamy deploymentu, to Helm go nie będzie w żaden sposób redeploy’ował w tym wypadku, jeżeli zmienisz samą Configmapę. A tutaj fajnie zrobi, wywoła cały rolling update i inne takie elementy i też widzimy co się zmienia, jak wygląda. To jest jedna z takich pierdół, które bardzo dobrze działają.

Szymon Warda: Generatory są fajne, tutaj nie ma większej dyskusji. Chociaż w kontekście jak mówisz jeszcze generatory odnośnie Secretów, to Łukasz nie trzymasz swoich secretów w Key Vault? Tak jak Ty żartuję, to jest żart, spokojnie.

Łukasz Kałużny: Tak, wiesz, wróćmy Szymon kto tu jest fanem SOPS-a od dawien dawna?

Szymon Warda: Nie. Znaczy Mozillowe naprawdę są spoko secrety.

Łukasz Kałużny: Nie, dlatego wiesz, mówię tak, że w tym, dlatego też jest plugin po prostu. Tak na przykład jak mamy SOPS-y, to SOPS-y bez problemu spina się z tym, sopsy można bez problemów… W scenariuszach GitOpsowych nawet pluginu nie potrzeba, żeby to wszystko spiąć ze sobą.

Szymon Warda: Słuchaj, na zawsze, to mieliśmy swego czasu odcinek właśnie o tym, jak ja bardzo nienawidzę Secretów. Tak.

Łukasz Kałużny: I tak, i ja też nienawidzę, więc tu akurat jesteśmy zgodni z tym, SOPS-y na szczęście przejęły.

Szymon Warda: SOPS-y przejęły i przejęły bardzo dobrze. Wiesz co, dla mnie ok, zgodzę się, generatory są super fajne. Problem jaki ja mam z Customizem największy to jest fakt, że niestety to prowadzi do over architektury na poziomie overlay. Mamy overlay, który jest overlay’em, który ma overlay i overlay.

Łukasz Kałużny: Inaczej…

Szymon Warda: Czekaj i potem prowadzi do tego, że całą logikę jakby na serwis mamy gdzie? Mamy tam nadpisywaną i potem w sumie nikomu nie zależy na tym, żeby to przemigrować do głównego, bo rozwali wszystkim innym.

Łukasz Kałużny: Znaczy wiesz co, dlatego ja podchodzę, że jeżeli chodzi o nakładki, może być tylko base, który zawiera w całą rzecz podstawową, tylko base i jedna nakładka per środowisko. I to będzie… Inaczej, czy można w Customizie się skrzywdzić? O Boże, jak… Inaczej, jak zaczynamy hackowanie, jak zaczynamy hackowanie…

Szymon Warda: Nie hackowanie, to jest po prostu nadużywanie overlay’i, które jest bardzo łatwe do zrobienia.

Łukasz Kałużny: Tak, dlatego ja podchodzę Szymon bardzo prosto. Deployujemy tylko jeden overlay nad środowisko i koniec, nie ma więcej. Bo jeżeli zacznie powstawać overlay do overlaya, to się… Inaczej, dobra, nazwijmy to wprost, już mamy tyle czasu, przepraszamy przedszkolaki, zajebiemy się, tak samo jak z Helmem.

Szymon Warda: I wracamy do naszego głównego tematu, czyli w każdym z tych narzędzi możesz się pociąć. Ja bym tak, żeby to nie było na zasadzie, że zostaniemy przy swoich zdaniach i ja bym to zrobił w ten sposób, jeżeli podchodzimy do tego, że te nasze mikroserwisy, bo o tym głównie mówimy, są takie same i my kontrolujemy… Bo siła Customiza, łatwo jest zrobić konwencję w base’owym mamy i potem tylko overlay jest na kolejne serwisy, zapisuje sobie tylko image swój, jakieś swoje secrety i tak dalej. W tym jest świetny.

Łukasz Kałużny: Przykładowo albo w ogóle, albo trzymamy w ogóle manifest per serwis i tyle. I oddzielnie każdy i wersjonujemy je.

Szymon Warda: To samo można by było zrobić też w Helmie, że po prostu podmieniamy tylko image. To samo można by było zrobić, ale ok, zgodzę się, jak najbardziej. Natomiast jeżeli podchodzimy, że zespoły są niezależne i nie wnikam jak to wygląda i od siebie mogą się różnić i to mniej lub bardziej znacząco, to dla mnie wybór jest prosty - Helm. Bo w tym momencie wchodzimy, ma działać, koniec kropka, ogarnijcie się. Nie popsują sobie nawzajem.

Łukasz Kałużny: Ja jeszcze dodam jedną straszną rzecz, którą kurde ileś razy widziałem i zawsze widzę ją z problemami, to jeżeli ktoś próbuje zrobić Master Helma, który zainstaluje całe środowisko z logiką warunkową.

Szymon Warda: To jest kuszące.

Łukasz Kałużny: Wiesz o czym… I wiesz jak się potem kończy w większości przypadków jak osoba, która to stworzyła odchodzi albo przechodzi do innego projektu, to jest płacz.

Szymon Warda: Wiesz co, nie, to można zrobić poprzez użycie prostych dependencies, że masz dependencies i tyle. Nie robisz nic więcej, a potem tylko przekazujesz te fragmenty do valuesów dalszych. Więc to można. Ja podważałbym sensowność tego w większości przypadków. Większość organizacji tego nie potrzebuje, tam logika powinna być CI/CD. Chyba, że znowu wypychamy całość do jakiegoś klienta.

Łukasz Kałużny: Produkt, robisz produkt, tam niestety będzie logika warunkowa. Weźmy na przykład: czy zainstalować Redisa, czy użyjesz zewnętrznego i podasz connection stringa? Czy zainstalować na przykład Postgressa z operatorem? To co mamy u jednego klienta w pewnym produkcie, który przychodzi z rynku. To tam na przykład to jest software, którego używają setki klientów, więc on musi mieć ifa: zainstaluj mi Postgressa, podaj connection string do Postgressa na przykład, czy secret, w którym będzie connection string. Więc to są, w tym, ta ifologia się znajdzie przy produkcie. Tylko tam ona jest potrzebna, ta cała zabawa z logiką będzie potrzebna, tylko…

Szymon Warda: Tej ifologii tam nie ma dużo, bo to jest albo mam dependency podany, albo mam connection stringa po prostu, albo instaluję sam, albo śmiga.

Łukasz Kałużny: Tak, tylko że to jest, tylko zobacz, to jest właśnie prosta ifa. A widzieliśmy jak ludzie próbują zbawić problemy, których nie będzie.

Szymon Warda: Zgodzimy się z tym, jeżeli nagle widzimy, że ktoś ma cały zbiór funkcji w GO, które generują różne rzeczy, to zgodzimy się, że to już jest złe.

Łukasz Kałużny: To tak, bardziej niż, zaczyna się robić wesoło.

Szymon Warda: I zgodzimy się z tym, że trzymanie jednego i drugiego systemu jest dobre, póki jest proste. Teraz zostaje pytanie trzecie tak naprawdę, bo to nie jest czy Helm, Customize, tylko to jest takie połączenie jednego i drugiego. Czyli standardowa opcja, że mamy Helma, który nam wszystko generuje, a potem jeszcze Customizem zmieniamy pewne fragmenty.

Łukasz Kałużny: Nie, ja… Naprawdę, to jest… Widziałem jedną tylko polecajkę na takie coś… Inaczej, spotkałem się tylko raz z takim jawnym wskazaniem tego. I to było w tym, ponieważ Helm kiedyś do Consula był bardzo mocno ograniczony od Hashicorp i rekomendowali, że jak chcesz sobie pozmieniać to zrób builda i przeleć go dopiero Customizem. I wiesz co? Ja Ci powiem tak, dla mnie to jest już piekło, zaczyna robić, piecze.

Szymon Warda: Dla mnie to jest tak samo jak dostawanie się do prywatnych funkcji w kodzie przez refleksje i inne rzeczy, że polegamy na tym, że ten kawalek będzie wyglądał i prosimy się o to, żeby to się za chwilę rozwaliło. To tak, dla wewnętrznego użycia absolutnie nigdy nie, bo to jest absolutna rzeźnia. Dla zewnętrznego? Zgodzę się z tym, kiedyś te Helmy były ograniczone, teraz mamy te wszystkie możliwości rozszerzenia i labeli, i obrazów, podmiany, zmiany i tak dalej, to już prawie nie jest potrzebne. A jeżeli nagle ktoś czuje potrzebę, to ja bym zobaczył, czy na pewno nie można tego zmodyfikować i czy na pewno nie robimy czegoś totalnie pod prąd. Bo to śmierdzi czymś takim, że ja wiem lepiej niż ludzie, którzy na przykład wydają tego Prometheusza. Więc tak, dla mnie to jest takie bardzo poważne, powiedziałbym, że pomarańczowe, wpadające w czerwone nawet światełko.

Łukasz Kałużny: Dobra, jest jedna rzecz, która w Helmie potrafi być bardzo dobra i bardzo zła.

Szymon Warda: To dajesz.

Łukasz Kałużny: Przy produkcie jest bardzo dobra, przy naszym wewnętrznym potrafi znowu skrzywdzić. Nie mamy tego zupełnie w Customizie. A Szymon odnoszę się do hooków i testów. I żeby teraz tylko wprowadzić o co chodzi, Helm ma 1, 2, 3, 4, 5, 6, 7, 8, 9 hooków. Mamy akcję pre post instal, pre post delete, pre post upgrade i pre rollback, post rollback oraz taki ostatni, który też jest pod komendą helm test, czyli zrobienie testu. I chodzi o to, że na naszym klastrze w tym momencie mamy możliwość wrzucenia specjalnych hooków, podpięcia się pod wywołania w tych momentach eventy i coś może zostać na Kubernetesie. Przykładowo tutaj w tym miejscu to jest odpalanie joba Kubernetesowego po prostu, który nam coś sprawdzi, przetestuje, zobaczy jak to wygląda. Na przykład Szymon Twoje ulubione pre instal, pre upgrade. Jeżeli mamy connection string do bazy danych, to zrób upgrade migracji schematu albo seedowanie bazy.

Szymon Warda: Tu się łączy moja niechęć też do Fluxa w pewnych, dla instalacji aplikacyjnych nadmienię, aplikacyjnych, nie infrastrukturalnych. Sorry, taka logika dla mnie jednak mimo wszystko powinna być w CI/CD, odnośnie instalacji, weryfikacji i tak dalej.

Łukasz Kałużny: Tak, jak nie robisz produktu, znowu, jak nie robisz produktu, nad którym nie będziesz miał kontroli, to będziesz zmuszony, to jest jedyna opcja, żeby to poprawnie zrobić…

Szymon Warda: Nie kupuję tego.

Łukasz Kałużny: Wiesz jak jest z puszczaniem, wiesz jak jest z puszczaniem skryptów przez adminów: o, nie puściłem.

Szymon Warda: Ale w tym momencie jeżeli jakiś produkt będzie odpalał jakieś joby, które mają jakieś założenia, które mają jakieś migracje, z całym szacunkiem, nie. Kontrolę nad tym co się dzieje na moim klastrze produkcyjnym mam ja. Ten Helm powinien mi tylko zainstalować soft i odczepić się ode mnie. Nie, naprawdę, hooki, ewentualnie do weryfikacji czy coś się łączy i tak dalej, bardzo proste.

Łukasz Kałużny: Tak, testowe tak. Ale wiesz, na przykład softy wykorzystują, wiesz o tym, że wykorzystują to w trakcie upgrade’u, żeby zrobić na przykład, podbić schemat danych, puścić skrypty migracyjne.

Szymon Warda: Super, to jest, ładnie wygląda na prezentacji znowu, jak masz bazę 2 gigabajtów. Bardzo źle wygląda, jak masz bazę 300 gigabajtów albo i większą. Więc z całym szacunkiem, nie, nie, nie nie. To jest feature, który bardzo ładnie wygląda na prezentacji, nie sprawdza się w realnym życiu. Zbyt duże ryzyko i tak trochę wciskanie jest: ja wiem lepiej do organizacji, które instalują. Nie. Checki, czy jest połączenie, tego typu rzeczy - tak, nic więcej.

Łukasz Kałużny: A potem apka zupgradeowana, a schemat nie podniesiony.

Szymon Warda: Tak, migracja schematu to jest odpowiedzialność osoby, która robi wdrożenie. I doskonale wiesz, że tworzenie czegokolwiek większego to nie jest na zasadzie, że puszczam sobie skrypcik i idę do domu.

Łukasz Kałużny: Ale wiesz, że ludzie by tak chcieli.

Szymon Warda: Łukasz, zdaję sobie sprawę, że by chcieli. Ci, którzy tak zrobili i się wywalili na twarz, już tak nie chcą.

Łukasz Kałużny: Dobra, czyli tak, to będą moje preferencje. Tak jak powiedziałem, rzeczy, które instalujemy z zewnątrz, z open source’u produkty, Helm jest super i tu nie kombinujcie, o tak. Ja wewnętrzne rzeczy jednak zrobię na Customizie, o tak. Chyba, że zespół nie będzie latał z brzytwą, to i prosty Helm też jest spoko w tym miejscu. Jestem antyfanem przekombinowania po prostu.

Szymon Warda: Dobrze, to ja odnośnie Helma powiem tak, jakie jest (…) odpowiedzialności, a ja jestem zdania, że teamy są od siebie niezależne i jednak mówię ogarnijcie się. To jednak jest Helm, prosty, bardzo prosty. Możliwe, że jakieś powiedzmy funkcje wspierane z poziomu platformy jak najbardziej, ale to tak zobaczymy. Niezależność bym czy Customize i ja jednak mimo wszystko nie, zbyt się sparzyłem na Customizie, tak że nie. Tyle. Faktycznie z tą uwagą, żeby pilnowanie, żeby jasne ustalenie kiedy jest wersja i jak to wygląda, kiedy wersjonujemy, żeby to było znajome wszystkim i wszędzie zawsze, to jest ważna uwaga. I zwracanie też uwagi na to, co można rozszerzać i żeby te rozszerzenia były.

Łukasz Kałużny: Szymon, zażartuję, żeby nie wyglądało to jak Pulumi, żeby ten Helm nie był ten, nie był pisany Solidem jak w C Sharpie.

Szymon Warda: Tak, dokładnie tak, żeby nie było nawet potrzeby myślenia o Solidzie i Dry i tak dalej. To nie ten poziom.

Łukasz Kałużny: Jedną rzecz w ogóle przegapiliśmy słuchajcie. Uwaga Szymon, bo ja w ogóle jedną rzecz przegapiłem zupełnie. Wyszedł Helm 4.0 tak w ogóle, tak by the way, by the way na koniec. Trzy dni temu, tak jak nagrywamy, wyszedł, przepraszam, dwa tygodnie temu, jak nagrywamy, czyli w połowie ten, w połowie. Zupełnie to przegapiłem. I uwaga Szymon, słuchajcie, trzymaj się, bo spadniesz tutaj mi. Stoisz, więc nie spadniesz, ale trzymaj się. Redesign plugin system that support WebAssembly based plugins.

Szymon Warda: Jezus, Maria, to będzie może jeszcze lepsze funkcje pisać. Nie jest dobry rozwój.

Łukasz Kałużny: Stary, Postgressa odpalisz z WebAssembly w ramach Helma.

Szymon Warda: Ja się boję tych prezentacji, przysięgam.

Łukasz Kałużny: Teraz widzicie minę Szymona, już wiesz dlaczego. I jeszcze za rok się przeprosisz z Customizem jak ktoś cię skrzywdzi.

Szymon Warda: Customize z overlayem, może, ale dalej pisanie tych pathów nie.

Łukasz Kałużny: Okej. Raczej tam pathów. Mówisz Sonetowi, że ma Ci dopisać w Copilocie i jest dobrze. Dobra.

Szymon Warda: Kończymy.

Łukasz Kałużny: To co, kończymy?

Szymon Warda: Trzymajcie się, heja.

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