Ostatnie Patoszkolenie w tym roku👇
Good to be back! Czy wiesz co pachnie pleśnią!? Zaczynamy od kolejnego już przeglądu Technology Radar, tym razem vol. 26.
Ciekawe linki i inne znaleziska z tego odcinka:
Szymon Warda [SW]: Cześć! Słuchacie Patoarchitektów. Prowadzą: Szymon Warda
Łukasz Kałużny [ŁK]: i Łukasz Kałużny.
SW: No, w końcu powrót. Wersja, Łukasz mówi, że pierwsza, ja twierdzę, że druga.
ŁK: Raczej sezon drugi albo trzeci. Można się kłócić. Wszystkie linki do tego odcinka znajdziecie klasycznie na: patoarchitekci.io/37.
SW: Tak, tu już bez numeracji od sag odcinków. Dobra, zaczynamy w sumie od ogłoszeń. Więc… Drum’n’roll Łukasz.
ŁK: Tak, jedziemy. Dzisiaj nie ma linku, za to ogłoszenie: zniknęliśmy na jakiś czas. Część osób mogła to zauważyć. Kiedyś nawet wspominaliśmy, że będziemy mieli ogłoszenie tego typu. No i musimy przyznać, że Patoarchitekci mają też swoją część komercyjną - bo tak to trzeba określić - i prowadzimy butik doradczy o nazwie „Protopia”.
SW: Dokładnie tak. Tyle ogłoszeniowo. Więc co, lecimy dalej? Linki.
ŁK: Tyle.
SW: Dobrze, co dzisiaj po odnowieniu, że tak powiem? Oczywiście to, od czego w sumie zaczynaliśmy tak naprawdę jeden z pierwszych odcinków Pato – Technology Radar od Thoughtworksa. Słowem wstępu: czym jest Technology Radar? Łukasz.
ŁK: Dobra. Technology Radar firmy Thoughtworks to raport, który dał całe podejście do technologicznych radarów, czyli umiejscowienie sobie na radarze technologii i jak do niej podchodzić i – co ważne – jest on budowany na ich subiektywnych doświadczeniach i…
SW: Wetknę Ci się. Bo nie tylko technologii. Tam są obszary, o których pewnie będziesz za chwilę mówił, ale nie mylmy tego, że mówimy tylko o programach. Tam mówimy o wszystkim w związku z IT i projektami.
ŁK: Tak. To jest lepsze określenie - wszystko w związku z IT. I to bazuje na ich doświadczeniach z ich projektów, dlatego jest mocno subiektywne. Co tym razem? Poużywamy chyba sobie.
SW: Poużywamy chyba sobie, bo jak zaczynaliśmy, to on był dość ciekawy, był taki trochę bardziej ryzykowny, a ten radar jest jakby…
ŁK: Uciekł.
SW: …uciekł. Tak trochę. Bardzo bezpieczny jest.
ŁK: Dobra. Może wezmę teraz obszary i przypomnę, co jest.
SW: Oczywiście.
ŁK: Są: techniki, czyli właśnie w jaki sposób podchodzimy do czegoś w IT, metodologie, procesy etc. Platformy, czyli narzędzia takie platformowe, podejścia platformowe, rozwiązania platformowe. Potem Toolsy, czyli typowa część narzędziowa, bibliotekowa. Oraz języki i frameworki, czyli cały taki syf – nazwijmy to – programistyczny, który sobie lata i w którym tworzymy.
SW: I do tego mamy jeszcze drugi wymiar, jeżeli chodzi o poziomy. Bo każda z tych technologii jest umieszczona na czterech wymiarach: Adopt - w rozumieniu radaru to jest ‘bierz i używaj’, czyli bezpieczne, stabilne, można. Dalej jest Trial, czyli ‘próbuj’ - to są obszary takie bardziej POC, którą z tych technologii tak naprawdę wybrać albo po prostu rób POC, czy ta konkretna technologia Ci pasuje.
ŁK: Ewentualnie: spróbuj w projekcie.
SW: Tak. Jest Assess, bardziej na zasadzie: ‘zrób research’, zobacz na poziomie miękkim, na papierze, czy to w ogóle pasuje, czy to ma sens, czy spełnia twoje wymagania. I na końcu jest Hold, który jest najciekawszy, bo to są technologie, dla których Thoughtworks mówi: ‘nie używaj’, albo: ‘wstrzymaj się na chwilę z tym’. I to jest z reguły taka przepaść, w którą spadają technologie i rzadko kiedy z niej wychodzą. To jest też taki sygnał, że już koniec z tą technologią, koniec z danym podejściem. Dobrze. Więc przechodzimy sobie przez technologie pierwsze. To sobie zacznę.
ŁK: Tak.
SW: Mój ogólny komentarz, co też się zgodzisz całościowo, jest… zalatuje trochę pleśnią ten cały Radar. To mi się rzuciło pierwsze w oczy. W Adopt, czyli w opcji: ‘bierz i używaj’, jest coś, co ładnie zostało nazwane: four metrics. Jakie są metryki? Change lead time – czyli czas do zmiany, deployment frequency – jak często zmieniamy, mean time to restore (MTTR) – jak szybko od faila umiemy działać z powrotem i change fail percentage – jak często mamy zmiany, które powodują błędy. I jeżeli ktoś ma déjà vu, że to nic nowego, to ma rację.O tym to mówimy w State of DevOps report. Sprawdziłem i to ma już osiem lat lekką ręką. Szybkie googlanie, bo niestety nie ma całej historii publikacji State of DevOps report, i udało mi się cofnąć do 2010 roku. To jest dwanaście lat. To są wszystkie cztery metryki, które de facto wychodziły z State of DevOps report. To już powinno być daleko poza Adopt, mieć poziom, że tak powiem, zero.
ŁK: Tak tak.
SW: Tak. I jeśli mówimy, żeby teraz outować, jest smutne.
ŁK: Wiesz co… z jednej strony smutne, z drugiej wezmę ich trochę pod obronę w tym miejscu. Bo większość ludzi, mimo że jest w stanie te metryki zmierzyć, przy aktualnym stanie narzędzi, tego jak niektórzy kochają Jirę i inne narzędzia, to jesteśmy w stanie te informacje wydobyć, ale nikt na te metryki w ogóle nie patrzy.
SW: Mówisz, że będziesz ich bronił. Nie wydaje mi się, że koniecznie trzeba to robić, bo dla mnie smutny jest element, że przez dziesięć lat to się w naszym światku nie stało oczywistością, tak naprawdę. Że teraz Thoughtworks musi wychodzić i mówić: używajcie tego. Coś o czym już wiemy, mówiliśmy już. ŁK: Tak, jest to… bo nie patrzyłem, czy ona się wcześniej pojawiały, jak wyglądały te four metrics. Ale tak, powinno być to standardem przy de facto patrzeniu na jakość wytwarzanego oprogramowania.
SW: Tak. Dla mnie to jest tak samo, jakby nagle wylądował Git, żeby kod trzymać w repo.
ŁK: Poczekaj, bo możemy się jeszcze zdziwić przy następnym, jeżeli podejmiemy się tego. Jak to robi załóżmy Istio . Najczęściej właśnie w jakimś orchlestator. I dla mnie, ja to wybrałem trochę bardziej, żeby porozmawiać o tym… O meshach mówiliśmy dwa lata temu, że adopt…
SW: Tak. Ale to jest tego kalibru rzecz, ta naprawdę. Bo zarządzanie jakimikolwiek metrykami, projektami, cokolwiek, jeżeli chodzi o wszystko na produkcji i zespół, który wytwarza, to metryki są podstawowe. Więc smutno. Ale, ale, ale…. żeby nie było, że marudzę. To drugi obszar, to jest Service Mesh without sidecar. I trochę… O czym w ogóle chodzi z sidecarze? Oczywiście, że jak mamy service mesha, to musimy mieć coś, przez co cały ruch przechodzi, żeby to monitorować i… teraz tu się wiąże cały element z injection
ŁK: Trzy…
SW: Albo trzy… coś w tym stylu. A wydaje mi się, że wtedy mówiliśmy, że ok, będą. Niewiele się zmieniło w ogóle w tym podejściu.
ŁK: Raczej jest dużo szumu, ludzie wykorzystują to w pojedynczych projektach, nie jest to jakiś trend szeroki.
SW: Tak. I one nadal są w tym miejscu, w którym były. Mieliśmy z klientem rozmowę, i jak powiedzieliśmy, że ok, bo jest wykorzystywana Grafana, jest wykorzystywany Jagger, jest wykorzystywany Prometeusz, co tam jeszcze było…
ŁK: Ogólnie stos cloud native.
SW: Tak. Cały nativowy. I było tematem… To może w takim razie do observability niezrozumiałe ability użyjmy mistio. I pierwsze zdanie, które padło na tę propozycję, to było: ‘Nie, to będzie miało duży narzut wydajnościowy’. To zostało szybko obalone, jak znowu weszła strona, którą Istio publikuje w kontekście właśnie wydajności i narzutów wydajnościowego. Ale wydaje mi się, że to zdanie mówi jedną, bardzo konkretną rzecz: że meshe dalej kojarzą się z tym, że będzie wolno i że to jest zabawka, ale na produkcji będzie tego zbyt duży koszt.
ŁK: No. Znaczy wiesz co… jest tak. Widzę inne problemy, bo trzeba software dostosować częściowo pod mesha, o czym się nie zawsze mówi, że init containery mają problemy, jest cała układanka z tym.
SW: Tak, ale to ułożysz. Ale chodzi mi o takie pierwsze skojarzenie. ‘A… nie możemy bo… to jest wolne’, nawet bez próby, jak bardzo, co to robiło.
ŁK: Znaczy niektórzy tak. Drugi: mamy bardzo duży narzut konfiguracyjny. To jest… zdanie, z którym i częściowo się zgadzam.
SW: Tak, to jest prawda.
ŁK: Bo jak zaczynasz kombinować coś więcej niż z pudełka, jest to ciężkie.
SW: Ale użyłeś słowa kombinować. Czyli właśnie, mam wrażenie, to samo co mówiliśmy ostatnio o meshach: że jak zaczynasz przekombinowywać, dużo robić routingu, trafficu na podstawie http, nagłówków albo treści, to wtedy meshe oczywiście zaczynają być drogie. Ale wydaje się, że w takim w miarę sensownym użyciu to ta konfiguracja nie jest aż tak absurdalnie wręcz duża.
ŁK: Tak.
SW: Ale teraz, o co chodzi w sidecarze? Pomysł jest taki, żeby wykorzystać też coś, co nie jest wcale jakieś nowe, żeby sidecary były na poziomie Kernella. I co można robić? Można robić od dawna przez Berkeley Packet Filter, i to o tym też była mowa, wykorzystaniem w kontekście K8S-a, też od kilku lat. To nie jest…
ŁK: De facto takim challengerem na tym rynku jest Silium, które ja tam gdzieś… Bo też to wybrałem w późniejszej części tego.
SW: Widziałem właśnie.
ŁK: Technologia samego eBPF-a jest zajebista. I samo podejście. Jest szeroko używana - to jest bardzo ważne - przez outlera, przez innych w tej szerokiej branży, ale dopiero się uczymy jej używać. Bo to jest też ważna technologia. Jest teraz w fazie adopt. Zobaczymy jak serwisy mesh to uciągną…
SW: Ale też jest wykorzystywana w kontekście zabezpieczenia ruchu wewnątrz klastra. Nie jako serwis, nie w serwis mesha.
ŁK: Tak, ale wszędzie jest nadal eksperymentalnie. Patrzę, obserwuję, co będzie z Silium, bo dla mnie to będzie wyznacznik. Oni są najbardziej zaawansowani w pracach z użyciem tego, Istio jeszcze podchodzi ze swoim container network interface, swoim driverem sieciowym, więc zobaczymy. Ogólnie pomysł jest taki, że wyrzucamy to do środka węzła i nie patrzymy na to, i zaczyna to być dla nas transparentne z poziomu infry
SW: Tak powinno być.
ŁK: Zaczyna to wyglądać dobrze. Czekam jeszcze trochę na uproszczenie pewnych rzeczy w konfiguracji. Boję się, jak będą wyglądały te elementy.
SW: Ja się… boję upgrade’ów, boję się właśnie, jak będzie to wszystko ładnie spięte. No bo to musielibyśmy mieć bazowy obraz. Pytanie, czy nie skończymy na tym, żeby kontenery, które chodzą w ramach klastra, musiałyby mieć określony obraz albo właśnie były jakoś wstrzykiwane. I to zaczyna być takie… Jestem ciekawy jak to pójdzie, ale dla mnie to jest najlepszy kierunek, w którym może pójść, aby właśnie odciąć się od tego, że ‘’Oj będzie wolno’, ‘za dużo kontenerów’ itd.
ŁK: Kierunek jest spoko, zobaczymy jak wykonanie.
SW: Tak. I zobaczymy jak rynek to przyjmie. czy faktycznie uda się zdjąć tą narzutkę. Łukasz, teraz ty.
ŁK: Dobra. Pierwsze co biorę, to Data mesh. Mam sentyment do rynku i części data’owej. Data mesh to koncepcja, że mamy kilka-kilkanaście data lejków i robimy wymianę danych, synchronizacji. Ja bym to nazwał mikroserwisami albo konwayem dla części analitycznej w naszych organizacjach.
SW: Bo to będzie potrzebne.
ŁK: Tak, będzie potrzebne. W Raporcie jest jako Trial. Wiem, że firmy próbują, wykładają się na tym (to jest lepsze określenie) i mówią, że udało im się to zrobić. Mam wrażenie, że dzisiaj nie nauczyliśmy się do końca data lake i koncepcji Lakehouse, które są przez niektórych promowane, i próbujemy znowu rozwiązywać kolejne problemy zanim się cofną. Mam swoją teorię, czemu tu się pojawiło. Ponieważ o Data meshach było na blogu Fowlera, więc prawdopodobnie dlatego tu się to pojawiło. Taki ciekawy element dla mnie, bo bardziej na asses pasuje niż nawet na Trial. To nie powinno być domyślnym podejściem, że ‘sprawdzaj’. Dobrze, że nie jest na adopt.
SW: To ja znowu mam déjà vu. Zrobiłem szybkie googlanie. I pierwszy raz, bo wydaje mi się, że mówiliśmy już o data meshach, pierwszy raz data meshe pojawiły się w 2019 roku. Na asses właśnie były. Więc to trochę powoli idzie.
ŁK: Też pamiętajmy, że to są skomplikowane projekty.
SW: Tu dotykamy danych w organizacjach dużych, bo duże będą miały potrzeby. Tak, to będzie mega skomplikowane.
ŁK: Tak. Duży biznes może potrzebować data meshy, ale w większości wystarczy dobrze zarządzany data lake. Dobra.
SW: Mhm. Dobra, masz kolejne.
ŁK: Kolejne. To, co mam, poruszymy prawdopodobnie w przyszłych odcinkach. To są Miscellaneous platform teams. Czyli różne zespoły platformowe. Bo teraz to, co się dzieje ze słowem platform, zaczyna powoli być nowym devopsem. Często przykleja się zespołom administratorom, na których była naklejka devopsów, naklejkę platformową. I tutaj chodzi o to, żeby tego specjalnie nie tworzyć, czyli jest na Holdzie. Moim zdaniem trafili troszeczkę przed czasem nawet. I to jest, w mojej opinii, jedna z perełek w tym Radarze. Powiedzieli, aby się wstrzymać z tym. Dobry krok. I teraz chodzi o to, żeby zespołów apliakcyjnych, zespołu ‘badziewi’ to nazwijmy, bo to jest dobre określenie, żeby nie nazywać rzeczy platformami, jeżeli one nie są platformą, tylko nową naklejką brandingową na kolejny sukces kawałka organizacji czy managerów.
SW: Ja się z tym zgodzę. Ty bardziej, że mam doświadczenie w budowaniu takich zespołów i ciężko zbudować zespół platformowy. Tam musi być bardzo dużo umiejętności i ludzie muszą być po zmianach mindsetu.
ŁK: Raczej to jest… zespół platformowy to taki sneak-pick tego, o czym bym chciał porozmawiać w przyszłych odcinkach. To jest zmiana, że stajesz się dosłownie wewnętrznym dostawcą
SW: Tak, dokładnie.
ŁK: I mocno odciętym w pewnych rzeczach od organizacji. Ale to zostawmy sobie i nie wyczerpujmy sobie tematu. Kolejną rzeczą, która mnie tutaj zaskoczyła i…
SW: Mnie też
ŁK: i mam wrażenie, że z rynku start-up’owego i Ruby’ego przyjechała za mocno, czyli Hold na: SPA by default. Założenie jest takie, że Thoughtworks w swoim raporcie twierdzi, że aplikacje SPA nie powinny być wybierane jako domyślny sposób. Jako alternatywę wskazują np. Hot wire i wszystkie technologie, które zaczęły znowu powracać do łaski, czyli renderujmy html w backendzie w ramach naszego frameworka.
SW: Mnie to tylko cieszy, tak powiem.
ŁK: Raczej tak. Mam wrażenie, że zaraz pojawią się tu stare webformsy i wrócimy prawie że do webformsów.
SW: Aż tak może nie, ale wydaje mi się, że oni unikają zrzucania rzeczy do Holda. Dla mnie to jest taki kubeł zimnej wody i zdrowego rozsądku, bo SPA są fajne, a ich koszt wdrożenia jest tak momentami absurdalnie duży.
ŁK: Czyli jest przekombinowane.
SW: Tak. To się niezrozumiałe stało, żeby by default. Nie wszystko musi być SPA, i żeby właśnie rozważać, żeby wrócić do dyskusji, gdzie SPA ma sens
ŁK: Znaczy, powiem tak. Patrząc na mnogość developerów, kompetencji na rynku, jeżeli dobrze wystartujemy projekt i go poukładamy, nie będzie to straszne. W aplikacjach biznesowych np. jest to super, patrząc, jak się biznes do pewnych rzeczy przyzwyczaił i jego użytkownicy. Jeżeli mówimy np. tutaj przy Ruby on rails, który istnieje mocno w światku start-up’owym. Tam np. w NBP w prototypach, innych rzeczach – zgodzę się z nimi, że prościej jest zrobić sobie fullstackowo i położyć mniejszy nacisk na superzajebistość Java Scriptu, za to przy apkach biznesowych zostanę, że to nie jest dobry pomysł.
SW: Dla mnie to już często jest tak, że użytkownik nie zauważa, gdzie ma do czynienia ze SPA, a gdzie ma do czynienia ze zwykłym przeładowaniem.
ŁK: Dokładnie. Lećmy dalej. To Szymon - narzędzia. Co wybrałeś?
SW: Dobrze. Toolsy. Dla mnie jest kilka ciekawych toolsów, jak się popatrzy. Po pierwsze, nie ma niczego na Hold, co jest ciekawe. Jedna rzecz jest dla mnie ciekawa, ale nie ze względu na technologię. Cloud Carbon Footprint, czyli możliwość tego, żeby można było obliczyć footprint carbonowy naszej infrastruktury sieciowej. Można powiedzieć, że ‘oo… pit-pitu, to nie ma sensu’. Jest jedna rzecz, którą tu trzeba mieć bardzo na uwadze: wchodzi nowa regulacja amerykańskiego FCC, czyli nadzoru finansowego, która będzie wymagała od firm publikacji kwestii ekologicznych swoich, jak i swoich dostawców. Nawet jeżeli one nie są publicznymi firmami. To dotknie wszystkich firm notowanych na giełdzie amerykańskich tak naprawdę. Więc nie mówimy tutaj o tym, czy wejdzie, albo czy będziemy korzystać. To wejdzie. To będzie coś, co wejdzie kompletnie bokiem przez regulacje prawne i wymagania prawne.
ŁK: Tak, tam nawet jest w AWS-ie Tool do tego. Jakiś czas temu dorobili Tool, aby można było patrzeć na swój Carbon Footprint właśnie - ślad węglowy.
SW: Tak, dokładnie.
ŁK: Jest to ciekawe z perspektywy ekologicznej, tylko ciągle mam wrażenie, że (to już jest moja perspektywa, nie powinniśmy wchodzić w to przeświadczenie), dla mnie te regulacje, to co mówią dostawcy Clouda i w ogóle, to taki green washing.
SW: Teraz był raport, gdzie wyszło, że jedna z osób, która prowadziła carbonowe inicjatywy w Black Rocku, czyli największym generatorze ETF-ów, właśnie odeszła z tego powodu. Ale o co chodzi? Chodzi o green washing. Będziemy musieli te raporty wypluwać i to będzie jeden z elementów, który będziemy za parę lat brać pod uwagę. Więc IT poza budżetem, będzie też miało budżet w kontekście carbonowym.
ŁK: Wrócimy do pisania optymalnego kodu? (śmiech)
SW: Tak. Ale też jest o tyle ciekawsze, że są całe podejścia, różne data center mają też różny carbon. Są w Norwegii między innymi takie, które są zerowe, a przecież cały CAT MS ma inicjatywę, żeby być carbon negative tak naprawdę. To jest bardzo ciekawa inicjatywa.
ŁK: Dobra. Lećmy do następnego Twojego elementu.
SW: Dobrze. Kube-score. O co z tym chodzi? Testowanie i weryfikacja konfiguracji K8s-a. I to jest o tyle fajne, bo pobawiłem się chwilę, i to ma sens. Często pisałem zwykłe kawałki basha, które sprawdzają pewne rzeczy, ale powiem, że po szybkiej zabawie, no.. tak…
ŁK: Raczej… Daje, z ręką na sercu, w tym roku radę. Z trzy czy cztery audyty z tym narzędziem wykorzystałem i ono wskazuje… Bardzo ważna rzecz: można potraktować je jako unit testy do swojego CI. To jest najważniejsza rzecz, że można je dziecinnie prosto wpiąć do swojego zestawu. I to jest najważniejsze.
SW: Tak, tak. I ładne wyniki są bardzo opisowe. I naprawdę te wyniki są sensowne, więc…
ŁK: Tak, chociaż brakuje ciągle dla K8S-a jakiegoś zebrania sensownego w ogóle wymagań w pewnym sensie od aplikacji a nie od infrastruktury. Bo CIS benchmark, który jest dla K8s-a, on jest de facto dla klastrów, dla innych aplikacyjny jest tam niewiele. Ale to już nie drążmy. Dobra, biorę swoje i zacznę od K8s-a. Jest tutaj narzędzie: Conftest. W Trialu. Dla mnie ono jest na poziomie Adopt. Chodzi o to, że mamy taką rzecz, jak regopolisy i gatekeepera, czyli polityki dla K8s-a żeby sprawdzać. I conftest pozwala te polityki odpalić lokalnie. Czyli możemy, zanim będziemy tak jak Kube-score był podany, możemy zapalić conftesta na poziomie CI i sprawdzić. Czy nawet jeszcze na poziomie pre hooków do commit innych rzeczy, w zależności jak sobie zrobimy stos. Możemy sprawdzić, czy jesteśmy zgodni z politykami, które przyjęliśmy sobie na K8s-ie. Czyli te polityki, które stoją za Gatekeeperem i open police gatem, można władować do CI lokalnie i wszystko zweryfikować, czy spełniamy nasze wymagania czy nie. I narzędzie Justwork. Jeżeli mamy na klastrze jego polisy wrzucone, to możemy je tak samo spróbować odpalić lokalnie.
SW: Ok. Ja bardziej czekam na Twój drugi element.
ŁK: Dobra. Ogólnie tutaj w narzędziach jest dużo terraforma.
SW: Dużo terraforma, to się zgadza.
ŁK: Zastanawiałem się teraz, co wybrać. Czy Tfsec alo czy infra costa. Tfsec jest na Adopt i używajcie go. Jest tam dużo terraforma. Tfseca po prostu używajcie, wepnijcie go w CI i koniec. Zakończmy tą dyskusję. Dobre narzędzie.
SW: Łukasz, poleca coś dla Terraforma. No niesamowite.
ŁK: Umiem go używać, a to, że go nienawidzę, to inna rzecz. Dobra. Za to jeżeli chodzi o infra costa - bardzo fajny projekt. Tutaj jest na Asses i słusznie. Pozwala nam wyliczyć na podstawie changera, którego robimy w terraformie koszty, jakie wprowadzi w naszej infrastrukturze na podstawie tego, co mamy. I uważam to za rzecz po prostu genialną. Niestety tylko dla AWS. Chyba dla Azura też…
SW: Pojawiło się, ale chyba nie w pełni. Nie wszystko jeszcze.
ŁK: Tak, więc powiedzmy, że na razie to jest AWS. Ale ogólnie podejście, żeby na bazie pool requestów wyliczyć sobie potencjalne zmiany w kosztach jest genialne.
SW: My właśnie to będziemy teraz spinali. Ale… dla mnie to jest ciekawe, jak to będzie działało w praktyce. Bo ideowo, zgodzimy się, że jest to fenomenalne i jest to bardzo fajne. Jestem po prostu ciekawy, jak te liczby będą dokładne, bo wystarczy kilka takich błędów, albo to, że on będzie momentalnie ignorowane. I to będzie właściwie rzecz, która wejdzie do CI/CD i szybko trzeba będzie go usunąć, bo po prostu będzie martwe.
ŁK: Tak, więc zobaczymy, jak to będzie wyglądać. Ale ogólnie sama koncepcja jest świetna.
SW: Tak. Platformy. Lecisz teraz Ty pierwszy.
ŁK: Dobra. Z platformami bardzo szybko. eBPF, o którym już wspomnieliśmy przy sidecarach.
SW: Rozwiń skrót, bo zwykle rozwijasz
ŁK: Extended Berkeley Packet Filtering, czyli…
SW: Dokładnie
ŁK: …filtrowanie pakietów sieciowych w Kernellu pomijając cały stos system space’ów. Jeżeli ktoś zna w detalach, czyli w tzw. user space’ie możemy wstrzyknąć z user space’a swoje kawałki kodu, żeby przefiltrować pakiety, które wpadają. Zrobić to bardzo wydajnie, bezpiecznie, jeżeli chodzi o całość, z perspektywy całego systemu operacyjnego i, co ważne, pomijając cały stos sieciowy. Więc już pojawiały się pierwsze ataki wykorzystujące do wrzucenia jakichś ramsoftwear’ów (bo teraz już trojan się na to nie mówi), żeby zagnieździć przechwytywanie pakietów. Jest to w mojej opinii przyszłość networkingu, softwear define networkingu, SDN-ów. Tylko co ważne, de facto w codziennej pracy powinieneś wiedzieć, co to jest, znać zasady działania i powinno ci to za przeproszeniem gówno obchodzić, bo powinno to przyjść z takim np. service meshem czy z produktem sieciowym, którego używasz.
SW: Tak, to nie jest coś, co developerzy powinni pisać. To jest element kodu, który wchodzi w Kernella. Developer Kernela to nie jest standardowy zestaw umiejętności developera.
ŁK: Tak. Dla admina to jest świadomość, jak to działa i będzie pewnie travel shouting. Dla devopsa w zależności, jak go nazwiemy. Dla ludzi od infry, którzy jej dotykają, świadomość, co to jest i ewentualnie jak sprawdzić, jaką mamy konfigurację, co tam się dzieje. I tyle dla developerów, przychodzi to z gotowym produktem, jaki wykorzystują.
SW: Tak. Ja bym tutaj turbelshootingu nie oczekiwał. Jak mam być szczery. Albo przy takim bardzo wysokim poziomie.
ŁK: Widzisz, mam załadowane, co się dzieje. Bo to trzeba po prostu na takiej zasadzie, popatrzeć na to. Tylko tyle.
SW: Tak. Ale debugowanie nie ma opcji.
ŁK: Raczej… debugowanie. Bardziej sprawdzenie.
SW: Tak.
ŁK: Taka podstawowa diagnostyka.
SW: Dobrze. Idź do kolejnego, tu jestem bardzo ciekawy.
ŁK: Dobra. Jest sobie na Trialu takie gówienko, dlatego je tutaj wpisałem, nazywa się Sealed Secrets od Bitami. Jest to bardzo stare. Wydaje mi się, że nawet pokazywałem to na streamach w ramach Pato, jak bawiłem się raz klastrami na K8s-a. I o co chodzi? O to, żeby móc w bezpieczny sposób wrzucić secrateamy do repozytorium, żeby przy podejściach depodsowych i fluksowych się rozwinęły do K8s-a w ładny sposób. Poczekaj, Szymon, zanim wylejesz wiadro pomyj. Uważam, że GitOps ciągle ma problem z secrateami i powinno to się robić zewnętrznymi rzeczami i voltami. To powinno być pierwsze podejście, że dostarczamy providery do credentiali, w innym miejscu je zaciągamy definicjami stamtąd. Taki volt, czy każdy KMS, key managment system, który mamy w cloudach powinien to robić. I teraz, Szymon, możesz wylać swoje żale.
SW: Szczerze? Nienawidzę tego narzędzia. Jak ja go nienawidzę. Trochę się z Tobą zgodzę, że faktycznie cały key managment można wywalić, cały secret managment. Ale ostatnio zacząłem się bawić, wykorzystywać w projekcie Mozilla Soups i naprawdę daje radę. Dużo fajniej się z tego korzysta, dużo lepiej się to spina. Dogaduje się to z innymi narzędziami, więc, jeżeli ktoś nie może, lub ktoś chce mieć po prostu takie czysto devopsowe podejście z kluczami albo wewnętrznymi vaultami, no to na całego docsa trochę psuje, nazwijmy to. Że nie wszystko mamy w typ repo. Jakby ktoś się upierał, to może rzucić okiem na Soupsa. Po pierwsze, stoi za tym Mozilla, czyli to ma ręce i nogi. Po drugie, jest to dojrzałe, integruje się ze wszystkimi chmurami tymi większymi, nie oszukujmy się. A po kolejne, działa po prostu dobrze. Naprawdę miło się z tego korzysta.
ŁK: Dobra. A Ty co wybrałeś, bo specjalnie zostawiłem, nie wziąłem jednej rzeczy, więc… Co wybrałeś Szymonie?
SW: Ja najpierw skomentuję, bo tutaj to fajnie widać. W platformach nie ma nic w Adopt, nie ma nic na Holdzie. Jest taki środek. Więc dla mnie to trochę stagnacja. A co ja wybrałem? Wybrałem GH Actions. One istniały… Tam jest GitHub Actions, GitHub Reusable workflows itd. Pamiętam, jak zaczynałem używać Actions dwa lata temu. To było takie narzędzie do CI, do niczego więcej, tak naprawdę.
ŁK: No ja trzy lata temu to zaczynałem, jak wchodziło. Bo zaczynałem tego dotykać na przełomie 2019 chyba.
SW: Coś tam mogło być. Tak, nie oszukujmy się, ostatnie dwa lata się trochę tak pozmywały. A od tego czasu to się mega rozwinęło. Po pierwsze, jest całkiem fajne podejście, jeżeli chodzi o wsparcie dla platform, o wsparcie dla secreatów dla różnych platform. Jest dużo bardziej enterprise. Są reużywalne workflowy. Czyli po prostu możemy dziedziczyć na workflowów. To na prawdę stało się bardzo dojrzałe i przyjemne.
ŁK: Znaczy, wiesz co, brakuje mi tylko w porównaniu np. do Asure Devopsa, bo to jest takie… zrobię mocne porównanie, bo to jest ten sam właściciel
SW: Tak.
ŁK: I część ludzi z devopsa pisze de facto w Actions teraz.
SW: I kod jest też mega podobny do siebie.
ŁK: Tak. Brakuje mi tego, że nie jest to hostowane… To jest robione trochę pod amerykańskiego klienta. Czyli nie wszystko jest hostowane w Europie. Jak chcesz mieć coś bardziej dedykowanego, to są rzeczy komercyjne z o wiele droższymi licencjami, nie jest to już takie przyjemne. Więc to jest takie moje… Te bardziej enterprise zrobiło się w kierunku klienta amerykańskiego, jak popatrzymy.
SW: Tak, to widać od razu.
ŁK: Bo cena dedykowanych rzeczy, GitHub serwerów, których nie chcesz utrzymywać, albo ich Cloud enterprisowego jest mocno enterprisowa.
SW: Tak, choć jeśli nie wchodzimy w enterprisowy, to prising jest bardzo przyjemny.
ŁK: Mam do nich podpiętą kartę i jedyne, za co mi ściąga, to Code Space GitHub.
SW: Tak. Jeszcze jedna rzecz, która jest w actions. Jak porównuje się między, bo porównywałeś do devopsa… Actionsy są dużo czystsze. Devops ma dużo kombinacji, jak można to ułożyć w kontekście, żeby ta składnia była niby lepsza, przez co on jest bardziej messy, jest bardziej nieułożony, łatwiej zrobić błędy. Actionsy są dużo łatwiejsze przez to, że jest jasna, konkretna składnia, nie pozwalają iść na skróty. I po prostu dużo fajniej się z tego korzysta.
ŁK: No dobra. Przejdźmy sobie. Ja się zgadzam, że Actions, jeżeli możecie, użyjcie w projekcie – są naprawdę super. Dobra. Przejdę sobie do języków ze swojej strony. Zacznę od rzeczy, z którą się nie będziemy sprzeczać, czyli WebAssembly. I ono jest na Acces. WebAssembly, czyli odpalanie i kompilowanie się innych języków niż JavaScript do przeglądarki i odpalanie prawie z natywną wydajnością.
SW: Niekoniecznie przeglądarki.
ŁK: Właśnie. Założenie było, że do przeglądarki. Ja patrzę na to przez zupełne inny pryzmat. Obstawiam na 80%, że będzie dane nam bardzo mocno poznać, ponieważ patrzę przez pryzmat server odpalania, server side’a i jako następstwa kontenerów.
SW: Ale o tym też mówiliśmy dwa lata temu czy coś w tym stylu.
ŁK: Tak, dwa lata temu, przy klustlecie, czyli projekcie m.in. Microsoftu do odpalania właśnie WebAssembly jako server side. I to wszystko się dzieje powoli, swoim tempem. Dzieje się i dojrzewa. To będzie bardzo ciekawy moment.
SW: Ale dzieje się wolno bardzo. Pączkuje, pączkuje i zastanawiam się po prostu, czy to nie…
ŁK: Dobra, przy tej adopcji kontenerów, które są prawie by default w każdym projekcie.
SW: No tak, to już jest default.
ŁK: Tak, to jest default. Jeżeli firma nie jest Comarchem czy Asseco w mentalności, to rzadko kiedy korzysta z tego. A spotykamy się z takimi nadal. Ale w większości projektów one są by default na kontenerach albo na jakichś usługach passowych. Nawet jak ktoś robi w on premmy i nie ma K8s-a, to zazwyczaj i tak dostarcza to w kontenerach, chyba że jest zatwardziałem IOS-owcem.
SW: To już pokontynuuje ten temat po Twoim przerwaniu. Świat w IT się rusza cały czas. O Web Assembly mówiliśmy właśnie, o tym, o czym ty mówisz, czyli głównie kompilowanie języków typowo server side. Przy czym mam wrażenie, że trochę mniej się przyjęło. Server side właśnie do WebAssembly, żeby odchudzić nasze kontenery. I mam wrażenie, że w tym obszarze to się bardzo niewiele ruszyło.
ŁK: Nie, wiesz co, tam…
SW: Tak samo jak meshe, tak samo jak inne rzeczy. Że stoi to.
ŁK: Wiesz co… w tym roku sporo się ruszyło, bo krusl też już poszedł mocno do przodu. Poszedł w Sanboxa CNC, czyli jest już sobie w ramach CMV. Dużo musi dojrzeć. Ja widzę tutaj dwie zalety: zupełnie odcinamy się od systemu operacyjnego. Jak w przypadku zależności, które mieliśmy w kontenerach, więc dla wytwarzanego przez nas softu jest to super, bo dostajemy takie kontenery from scratch bez wiedzy o frontscatchu. Druga rzecz, która będzie ważniejsza, to zmniejszamy ilość wad, które trzeba ograniczyć od strony security.
SW: Ja się z tym zgodzę w zupełności. Nie neguję plusów.
ŁK: Tak, tylko wiesz co, tylko trzeba czasu, żeby to dojrzało.
SW: Dobra. Bo Asses, potencjalnie rozważasz, żeby można nawet tego użyć. Użyłbyś tego w projekcie obecnie?
ŁK: Takiego czystego nie.
SW: No właśnie.
ŁK: Ale ludzie z sukcesem zaczynają używać Blazzora, z tego co słyszymy z rynku.
SW: Tak.
ŁK: Jeżeli popatrzymy na pierwotną wersję WebAssemply… Zobacz, że jeden z naszych klientów, któremu robiliśmy architekturę SAS-ową, też wykorzystywał na froncie u siebie Rasta do ciężkich rzeczy w Web Assemply.
SW: Pamiętam.
ŁK: Więc od strony frontowej znajdziemy gros przypadków, które jest. Od strony backendowej…
SW: O tym właśnie mówię głównie.
ŁK: Tak, od strony backendowej za to, to jest na razie wielka niewiadoma. Dla mnie to jest zakład z K8s-em, że też zamierzam się tego… Taki zakład zrobiłem kiedyś z K8s-em i kontenerami. Dla mnie to kolejny zakład, mój bet, w to, że warto dowiedzieć się, o co chodzi w tym WebAssembly chodzi i zainwestować czasu. I najbliższe cztery lata, bo to jest teraz czasoprzestrzeń czterech lat.
SW: Tak.
ŁK: Bo ja teraz porównuję to gdzieś do 2016 roku w przypadku kontenerów. Patrząc na ten ekosystem, to jest moment gdzieś 2016 dla kontenerów.
SW: Wydaje mi się, że tak… Jeżeli 16 nie będzie popularne, to znaczy, że umarło.
ŁK: Więc zobaczymy.
SW: Tak. Dawaj kolejny element, który jest bardziej kontrowersyjny.
ŁK: Azure Bicep, czyli nowy DSL od Microsoftu, nakładka na ARMa czyli taki C# dla Azura ARma.
SW: Ładnie nazywasz generator do JS’ona.
ŁK: Tak. Generator do JS’ona. Dobra, nie będę szydził z terraforma. Twój terraform też generuje JS’ony i wysyła je w kosmos.
SW: Tak.
ŁK: Dobra. I chodzi o to, że mamy przyjemniejszą składnię językową na znienawidzonego przez niektórych ARM templaty, które są w Azurze.
SW: Dobrze, że użyłeś formy przyjemniejszą, a nie przyjemną. Bo przyjemniejszą oznacza poprawę. Poprawa jest.
ŁK: Inaczej: dla mnie tak samo ssie pałę, jak terraform.
SW: Ma terraform trochę lepszą składnię według mnie. Dalej mimo wszystko…
ŁK: To są już pierdoły. Ale ogólnie: z założenia produkcyjnego, bo używam, działa. Ma sens. Wkurzyło mnie parę rzeczy, bo jest parę luk logicznych pomiędzy możliwościami, które da się zrobić w ARM-ie. O tak. Jest parę, i to mnie dość mocno zirytowało ostatnio. W szczególności w zeszłym tygodniu musiałem trochę przerobić swoje założenia, jak coś tam ma działać i deployować. Jest ogólnie bardzo przyjemny. Jeżeli robimy jakiś projekt można iść śmiało. Jeżeli robiłeś w ARM templaty, to śmiało wyrzuć je i zacznij korzystać z Bicepa.
SW: Ja się doczepię do tego: bardzo przyjemny. On nie jest bardzo przyjemny.
ŁK: To jest moja perspektywa, dla mnie jest naprawdę spoko. Jestem w stanie kogoś Bicepa w ciągu dwóch dni nauczyć, jak go używać.
SW: Tak. Jeżeli ktoś korzystał z ARM template, to Bicep to jest nawet krócej.
ŁK: A to nawet jeden dzień. Ja mówię siąść i od zera. Jeżeli ktoś rozumie Azura, to od zera w ciągu dwóch dni jesteś w stanie nauczyć Bisepa i nie ma pewnych filozofii tutaj. Nie występują pewne ciężkie filozofie. I teraz ważne: to co Microsoft zapowiedział, pokazuje, kiedy dociągną całą implementację, server side w ogóle w swoim resource managerze, to będzie fajny terraform server side. Będzie bez wad terraforma, jeżeli chodzi o pik stanu i inne takie rzeczy. Po stronie Azura to będzie bardzo fajnie robione przez samą platformę. Dwie rzeczy, które w Bisepcie są istotne i bardzo dobrze działają: po pierwsze, moduły zostały trochę zerżnięte z terraforma.
SW: Trochę bardzo.
ŁK: Trochę bardzo, ale idea jest dobra zatem. I działa.
SW: Tak, tu słusznie zrobili.
ŁK: Druga rzecz, jest dla mnie świetna, że moduł można będzie opublikować jako szablon w naszym tenancie. Czyli zespół platformowy, cloudsowy, jak go sobie nazwiesz, będzie mógł np. dla usług przygotować jaki manifest i inne rzeczy, opublikować i potem w CI-u wymagać ich stosowania przy deploymencie.
SW: Dla mnie potęga Bisepta jest w innym obszarze. Można zrobić tak, że na końcu wygeneruje JS’ona i jego aplikujesz. Więc koszt wdrożenia jest zerowy. Ryzyko wdrożenia jest zerowe. Tak uważam. Jeżeli ktoś ma ARM templaty, to zostaje tym samym z pudełka.
ŁK: I jest łatwy, transkompliata w drugą stronę. Można sobie skompilować, rozkompilować w JS’onie do Bisepta z powrotem. I to działa dobrze. Stosuję to na starociach, żeby zabrać gotowe kawałki.
SW: Tak, tylko przy dużych projektach będzie to problematyczne. Ludzie będą mówili: ‘a może jakieś ryzyko będzie’. A chodzi mi o to, że mamy ARM templaty, wystosujemy Bicepca, można zacząć wykorzystywać tu i teraz. Nie ma z tym żadnego problemu.
ŁK: Tak, bez problemu.
SW: Więc to mnie praktycznie cieszy, bo wtedy faktycznie ładnie to MS zrobił.
ŁK: Tak, Szymon jest fanboyem terraforma, ja jestem fanboyem natywnych rzeczy, które mają support producenta, a nie gdzieś…
SW: Dobrze, idąc w moje languages. Znowu komentarz do tego, co jest w językach. Tu są prawie, jak liczyłem, to są rzeczy mobilne. Bardzo dużo rzeczy jest, jeżeli chodzi o mobilki. Ale parę rzeczy wyszło. Takich komentarzy bardziej. Java 17 nadgania. To rzeczy, które są to, C# do wniosku prowadzi: Java nadgania. Co mnie…
ŁK: Raczej Java jako język.
SW: Jako język.
ŁK: Bo JVMowe rzeczy i programowanie funkcyjne… no wcześniej trochę istniało w tamtym świecie.
[SW]; Tak, to się zgadza. Tu konkretnie mowa właśnie o Javie jako języku. Ale co mnie dalej zadziwia, to jest to, że dalej są dyskusje, czy powinniśmy się upgrade’owywać do nowej wersji języka. Co w ogóle w świecie .NET to nie istnieje. To po prostu oczywista oczywistość.
ŁK: Wiesz co… oczywista, ale od kiedy zespół przeniósł się na LTS-a 3.1
SW: Znaczy nie. Wcześniej było tak, że w ramach takiego frameworka, to była oczywista oczywistość. Potem LTS .net/C#, a teraz znowu to jest oczywista oczywistość.
ŁK: Tak. Czyli teraz, co LTS trzeba się upgrade’ować i tyle.
SW: Tak. Ale taką ciekawostką, którą też mnie zaciekawiła, pierw jako żart, ale ma to ręce i nogi, SQLC, czym to jest? To jest odwrócony ORM dla Go. Czemu odwrócony ORM? Bo to działa tak, że po pierwsze, sprawdza nam poprawność SQl i generuje modele Go pod te SQL-ki. Więc dlatego trochę odwrócony, bo z reguły ORM generujemy w drugą stronę. Ale pop inicjalnym, zastanawiałem się właśnie jaki to ma sens, to ma sens. Bo jednak te SQL-e będą wymagane - nie zawsze, Łukasz pewnie powie więcej niż ja, ale… Ja wiem, że to ma sens.
ŁK: Ogólnie zaczęliśmy się z tego śmiać, a potem: ‘kurde to ma sens’. W szczególności np. wejdźmy sobie, który jest bardzo często wykorzystywany do read modeli i innych rzeczy. I może się okazać, w wielu przypadkach, że jeżeli ktoś umie w relacyjne bazy danych, (to jest jeszcze bardzo ważna rzecz: jeżeli umie w SQLa), to może się okazać, że dziesięć razy szybciej wygeneruje sobie to, co jest potrzebne niż z jakimś podejściem Code first.
SW: Powiem tak. Bardziej mnie cieszy to, że mamy narzędzie, które to nam generuje. Więc możemy to wpiąć w CI/CD i nasze modele odświeżać na poziomie tego, co mamy w bazie. Więc trzymamy tą zgodność tak naprawdę. No bo procedury nie przegenerujemy w tym momencie. Mamy procedurę, procedura aktualizuje kod, który nam się potem ewentualnie nie skompiluje.
ŁK: Nadal jest to trochę risky, a bardziej bym powiedział, że to jest fajne do małych rzeczy. To jest fajne do małych rzeczy, pewne automaty i inne rzeczy żeby sobie zrobić w miarę to rozwijalne i szybko utrzymywalne. W dużych to zawsze będzie wyzwanie.
SW: No tych procedur skorelowanych niby nie powinieneś mieć tak właśnie znowu bardzo dużo. Ten ruch fajnie obniża koszt utrzymania tych rzeczy po prostu. Mnie to ucieszyło bardzo. Od żartu do podejścia, że nawet by się przydało. Tyle.
ŁK: Tak, ciekawe. Ktoś pisze w Golangu, to naprawdę wydaje się to ciekawą perspektywą, tak jak na to się patrzy i ma sens przy pierwszym rzucie oka.
SW: Tak. A mnie się wydaje, że to rozszerzy się na inne języki. Powiem tak.
ŁK: To byłoby ciekawe, żeby wrócić do podejścia Data by first.
SW: Wróciliśmy już w wielu obszarach, więc nie zdziwi mnie absolutnie nic. Dobra, Łukasz, kilka słów podsumowania tego Technology Radar. Jakie są Twoje wrażenia?
ŁK: Moje wrażenia są takie, że będę to przeglądał tak jak kiedyś, ale być może będzie to ostatni Technology Radar na dłuższy czas, który reviewujemy , jeżeli będzie tak zalatywał, jak to określiłeś ładnie, pleśnią. Tylko to nie jest ta pleśń jak we francuskim serze.
SW: Co za poetyckość. Ja też to powiem. Znaczy to nadal jest fajne narzędzie w kontekście tego, że załóżmy jak chcemy przepchnąć jakąś technologię, jakieś podejście w organizacjach, że inni z tego korzystają i że jak się pojawia w Asses, Trialu czy Adopt (w tym to już w ogóle oczywista sprawa).
ŁK: Albo ubijanie Holdem.
SW: Albo ubijanie Holdem. To dalej jest fajne narzędzie do uzasadnienia czemu coś robimy lub nie robimy. Natomiast nie patrzę już na niego, jako na pewien wyznacznik, w co warto pójść, rzucić, bo laguje strasznie za tym, co się dzieje na rynku i za tym co uważam, że powinno być w odpowiednich obszarach.
ŁK: Czekaj. Dobra, ja muszę sprawdzić jedną rzecz. My braliśmy 23 jako ostatni przed przerwą. Przeskoczyliśmy dwa Technology Radary i widzimy laga.
SW: Tak, dużego. Więc to nie jest różny beacon na horyzoncie, który mówi, w którym kierunku isć. To raczej coś, co jest podkładką pod to, co chcemy zrobić.
ŁK: Tak. Więc trochę zróbmy teraz rest in peace (RIP) i podziękujmy Thoughtworksowi za spopularyzowanie samej idei Radaru w IT.
SW: Tak. i szukajmy czegoś innego. Dobrze. tyle w takim razie. Dziękujemy.
ŁK: Miłego dnia.
SW: Na razie. Hej!