“Dla większości jest tak przekombinowany, że szkoda Waszego życia, żeby go sprawdzać.” Łukasz otwiera odcinek o Crossplane najbrutalniej jak się da - bo pod odcinkiem o chmurze w małej skali fani Kubernetesa zasugerowali “prawidłową automatyzację”. Szymon doprecyzowuje: “To ma dla mnie sens jak masz 100+ developerów.” Koszt? “Największym problemem jest to, że koszt ludzki utrzymania, zdobycia i zapewnienia kompetencji jest masakryczny.” 🎯
Platform engineering jako buzzword? Szymon: “Platforma to sposób na ujednolicenie, ale trzeba mieć co ujednolicać.” Łukasz dodaje: “Wyrzucimy pieniądze w błoto, spróbujemy zmusić ludzi do korzystania i nie będzie żadnych benefitów.”
Plot twist? Terraform przeżyje. Szymon: “Pamiętam znajomego, hate’ował Terraforma. Jak on się nazywał? Łukasz jakiś.” Dziś Łukasz przyznaje: “Nie wygram z rynkiem.” Ekosystem, kompetencje, AI - “good enough” wygrywa. A OpenTofu? “Żyje i ma się dobrze.”
Kiedy Crossplane ma sens? Spotify-level skala, firma produktowa SaaS, 100+ deweloperów, ograniczony stos. Łukasz szczerze: “Dla fanu inżynierskiego chętnie zbudowałbym platformę na Crossplane.” Ale uwaga - to jest “fajna zabawa dla osoby, która to buduje”, a potem ktoś to musi utrzymywać. Prawdopodobieństwo utopienia budżetu? 🔥 Ogromne.
Czy Twoja organizacja ma skalę na Crossplane, czy tylko buzzword na platform engineering? Zanim rzucisz się w budowę platformy - posłuchaj, bo możesz zaoszczędzić sobie spalonej kasy i zmarnowanych miesięcy 💸
Linki i ciekawe znaleziska
Transkrypcja
Łukasz Kałużny: Nie jest do wszystkiego i dla każdego. Dla większości jest tak przekombinowane, że szkoda Waszego życia, żeby go sprawdzać. Wszystkie projekty, które widzę, zawsze kończą się porażką, ubiciem albo porzuceniem przez wszystkich, bo nie będą z tego korzystać.
Szymon Warda: To ma dla mnie sens jak masz 100+ developerów.
Łukasz Kałużny: Problemem Szymon, tutaj taką największą rzeczą jest to, że większość organizacji koszt ludzki utrzymania, zdobycia, zapewnienia kompetencyjny jest masakryczny.
Szymon Warda: To jest gorsze experience dla osób, które to muszą utrzymywać. I tu jest mój największy problem z tym wszystkim. Większość problemów można rozwiązać na dwa sposoby: technicznie, to jest przykład rozwiązania technicznego i miękko, czyli po prostu tak zwana forma zamordyzmu, czyli mówimy, że tak ma być i koniec. Cześć, czołem, kluski z rosołem. Słuchacie Patoarchitektów, prowadzą Szymon Warda i roześmiany…
Łukasz Kałużny: Łukasz Kałużny. Dobra, te kluski to sobie można darować. Ale lecimy. Wszystkie linki do tego odcinka na dole. 16 czerwca konferencja, linki do zapisu znajdziecie, może niedługo dojdzie landing page już wreszcie taki właściwy. Już pierwszy zarys agendy też już się pojawia, więc zobaczycie + szkolenia.
Szymon Warda: I nasza prośba do Was jest taka, żeby nie odkładać zakupu na ostatnią chwilę, bo nasz kochany Mikołaj właśnie nam się poskarżył, że zbyt dużo telefonów od Was odbiera jakie szkolenie zamyka, bo się wypełniło. Tak że oszczędźcie chłopaka. Zapraszamy, zobaczcie.
Łukasz Kałużny: Dobra, to dzisiaj triggerem odcinka jest AI Native Platform Engineering Polska. I przejdziemy sobie, nie wiem czy Piotrek to Ciebie pozdrawiam, kto się kryje za tym kontem, ale widzimy fanatyka Kubernetesa, o tak. I komentarz pod odcinkiem o Chmura w małej skali. I słuchajcie, i żebyśmy mogli się merytorycznie odnieść i żebyście wiedzieli do czego się odnosimy, to zaczniemy sobie od takiego cuda, które się nazywa Crossplane.
Szymon Warda: Czyli kolejny pomysł na to, jak zarządzać wszystkim z poziomu jednej tylko rzeczy. Przypomnę, że wcześniej były, mieliśmy rzeczy typu na przykład Postgres, a tym razem będzie to Kubernetes. I ogólnie idea, ja bym chciał zaznaczyć na samym starcie, nie będziemy krytykować Crossplane jako takiego, bo w pewnych zastosowaniach on naprawdę bardzo ma sens.
Łukasz Kałużny: Raczej jest…
Szymon Warda: I ma swoje plusy i minusy.
Łukasz Kałużny: Inaczej, i teraz sobie powiedzmy wprost, Crossplane, żebyście wiedzieli, nie rzucajcie się do niego. Jest jak z każdym operatorem, nie jest do wszystkiego i dla każdego. Dla większości jest tak przekombinowany, że szkoda Waszego życia, żeby go sprawdzać.
Szymon Warda: Ale powiemy sobie na koniec o Crossplanie, kiedy naszym zdaniem stosować go, kiedy nie stosować i tyle. Na razie okej.
Łukasz Kałużny: Dobra.
Szymon Warda: Zacznijmy w ogóle czym jest i jak to działa.
Łukasz Kałużny: Czyli Crossplane, chodzi o to, że jesteśmy w stanie powoływać całe aplikacje, custom aplikacje, custom obiekty, własną infrastrukturę cloudową, zautomatyzować wrzucając definicje na Kubernetesa. Czyli tak jak rozszerzamy Kubernetesa, żeby stał się naszym control planem do zarządzania deploymentu aplikacji i infrastruktury.
Szymon Warda: Czyli korzystamy z CRD-ków, deklarujemy to, co będzie u nas na infrze się działo na naszym Azure albo dowolny inny operator.
Łukasz Kałużny: AWS-ie, whatever, tak, co zautomatyzujemy. I teraz bardzo ważne, był jego duży release v2, który bardzo go posprzątał. To też jest istotna rzecz. Jest w CNCF-ie, jest wysprzątany. Pod spodem, jako, że to jest operator i CRD to mamy ten cały reconciliation loop, czyli on w kółko działa i sprawdza czy wszystko ze wszystkim się zgadza, co jest jego niewątpliwie bardzo dużą zaletą, dążenie ciągle do tego docelowego stanu konfiguracji.
Szymon Warda: Czyli tak, to jest zaleta Łukasz, ale też w drugiej sytuacji on też pilnuje pewnych rzeczy, jak coś zmienisz na chwilę, żeby zadziałać i potrzebujesz procesów ręcznie wprowadzić podczas awarii, to on ci to też zaora.
Łukasz Kałużny: Tak, więc właśnie.
Szymon Warda: To jest plus. W ogóle, żeby nie było, to jest bez dwóch zdań, to jest ogromny plus, że pilnujemy, że nie mamy tej różnicy między tym, co chcieliśmy, a tym, co mamy. To jest super. Jednak są pewne minusy, kiedy może nas ugryźć w miejsce, w które nie chcielibyśmy, żeby nas gryzło.
Łukasz Kałużny: Dobra, i teraz tak, lecimy. Tam takie były rzeczy, że jest posprzątane, czyli że obiekty wrzucamy do namespace’ów. I pojawia się pierwszy zgrzyt, który jest. Bo słuchaj, zamiast walczyć poprzez API, poprzez CRD i Yaml’e możemy też używać composition w postaci Golanga czy Pythona i kolejne kawałki operatora deployować sobie, teraz ja to upraszczam, ale żebyście wiedzieli. Mamy niby operatora, ale też część rzeczy hostujemy znowu na Kubernetesie w kontenerach, żeby to budować.
Szymon Warda: Musi być ten operator, to jest jednak coś, co działa w Kubernetesie. Jest jakiś bot, coś musi zrobić, ten kod będzie działał, oczywiste.
Łukasz Kałużny: Czyli jak wam wytłumaczyć? Budujecie sobie custom definicje waszej infrastruktury, usług i innych rzeczy i on pomaga wam przerobić CRD-ka na to, co Wy chcecie.
Szymon Warda: Przerabiać z CRD-ka na jakiegoś IaC-a, mówiąc bardzo prosto, albo (…).
Łukasz Kałużny: Poprzez API, czyli tak jak Terraform, odnosząc się, tutaj, tak jak macie w Terraformie HCL-a, to on, Terraform nie działa w kółko, a to będzie działało w kółko i poprzez API cloudowe będzie próbowało cały czas coś kręcić i tworzyć te zasoby i zmieniać konfigurację. Czyli na przykład co 5 minut sprawdzi konfigurację, jak się nie zgadza, to ją podmieni.
Szymon Warda: Dokładnie, czyli jest to pewna warstwa abstrakcji, która umożliwia nam, żebyśmy mieli jeden język, jeden Yaml Kubernetesowy do zarządzania wszystkim aplikacjami, Kubernetesem, chmurą i tak dalej. Więc oczywiście nam się rodzi problem podstawowy, który jest, mianowicie, że będzie lag między tym, co możemy z CRD-ka zrobić, a tym, co możemy w chmurze zrobić.
Łukasz Kałużny: Tak, ale to jest… Inaczej, to zostawmy, to nie jest jakaś wada. Słuchaj, jak odświeżysz czasami wiesz ile się potrafi stan w Terraformie odświeżać, więc zostawmy. I teraz, jeżeli popatrzymy, tam w v2, ja tutaj zrzuciłem do notatki pełno feature’ów, ale nie ma sensu w sumie o nich patrzeć co robi, bo chodzi, tutaj najważniejsza jest, że pozwala Wam robić własną automatyzację i budować rzeczy istniejące i w teorii zarządzać multicloudem.
Szymon Warda: Dobra, dobra, dobra.
Łukasz Kałużny: Dobra, no właśnie. Potem z tej samej perspektywy mamy jeszcze jedną taką rodzinę rozwiązań, które też tam padły w tym komentarzu, który się odniesiemy, jest mowa między innymi Azure Service Operator. Czyli wrzucamy Yamlę albo tworzymy CRD-ki przez API, czyli sorry, to jest to samo z tej perspektywy i to nam tworzy potem zasoby cloudowe. Czyli chcemy stworzyć resource grupę, to tworzymy Yamla, który tworzy nam service grupę i on jest tworzony, tak. I słuchajcie, i to jest po prostu kolejna abstrakcja. Tak, mieliśmy operatora. I tak jak ja nie hejtuję na przykład Postgresów, innych rzeczy, uważam, że…
Szymon Warda: Które są świetne.
Łukasz Kałużny: Tak.
Szymon Warda: Uważam, że to jest ważne.
Łukasz Kałużny: Tak, że te operatory na przykład, żeby wykorzystać Kubernetesa jako Compute Platform, to tutaj o tu tak, serduszko do tego. Tylko, że teraz patrzenie sobie, jest to taką dużą zaletą, jak popatrzymy, że to jest GitOps Native, można zacząć budować self service platform na tym wielu. W teorii na papierze jedno API do wiele chmur. Przepraszam, ale to jest jedna wielka… Wszystkie projekty, które widzę zawsze kończą się porażką, ubiciem albo porzuceniem przez wszystkich, bo nie będą z tego korzystać.
Szymon Warda: Sekundę, pamiętajmy, że był taki język, który miał być jednym językiem dla wszystkich chmur i się nazywa Terraform. I o dziwo nie możesz wziąć tego samego Terraforma i zaaplikować raz na AWS-ie, raz na Azure, raz na GCP. Więc tutaj marzenia oczywiście się nie spełniają.
Łukasz Kałużny: Raczej wróć, VM-kę możesz. Możesz zrobić uniwersalny moduł do VM-ek i zadziała i na tym koniec.
Szymon Warda: To faktycznie jest główny element budulcowy AWS-a. Trochę żartuję, ale za bardzo.
Łukasz Kałużny: Więc dobra. I teraz tak, wady jak popatrzymy. Największe wady to jest, jeżeli popatrzymy, adopcja tego w organizacji i w ogóle zbudowanie zespołu, który będzie umiał to utrzymać, to jest masakra. Zespół będzie…
Szymon Warda: Nie, nie Łukasz, to nie jest masakra. Zależy od skali. Jak masz bardzo unormowane to, co budujesz i to jest tylko do części aplikacyjnej na przykład, nie do raportowej i tak dalej, nie dla ML-owej i tak dalej, zawężasz i masz duży zespół, to to może mieć sens.
Łukasz Kałużny: Dobra, tylko duży. Mówisz teraz o dziesiątkach, setkach serwisów, aplikacji i potężnej ilości teamów. I teraz zobacz…
Szymon Warda: To ma dla mnie sens jak masz 100+ developerów.
Łukasz Kałużny: Dobra, raczej powiem tak, uważam, że jeżeli będziesz Spotify’em, to ma sens.
Szymon Warda: Tak, dokładnie. Ale to też ważne, też w wydzielonym dziale aplikacyjnym i tak dalej, bo będą działy, które będą korzystały ze wszystkiego. I obudowywanie właśnie w operatory całego Azure’a nie ma sensu po prostu żadnego.
Łukasz Kałużny: Tak, przypomina mi się ten fuck up Spotify’a, bo używali przecież Terraforma jak klastry, wtedy GKE położyli…
Szymon Warda: Dokładnie.
Łukasz Kałużny: W tym. Więc inaczej, dla mnie problemem Szymon tutaj, taką największą rzeczą jest to, że większość organizacji koszt ludzki utrzymania, zdobycia, zapewnienia kompetencyjny jest masakryczny.
Szymon Warda: Tam jeszcze jest drugi, to będzie custom framework mimo wszystko. To będzie coś, co (…) firmowe i tak dalej.
Łukasz Kałużny: Więc Crossplane jest ok, jeżeli chcemy budować własną platformę. Bo teraz trzeba sobie powiedzieć, nienawidzę osób wpychających, tutaj pozdrowienia dla Krzysztofa, który przepraszam, ale moim zdaniem pisze bullshit na LinkedInie na temat platform engineeringu, ile to Ci platforma da zwrotu. W większości przypadków jakiego zwrotu, jeżeli Ty nie masz standardów, wcześniej ich nie robiłeś. Platforma stanie się tym samym syfem… Inaczej, wyrzucimy pieniądze w błoto, spróbujemy zmusić ludzi do z niej korzystania i nie będzie żadnych benefitów z tego, bo większość przepalimy, a ludzie będą…
Szymon Warda: Nie, będą.
Łukasz Kałużny: To przez platformę…
Szymon Warda: Potrzebujesz dodatkową osobę zatrudnić, to jak najbardziej.
Łukasz Kałużny: Tak i będzie tekst, że nie wdrożyliśmy tego, bo platforma nie daje tego feature’u albo nie możemy z niego korzystać.
Szymon Warda: Mówiąc bardzo poważnie, tak, platforma to jest sposób na ujednolicenie, ale trzeba mieć co ujednolicać.
Łukasz Kałużny: Ja pozdrawiam Kingę i ten odcinek u nich o mierzeniu C4 w Pracuj.pl. Tam mieli platformę, ale nie było w ogóle słowa platform engineering na rynku. I tak można byłoby wymieniać firmy…
Szymon Warda: Łukasz, my też mieliśmy platformę wcześniej i tak dalej bez słowa platform engineering.
Łukasz Kałużny: Tak, więc tam, gdzie to wyrosło naturalnie, to się sprawdza. I teraz popatrzymy te sweet spoty, te duże organizacje, które faktycznie tego potrzebują. I też jest jedna rzecz, to jest też cały model kulturowo-operacyjny wokół tego, jak aplikacja jest utrzymywana potem. Bo bardzo często tam, gdzie widzieliśmy, gdzie to się sprawdza, zespół developerski jest odpowiedzialny za aplikację od A do Z najczęściej.
Szymon Warda: Tak i mają bardzo unormowany stos.
Łukasz Kałużny: Ewentualnie nie ma on calla, bo jest jakoś częściowo delegowany, o tak, częściowo delegowany, to jest jedyna rzecz.
Szymon Warda: Albo jeszcze inna opcja, te aplikacje nie są po prostu używane poza godzinami pracy. Typowa większość aplikacji korporacyjnych nie chodzą 24h.
Łukasz Kałużny: Dobra i też pada tam, jest taki, bo trafiliśmy pod którymiś odcinkami na tekst: Terraform to syf, jest martwy i w ogóle. I wiesz co powiem o Terraformie? To samo, ludzie nie chcieliby mieć tak samo Kubernetesa jak Terraforma, tak jak porozmawiasz z klientami.
Szymon Warda: Pamiętam jak miałem takiego znajomego, w ogóle kumaty koleś, hate’ował Terraforma. Jak on się nazywał? Czekaj… Łukasz jakiś, Łukasz.
Łukasz Kałużny: Nie wygram z rynkiem… Słuchaj inaczej, czy na przykład wolałem ARM-a czy tam Bicepa dla Azura? Tak, miał dużo różnych zalet, ale był w obrębie jednej… Inaczej, technologicznie za dużo trzeba było hackować, jak trzeba było zaczynać łączyć, to jest jedno. Druga, sorry, rynek to przyjął i nie ma co z tym walczyć.
Szymon Warda: Nabijam się z tego.
Łukasz Kałużny: Tak.
Szymon Warda: Zgadzam się, że Terraform ma swoje plusy.
Łukasz Kałużny: Ma… Kurde, inaczej, ma też masę wad. Nadal urywa ręce, jak nie potrafisz go używać, to tak nazwijmy. To się nie zmieniło.
Szymon Warda: Inna opcja…
Łukasz Kałużny: AI pomaga.
Szymon Warda: Jak używasz go w zbyt dużej skali.
Łukasz Kałużny: Tak, więc tutaj… On jest, dla większości firm jest good enough. Jego zaletą jest faktycznie, że składnia i filozofia jest taka sama na trzech głównych chmurach i na Kubernetesie. Filozofia Szymon, używam słowa filozofia. Nie używam słowa tutaj, że on jest…
Szymon Warda: Przenośność, bo nie jest przenośny.
Łukasz Kałużny: Multicloud. Nie, nie, nie, nie, nie, nie, nie, to jest… Nie, dobra, za to ktoś się znowu obrazi w komentarzach, jak powiem. Więc zapraszam na Discorda, odpowiem, bo jest stary tekst na temat Javy i pewnego rodzaju stosunku, więc Ty już kojarzysz.
Szymon Warda: Łukasz, lecimy dalej, lecimy dalej.
Łukasz Kałużny: Dobra, to Terraform jest good enough. Ekosystem providerów, od dostawców jest potężny w tym miejscu. Weźmy na przykład klienta, któremu automatyzowaliśmy on premove checkpointy tym.
Szymon Warda: Zgodzę się, że plus Terraforma jest to, że on wychodzi poza chmurę.
Łukasz Kałużny: Tak. I jesteś w stanie połączyć ileś takich elementów ze sobą.
Szymon Warda: Zgadza się.
Łukasz Kałużny: Druga rzecz, realnie, jeżeli chodzi o kompetencje, po prostu bierzesz z półki, że tak powiem.
Szymon Warda: Zgadza się. I AI-e też sobie ładnie z nim radzą, bo po prostu jest dużo tego kodu.
Łukasz Kałużny: Dobra, to jest to, tak, ma tam swoją łopatologiczność, są kompetencje dostępne. Jest ten tekst, że jeżeli technologia jest X lat na rynku, to będzie drugie X lat żyła.
Szymon Warda: Zgadzałoby się.
Łukasz Kałużny: Tak, więc śmierć jest przedwczesna. OpenTofu żyje, ma się dobrze, mimo że…
Szymon Warda: Nawet nie śledziłem co tam się dzieje, ale tak, jest rozwijany.
Łukasz Kałużny: Stabilnie się rozwija… Ty, powiem Ci tak, w niektórych miejscach aż zazdroszczę feature’ów i mnie korci już w jednym miejscu, żeby wreszcie przetestować i się przepiąć na OpenTofu.
Szymon Warda: To jest rok niesamowitych rzeczy i zmian.
Łukasz Kałużny: Nie, w sensie zupełnie pragmatycznie. Odpada jeden hack po prostu, jeżeli chodzi o dynamiczne providery. Czyli na przykład powołaj subskrypcję Azurową i załaduj do niego dynamicznie provider w tym kodzie, który istnieje, więc…
Szymon Warda: Wiem, to bardzo boli.
Łukasz Kałużny: Tak, więc to akurat jest w tym. I teraz tak, jeżeli popatrzymy sobie… Inaczej, uważam, że jeżeli nie miałeś problemu, że platforma wybudowała się u Ciebie naturalnie, to w używaniu Terraforma i zapomnieniu… Inaczej, zróbmy w organizacjach to, że self servicem jest to, że jesteś w stanie dostać resource grupę z siecią, albo subskrypcję z uprawnieniami sprawnie i że masz blueprinty, jak to ma być bezpiecznie zrobione, albo polityki Cię chronią czy moduły, dostajesz moduły terraformowe, które Cię nie ograniczają, a dają zgodnie z wytycznymi.
Szymon Warda: Zgadzamy się z tym, że tak naprawdę wszystkie elementy platformowe wykładają się na tym, że właśnie dostępy są najdłuższym elementem. Co z tego, że masz wszystko, ładnego backstage’a, skoro czekasz na ticketa w Girze, który Ci założy rzeczy.
Łukasz Kałużny: Raczej nie, jak masz backstage’a, to zostawmy to, bo to jest zawsze znowu co i jak potrzeba z tym self servicem. I tak, na przykład kurde, chętnie dla czystego fanu inżynierskiego zbudowałbym sobie platformę na Crossplanie, zbudowałbym sobie platformę na Azure Service Operator. Szymon, nawet nie wiesz jakbym siadł i się tym pobawił. Ty zresztą też lubiłeś takie rzeźbienie, wiesz o tym.
Szymon Warda: Znaczy to jest fajne…
Szymon Warda: Inżyniersko to jest…
Łukasz Kałużny: To jest bardzo fajna zabawa dla osoby, która to robi. To jest gorsze experience dla osób, które to muszą utrzymywać. I tu jest mój największy problem z tym wszystkim.
Łukasz Kałużny: Wiesz, to jest tak jak budowa, jak budowaliśmy platformę Kubernetesową w banku. Sorry, dostarczamy tylko Kubernetesa jako usługę i wyjdźcie z tych pomysłów innych usług on top of, bo jest za mało zasobów, czasu, skupienia się i w dużej skali nawet utrzymania takiego Kubernetesa jako usługi było i jest dla, pozdrawiam Mariusza, nie jest łatwą rzeczą.
Szymon Warda: Ja trochę uszczegółowię to, o czym mówisz. Poza operatorami, które są w Kubernetesie, to były właśnie Postgresy i inne rzeczy. Tam to się sprawdza.
Łukasz Kałużny: Tak i teraz przejdźmy sobie, teraz pierwsza rzecz, która była, przy prawidłowej automatyzacji nie ma znaczenia, czy mamy 2 konta czy 120. Oczywiście Terraform do tego się nie nada, trzeba użyć ASO i CRO.
Szymon Warda: Dobrze, to Łukasz zacznij swojego ranta. Ja tu dorzucę jedną rzecz na start. Zrobienie wszystkiego zajmuje jakiś czas. Wszystko można zrobić. Dla mnie, na przykład po czym ja poznaję dobrego Senior Engineera, seniora, może nazwijmy to tak, to jest osoba, która zaczyna myśleć: ok, wszystko mogę, ale co przyniesie największy zysk? Co jest sens zrobić? Co się zwróci w tym wszystkim?
Łukasz Kałużny: Dzisiaj rano byłem na kawie, niestety, trzeba popatrzeć na to cynicznie, do diabła, ile na to wydam? Kto z tego tak naprawdę skorzysta? I kto to, do diabła, będzie potem rozwijał?
Szymon Warda: Tak. I w ogóle kiedy to się zwróci? Kiedy to w ogóle zakończę? Nie sztuką jest zakopać się z jakimś projektem na pół roku, bo to zostanie ubite, to się nie przyjmie po prostu.
Łukasz Kałużny: Wiesz i teraz tak, i tutaj idę 2, 320 kont, tak, jest różnica. Bo jeżeli masz 120 kont, 120 aktywnych userów, to zupełnie inaczej wygląda takie coś niż 2 konta w małej skali.
Szymon Warda: Ja zawsze podkreślam jedną rzecz, większość problemów można rozwiązać na dwa sposoby. Technicznie, to jest przykład rozwiązania technicznego i miękko, czyli po prostu tak zwana forma zamordyzmu, czyli mówimy, że tak ma być i koniec. Jeżeli masz zespół 5-osobowy, to szybciej się dogadacie odnośnie waszych standardów, jak to zrobić, niż odpalicie cały wielki projekt techniczny, który będzie tego pilnował. Wszystkie rozwiązania, wszystkie rzeczy trzeba skalować razem z organizacją. I zamordyzm też w pewnych sytuacjach jest dobrym rozwiązaniem. Google ma zamordyzm w pewnym stopniu.
Łukasz Kałużny: Mało powiedziane, jak nie spełnisz wymagań, to kurde nawet oncalli od Ciebie nie przejmą, więc zostawmy to, wiesz.
Szymon Warda: I masz 3 miesiące na migrację na nowe API. Nie utrzymujemy jakichś API sprzed dwóch lat.
Łukasz Kałużny: Ale są automatyzacje i inne rzeczy, to też to. Dobra, następne było, że liczba kont i compliance. Słuchajcie, guys, jeżeli kurde wpadam w SOC-a, ISO, HIPAA, to niestety tanio już było. Inaczej, tanio, inaczej, wróć Szymon, ona może być liczbowo, może być przychodowo, ale sorry wymogi już masz, dorosłą skalę, to nazwijmy, wymogów compliance’owych i tu oszczędność… Inaczej, jeżeli mamy SOC-a, ISO wyrzućmy do śmieci, bo… Inaczej, wiesz jak się ISO robi, przestańmy teraz udawać, ISO nic nie znaczy.
Szymon Warda: Nie.
Łukasz Kałużny: W zależności…
Szymon Warda: ISO może być okazją do uporządkowania firmy, może być okazją tylko do zrobienia papierka nic nie zmieniając.
Łukasz Kałużny: Raczej wróć, wiesz o tym, że to Ty tworzysz procesy, które certyfikujesz. Jesteś w stanie zcertyfikować kupę w ISO, wiesz o tym.
Szymon Warda: ISO jest dowodem na to, że na wszystko masz papier po prostu i tyle.
Łukasz Kałużny: Tak, tak, SOC, HIPAA, ok. I to jest tak, jak mamy SOC-a, HIPAA, PCI, DSS-a, potrafi przyjść audytor, który wie o co pyta, przyjść audytor techniczny i zwykłe zielone kontrolki nam nie przejdą.
Szymon Warda: Dobrze, dalej lecimy.
Łukasz Kałużny: No dobra, tutaj z kontami, nic o tym nie mówiliśmy, ale znowu, jeżeli odnosimy się do SOC-a i do ISO, znowu powiedzieliśmy wprost, jak robimy chmurę w małej skali i chcemy tanio, to ona nie przejdzie audytu.
Szymon Warda: Odsyłamy do poprzednich odcinków.
Łukasz Kałużny: I tutaj gdzieś był kurde komentarz o tagach. Ja go nie namierzyłem w naszych odcinkach. Nie wiem gdzie zniknął komentarz, bo mieliśmy komentarz na temat gdzieś tagów i hate na omówieniu tagów, że centralnie zmienione tagi i inne takie elementy. O, znalazłem go, że a, że FinOps Foundation nie rekomendują łączenia tagów, używania ich i hierarchii, w tym z hierarchią kont, projektów i subskrypcji. Tam była taka rekomendacja w tym. I całość, jak już popatrzymy, to z tymi tagami naming convention… Słuchajcie, inaczej, dlatego mówiliśmy, że tagi trzeba wstępnie dobrze zrobić, bo nikt nie powinien tego centralnie aktualizować i hurtem i grupowo. To jest w ogóle przy self service. Dlatego tagi są istotnym elementem, ale robione z głową i minimalizmem, a nie zbawieniem wszystkiego.
Szymon Warda: Tagów powinny być 3 do 5 powiedzmy sobie. I to w większości sytuacji Wam wystarczy. Naming convention - fajnie, fajnie, nie wystarczy, bo wyszukiwanie nie jest aż tak dobre i filtracja i tak dalej, dużo można zrobić na bazie tagów i dlatego właśnie są potrzebne. Sorry, nie od parady tak wiele mechanizmów jest na nich oparte.
Łukasz Kałużny: Był jeszcze jeden komentarz, bo go znalazłem, że Software-Defined Networking w tym i łączenie tego. I teraz realnie, tam był podany jeden z produktów, w którym przepraszam, ale wszędzie gdzie słyszę o tych wdrożeniach, gdzie używamy natywnie i rozpięte, przepraszam Szymon, ale u wszystkich klientów, gdzie się spotkaliśmy i od kolegów, którzy też to mają jeszcze w większych skalach, wszędzie leci jedne wielkie brzydkie słowa.
Szymon Warda: Ja to powiem tak, wszystko fajnie. Znowu, jeżeli ktoś przyjdzie, będziemy się musieli tłumaczyć czemu tak, czemu jest odstępstwo od tego jak to powinno być robione i tak dalej, i tak dalej, w pewnych przypadkach kawałki Software-Defined Networking mają sens, gdzieniegdzie, tylko jako jakieś przelotki i tak dalej. Ale w większości sytuacji? Sorry, nie, normalna sieciówka.
Łukasz Kałużny: Inaczej, one gdzieś tam mają sens, jak robimy sobie cross cloud connectivity jako warstwa połączeniowa, ale potem gdzieś w którymś momencie… Inaczej, kurde, widziałem, że to wszystko przepięknie wygląda na prezentacjach i demach. To jest trochę tak jak z tym wystąpieniem, które szykuję na Azure Day’a, które wymyśliłem sobie po jednym z ticketów do Microsoftu, gdzie po prostu już mam dość. Stwierdziłem, że zrobię prezentację: microsoft Foundry działa na demo, a w firmie?
Szymon Warda: Już kończymy tutaj reklamę, ale na konferencję zapraszamy.
Łukasz Kałużny: Tak, więc to jest, chodzi o to, że tutaj o tym, co mówimy, kurde, na slajdach, tak jak powiedzieliśmy, crossplane, te SDN-y, to jest cudowne.
Szymon Warda: Dobra, zwijamy ten odcinek.
Łukasz Kałużny: Tak, trzeba.
Szymon Warda: Podsumowując, żeby zrobić crossplane, gdzie ma sens? Duża skala, jak najbardziej. Bardzo ograniczone to, z czego mogą ludzie korzystać, to nie jest dla całej firmy, to jest dla pewnych działów. Coś jeszcze Łukasz?
Łukasz Kałużny: Wiesz co, powiedziałbym, że tak, to jest tak jak z platform engineeringiem, jeżeli budujesz platformę in house, budujesz kompetencje, jesteś firmą produktową SaaS-ową, która dostarcza coś takiego - robimy. Możesz to wziąć jako jeden z elementów building bloku, który leży gotowy, jak chcesz oprzeć i wykorzystać Kubernetesa jako API dostępowe do platformy i serce jako bazę danych. I to jest świetne.
Szymon Warda: Albo jeszcze ewentualnie jesteś na tyle wielką korporacją, która realnie może mieć wymogi multiclouda.
Łukasz Kałużny: Ale dobra, Szymon, dobra, może inaczej powiedzmy, jest to jeden z kolejnych… Przepraszam, ja pamiętam, w pewnej firmie dużej amerykańskiej, jak tam pomagałem, okazało się, że trzy konkurencyjne zespoły budowały platformę do kontenerów. I skończy się na tym, że to jest platforma dla jakiegoś obszaru, gdzie wszystkie inne projekty będą sponsorowały tą zabawę.
Szymon Warda: Oczywiście, że dalej, w takiej korporacji też tego nie rozepniesz na wszystko, nie ma opcji generalnie, to nie ta bajka. Dobra.
Łukasz Kałużny: Dobra.
Szymon Warda: Crossplane - powiedzieliśmy. Terraform - zgadzamy się.
Łukasz Kałużny: Będzie miał się dobrze, kompetencja w tym. Znaczy inaczej, jeszcze dzięki AI-owi kompetencja stała się tańsza i bardziej dostępna.
Szymon Warda: Per token. I co? I tyle tak naprawdę.
Łukasz Kałużny: Tyle.
Szymon Warda: Trzymajcie się, na razie. Hej.
Łukasz Kałużny: Hej.

Wypełnij poniższy formularz, aby być na bieżąco ze wszystkimi
odcinkami Patoarchitektów
i uzyskać dostęp do dodatkowych
materiałów.