Robimy przegląd Technology Radar vol. 22.
Ciekawe linki i inne znaleziska z tego odcinka:
Łukasz Kałużny [ŁK]: Cześć, słuchacie patoarchitektów. Prowadzą: Łukasz Kałużny
Szymon Warda [SW]: i Szymon Warda. Wszystkie linki do tego odcinka znajdziecie na:patoarchitektci.io/29. No i oczywiście na Twitterze i Facebooku.
No to zacznijmy Łukaszu od linków. Co wykopałeś?
ŁK: Jest jedna rzecz: JavaScript , a raczej TypeScript , czyli Deno. Dostał realise 1.0. Czym jest Deno? Jest to następca Node.js. Jest to silnik, serwer Site, który jest napisany przez twórcę Node.js'a. Tak naprawdę ma on zamknąć te wady, do których doszło w Node.js. Ma również działać natywnie z TypeScript'em (teraz Node.js tego nie robi). Więc jest to bardzo ciekawy ruch.
SW: To wszystko będzie automatycznie tłumaczone do WebAssembly czy on to będzie domyślnie interpretował?
ŁK: Jeszcze nie wchodziłem w szczegóły, jaki Deno dokładnie ma być. Najbardziej zaintrygowało mnie to, że to będzie TypeScript. Po pierwsze: TypeScript będzie używany jako natywny (domyślny) język, a po drugie: okazało się, że twórca Node'a, „wziął zabawki i poszedł do innej piaskownicy".
SW: Tak, to może być ciekawe.
ŁK: Zainteresowało mnie to dlatego, że teraz WebAssembly stał się kolejnym następcą języka skryptowego dla JavaScriptu. Przecież teraz Envoy zaczyna pozwalać na wstrzykiwanie kawałków WebAssembly. Prawdopodobnie to będzie API Gateway z logiką. Bardzo ciekawy ruch.
SW: Z drugiej strony ma to być WebAssembly. Kiedyś dawaliśmy nawet link o tym, że można odpalić WebAssembly na Kubernetesie. To wszystko, co jest związane z WebAssembly podąża w ciekawym kierunku. To do kodu biznesowego może być naprawdę ciekawą rzeczą. Nie tylko samo Deno, ale w ogóle całe WebAssembly. A Deno… ponoć jest trochę szybszy od Node'a. Więc w niektórych scenariuszach, może nagle zagości serwer lessie.
ŁK: Bardzo możliwe. Szczególnie przy większych projektach to faktycznie może mieć sens.
SW : Kompilowanie, nie oszukujmy się, oszczędza trochę problemów.
ŁK : A Ty co masz?
SW: Ja mam dość ciekawy blog: pragmatic engineer. Wpis się nazywa: surprising things about working at tech unicorns. O co w nim chodzi? To jest wpis, który dla niektórych jest kubłem zimnej wody i otrzeźwienia. Przeczytamy w nim o tym, co się dzieje w dużych firmach i jak na to patrzymy. Często przeglądamy blogi technologiczne, Twittera, Netflixa i jeszcze parę innych, i widzimy jak w tych organizacjach jest wspaniale i tak dalej. A to jest wpis opowiadający o tym, jak to wygląda poza elementami marketingu. Bo nie oszukujmy się – te blogi są elementami marketingu i promocji. Pragmatic engineer pokazuje ciekawe przykłady, jaki wewnątrz firmy może być „pierdolnik". Na przykład Skype: przez bardzo, bardzo wiele lat był wydawany waterfallem, a procedury wydawania kolejnych wersji Skype'a trwały kilka miesięcy. W dodatku nie miał przeprowadzonego żadnego testu automatycznego – był testowany całkowicie manualnie przez całą armię testerów manualnych. Wpis pokazuje również kwestie, które widzimy w zewnętrznych wersjach firm (np. widoczność zmian kulturowych na przykładzie Ubera). Przeczytamy też o tym, co się dzieje, jeżeli chodzi o sukces firm. Podsumowując: ciekawy wpis, fajnie napisany, który pokazuje, jaki jest kolor korporacyjnej trawy po drugiej stronie. Że ona nie jest tak bardzo zielona, jak mogłoby się z zewnątrz wydawać.
ŁK : Jak popatrzysz na wpis, to już same nagłówki są wartościowe – podzielony jest na 13 punktów. Także wartościowe jest już nawet samo przeczytanie nagłówków. A sama treść jest bardzo fajnym wsadem merytorycznym – nie tylko przykładem, który pokazuje rzeczy wokoło (że nie wszystko jest tak różowe, jakby się mogło wydawać).
SW : Wszędzie jest taśma i wszystko jest w duct type. Lecimy do głównego tematu, czyli już trochę regularnego z serii odcinków à propos oczywiście Technology Radar od ThoughtWorks.
SW : Łukaszu, jak się dzieli Technology Radar?
ŁK : W Technology Radar mamy:
SW : Każda z tych grup jest podzielona na 4 poziomy. Każda technologia, właściwie każdy wpis, jest podzielony na 4 etapy dojrzałości ThoughtWorks'a. Oczywiście są one fajnie skontrowane przez Grega Janga. Wpis pewnie gdzieś dorzucimy, chociaż już raz był w linkach.
Najbardziej dojrzałą wewnętrzną fazą dojrzałości jest Adopt. To jest takie ThoughtWorks'owe: bierz, używaj i niech wszystko pójdzie dobrze.
ŁK : Dodajmy jedno: ThoughtWorks robi ten raport na postawie swoich doświadczeń. Uwzględnia w nim: to, co robi u klientów (projekty, doradztwo i inne rzeczy), to, co się dzieje na rynku oraz swój reaserch, który jest robiony wewnętrznie. Starają się ten cały świat techniczny wziąć i połączyć w jeden raport.
SW: Cieszy mnie, że dodałeś to, że właśnie oni (bo to jest ważna uwaga), patrzą co się dzieje u klientów. Bo ten radar jest mocno kliencki. Są w nim powroty do paru rzeczy.
Jest Adopt wewnętrzny, w sensie: bierz, używaj, wszystko jest w porządku. Trial , który oznacza: powinieneś spróbować, zrobić porządniejszego poc-a (proof of concept).
ŁK : Trial to już jest pilot, bo to nie jest już nawet reaserch. Możesz użyć na zasadzie: możesz spróbować tego użyć, ale ze świadomością, że się będziesz musiał wycofać.
SW: Tak, słuszna uwaga. Assess , który oznacza: zobacz czy ten klocek w ogóle pasuje do tej układanki. Przejrzyj dokumentacje. Zrób prostego poc-a. Zobacz, przejrzyj, przerzuć logi. Dalej jest zewnętrzna faza:Hold , w sensie: nie używaj. Co jest ważne: technologie i wszystkie wpisy mogą przemieszczać się od Holda do Adopta, ale także mogą przejść od Adopta do Holda. Nie muszą iść każdymi obszarami, mogą się przesuwać dowolnie.
ŁK : Czyli przy Holdzie lepiej danego programu czy danej funkcjonalności nie używać. Przynajmniej w większości przypadków.
SW : Tak. Przy Adoptcie czasami warto jeszcze sprawdzić.
ŁK : W Adopt myślimy, a w Holdzie można się posłuchać i powstrzymać od użycia.
SW: Co Łukaszu wygrzebałeś?
ŁK :Zero trust architecture. Marketingowo jest coś takiego jak: zero trust network. Jest to cały zbiór marketingowych podejść, gdzie duzi dostawcy mają już bardzo podobny kierunek, jeżeli chodzi o zero trust network. A zero trust architecture jest jego rozwinięciem i tak naprawdę jest projektowaniem usług w ten sposób, żeby nie ufać niczemu, co jest wokół, nawet w ramach tego samego systemu. W dużym uproszczeniu. Oznacza to, że wszędzie narzucamy filozofię restrykcyjnych standardów. Jest to po prostu bezpieczne projektowanie i budowanie z założeniem „niezaufanego środowiska". Takie podejście obecnie jest dla nas standardem. W szczególności, teraz kiedy dochodzą wszystkie kwestie regulacyjne, jak GDPR i inne, a także wszystkie standardy bezpieczeństwa i prywatności, które ma dział compliance i coś nam narzucają. Takie podejście pozwala nam być zgodnym, prawie że od pierwszego dnia, w którym aplikacja działa (oczywiście jeżeli projektujemy aplikację, w której wszystko jest niezaufane).
SW: Mnie się wydaje, że to był konieczny ruch, w kontekście architektury mikroserwisowej, albo w której więcej osób ze sobą rozmawia. W takich sytuacjach nie ogarniemy już kto jest mniej lub bardziej zaufany. Musimy po prostu pójść po ZTA.
ŁK : Tak. Teraz trzeba bardziej popatrzeć na ten proces, jak na wycieczkę: rzecz, którą budujemy w strategii organizacji, niż że będziemy robić tylko w jednym systemie. To dotyczy już całej organizacji. Oczywiście możemy stosować te praktyki w projekcie, ale jeżeli mówimy o takim ZTA, to jest to bardziej pieśń czegoś większego po prostu strategicznego podejścia.
SW : Tak. Po prostu nagle widzimy, że wszystkie systemy będą się ze sobą integrowały i podchodzimy do tego z założeniem, że nie wiemy, czy to będzie integrator zewnętrzny, czy wewnętrzny.
ŁK: Drugą ciekawostką, którą dorzucę, a której nie chcę omawiać, a jedynie o niej wspomnieć jest zdecentralizowana tożsamość. Decentralized identity , o którym Tomek Onyszko wspominał na Live'ie. Prace nad tym trwają i w raporcie również się pojawiło to w Assess.
SW: Mam jeden wpis, który ucieszył mnie, że jest na Holdzie. Chodzi o Cloud lift and shift. Jest to proste podejście, w ramach którego przenosimy wirtualki z on-prema do Clouda. Wreszcie podejście, o którym się mówiło przez wiele lat, dostawcy chmur zrobili, że można z niego skorzystać. Już nie jest ono zalecane. Wiadomo, że można jeszcze je robić, ale w raporcie nie polecają. Jednak działania idą w kierunku robienia replatform oraz żeby przechodzić na hasła. I to bardzo mnie ucieszyło, ponieważ można zarządzać tysiącami wirtualek w chmurze, jednak nie ma to żadnych wartości.
ŁK : Mam wrażenie, że Cloud lift and shift jest maszynką do zarabiania pieniędzy dla ekosystemu, a nie dla klientów. To jest moje prywatne wrażenie, które wiążę z marketingiem.
SW : Przy ogromie skali organizacji to był konieczny krok. Fajnie, że teraz zaczynamy robić to inaczej.
Moje ogólne wrażenie o Techniques jest takie, że Adopt jest jakby 2-3 lata w plecy. Rzuciło mi się w oczy, że Infrastructure as code, który pojawił się już w 2011, potem w 2012, a teraz w 2020 roku. Czyli teraz właściwie wrócił. Przypominamy o nim.
Kolejny punkt: Micro frontends już jest tam od roku. Pipelines as code coś, o czym wiemy, czyli nasz CICD powinien być w formie kodu, a nie być klikany z interfejsu. Pojawił się już w 2016, w 2017, a potem w 2020, czyli znowu wrócił.
ŁK : Możliwe, że większość narzędzi na rynku pozwala już to zrobić bez problemów. Może dlatego wrócił.
Dorzucę jeszcze jeden punkt z Holda: używanie lock agregation dla analityki biznesowej. Wcześniej jakoś mi się to nie rzuciło w oczy, ale jest genialne. Widziałem dużo projektów, które się na tym wyłożyło. To jest genialne. I pada przykład Splunk. Widziałem wdrożenia Splunk, gdzie z logów technicznych aplikacyjnych próbuje się zrobić w niektórych miejscach logikę biznesową.
SW : Albo audyt.
ŁK : Tak, dokładnie. Więc to jest dość ciekawe, ze w raporcie jest na Hold. Z jednej strony nie będę tego negował, bo czasami się pojawia w szczególności na początkowych stadiach, jak ktoś robi biznes internetowy. Tam, gdzie masz logi transakcyjne, raczej masz logi z komunikacji z http i innych rzeczy, bo czasami jest to obróbka po tym, jak są zbudowane url-e, host-y czy po tym, skąd wchodzi jakaś sesja. To potrafi być przydatne, bo zazwyczaj później w dojrzałych rozwiązaniach, logi z nginx czy innych rzeczy, http streamuje się w całe flow i buduje się pipeline'y. Czyli na początku może się okazać, że to będzie dobra analityka. Więc na starcie może to nie jest złe, ale w dojrzałych rzeczach albo czysto biznesowych projektach, to jest bardzo złe podejście.
SW : Mamy jeszcze jedną rzecz, co do której się zgodziliśmy, że bardzo fajnie, że się pojawiła. Applying product management to internal platforms. To oznacza, żeby podchodzić do projektów wewnętrznych (a szczególnie do platform), jak do zwykłych produktów. Czyli żeby miały marketing wewnętrzny, żeby miały dokumentację, żeby miały przykłady, żebyśmy my, jako ludzie wytwarzający i konsumujący traktowali je jako normalne produkty. I to jest bardzo, bardzo ważne.
ŁK: Tak, to jest sztuka. Trzeba do tego dojrzeć. To nie jest prosta rzecz, bo taki product managment kosztuje. Ale później daje boost'a.
SW : I nigdy nie widać zwrotów zrobienia wewnętrznej reklamy do wewnętrznego marketingu. To jest element uświadamiania i jest naprawdę bardzo ważny.
ŁK: Tak dużo potrafi pomóc.
ŁK: Co Szymonie wybrałeś w Toolsach?
SW : Oczywiście Jaeger. Zdziwiło mnie to, że dopiero w 2018 roku pojawił się w Assess. Nawet o tym rozmawialiśmy swego czasu. Teraz się pojawił w Trialu. Dla mnie powinien już być w Adopt, bo to już jest tak naprawdę standard. Tym bardziej, że o observability mówi się już sporo. Przy jakichkolwiek systemach rozproszonych to jest konieczność.
Z rzeczy mniej poważnych, ale przydatnych to jest K9S , który pojawił się w Trialu. Co to jest? To odczyt z Kuberentesa i przeglądanie Kuberentesa w klastrach w formie interfejsu Norton Commandera.
ŁK: Czyli to jest TUI: text user interfejs.
SW : Tak. I o ile QPST jest bardzo fajny do aplikowania czy debugowania, to naprawdę ułatwieniem jego odczytywania jest wypisywanie tego w formie sensownej tabelki. To fajnie wygląda i ja tego używam.
ŁK: K9S-a znam już od jakiegoś czasu. Na konsultacjach bardzo często spotykam się, że ktoś chce jakieś GUI przeglądarkowe. To są dwie zabawki:Oktan i Lens. Lens jest wymieniony w Assess. Natomiast Oktan to open source od VMware, który odpalamy u siebie na stacji serwer http w postaci jednej binarki, z całą apką do przeglądania, więc nie trzeba rozwiązywać problemów security i innych z dostępem do Kubertenea. Tak samo zresztą, jak na K9S-ie. Jeżeli ktoś chce mieć user interface z prawdziwego zdarzenia, to Oktan jest przeglądarkowy.
SW : Dla mnie plusem K9S-a jest to, że jest całkowicie w konsoli.
ŁK : Ja zostanę przy QPST. Jeśli ktoś, kto nie jest z IT patrzy w mój monitor i na to co robię, to śmieję się, że to jest super moc.
SW: Tak, to się zgadza. QPST jest bardzo potężny i jest fajny. Łukaszu, a co Ty wygrzebałeś?
ŁK : Dobra. Znowu Kubernetes. W Adopt w wielu miejscach króluje frontend, a dodatkowe narzędzia są jedynie dodatkiem. Pierwsza rzecz to nie do końca Kubernetes, ale aktualnie jest on głównym odbiorcą. Open Policy Agent (OPA), czyli tak naprawdę kawałek zabawki, który można wpinać i wbudować polityki restowe z całym językiem zapytań. W Kubernetesie służy do pilnowania tego, co on robi, tego co mu zlecamy do zrobienia. Tamta implementacja się nazywa Gate keeper. Tak naprawdę Open Policy Agent można wziąć i zaimplementować u siebie. Możemy go sobie wstrzyknąć, wysłać mu request aplikacyjny (restowy), który chcemy sprawdzić czy jest zgodny, czy nie. Dajemy mu wsad w postaci tak zwanej regopolisy, czyli opisu tego, co w jakich przypadkach ma taki request zawierać. Możemy zwrócić informację czy jest poprawny, czy nie. Czyli jest to cały gotowy silnik do walidacji requestów.
SW : Ok, w tym momencie mówisz o requestach. Ale requesty na poziomie Kubernetesa to requesty konfiguracyjne, ale też aplikacyjne. I to się zalicza do…?
ŁK : Jak zlecamy konfigurację to w Kubernetesie do konfiguracyjnych. Tak naprawdę możemy tu wpakować również nasz request aplikacyjny. Bo sam Open Policy Agent jest rzeczą zewnętrzną.
SW : Czyli de facto wchodzimy w takie Policy, które widzimy w Azure albo w dowolnej innej chmurze.
ŁK : Dokładnie to samo. Chodzi o to, że można to u siebie zaimplementować, bo to jest po prostu tylko wysyłanie requesta i napisanie polityk. Więc można to zrobić nawet swojej apce, która nie jest już managmentowa, tylko jest biznesowa. W ten sposób można pilnować requestów, jeżeli pozwalamy na więcej jakichś dowolności, elastyczności.
Kolejna rzecz:Kind. Kubernetes indooker, czyli jeżeli ktoś się uczy Kubernetesa, testuje (ja często tego używam już od półtora roku), to pozwala to mu odpalić klaster Kubernetesa na Dockerach, załadować pluginy sieciowe i inne zabawki i mieć lokalnie na stacji wielo Node'owy klasterster bez wirtualek.
SW: To jest bardzo przyjemne
ŁK : Tak i teraz będzie się integrować z nowym WSSlem 2 oraz z innymi rzeczami. Zaczyna to fajnie wyglądać. I dorzuciłbym (jako ciekawostkę) jedną rzecz, która mi się teraz rzuciła w oczy w Trialu:Visual Studio Liveshare się pojawił w Toolach.
SW : Nie zwróciłem uwagi.
ŁK : W Toolach pojawił się Visual Studio Liveshare, który jest pokazany razem z Visual Studio Code. Dla tych, co nie wiedzą – Visual Studio Code ma możliwość sharowania sesji. Teraz Microsoft dodaje do tego jeszcze głos. Dzięki temu możemy wysharować połączenie do naszego Visual Studio albo Visual Studio Code i mieć przekierowanie portów do tej osoby, która nam sharuje swoją sesję. Mieć wjazd do debuggera, do edycji kodów i można zrobić wtedy remote debugging, remote code, kodowanie w parach (pair coding – pair programming). Można to zrobić wraz z głosem i innymi rzeczami. Najlepsze jest to, że Visual Studio Code może się podpiąć do sesji np. na zwykłym Windowsie do Visual Studio pełnego i zobaczyć normalnie debuggera i inne rzeczy. Więc ja, jako użytkownik MACa, mogę się podpiąć do osoby, która ma Visual Studio i te wszystkie rzeczy zobaczyć. Jeżeli nie mieliście okazji z tego korzystać i korzystacie z Clouda, to to rozwiązanie jest genialną rzeczą.
SW : To się przydaje na szkoleniach. Jednak zdziwiło mnie. Możliwe, że wpłynęła na to sytuacja związana z Koronawirusem i wymuszoną pracą zdalną. Nie mniej – ciekawe.
ŁK : Dlatego właśnie dorzuciłem to jako ciekawostkę. Dopiero teraz rzuciło mi się to w oczy, bo wcześniej nie patrzyłem na to w ten sposób.
SW: Lecimy do platform. Co ciekawego tu znajdziemy? .NET Core po raz kolejny jest w Adopt. Najpierw był w 2018 roku, teraz pojawił się znowu w 2020 roku. To jakoś nikogo nie dziwi, ale to, co jest fajne: pokazuje dojrzałość platformy. Zdziwiło nas trochę to, że Istio się pojawiło w Adopt. Ostatnio nadrobiłem trochę zaległości podcastowych i muszę powiedzieć, że w podcastach słychać, że mocniejszy push Istio w to, żeby być bardziej widocznym i żeby pokazać, że jesteśmy dojrzali i tak dalej.
ŁK : Z drugiej strony, jakie były Twoje wrażenia po release monolitycznym w Istio, jak pierwszy raz je odpaliłeś?
SW : Moje wrażenia (po wersji 1.5) są takie, że tam po prostu jest to nieaktualne. Dokumentacja (którą uporządkowali) jest mocno w plecy. Ten ruch jest dość ciekawy i ukierunkowany na to, żeby operator miał łatwiejsze życie, a zarządzanie całym Istio było łatwiejsze. Jednak znalezienie czegoś konkretnego w dokumentacji nadal kuleje. Plus za sample, które są już w porządku.
ŁK : Ostatnio nie patrzyłem na Istio, jednak jestem ciekaw, czy uporządkowali kwestie dokumentacyjne. Jak to teraz u nich wygląda: czy coś się zmieniło, czy nie.
SW : Jak patrzyłem jakieś 2 miesiące temu czy posprzątali, to na tamten moment wybitnie nie.
ŁK : Może się zmieniło teraz – diabli go wiedzą.
SW : Ciekawe jest, że w Trialu pojawił się OpenTelemetry. Fajnie, że się pojawiło, chociaż zdziwiło mnie, że dopiero w Trialu. Pierwszy raz pojawił się w 2017 roku również w Trialu. Teraz się przypomnieli w 2020 roku. To oczywiście jest cały mechanizm, na którym polega, i z którym zgodny jest Jagger. Według mnie to powinno być w Adopt. Nie wyobrażam sobie sytuacji, w której mamy system, który jest większy i nie mamy traisingu czy nie mamy OpenTelemetry. Ostatnia rzecz, którą dorzucę, bo jest ciekawa, to Node overload , który się pojawił. Co to znaczy?
ŁK : Tak, nazwa jest dziwna. Właśnie – powiedz, co ona oznacza.
SW : O co chodzi? Chodzi o to, że ThoughtWorks zwraca uwagę na to, że może nie powinniśmy używać tego samego języka do budowania absolutnie wszystkiego. ThoughtWorks powiedział jasno: za dużo Node-a, zacznijcie używać innych języków programowania, tam, gdzie to ma sens. Czyli wracamy do poliglote programming, czyli znajomości wielu języków, bo Node, jak się okazuje, nie jest idealnym językiem do wszystkiego.
ŁK : Właśnie myślałem, że Node overload to będzie przeładowanie. Że niektórzy zaczęli za bardzo naciskać na high the city, a to się okazało, że dotyczy poliglotów. Ostatnio odpaliłem sobie z ciekawości Pythona 3 na serwer lessie i powiem, że jestem bardzo miło zaskoczony. Dobrze klei w niektórych miejscach, łatwiej się robi klej „integracyjny", restowy niż w Node'zie.
SW : Python jest ciekawie zrobiony, jeśli się przestawisz na jego składnię.
ŁK : Może inaczej. Ja mam definicje. Zaakceptowałem ctrl flow wcięciami przez jable. Przez co, że z tymi jablami tyle się pracuje. To może dlatego teraz mi nie było tak ciężko do tego podejść.
SW : Akurat wcięcia tam bardzo lubię. Zgadza się. Moje „ale" do Pythona, jeżeli chodzi o serwer lessy jest takie, że dużo więcej przykładów, dużo więcej gotowego kodu jest w NODzie. Ale może to się zmieni. Łukaszu, co ty wygrzebałeś?
ŁK : Teraz znowu Kubernetes. Nuda. Mam nadzieję, że kiedyś to ubijemy i wyrzucimy. Argo CD , czyli natywne podejście do deploymentu, które jest zbudowane w takiej właśnie modle, która się stara nam pracować na design state configuration i natywnie integruje się z Kubernetesem. To tak naprawdę jest implementacja techniki GitOpsowej. Czyli zarządzaniem całą konfiguracją przez Git. Jest on takim źródłem prawdy. Ciekawe jest to, że Argo CD ponieważ pod spodem korzysta z GitOpsa, to uwspólniają się z drugą konkurencją, czyli Fluks CD. Uwspólniają silnik pod spodem. Z Fluks mają dwa różne kierunki, ale zaczynają budować pod spodem wspólne komponenty, które będą działały razem. Fajne. Takie Argo można władować na jeden claster, na drugi… bardzo ładnie da się go skonfigurować i zrobić. W świecie Kubernetesowym może to być banalnie prosty. To, co ważne: nie jest to CI. Nawet w nazwie produktu jest: Argo CD. Jest on na Trialu, czyli dość wysoko w tym podejściu.
SW : Cieszy mnie bardzo mocno, że Kubernetes wszedł już w ruch GitOpsowy. Czyli, że mamy konfiguracje i de facto całym środowiskiem, clastrem zarządzasz przez Jample, które są w repo. Że odchodzimy…
ŁK : ….albo są generowane na podstawie tego, co jest w repo dynamicznie, bo to jest też…
SW : … też tak może być. Chodzi o to, że nie robimy w Kubernetesie dużo przykładów na starcie, tylko że lecimy kubectl i tworzymy sobie ręcznie wszystkie kody i tak dalej.
ŁK : Wiesz o tym, że dla wielu jest to czytelne podejście imperatywne?
SW : Zgadza się. Tylko że to jest nie do utrzymania na dłuższą metę. Cieszy mnie, że ten ruch GitOpsowy wchodzi bardzo mocno.
ŁK : Z ciekawostek… SnowFlake , który jest w Trialu. To jest taka platforma SASowa do data, która jest bardzo wydajna. Jeśli patrzymy na koniec dnia to jest względnie tania, względem tego, co oferuje. Cena fischera i cena za GB też już jest względnie tania i bardzo mocno się nią wybijają. To stoi na AWS-ie i Azurze, jako SaaS, więc jest to duża ciekawostka.
SW : Dużo słychać o SnowFlake'u. Przeglądając blogi czy przeglądając wpisy podcastów, to głośno się o nim zrobiło ostatnio.
ŁK : W data, tak. Jest to dużo ludzi z analityki, którzy to robili na Googlu, Microsofcie czy AWS-ie. Dużo osób tego dotyka i dobrze to widać marketingowo. W pewnym momencie zaatakowali tym cały świat jako system partnerski. Wszyscy równocześnie, stąd to widać. Zobaczymy, co zrobi Microsoft, bo zapowiedział już upublicznienie swojej platformy Synaps w Azurze. Będzie do niej publiczny dostęp, więc zobaczymy, jak to się poukłada. Dużo klientów Microsoftowych, których jest na Azurze używa SnowFlake'a, który też jest postawiony na Azurze. I te dane są jakby lokalnie w ramach regionu, mimo że jedno jest SASowe, a drugie w naszych subskrypcjach. Więc ciekawa układanka się będzie budować.
SW : Microsoft i tak, i tak wygrał w tej sytuacji. Bo czy platformy i firemki będą hostowały ich system czy snowflake'a, to kasa i tak się będzie zgadzała.
ŁK: O tak. Powiedzmy sobie wprost: na kliencie, który użyje synapsa zarobią więcej. Jednak jeżeli będzie to SnowFlake, to też zarobią. Ważne, tylko żeby to był SnowFlake w Azurze.
SW : Dokładnie.
SW : Co wygrzebałeś?
ŁK : Powinniśmy zacząć od tego, że jest za dużo frontendów.
SW : Powiedziałbym, że to jest prawie sam frontend. Jest bardzo mało rzeczy nie frontendowych. No i jest tam PyTorch'a.
ŁK : Czyli tak naprawdę jest frontend i odrobina emela.
SW : Tak, odrobina emela i jakieś testowanie. Wygrzebałem coś, co już w pierwszym nagraniu o Technology Radarze robiliśmy. Karate , który teraz wskoczył do Triala do testowania. Powoli idzie sobie do góry. Obecnie jest do testowania ogólnie, do testowania API, więc można sprawdzić. Dla mnie było plusem, że można dobrze opisać testowanie swojego API testowego i wrzucić to w czytelnym formacie do repo. To dla mnie był duży plus, jeżeli ktoś chce robić testy integracyjne. W przeciwieństwie do tego, jak gadaliśmy o Postmanie i jego hakach, które ma.
ŁK : Tak. Z Postmanem ostatnio mam coraz więcej do czynienia. Muszę powiedzieć, że pomimo tego, że trochę rzeczy pozmieniali, to przy większej skali bywa problematyczny. Nie oszukujmy się – trzeba będzie pójść w wersję płatną. Ciężko wybrać coś, co nie jest frontendowe, ale jest ciekawa rzecz:GraphQL Inspector. Co to jest? Opis jest dość ciekawy: lets you compare changes between two GraphQL schemas. Czyli: GraphQL dorasta do tego, że jednak wersjonowanie jest dobrym pomysłem.
SW : Albo przynajmniej sprawdzanie, co się zmienia.
ŁK : Tak. Coś, co generalnie jak robiliśmy opis o GraphQL-u i ApiGraphQL-u to się zwróci uwagę, że ona tam po prostu nie ma jak wcisnąć właściwie wersonowania. I w tym przypadku restowa api zdecydowanie wygrywa. A nagle, ktoś dochodzi do wniosku, że jednak: no kurcze, ten schemat się będzie zmieniał. Więc to jest ciekawe. Z rzeczy nie frontendowych, mogę powiedzieć, że Rust wszedł dość głęboko. Zdziwiło mnie w nim to, że Rust bardzo powoli idzie w kierunku tego, żeby zastąpić głównie C++.
SW : Ja bym powiedział, że chce zastąpić C++. To nie będzie język mainstreamowy. Bo w teorii trochę osób chciałoby, aby Rust był językiem mainstreamowym. Jakoś nadal go sobie takiego nie wyobrażam.
ŁK : Wydaje mi się, że tak samo jak C++ generalnie nie będzie. Już nie stał się mainstreamowy. Spadł dość nisko. Teraz będzie powoli ten mały obszar rynku zajmował. Co jest ciekawe: ma wsparcie od dużych prowiderów: MS zrobił commitent, co sprawia, że będzie go wspierał i rozwijał.
SW : Z drugiej strony ma go na bazie. Z drugiej strony jestem ciekawy, bo chyba Microsoft Reaserch ostatnio robił jakiś reaserche na temat tego, co można zrobić na bazie Rusta. Na zasadzie: jak go rozwinąć po microsoftowemu. Zobaczymy czy będzie tak, jak z NODEm czy PayScriptem, czyli że mogą albo zakselerować, albo zrobić coś swojego. Wydaje mi się, że raczej będą komitować do Rusta niż robić coś swojego (patrząc na ich ogólne podejście).
SW: Microsoft reaserch jest teraz bardzo ciekawym działem i ciekawe rzeczy z niego wychodzą. Więc trzeba obserwować – zdecydowanie.
ŁK : Tak. Jednak dla mnie Rust nie przejdzie do mainstreamu, tak jak Golang. Bo zobacz, że o Golandu dużo osób wie, ale on jest kiedy potrzebujesz tanim kosztem uzyskać dużo wydajności. A Rust, moim zdaniem, teraz bardziej idzie tam, gdzie teraz potrzebne jest bezpieczeństwo i wydajność w jednym miejscu.
SW : Tak. To będzie lepszy C++. Może za lat 30 go zastąpi, chociaż C++ się wziął bardzo i zaczął ostatnio się bardzo mocno rozwijać.
ŁK : Ale on się mocno rozwija. Można powiedzieć, że odstaje jedynie w naszej mentalności. W rzeczywistości jest tam już dużo zaawansowanych technik, o których nikomu się nie chce myśleć.
SW : Tak, zgadza się. Dobra, to powoli kończymy ten odcinek. I jak wrażenia a propos tego Technology Radar, Łukaszu?
ŁK : Mam wrażenie, że jest taki spokojno-covidowy. Mimo, że jest dużo nowości, to jest taki spokojno-kovidowy.
SW : Dla mnie jest taką przypominajką, na zasadzie: „ej chłopaki pamiętacie? Mówiliśmy o tym 2 lata temu, to to jest dalej aktualne". Jest dużo rzeczy, które już kiedyś w raporcie się pojawiły.
ŁK : Tak. A że we frontendzie jest dużo ruchu w językach frameworkach – to normalne w tym świecie.
SW : W zupełności normalne. Dobra, to kończymy w takim razie. Dzięki!
ŁK : Dzięki, na razie.