Szymon wrócił z urlopu i robimy przegląd Technology Radar vol. 21.
Ciekawe linki i inne znaleziska z tego odcinka:
Odcinek znajdziesz na:
Ł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/15. To o czym dzisiaj będzie?
ŁK: W międzyczasie jak się urlopowałeś, wyszedł Technology Radar edycja 21. No i zrobimy review.
SW : Przydałoby się, bo jest ciekawy. Inny niż poprzedni.
ŁK: Przejdźmy może do linków.
SW: Tak, linki. To ja zacznę (prawo tego, kogo dawno nie było). Z mojej strony: ciekawa seria na infoQ à propos testowania mikroserwisów. 3 artykuły są całkiem nieźle ujęte. I wszystko byłoby ok, gdyby nie to, że przeglądając cały wpis z tyłu głowy kołacze mi się, że wszystko fajnie, ale to jest powtórka tego, co widzieliśmy już w systemach rozproszonych. To jest ujęte w książce, o której rozmawialiśmy: Enterprise Integration Patterns, która nie jest idealna.
ŁK: Tak i to jest bardzo ważne. Książka była tworzona dla prawdziwego SOA, ciężkiego ESB i możemy ją przeczytać, ale w dzisiejszym świecie trzeba do niej podchodzić bardzo zdroworozsądkowo.
SW: Tak. Jak najbardziej – trzeba umieć wyciąć z niej pewne rzeczy. Tam w kontekście mamy do czynienia z szyną (inną szyną), więc nie należy łączyć tych dwóch rzeczy. Ta powtarzalność (szczególnie wzorców projektowych) i ich reodkrywanie, i reimplementacja mnie osobiście trochę zmartwiła. I tyle. Jednak artykuł faktycznie warty jest przeczytania. Jest całkiem nieźle napisany. Będzie oczywiście w linkach. Co u Ciebie?
ŁK: U mnie teraz był re:invent. I jak zawsze kupa usług jest od Amazona, AWS-a, kupa usług holdowych. Jest jedna usługa, która mi szczególnie przypadła do gustu i jest najciekawsza. Być może będziemy widzieli, że firmy się na nią rzucą: AWS' CodeGuru.
SW: O… tak, tak.
ŁK: CodeGuru, czyli AWS' robi coś, co myślałem, że szybciej zrobi Microsoft po zakupie GitHuba.
SW : Też o tym myślałem. Tylko że oni taki produkt już mieli.
ŁK: Tak, ale czym jest CodeGuru? CodeGuru jest to usługa do automatycznego code review za pomocą machine learningu. Czyli chwalą się, że na bazie mają 1000 projektów – swoje wewnętrzne szkolili – i że przy pull requestach maszyna robi code review naszego kodu, który mógłby być lepiej zrobiony. Więc jestem ciekawy efektu. Cena do indywidualnego użytku zabija, o czym Szymon mnie już uświadomił.
SW : Zabija. 75 centów za 100 linii na miesiąc. To jest bardzo dużo.
ŁK: Więc zobaczymy, jak to będzie wyglądało w praktyce. Już teraz widzę, że takie typowe firmy korporacyjne (i ta wielka doradcza część) zaraz się na to prawdopodobnie rzucą…
SW : Na pewno.
ŁK : …w swoich projektach. Więc to jest ciekawe, bo zaczynamy wchodzić w coś, co może spowodować, że deweloperka ma być strasznie comodity.
SW : Znaczy, nie oszukujmy się. Rozmawialiśmy już wcześniej, że jesteśmy w podobnej sytuacji, jak byli ludzie, którzy budowali samochody Forda: wysoko wyszkoleni, drodzy i mało ich było na rynku. A potem wyszły roboty.
ŁK : Tak, tylko mówimy o budowie samochodu w momencie, jak zaczęły one powstawać.
SW : Tak, dokładnie. A to z czasem się zmieniało. Na pewno zmniejszenie kosztu developmentu jest złotym graalem bardzo wielu firm. Każdy biznes o tym marzy i myśli.
ŁK : Stąd wszystkie pomysły low code i inne.
SW : Tak. Czy CodeGuru będzie odpowiedzią, będzie miał jakąś szeroką adopcję?
ŁK : Diabli go wiedzą.
SW : Mnie się wydaje, że nie. Wydaje mi się, że ta cena zleci dosyć szybko.
ŁK : Raczej otwiera furtkę. O tak, bo ja już widziałem pewne startupy, które mają za zadanie akcelerować, czyli robić turboprogramistę. Z seniora będzie sam. Z machine learning dam mu dwóch juniorów, zamiast męczyć się z nimi. Więc jest to ciekawy kierunek.
SW : Tak, to też pewne. To, co powiedziałeś – to nie jest pierwsza firma, która się zmierzyła z takim podejściem. Takie narzędzia do poprawy jakości kodu są chyba od zawsze, odkąd programujemy.
ŁK : Tak. Tylko teraz zaczyna być to ciekawe, bo mamy czym je wyszkolić.
SW : Tak. Dokładnie. Teraz mamy wiedzę, jak i gdzie to zrobić, i mamy jakieś konkretne podejście.
ŁK : Boję się, że dla PHP-a nauczyli go WordPressem.
SW : O, tak może być. Dobra, główny temat.
ŁK : Zrobimy sobie review 21. Technology Radara.
SW : Wróćmy do tego, że mieliśmy już review poprzedniego Technology Radara w odcinku 4 i 5, bo nam się rozbiło na 2 dość długie odcinki. To był też zupełnie inny Technology Radar. W tym wydaje mi się, że zmieścimy się w 1 odcinku.
ŁK : Tak. Zmieniamy troszeczkę formułę. Co ważne, nie będziemy tłumaczyć wszystkich pojęć (nie będziemy teraz tłumaczyć czym są obszary, pojęcia). Jeżeli jesteś ciekawy, to wróć do odcinka 4, bądź do PDF-a od Technology Radar, w którym wyjaśniają, czym jest dany status i dana…
SW : Grupa.
ŁK : … grupa, tak. Kwadrat.
SW : Dobra. To zacznijmy od Techniqs. To Twój pierwszy obszar, o którym chciałeś powiedzieć.
ŁK : Tak. Czyli w Techniqs – bardzo ważne – nie ma dużego ruchu (jak i w ogóle w całym Technology Radarze). Praktycznie nic się nie pojawiło nowego. Za to było dużo ruchu pomiędzy Adopt, Trial i trochę Holdów.
SW : Ja bym to rozszerzył. Bardzo mało rzeczy, jakieś 5%, jest na tym samym miejscu, na którym było. Co jest bardzo niezwykłe, bo poprzednia edycja była w miarę równa.
ŁK : No to zacznijmy. Pierwsza z technik będzie czymś ciekawym, czymś co powinniśmy robić już od dawna. Container security scanning. Czyli tak naprawdę, chodzi o to, żeby zacząć się interesować kontenerami (jeśli chodzi o security w całym procesie wytwarzania). Tutaj ma status Adopt, czyli żeby to robić. Na czym to polega? Na tym, żeby zacząć skanować kontener już od pull requestu. Czyli twój pull request nie przechodzi, jeżeli w procesie CI-owym zbudujemy, przetestujemy aplikację, ale również sprawdzamy, czy kontener nie ma podatności. Jeżeli ma podatność – nie można zmergować tego kodu i konfiguracji.
SW : Ja bym doszczegółowił: nie tylko twój kontener, ale również baza, z której dziedziczysz. To jest ważne.
ŁK : Tak, dlatego mówię: cało wyjściowy artefakt. Bo możesz doinstalowywać rzeczy z palca, jak i twoja baza może być zatruta, więc to jest to. Następnie statyczne skanowanie w repo: przykładowo raz dziennie lub raz w tygodniu skanujemy nasze obrazy statycznie. Oraz na sam koniec sprawdzamy, co realnie chodzi na naszych hostach. To jest taki end to end: Ja zawsze tak nazywam sprawdzenie jaki mamy poziom paranoi. Takim podstawowym poziomem paranoi jest przynajmniej CI, żeby w CI-u skanować. Drugi poziom to jest już repo. No i trzeci, ostateczny, to jest też skanowanie runtime, ale do tego trzeba troszeczkę dodatkowych tooli.
SW: Tak. Ja tu dorzucę, że nie tylko przy tej pozycji zaskoczyło nas to, że dopiero teraz pojawiła się ona w Radarze. Bo pokazaliśmy ją w kontekście skanowania. Tylko jest taka firma Snyk, która bardzo dużo skanuje. W zależności właśnie do Dockery i oni swoje raporty publikują już od jakiś 3 lat.
ŁK : Docker harp ma to od dawna.
SW : No właśnie. To jest coś, co…
ŁK : White też ma to od dawna. Więc tak, ale dopiero pojawiły się jako Adopt.
SW : To jest zaskakujące.
ŁK : To, że wreszcie znalazł się w tym obszarze będzie widać na rynku. W tym roku to się pojawiło jako adopcja. Firmy zaczynają o tym myśleć.
SW : Tak. I raczej powinny o tym myśleć, bo to będzie znaczyło, że weszło. Dobra. Teraz mój kawałek, czyli Micro frontends. O co chodzi? Jeżeli zbudujemy jakikolwiek system rozproszony i mamy wiele źródeł, które serwują swoje API, no to słabe będzie przenoszenie tych wzorców projektowych i w danym momencie stworzenie jednej monorepo pod nasz frontend. Co kiedyś, jak nie mieliśmy tylu bibliotek i tak dużo logiki po stronie frontendu, to jeszcze może miało sens. Na chwilę obecną ten frontend (jak widzimy po ogłoszeniach o pracę) specjalizuje się już dość mocno. Nie ma sensu tego wrzucać w jedno repo. W takim razie, w jaki sposób dzielić i organizować nisze frontendowe, które potem scalamy w jedną całość? Samo podejście jest też ciekawe. Mnie jednak znowu zmartwiło (czy zaciekawiło), ponieważ na konferencjach i na blogach często jesteśmy na etapie, żeby to robić. Jesteśmy na etapach: jak to robić dobrze i jak tego nie robić. Powiedziałbym, że jesteśmy na etapie lessons learned. Więc w samym kontekście adopcji – ciekawie, że się pojawiło. Jak najbardziej powinno to być adoptowane. Według mnie to powinno być już trochę wcześniej.
ŁK : Dorzucę od siebie, że już widziałem na rynku takie działające projekty. Na naszym polskim rynku. I widziałem wykorzystanie tego. No i w ogóle: po co micro frontends? On fajniej się sprawdza w dużych projektach, gdzie mamy wielu dostawców i bardzo rozdzielone funkcjonalności, a chcemy mieć wspólny frontend. Czyli często do wewnętrznych dużych kobył biznesowych.
SW : Tak. Albo po prostu, gdy za jednym frontendem ukrywamy bardzo wiele systemów. Realnie jest tak, że obecnie mamy system do każdej małej części. Więc jak najbardziej.
ŁK : I co ważne: jeżeli spojrzymy na dobre praktyki (jeżeli jesteście ciekawi), to można pożenić Angulara, Reacta w jednej aplikacji. Wymaga to narzucenia paru ram i ograniczeń, ale to działa.
SW : Działa. Jak najbardziej to działa. Już nie jesteśmy na etapie dzikiej adopcji: już wiemy, jak to w miarę dobrze robić. Ok. Kolejne.
ŁK : Kolejne. Pipelines for infrastructure as code. I tu jest kolejne moje zdziwienie, bo jest na statusie adopcji. Dla mnie od 3 lat jest to norma, którą robię z klientami. O co chodzi? O to, żeby infrastruktura była wdrażana z continues deploymentu, tak jak aplikacja. Zastanawiałem się, czemu to może być na Adopt. Doszedłem do wniosku, że dlatego, że na początku boli, jak dopiero zaczynamy z tym pracować.
SW : Bardzo boli.
ŁK : Boli. Potem, jak już nauczymy się kodować, nie wyobrażamy sobie już życia bez tego. No i mamy do tego sporo rozwiązań. Są Terraformy, Ansible, natywne rozwiązania: takie właśnie reaserch manager templates czy cloud formation. Więc to wszystko jest natywne. W szczególności dla części OPS-owej trzeba wprowadzić pojęcie idempotencji. Ta konfiguracja powinna być idempotentna. To jest też często problem dla ludzi, ponieważ byli przyzwyczajeni do imperatywnego trybu: że robią coś z palca, z poleceń i potem to żyje. No i druga sprawa: optymalizacja kosztów, która naprawdę robi tutaj robotę. W szczególności stawianie środowisk przy pull requestach…
SW : Tak. O tym mówiliśmy. W tym momencie bardzo przechodzisz do mojego kawałka. Zasadniczo to, z czym się bardzo mocno zgadzam: Run cost as architecture fitness function. O co chodzi? Chodzi o to, żeby jedną z miar oceny naszej architektury była kwestia kosztów, jakie ponosimy w chmurze. I to pokazuje, że w tym momencie, skoro patrzymy na koszty, zaczyna nam się opłacać robić takie rzeczy jak: pipelines for infrastructure as code. W krótkim rzucie to nie ma sensu, natomiast w długim zdecydowanie zaczyna go mieć. Dodam jeszcze tylko jedną rzecz: skoro jest taka potrzeba, znaczy, że firmy zauważyły, że koszt chmury zaczyna być widoczny. Że to nie jest już takie…
ŁK : Takie nieprzewidywalne. Bo to jest największy problem, przynajmniej z tymi serwerami w frontpremie. To często….
SW : To było do przewidzenia.
ŁK : Tak. Było przewidywalne – najwyżej brakło nam zasobu. Znaczy – nieprzewidywalny był brak zasobu. To zawsze jest. Cappasity zawsze leżało. Ale przynajmniej potem dokupienie tego, to: albo nie mieliśmy zasobów, albo dokupowaliśmy i był cały znany proces.
SW : Ale kontrolowaliśmy cenę.
ŁK : Mocno.
SW : Tak. A potem wszedł proces: generalnie wejdźmy wszyscy w chmurę, nieważne za ile, tylko żebyśmy byli. To już minęło. Teraz jest dobry hind. dla wszystkich, którzy zajmują się chmurą, albo którzy chcą wejść w chmurę. To już nie jest ten dziki zachód, który był wcześniej. I te wdrożenia muszą już być sensowne. To już musi być z głową. I bardzo mocno się podpisuję pod tym. Powinno to być brane pod uwagę.
ŁK : Tak, to jest jak najbardziej istotne. Ja to właśnie często wykorzystuję. Ostatnio nie miałem żadnych poważnych projektów z IoT. Ale na przykład: ile kosztuje nas cały system? cała ta chmura w kontekście urządzenia czy końcowego użytkownika? Tam były jeszcze pomysły na marżę, na przychód. Jest trochę takich czynników, które potem w Excelu wprowadzamy i zaczynamy z biznesem optymalizować koszty naszej infrastruktury. Bo mówią: tu się mieści, tu się nie mieści.
SW : Tak. To jest to samo, co robią księgowi od bardzo, bardzo wielu lat. Mówią, co na które konta, czyli co do której grupy nas kosztuje. To my będziemy musieli robić na pewno na chmurze, bo to zaczyna być coraz bardziej widoczny koszt dla organizacji. Dobra, Twój.
ŁK : Mój, czyli teraz znowu Continuous delivery , ale dla machine learningu. Jest on tutaj jako Trial, bo to dopiero zaczyna się taki machine learning OPS. Dopiero zaczynamy do niego dojrzewać i porządkować. Czyli o co chodzi? O to, żeby tak naprawdę całe machine learning, całe podejście (czyli projekt, budowę modeli, testowanie, dostarczanie ich) wreszcie opakować w porządną automatyzację, a nie tylko w stację pod biurkiem czy kawałek klastra w jakimś Cloudzie z DPU. I to liczenie po drodze. Więc zaczynamy porządkować machine learning do użycia produkcyjnego. Co ważne w tym starym, dzikim podejściu: odchodzimy od zipa na proda i dostajemy audytowalność, co w przypadku tych rozwiązań jest bardzo, bardzo istotne.
SW : Tak. To, co dla mnie jest dziwne, to jak prawie 2 lata temu prowadziłem zespół AI/ML, to w tamtym momencie jednym z naszych kroków było to, że robimy CICD. Pamiętasz, jak wtedy w podcastach (à propos AI/ML-ach) mówiło się o tym, że fajnie byłoby zacząć używać Git-a. I powinno się mieć dużo kursów, co widziałem po moich ludziach, właśnie kursów GIT-a dla ludzi od machine learningu. Widać, że techniki do repraktyki zaczęły powoli przeciekać.
ŁK : Tak, bo tam było trochę mniej znane tak naprawdę całe środowisko BI-owe (czy inne) przez bardzo długi czas. BI-e praktycznie do dzisiaj nie znają podejścia takiego cyklu automatyzacji.
SW: ** Mam wrażenie, że znają, ale udają, że nie znają. Da radę to wdrożyć. Robiliśmy to nie raz. Na końcu rzecz, która dobitnie pokazuje, że ten tech radar jest spojrzeniem wstecz o te pół roku, bo pojawił się **ten times engineer na Holdzie. W kontekście to będzie z kultury: kogo zatrudniać, jak budować zespoły. Czemu się pojawiło? Oczywiście z racji szumu, który wokół tego tematu się pojawił.
ŁK : W którymś z podcastów już o tym dyskutowaliśmy.
SW : Tak, dokładnie. Tylko nie pamiętamy, ale było. Zachęcamy do przesłuchania całego zestawu wcześniejszych podcastów. Dobra. To lecimy do kolejnego.
ŁK : Tak, platformy.
SW : Platformy. I tu kolejny raz nie ma nic z Adopt.
ŁK : Tak, co jest dziwne.
SW : To jest bardzo dziwne. I też jest bardzo dużo ruchu. Dobra. Łukasz – zaczynamy.
ŁK : Tak, zaczynamy. Znowu startuję. Moja pozycja to tak naprawdę dwie pozycje: Azure DevOps i Azure Pipelines.
SW: Taki… trochę powtórka z poprzedniego.
ŁK : Tak, trochę powtórka, ale teraz bardzo ważne: to są dwie pozycje. One są na Assess. Dlaczego jestem zdziwiony? Po pierwsze, dlatego że są oddzielnie. Że oddzielnie jest nazwane Azure Pipelines i Azure DevOps. I to pokazuje mi jedną, bardzo ważną rzecz: że Microsoft błądzi z przekazem marketingowym dotyczącym tych usług. Przez to, że GitHub też jest (bo Technology Radar powstaje głównie w Stanach – to jest trochę istotne). Żeby pokazać: jest taki problem, że Microsoft teraz aktywnie sprzedaje dostępy do GitHuba, bo jesteśmy fancy, nowocześni i innowacyjni. Ludzie się w tym gubią. Więc trochę oddzielnie Pipelines, trochę oddzielnie DevOps. I co chyba ważne: z tej usługi po prostu warto skorzystać, jeżeli używamy Azure, wytwarzamy oprogramowanie i dostarczamy jakąś infrastrukturę na nim – to po prostu warto z tego korzystać. O. To tak jak z Pipelines'ami do infrastruktury.
SW : A ja bym to rozszerzył. Nawet, jeżeli deployujemy aplikację na Azure, to Azure DevOps i Azure Pipelines, o ile kiedyś nie były idealnym produktem – nazwijmy to politycznie, to MS zainwestował tyle milionów w Azure DevOpsa i Pipelines, że to naprawdę zaczęło mieć sens. Ten Pipelines dobrze działa.
ŁK : To jest realna konkurencja dla stacka Attlassiana. Jeżeli patrzymy (bardzo ważne nie mylić z Jirą), to trzeba patrzeć na to tak: Azure DevOps jest project sentrickt, czyli na pierwszym miejscu stawia projekt, a nie tak jak Jira Confluence – całą organizację. Jeżeli szukamy narzędzia project sentrickt do wytwarzania całościowego oprogramowania, to warto w niego zainwestować. Bo to już nie jest C# i .NET. To jest tak naprawdę wszystko.
SW : Tam jest wszystko. I nawet dla kogoś, kto używa Jenkins. Mamy tam dużo rzeczy, które dobrze działają. I też może to być fajne kosztowo. Dobrze. To teraz z mojej strony. To jest temat, który też już od jakiegoś czasu się obija o uszy. Mianowicie: Rootless containers. Jaki jest problem? To jedna z największych wad Dockera, która była zawsze, i o której wszyscy trąbili na starcie, czemu go nie używać. Czyli to, że często jest opcja, że kontenery i rzeczy na kontenerach chodzą jako root i w tym momencie problem jest taki, że jak będziemy mieli security i jakiś nowy włam na kontener, to możemy łatwo przejść na hosta trzymającego.
ŁK : Jeżeli są przemapowane (w szczególności zasoby), bo przechodzimy do hosta z uprawnieniami roota, jeżeli ktoś za szeroko się machnął.
SW : Dokładnie. I to jest temat, który dla mnie też był ciekawy i zastanawiałem się, czemu jest w Assess. Częściowo dlatego, że zaczyna już być dużo lepsze wsparcie i dlatego może pojawiło się w radarze – żeby faktycznie na to rzucić okiem i przyjrzeć się. Pokazuje to, że Docker jako taki już dojrzał i teraz zaczyna rozwiązywać problemy security.
ŁK : Tak, ale i wracamy do pierwszych idei. Bo jedno, że jest właśnie Rootless containers, czyli, że nie mamy tego roota, a drugie jest…
SW : Skalowanie.
ŁK : Tak. Brakuje mi tego. Chyba tego nie było wtedy w radarze. Distroless containers. Czyli w ogóle wyrzucone tak, jak pierwotnie było. Bo w kontenerach teraz używamy jakiejś bazy, która jest na bazie jakiejś dystrybucji. A można tak naprawdę wyrzucić wszystkie zależności. I w Google jest projekt o nazwie Distroless containers.
SW : Obił mi się w pewnym momencie o oczy.
ŁK : Nawet mają .NETa 2.2 i chyba nawet już .NET 3 zaczęli wprowadzać.
SW : Więc tyle. Idea bardzo fajna i fajnie, że Docker zaczyna swoje rzeczy z backlogu nadrabiać, bo to się przydaje. To może nie będzie rewolucja w deweloperce, ale naprawdę ułatwi życie. I co? Tyle właściwie robimy z platformy. Toolsy.
ŁK : Tak. Toolsy. Znowu nic w Adopt.
SW : Znowu, dziwnie. I tym razem ja zaczynam. To, co jest bardzo mocno dziwne, to fakt, że w Assess jest ESLint. Dla każdego, kto robił cokolwiek w JavaScripcie, nawet zainstalował VisualStudio Codea i otworzył taki projekt w JavaScripcie, to Code już nam podpowiada automatycznie, że może użyje ESLinta do sprawdzania, weryfikacji składni, stylu i tak dalej. I zszokowało mnie, że to jest dopiero na Assess, żeby operować, bo prawie wszystkie narzędzia pokazują, że jak najbardziej by default używają ESLinta. Nie wiem czemu – powinno być w Adopt już od dawna. Pojawiło się teraz. Może właśnie to jest charakterystyka rynku amerykańskiego, że tam pojawiła się taka potrzeba.
ŁK : Dobra. Teraz z mojej strony: Azure Data Factory for orchestration. I co ciekawe: jest na Hold. Data Factory, czyli usługa do zarządzania flowami, która dość ciekawie pokazuje, że ten hype marketingowo i referencyjne architecture nie zawsze działa na produkcji prawidłowo. Sądzę, że tutaj ThoughtWorks może się sparzyło na paru projektach, bo Data Factory przy skomplikowanych rzeczach potrafi urwać rękę na produkcji. Czasami. Albo możemy trochę błędnie się zapędzić, przy czym to nie jest Hold na całą usługę. Tylko do robienia naprawdę ciężkich procesów. Jednym z zarzutów, z którym się zgodzę jest platforma, gdzie konfiguracja jest taka… nie jest as code taka prawdziwa w porównaniu do apache flowa, w którym wszystko definiujemy w Pipelinach i możemy dorzucić sobie klocki Pythonowe. Czy jakiekolwiek inne, które chcemy. I tutaj po prostu jest Hold dla używania skomplikowanych rzeczy. I zgodzę się z tym. Jeżeli robimy proste flowy, proste ETL'e, chcemy odpalić jakąś paczkę CIC-ową, jakiś job w data bricksach chcesz przewalić, to jak najbardziej tak. Im bardziej pójdziemy w skomplikowanie, tym bardziej zaczyna się parę ciekawych rzeczy. Na przykład monitoring.
SW : Tak, dobra. Teraz mój kawałek. I znowu Docker, który nadrabia rzeczy z backlogu, mianowicie Docker Notary. O co chodzi? O rzecz, którą robimy już od dawna, jeżeli chodzi o zależności, czyli podpisywanie i obrazów i my później DLLki zawsze (czy to na pewno jest ten projekt). I podnoszenie security. I Notary daje właśnie tę opcję, że możemy podpisać obraz. Dzięki temu mamy weryfikację, że nikt nam tego obrazu nie zmodyfikował. A pamiętajmy, że były takie sytuacje, w których było kilka włamań na popularne biblioteki, gdzie ktoś wstrzykiwał kod zależności do popularnych bibliotek.
ŁK : Node.js.
SW : W Node było, ale było też chyba w Java. Po prostu to są wirusy. Wredne. I mówiliśmy wtedy o kilkudziesięciu, a nawet kilkuset tysiącach pobrań. Niewesołe. Notary właśnie jest adresowane do tego problemu.
ŁK : Co pokazuje, że dojrzewamy. Znowu.
SW : Tak, ale dla mnie też pokazuje skąd wynika potrzeba robienia takich rzeczy? Z mocnego ciśnięcia w Kubernetesa. To, że nagle ma tak szeroką adopcję i nagle zrobiło się go dużo więcej. Nagle ktoś się obudził, że ok: ściągamy to gówno, co z tym zrobimy tak naprawdę.
ŁK : Tak i ja bym jeszcze dodał, że dużo osób (w szczególności w świecie .NETowym) zapomniało, że kiedyś przecież code signing robiło często rozwiązania.
SW : Tak, oczywiście. To jest też popularne. Mamy podpisywane paczki, jak najbardziej. Nie wszystkie aplikacje działają z podpisywanymi paczkami, ale to jest też opcja, która jest dostępna. Dobra, Twoje.
ŁK : Dobra, moje. To będą znowu kontenery. I w Assess. Jest to narzędzie Trivy , które jest powiązane z Container security scanning. To jest darmowe narzędzie OSS od aqua security do skanowania naszego kontenera. Narzędzie, które po prostu możemy sobie włączyć w pipeline SI i sprawdzić to, więc nie ma co się rozwodzić. Jeżeli potem zobaczymy, ile gadamy o kontenerach (nie chciałem już tego liczyć), ale naprawdę narzędzi do kontenerów i Kubernetesa w tym raporcie jest masa.
SW : Ja bym jeszcze dorzucił narzędzia do UI i do frontendu. Też dużo się pojawiło.
ŁK : Tak, czyli ogólnie właśnie UI, frontend i gdzieś okolice testowania tego, jak i konteneryzacja. To jest teraz głównie Technology Radar.
SW : Tak. Dobra.
ŁK : To dalej.
SW : Languages & Frameworks. Ponownie – nic w Adopt.
ŁK : Dokładnie. No to zaczynaj.
SW : Co się pojawiło? Pojawił się Flutter. Czym jest Flutter: jest językiem, a tak naprawdę frameworkiem do tworzenia aplikacji na urządzenia przenośne, ale nie tylko. Bo Flutter to są też przymiarki po to, aby tworzyć strony www we Flutterze, który był przenośny.
ŁK : Tak naprawdę PWA.
SW : Tak.
ŁK : PWA to jest złe określenie do tego. Ale chodzi o samą koncepcję.
SW : Tak, i czemu ma taką opcję? Jest to narzędzie od Google. To chyba bardzo wiele tłumaczy. Google sporo inwestuje, jest multiplatformowe.
ŁK : Jest świeże na rynku, bo dwa lata temu było pokazane.
SW : Dwa lata temu. Coś w tym stylu.
ŁK : Google AiO 2018, jeżeli dobrze pamiętam.
SW : Coś tak mi się kojarzy. Tak. Na tyle, że już jest paru googlowych envipów od Fluttera. W Polsce niedługo będzie konferencja à propos Fluttera. Ogólnoeuropejska – żeby nie było. Link do niej zamieścimy pewnie w źródłach. Flutter jak najbardziej ma sens, jeżeli mówimy o mobile developmencie i warto się mu przyjrzeć. Tu się z Technology Radarem zgadzam.
ŁK : Tak, jestem ciekaw z mojej perspektywy versus react native.
SW : Powiem to tak: magia nazwiska Googla tu może dużo zadziałać. To nie jest powodzenie technologii, to jest powodzenie tego, kto wydaje i kto utrzymuje.
ŁK : Właśnie tak. Reakcje są przez react native to jest Facebook, więc to jest…
SW : To nie jest łatka, która obecnie dodaje splendoru.
ŁK : Google też nie.
SW : E… mnie trochę ujmuje.
ŁK : Dobra. Teraz z mojej strony w sumie to będą dwa, bo pokazuje jedną rzecz. Jest to GraphQL , który jest na Asses i Tensorflow , który jest na Trialu. One nie są pierwszy raz w Technology Radarze (bo pierwszy raz pojawiły się w 2016 roku w podobnych statusach). Teraz mamy ich powrót. One po raz pierwszy były w kwietniu 2016. GraphQl pojawia się często i coraz częściej wraca. Chyba już zaczynamy rozumieć, po co jest ten koncept i jak go wykorzystać.
SW : Tak, chociaż dalej często GraphQl jest mylony z bazami grafowymi. To tak z mojego podwórka.
ŁK : Tak. No i Tensorflow prawdopodobnie wrócił, bo wyszła jego wersja 2.0.
SW : Tak, ale co ważne: to nie jest to, że on wrócił, bo został cofnięty. On dalej w tym statusie był tak naprawdę.
ŁK : Tak. Tylko zniknął z samych opisów i innych rzeczy, bo oni w pewnym momencie nie przesuwają tej technologii, tylko jej nie pokazują w tych samych wydaniach.
SW : Tak. Czym mnie Tensorflow najbardziej zdziwił? Bo stał się tak naprawdę standardem, jeśli chodzi o prace macierzowe.
ŁK : Zrobiłem sobie reaserch na ten temat i było parę porównań/zapytań, to dopiero gdzieś teraz Paytorch wyrównuje się w zapytaniach Googlowych z Tensorflowem. Czyli jest to dość ciekawe. To co, chyba czas na podsumowanie.
SW : Podsumowanie. Pierwszy wniosek, który się nasuwa: to jest Radar, który patrzy wstecz. Zdecydowanie. Na to, co się wydarzyło. To jest Radar ukierunkowany nie na wielkie firmy typu Google, ale bardziej na korporacje. Takie jest moje zdanie.
ŁK : Tak, bo on też tak powstaje: na podstawie tego, co ThoughtWorks robi. Ale pokazuje też to, że nasz rynek nie jest zacofany. To też jest ciekawy wniosek, bo patrzymy na parę rzeczy i technik, które się stosuje, że to się…
SW : … cudowanie to nie jest.
ŁK : … że technologicznie zaczynamy być gdzieś poza tą adopcją chmury, jak to niektórzy narzekają. Że bardzo się wyrównujemy w części korporacyjno-technologicznej. Nie w bleeding edge, ale w tym sofcie biznesowym.
SW : Powiedzmy to tak: na polskim rynku jest dość mało ofert pracy w wibid .NETcie, także wydaje mi się, że jest w porządku. Chyba.
ŁK : Tak. Jedną rzecz bym zaznaczył, że to nie jest narzędzie i wyznacznik całego rynku. Sam Technology Radar jest do przejrzenia. I znowu trzeba to podkreślać za każdym razem.
SW : Jest zopiniowany na pewno. Pamiętajmy, że o ile ThoughtWorks jest sporawą firmą, to nie mają całego zakresu. Moje wrażenie jest takie, że przy AIAML-u trochę mniej siedzą. I dopiero teraz weszli w rzeczy frontendowe, bo nagle pojawiło się tego dużo więcej.
ŁK : Testowania i innych rzeczy.
SW : Tak, dokładnie.
**ŁK: ** Z mojej strony jeszcze dodam, że dużo takich rzeczy idzie w szczególności w kierunku konteneryzacji security. Na zasadzie: był przed tym bardzo duży opór (aby robić niektóre rzeczy) albo zrobimy to kiedyś. I to „kiedyś" właśnie nadchodzi.
SW : Tak. I to pokazuje, że Technology Radar jest super narzędziem, z którym możemy pójść do przełożonego i powiedzieć: Panowie – wdrażamy, bo ThoughtWorks powiedział, że to już jest w Adopt. Więc wszyscy to robią. Róbmy to teraz, bo za chwilę będziemy z tyłu.
ŁK : Tak, to jeden z czynników. Nie róbmy tego głównym argumentem. Można to pokazać jako benchmark rynku.
SW : Nie jedyny, ale mocny czynnik. Tak. Bo zawsze porównuje się do innych. Z reguły jest dobrym argumentem przekonywania, czymś, co warto mieć. Mnie to pokazuje to, że Docker stał się takim typowym comodity. Czymś, co po prostu jest i daje kontenery.
ŁK : Konteneryzacja jest comodity. Może niedługo się pozbędziemy tego Kubernetessa.
SW : Tak, może tak być. Dobra. Właściwie teraz już kończymy. To do kolejnego odcinka.
ŁK : Na razie.
SW : Na razie.