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

Szymon Warda: …I Szymon Warda. Wszystkie linki do tego odcinka oczywiście na patoarchitekci.io/64. No to Łukaszu lecimy. Co tam masz ciekawego?

Łukasz Kałużny: Wiesz co, to taki bardziej zestaw rzeczy i pojęcia nachalności platform engineeringu albo Internal Development Platform, jak to niektórzy też nazywają. W ostatnich dwóch, trzech miesiącach.

Szymon Warda: Zrobiło się tego dużo. Ja się zgodzę. Faktycznie temat się wyhajpował.

Łukasz Kałużny: Tak, wyhajpował, na razie jeszcze jest… Na szczęście nie mamy żadnych Enterprisowych produktów, które się do tego przyklejają, za bardzo, jeszcze nie widać.

Szymon Warda: Może nie widać, ale gwarantuję Ci, że już coś jest robione.

Łukasz Kałużny: To na pewno - albo rebrandowane co gorsza w IBM-ie. Dobra, ale na poważnie jest tak, że my o platform engineeringu już tam jakiś czas temu mówiliśmy. Przed tym hype’em, który się teraz zapoczątkował. Gdzieś mamy z tym różne pozytywne, negatywne doświadczenia i całość, która jest taka funkcjonująca, jest to, że dla mnie to, co jest powiedziane, bo Platform Engineering z założenia jest po prostu sposobem budowy jakichś usług i historycznie ten buzzword w różnych postaciach ciągle wraca. Kiedy ja zaczynałem w IT… Szymon, pewnie pamiętasz sławetnego ITIL-a, który wtedy się…

Szymon Warda: Był.

Łukasz Kałużny: Taki, mocno się działo tak w 2007 roku, ‘06, te całe katalogowanie, usługowanie usług istniało i to już było takie pierwsze podejście. Z jednej strony to było operacyjne podejście do tego, do zarządzania. Z drugiej strony mieliśmy de facto SOA. Jeżeli popatrzymy na architekturę aplikacji, czyli że był pierwszy taki model wokół, usługowy model usługowy IT i model usługowy aplikacji.

Szymon Warda: SOA - było podejście na to, jak te aplikacje reużywać, to się z tym zgodzę tak naprawdę. Czy platformowość? Inaczej platformy postrzegam na chwilę obecną. Czym innym jest.

Łukasz Kałużny: Ja patrzę historycznie jak to wyglądało. Potem gdzieś przy szerokim wejściu, wirtualizacja i automatyzacji. To jest rok pi razy drzwi marketingowo 2011, 2010/11. Wtedy szeroko wchodziła automatyzacja, inne rzeczy i zaczęło się pojawiać słowo pięknie z open stackiem, VMWare’em, microsoft’owym stosem private cloudów i self service’ów dla Infry i innych rzeczy w onpremach.

Szymon Warda: To był bardziej… Uzupełnienie klocka, którego brakowało do platformy jako takiej do automatyzacji. A faktycznie to było takie zalepianie. Okej, tego nam brakuje to mamy pomysł, co z tym zrobić. Wielki hype i lecimy.

Łukasz Kałużny: Tak, zalepianie, tak, tylko że wszyscy w tym czasie te trendy robili. Większość firm dużych, które istniały, takie, w których na co dzień pracujemy, z którymi na co dzień mamy do czynienia, one z tymi trendami, z tymi hajpami szły.

Szymon Warda: Tak, tylko że akurat ten ma sens. W sensie automatyzacja i konteneryzacja i tak dalej. Jak najbardziej.

Łukasz Kałużny: Tak. Tylko że potem i tak się okazywało, że to admin odpalał self-service, a nie zespół produktowy.

Szymon Warda: Do tego dojdziemy w naszej dyskusji, bo tak będzie zawsze. Nie oszukujmy się.

Łukasz Kałużny: Tak i po tym trendzie to mamy następny trend, czyli cloud, potem kontenery. Dla niektórych może to się wydawać, że to gdzieś równolegle, ale wcześniej był cloud de facto - przed konteneryzacją.

Szymon Warda: Był dawno temu już.

Łukasz Kałużny: Tak. I powiedzmy, że 2014 to jest już taki DevOps na rynku na poważnie zaczynający się.

Szymon Warda: No. Zgadzałoby się.

Łukasz Kałużny: 2014, bo już TeamCity potrafiło dużo Jenkinsa już i Ensemble’a potrafiliśmy z puppetem, saltem, chefem wykorzystać naprawdę do niezłych rzeczy.

Szymon Warda: Znaczy wiesz co? Dla mnie to jest… Bo Ty patrzysz na technologię, ja patrzę bardziej na mindset. Czego zaczęło się wymagać od deweloperów?

Łukasz Kałużny: Ja wiem, wiem.

Szymon Warda: I ‘14 to tak, bym się zgodził, że to już było takie, że np. na rozmowach się pojawiało, że nie było kopiowania ręcznego na wirtualki, tylko faktycznie była automatyzacja, wymagane było jakieś skryptowanie, języki się pojawiły. No tak, to bym się zgodził.

Łukasz Kałużny: Historycznie i teraz wpadamy, był ten od 2014. No to sobie to fajnie jechało. Zaczęliśmy mówić, że DevOps się nie przyjął, ale sam model technologiczny stacku tak. Czyli powstały stanowiska, role typu DevOps Engineer i inne tego typu pochodne - i mamy nagle fala, potem 2018 zaczyna się fala na Kubernetesa, która doprowadza nas do tego, że róbmy teraz platform engineering, bo większość osób… Jeżeli popatrzymy to rozumie, że główną częścią platformy jest Kubernetes i to nie jest albo ładne UI, tylko nie wiadomo dla kogo.

Szymon Warda: Wiesz co, dla mnie jednej rzeczy brakuje, bo wydaje mi się, że nie do końca… To, jak Cię rozumiem, jak to przedstawiasz… To jest opcja taka, że DevOps się nie udał, bo z jakichśtam powodów. Jak patrzę na to, czemu de facto odbiliśmy się od idei DevOpsowej. Dla mnie to jest taka trochę smutna, mimo wszystko realizacja, że odbiliśmy się od tego, bo developerzy nie chcą tego robić, po prostu.

Łukasz Kałużny: Tak, to jest jedna część. Druga rzecz to są też buzzwordy rynkowe produkcji nowych tooli. Które sklejamy coraz bardziej, bo tak też jest.

Szymon Warda: Tak, ale wiesz co, toole toolingami, to można byłoby obejść, ale ja spotykam się często, szczególnie z developerami z rynków rozwiniętych. I teraz powiem czemu, bo miałem ostatnio dyskusję na ten temat, którzy po prostu są bardziej… Ludzie, którzy po prostu mówią, że ja chcę robić kod w jakimś języku, w którym koduje w Javie itd.

Łukasz Kałużny: Mnie reszta nie interesuje.

Szymon Warda: A na końcu chcę dać paczkę ZIP i koniec mojej odpowiedzialności, koniec mojego zainteresowania. I miałem na ten temat właśnie dyskusję generalnie nawet wczoraj odnośnie tego, że to chyba wynikało z tego, że jako powiem tak starsze pokolenie, niejako - my musieliśmy wszystkim kombinować, nauczyć się. Zobaczyć, jak to wszystko działa, a jak wchodzą developerzy z rynków rozwiniętych albo trochę młodsze pokolenie to oni po prostu: to wszystko działa. Jest, nie trzeba, można kupić, wziąć usługę, a kiedyś trzeba było te usługi poznać, bo z reguły trzeba było zbudować, bo rzecz gotowa była zbyt droga, więc trzeba było się tego nauczyć, wejść w internalsy i dowiedzieć się, jak to wszystko działa.

Łukasz Kałużny: Wiesz…

Szymon Warda: Dokończę jeszcze, generalnie to jest to, że wydaje mi się, że dlatego DevOps umarł, umarł dlatego DevOps, że wymyślony był przez trochę starsze pokolenie, bo to zaczynało się od ludzi, którzy zjedli zęby na automatyzacji masy rzeczy, ale niestety nie trafili na podatny grunt.

Szymon Warda: Po prostu. Bo wytworzyliśmy silosy w programowaniu, co ma lub nie ma sensu. Można dyskutować tak naprawdę. Ale dlatego właśnie umarło, a platforma jest pomysłem… Generalnie co zrobić, żeby mieć jakąś, wewnętrzne coś, co ułatwić? Mieć możliwość kodowania, mieć możliwość automatyzacji. Ale zabrać te całe skomplikowanie, wydaje mi się tu jest wartość platform engineeringu.

Łukasz Kałużny: I wiesz ,teraz, tylko, że dla mnie… Teraz patrzę trochę jeszcze z mentalności organizacji. Fajnie widać to po ogłoszeniach o pracę. To jest też, która rzecz mi się rzuciła, bo dostałem nawet takowe… Było SysOps, ops może tak, networking ops, infra ops, po prostu taka typowa sys-adminka wokół infry. Na to… Zobacz, że potem zaczęły się naklejać naklejki DevOps, mimo że nadal to był administrator.

Szymon Warda: No Łukasz, przecież wiadomo, że generalnie musisz je wpisać w wyszukiwania ofert pracy, no nie oszukujmy się, no.

Łukasz Kałużny: I teraz się okazało, że rynek już to odczuł i już nawet nie mamy administratorów, engineerów, DevOps engineerów. Teraz mamy platform engineerów, gdzie stos jest dokładnie rynkowo… Stos jest rynkowo, więc to jest taka jedna rzecz hajpu mentalnego, który się pojawił.

Szymon Warda: Znaczy wiesz co? Jedna rzecz. Zgodzę się, hajp tu jest ogromny tak naprawdę, ale poprawne nazwanie rzeczy faktycznie, że to nie jest DevOps, bo DevOps mówi zresztą tutaj, będziemy przy developerce i będziemy jeszcze przy platformie i tak dalej. Przy Opsach to to nie działa. Faktycznie takie skupienie się wokół tego toolingu jak zauważasz jest od groma obecnie wokół platformy i faktycznie ogarnięcie go i zrobienie z tego, bo wartość jest taka, że zmniejszamy ten narzut, ten overhead wokół developerki, no nie, że dajemy coś wewnętrznego - co ułatwi, przyśpieszy developerkę. I to jest wartość tej platformy. Więc nazwanie tego jako platform engineering ma sens. Spokojnie, nie mówię, że nazwanie tego w ofertach pracy jakkolwiek odzwierciedla to, co będziemy się zajmowali, bo pewnie nie. Nie oszukujmy się, ale ja się ogólnie bardzo cieszę z tego, że nazywamy to w końcu platformą, a nie DevOpsem tak naprawdę… Albo czymkolwiek jeszcze innym tak naprawdę.

Łukasz Kałużny: Wiesz co, tylko że… Jak popatrzymy… I teraz popatrzmy sobie, powiedziałem właśnie o tym Developer Experience, który się pojawia, czyli teraz Internal Developer Platform. Teraz dla mnie jest taka perspektywa, że de facto od paru lat takie IDP były dla każdego dostępne na wyciągnięcie ręki, bo nazywały się chmurą. Jeżeli popatrzysz, to większość takich zalążków to nie jest jeszcze kompletne nawet w tym momencie, ale jakość tego co weźmiesz np. na podstawie któregoś z top providerów cloudowych w porównaniu do tego, co Ty możesz lokalnie próbować zbudować, jest przepaść. Dla większości firm.

Szymon Warda: Ale wydaje mi się właśnie, że chmura jako taka pokazała i przeraziła ludzi do tego, żeby właśnie nie szli, żeby skupić na deweloperce. Usług chmury jest od groma i tam trzeba wiedzieć co robić i jak to robić. I chmura to posiadanie takiej opcji, że: “macie wszystko. Ale ja chcę tylko aplikację wyhostować. Macie wszystko.” Chmura jest zbyt szerokim workiem dla większości ludzi. Po prostu nie ogarną tego. Platforma wewnętrzna to powinien być generalnie zbiór praktyk. Okay, aplikacja tak, bazę tak. No nie? On tylko bierze pojedyncze elementy i cała reszta jest za niego ogarnięta. A chmura jest zbyt szerokim workiem możliwości konfiguracji itd. Wiadomo, że możemy je ograniczyć politykami itd. Wiele rzeczy tam możemy zrobić, ale dalej zbyt duży worek dla mnie. Z moich rzeczy, jak to wygląda.

Łukasz Kałużny: Tak. Raczej zgodzę się tylko zobacz, że tak - to od tej strony się zgodzę, że jest to za duży worek. I tutaj zaczyna się zabawa z architekturą, innymi rzeczami, żeby to… Opcje dokroić. O tak, dlatego mówię, że to jest stan wyjściowy. Z drugiej strony patrząc się kiedy te wewnętrzne platformy mają sens, czyli nie oszukując się musisz mieć jebitne IT i jebitny software house, wytwarzanie kodu in-house, żeby to miało gdzieś w ogóle ręce i nogi, bo team, który musisz - inaczej, jeżeli chcesz teraz skleić to z opensource’u, to jest…

Szymon Warda: Nie, nie, nie, nie…

Łukasz Kałużny: Inaczej, Szymon - to jest naście kompetencji

Szymon Warda: Tak.

Łukasz Kałużny: Weźmy sobie… Weźmiesz Kubernetesa backstage’a jakieś CICD. I wiesz, to się… Tutaj gdzieś metryki, grafana, ktoś zażyczy sobie Observability, to wiesz, co się będzie.

Szymon Warda: Znaczy, dla mnie - sensowna jedyna opcja - to jest takie generalnie, że budujemy platformy na jakimś providerze chmurowym. Sorry, budowanie go na onpremie to… To jest dla wielkich organizacji, co mówisz.

Łukasz Kałużny: Raczej tak, to jest dla organizacji, i wiesz… I patrząc się trochę na rys historyczny to ludzie powinni wrócić trochę do tego modelu usługowego IT, ze tak powiem. Jeżeli robimy coś wewnętrznie w onpremie, niż nazywać tego specjalnie platformą, kiedy mam wrażenie, że teraz to jest na siłę zrobienie albo portalu albo starterpacku w tym marketingu. Jak na koniec popatrzymy na zasadzie jest mówienie o takim Świętym Graalu, że tak powiem, tej całej infry, modelu DevOpsowego, że coś dostarczymy, niż o czymś, co jest realne dla większości.

Szymon Warda: Ja się z Tobą zgodzę. Budowanie platformy na onpremie… To jest naprawdę dla wielkich organizacji, mówię tutaj: banki. W sensie ten rozmiar organizacji to duże banki.

Łukasz Kałużny: Te, które same wytwarzają swój software.

Szymon Warda: Tak.

Łukasz Kałużny: To jest taki dodatek. Nie, bo zobacz, że sam Kubernetes to jest nawet… Jak weźmiesz jakiegoś gotowca, to jest rok czasu, żeby sobie go doszlifować minimum w organizacji. Jak weźmiesz CICD, jakbyś miał ustandaryzować CICD to wiesz, że to też jest gdzieś roczny, półtoraroczny proces. De facto. Budując taki kawałek jak mówimy o elementach i one niby mogą dziać się równolegle, ale - ja się śmieję: jakbyś nie liczył to wyjdą dwa lata, żeby zrobić coś dojrzałego przy naprawdę dużej kupie ludzi.

Szymon Warda: Dla mnie tooling jako programy to jeszcze jest w porządku, ale tam trzeba zmienić… Dwie dużo trudniejsze rzeczy do zmiany. Jak ludzie myślą i jakie są procesy w organizacji? I to są dopiero wyzwania. Jak to w ogóle pozmieniać tak naprawdę, bo w tym momencie też dotykamy security całego. Dotykamy alokacji, dotykamy budżetów, dotykamy ogromnej ilości rzeczy de facto.

Łukasz Kałużny: Wiesz, jak byśmy patrzyli, to w ogóle wiesz, mówisz o takiej zmianie? Ja rzucę w ogóle: jak pozbyć się starych? Jak stare workloady przenieść na nową platformę? Jak zrobić taki model, który jest jeszcze bardziej trudniejszy, bo platforma z góry zakłada, że nie ma trochę, że ona ma dostarczyć te 20% potrzebne dla 80% organizacji. Więc jeszcze trudniejsze. Tak jak mówisz o tych zmianach, innych rzeczach, to pomyśl sobie jak traktować te specjalności, które w infrze jednak gdzieś się dało wszystko zakręcić bez większego impaktu.

Szymon Warda: Ja powiem jeszcze więcej, bo Ty mówisz o przeniesieniu tych rzeczy. Zanim się przeniesie, to z reguły się pewne rzeczy wygasza, więc nagle odpalasz projekt - OK, musimy się przemigrować z systemu A na system B, bo nagle mamy system, który po prostu często nie da się skonteneryzować albo splatformować. Więc to jest dopiero trudny proces, bo nagle wam zaczniemy od groma procesów migracyjnych, wygaszeniowych, a niektóre po prostu się nie opłaca, bo ten system ubijemy i tak za rok, albo za 2 po prostu, bo kończy się jego wsparcie, bo jest na jakichś antycznych technologiach. Są takie sytuacje, więc platformizacja jest naprawdę wieloletni proces. De facto. Ja się z tym zgodzę jak najbardziej.

Łukasz Kałużny: Tak - i patrząc się… bo mówimy tak, więc dla większości z nas o tak powiedzmy, dla większości rynku te pojęcie platform engineering to jest tylko ładna łatka do marketingu, przyciągania i w ogóle nie ma to sensu. A organizacje, które potrzebują platform engineeringu, wbrew pozorom pewne rzeczy budują od lat już naturalnie.

Szymon Warda: Tak, no bo… to, co mówiliśmy de facto, to żeby automatyzować… Mamy tę samą potrzebę. Generalnie. Chcemy być bardziej zwinni, jeżeli chodzi o alokację zasobów, a jak będziemy zwinni i każdy będzie mógł sobie tworzyć wirtualkę, to nagle tworzymy, lądujemy w ogromnej ilości wirtualek… Upraszczam oczywiście… Jakichś tam kontenerów, wirtualek. O to samo chodzi. Czegoś, co może naszą aplikację hostować, które są niezautomatyzowane, nieustandaryzowane i nagle mamy po prostu bałagan. Więc chodzi o to, żeby być zwinnym, ale jednocześnie też ustandaryzować, żeby każdy nowy zespół uczył się tego samego nowego narzędzia do Observability, monitoringu itd. I zdjąć z deweloperów ten cały nakład. Więc potrzeba od bardzo wielu lat jest ta sama, tylko mamy inne pomysły jak to zrobić. Od DevOpsa się odbiliśmy, stwierdziliśmy, że to to nie wypali, bo ludzie tego po prostu nie chcą do końca. I teraz mamy kolejną falę migracji. Jak się za parę lat, 5 lat pojawi nowe podejście, wcale się nie zdziwię, bo okaże się, że w tym podejściu mamy jakąś dziurę. Po prostu albo adopcja jest trudna, albo budujemy to na onpremie, gdzie to jest mało realne.

Łukasz Kałużny: Czyli jakby to podsumować ten wątek platform engineeringu?

Szymon Warda: Ja powiem tak. Podsumowanie dla mnie jest takie, że tylko w cloudzie dla mnie. Większość organizacji, znacząca większość, budowanie platformy na onpremie jest szaleństwem.

Łukasz Kałużny: W zależności od skali… Inaczej, bo prawdopodobnie już to zacząłeś w jakiś sposób robić przed tym całym marketingowym hype’em.

Szymon Warda: Ale na pewno… Pewne rzeczy… Budowanie nawet - ja bym to zaliczył. Te budowanie wewnętrznych bibliotek do logowania np. z płytek standaryzujących pewne zachowanie w aplikacji. Dla mnie to też jest element platformizacji tego wszystkiego. Bo to jest takie generalnie, że oddzielamy tę część, powiedzmy jak coś, z czym się komunikujemy, czy na końcu wylatuje to z Plancka czy wylatuje do Application Insightsa, czy wylatuje do Grafany, Prometeusza, czy jeszcze z całych zasobów. To jest też element platformy, więc… Czy… Standaryzacja, jak logi wyglądają to też jest element platformizacji de facto. Więc na pewno robimy takie rzeczy od dawna, tylko trzeba do tego podchodzić po kolei tam, gdzie będzie to miało wartość - dla mnie przede wszystkim - i uważać na całą listę wpisów, które zaczynają być wokół marketingu i nie dać się zahajpować.

Łukasz Kałużny: No… wybiło go, wybiło go w ostatnich miesiącach.

Szymon Warda: Tak, ja już widzę jakieś takie serię wpisów, które po prostu nie maja większego sensu, a są bardzo mocno hajpowane i…

Łukasz Kałużny: Właśnie zrobiłem, mi na słowo - bo ja tak patrzę ile mam w pockecie, dodanych w ostatnich trzech miesiącach zaznaczyłem jakieś 180 artykułów że ma platform, bo se tak dodawałem patrząc się jak leci ten… Tyle się już tego naprodukowało po blogach, tweetach i innych tych. Więc masakra. Dobra to zrobiliśmy to, co u Ciebie Szymonie. Co wykopałeś?

Szymon Warda: Ja wykopałem… Lubię statystyki, lubię podsumowania. Z racji, że kończy się, kończy się trzeci kwartał, właściwie. Znaczy no, jesteśmy w połowie, czy kończy się właściwie bardziej, to pojawiły się…

Łukasz Kałużny: W zależności, czyli trzeci kwartał w zależności, w jakim kalendarzu.

Szymon Warda: Jezu… pierwszy kwartał. Tak.

Łukasz Kałużny: No i zastanawiałem się, jakim kalendarzem to liczysz.

Szymon Warda: Ale wyszły podsumowania finansowe, bo teraz organizacje sporo raportują i kilka liczb, bo mówiliśmy trochę o opcji, że no idzie kryzys, albo że firmy patrzą na to różnie. I tak. Wartości wzrostowe - Azure i serwisy powiązane wzrosły, Revenue wzrosło o 31%, przewidywane było 35, więc nieco poniżej przewidywań, ale dalej trzydzieści jeden procent wzrostu kwartalnego to jest dużo.

Łukasz Kałużny: Tak, to jest dużo.

Szymon Warda: To jest dużo i mówimy tu o dużych pieniądzach, więc mówimy tu o usłudze, która już jest naprawdę spora i naprawdę dużo kasy przynosi. I jeszcze dalej mamy wzrost - dużo, GCP 32% znowu różnicy kwartalnej, AWS 20% wzrostu w porównaniu generalnie do wzrostu w kwartale czwartym poprzedniego roku względem 28% w kwartale trzecim. Więc opcja, że się wynosimy z chmury na onprema, że Cloud is Dead i te inne… Nie do końca bym powiedział.

Łukasz Kałużny: Tak.

Szymon Warda: A tak to… Wiesz co, ja mam kilka takich trochę różnych… Kilka małych linków, to właśnie jest odnośnie wzrostu i jeden ciekawy link. Bo męczymy trochę temat, nawet rozmawialiśmy parę odcinków temu… Odnośnie Web Assembly użycia. I Containerd zaczął używać… Jeden z końcowych

Łukasz Kałużny: - wprowadził,

Szymon Warda: tak, wprowadził w ASI. Różnica - czemu? Szybciej. I bazowy obraz chyba dla pythona 6,8 mega.

Łukasz Kałużny: Tak, raczej tak jak popatrzymy w ASI. Czy jest to przyszłość?

Szymon Warda: Tak.

Łukasz Kałużny: Aktualnie wygląda, że tak, patrząc się na użycie… Bardzo proste - no i piękne jest potem w security. To jest dla mnie oprócz tej wagi, o której powiedzieć to te końcowe security jest piękne.

Szymon Warda: Uniwersalność i pozbycie się też bazowych części, bazowych obrazów. Bardzo dużo rzeczy tam ma sens. Naprawdę wydaje mi się, że to będzie miało sens głównie… Czemu to się przyjmie? Bo to ma ogromny sens dla cloud providerów. Że te obrazy będą mniejsze, narzut będzie mniejszy, dla nich wewnętrzne opłaty, będą mniejsze. I otwiera się akurat świat całego… podejrzewam, że w tym momencie mamy powrót do Serverlessów itd. bo te obrazy będzie można szybko stawiać. To będzie fajne nowe otwarcie.

Łukasz Kałużny: Tak - I de facto czy to Kubernetes, czy jakiś… Własna platforma serverlessowa cokolwiek to to zrobi. Ja patrzę ciągle też w kontekście, bo to wiesz, jedna waga to, druga patrzę troszeczkę na te security pod spodem, bo ten runtime da się coraz bardziej izolować procesowo.

Szymon Warda: Dokładnie, tak, właśnie.

Łukasz Kałużny: Da się go zamknąć nie w kontenerze, a w procesie. I to już zaczyna się robić ciekawie tutaj.

Szymon Warda: I tak, więc gubimy cały narzut i wszystko może chodzić po prostu lżej. A co pokazał CloudFlare dużo czasu temu - to ma sens, to jest tańsze po prostu. Więc dla mnie to jest przyszłość, zdecydowanie już.

Łukasz Kałużny: Oni już trochę na tym Vite, które robią w tym… Właśnie z JavaScript’em. To jest niesamowita rzecz tam pod spodem.

Szymon Warda: Tak - i tania, widać po cenniku.

Łukasz Kałużny: Jeszcze dodamy armę i to w ogóle się robi tanio… Dla cloud, nie dla nas.

Szymon Warda: I co więcej, będziemy odchodzili, będziemy… Otwiera się do tego, żeby przynosić coraz więcej na edge’a, tak naprawdę, do dużo, dużo mniejszych datacenter. Po prostu te obrazy mniejsze wymagają mniej hardware’u. Dobrze. Idąc kolejnym linkiem może komuś się przyda. OCV scanner od Google’a. Google wypuścił, zopensource’ował skaner, który korzysta z opensource’owej bazy do płatności. Jest, będzie w linkach najbardziej. I ostatni temat do dyskusji, ale już przedyskutowaliśmy, jakie mamy o tym zdanie… Infrastructure from Code. Czyli cały ruch… w kierunku temu, czyli próba… Bo jest kilka trendów, jest Infrastructure as Data. To jest jeden z tych ruchów. Czyli taki jeszcze bardziej deklaratywny, deklaratywność++, a teraz mamy bardziej imperatywny. Trochę, bo w tym momencie trend, który trochę się kroi, zaczyna tworzyć swoją strukturę. Jak to miałoby wyglądać. Czyli używanie języków programowania do tworzenia infrastruktury.

Łukasz Kałużny: Właśnie powiedz mi, z czego to wynika? Bo większość tooli Infrastructure as Code można też nazwać Infrastructure as Data.

Szymon Warda: Można z tego zbudować tak, można tak… Inaczej, można na toolingu, które on oferuje. To fajnie pokazuje repo do landing zony Azure’owych na terraformie, które pokazuje właśnie jak to… że po prostu dajemy dane i to się ładnie rozchodzi.

Łukasz Kałużny: Ale wiesz, mówię, jeżeli weźmiemy tam… Nie robiąc zaawansowanych rzeczy, o tak, zaawansowanych rzeczy, to Ty mówisz, że zrób mi teraz - bardzo upraszczając - zrób mi ten bucket S3 czy konto storage’owe w Azure w sposób XYZ. Parametryzujesz to.

Szymon Warda: Tak - a w naszych template’ach mamy, potem mamy pętlę for w każdym miejscu, żeby ogarnąć jak to będzie wyglądało. Dokładnie tak.

Łukasz Kałużny: Moim zdaniem powstało to, że dużo osób po prostu boli, że jest ta nazwa Infrastructure as a Code, a tam nie ma języka programowania żadnego na wierzchu.

Szymon Warda: Dla mnie bardziej to też jest to, że faktycznie taki goły Infrastructure as a Code. Np. taki goły basicowy Terraform… Faktycznie on dużo rzeczy umożliwia. A jak zrobimy Infrastructure as Data? W teorii ten pomysł, mówię pomysł tak naprawdę, że tylko pewne parametry - to standaryzujemy jak te rzeczy będą tworzone de facto. Więc to jest fajne. To samo w sumie można by z modułami zrobić de facto. No więc tak. Dyskusyjnie. Infrastrucure from Code, że… Ruch jest kilka, właśnie, żeby wyciągać de facto z kodu jakie są usługi używane i żeby korzystać z bardziej imperatywnego. Czyli co, jak, gdzie robimy… języków kodowania, jakie elementy infrastrukturowe będą wykorzystywane. I dla mnie to jest pomysł głupi, bo z tego co mówiliśmy wcześniej odnośnie platform. Developerzy… Nie wszyscy, ale jest grupa developerów, która nie chce takimi rzeczami się zajmować i wyciąganie tego z kodu - sorry, to po prostu nie zadziała. Nie widzę przyszłości dla tego. Nie wiem, jakie jest Twoje zdanie w tym momencie, bo tak…

Łukasz Kałużny: Raczej wiesz co, dobra, ja mam problem taki, że łatwiej sobie rękę odstrzelić pisząc taki kod niż deklarując to wszystko w takich toolchainach aktualnych narzędzi, że…

Szymon Warda: Deklaratywność jest łatwiejsza do rozumienia. Tam mniej można się pomylić, po prostu.

Łukasz Kałużny: Znaczy wiesz co, kod - inaczej… To teraz popatrzmy sobie, trochę nawiązując do początku naszego odcinka. No właśnie, czy to jest osoba z barykady bardziej? Odrzućmy teraz te klasyczne, że mamy inżyniera, który rozumie kod i pracuje albo na infrze albo na kodzie. Czyli jest to osoba bardziej z gałęzi kodujemy czy bardziej z gałęzi infra-adminka? Jak sobie patrzysz, to zazwyczaj i tak na koniec dnia utrzymują to osoby bardziej z tej strony administracyjnej.

Szymon Warda: Tak.

Łukasz Kałużny: Nazwijmy to: infrastrukturalnej - niż developerzy. I założę się, że jeżeli zobaczy potem kod, który dostanie interpretacji Clean Architecture do tworzenia infry… to się przekręci.

Szymon Warda: Dla mnie to kolejna rzecz z serii pullme, czyli wykorzystujmy język…

Łukasz Kałużny: W którym kodujemy…

Szymon Warda: Kodujemy, tak, do wszystkiego. To gdzieniegdzie ma sens, ale tu wracamy do tego, że może wszystko w bashu napiszmy. Tak naprawdę to jest ten sam poziom utrzymania. To jest strasznie trudne do utrzymania dla rzeczy, rzeczy, które są większe niż sample i przykłady. Tych obiektów dla infrastruktury będzie po prostu za dużo i pogubimy się co, gdzie i jak się to tworzy. Dlatego właśnie np. Terraform wypłynął z tym, że ooo, możemy sami tworzyć dependency. I co w jakiej kolejności tworzymy, właśnie z tego powodu, że jak mamy 40, 50, 200, 300 obiektów do stworzenia. Ciężko jest ogarnąć co w jakiej kolejności ma być. Więc nie widzę wartości naprawdę, dla mnie to jest trochę cofanie się i próba… Jeden język do wszystkiego.

Łukasz Kałużny: Znaczy, wiesz co…

Szymon Warda: Dlatego mamy SQL’a do baz relacyjnych, bo tam się ten język sprawdza.

Łukasz Kałużny: I powiedzieliśmy, żeby tam nie pisać logiki biznesowej poza widokami.

Szymon Warda: Dokładnie, bo ify w SQL’u się nie sprawdzają

Łukasz Kałużny: Więc, nie. Jeżeli popatrzymy tak… Inaczej - w pojedynczych zespołach to się sprawdza. Są zespoły, które dopóki są w takim, a nie innym stadium; zestawie kompetencji, to to działa. Gorzej jak osoba, która głównie to ogarniała, odchodzi.

Szymon Warda: Dokładnie, to chciałem powiedzieć. Ludzie się rotują i pisanie systemu, i wybieranie technologii tylko po to, żeby ona po prostu była. Bo ooo, my znamy i takie… Standaryzacja… No to nie ma większego sensu. Ci ludzie za chwilę odejdą, zmienią się trendy, nahajpujemy coś innego i potem będziemy mieli jeden system, którzy korzysta z jakichś innych technologii, które pewnie już umrą za parę lat i potem będzie: hmm… co z tym zrobić. To nie ma sensu.

Łukasz Kałużny: Tak, nie, nie, nie. Jedna rzecz, którą mnie przeraziłeś… Bo ja na to nigdy tak nie patrzyłem, ale graf zależności we własnym kodzie utrzymać to jest kurde…

Szymon Warda: No właśnie.

Łukasz Kałużny: Bo często masz… Żeby stworzyć tą usługę, potrzebujesz X, Y, Z, bo… Tak, to akurat Terraform tutaj wygrywa pod tym względem, ale tak… To jest… I nagle wychodzi, że masz as Code. Ale imperatywnie musisz pisać, ale nakładziesz na to solida, bo ci pull requesta nie przejdzie i nie przeskanuje się w którejś statycznej analizie prawidłowo. Dobre!

Szymon Warda: Dla sampli to zadziała. Jak stworzysz sobie jakieś tam… bucketa, storage account appservice itd. Ale cokolwiek, co będzie większe… Nie ma szans żeby to zadziałało.

Łukasz Kałużny: To jest fajna rzecz jak ktoś, ale na koniec dnia i tak skorzysta z natywnych bibliotek - jak próbuje tworzyć operatory na Kubernetesa i inne rzeczy, żeby automatyzować resztę clouda. To jest fajny wzorzec. Ale on jest bardzo specyficzny, bardzo, bardzo specyficzne.

Szymon Warda: Większość osób, firm, organizacji nie będzie i nie powinno pisać własnych operatorów tak naprawdę.

Łukasz Kałużny: No, dokładnie, dokładnie to jest kolejna rzecz. Dobra, to co, kończymy?

Szymon Warda: Kończymy. Trzymajcie się.

Łukasz Kałużny: Na razie!

Szymon Warda: Hej!