Ł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 są na: patoarchitekci.io/47. No i numerek się zbliża, więc będziemy mieli ogłoszenie. Łukasz.

ŁK: Dobra. Ogłoszenie na dzisiaj. Zamiast linków z okazji 50. odcinka, który zbliża się nieubłaganie (rok przesunięcia względem tego, co planowaliśmy), chcielibyśmy zrobić w Warszawie 9 listopada (po południu) pierwszy fizyczny meetup. Wszystkie informacje i link do rejestracji znajdziecie w opisie odcinka, jak i na social mediach. Co ważne – 50. odcinek też planujemy w trochę innej formule niż zwykle – chcemy go zrobić w wersji Ask Me Anything. Link do zadawania pytań macie poniżej lub zostawcie komentarz na socialach skąd doklikaliście się do odcinka. To tyle z ogłoszeń. Co dzisiaj, Szymonie, przechodzimy?

SW: Przechodzimy dzisiaj DevOps Report. Całkiem ciekawy i całkiem długi, bo to jest PDF, który ma 70 stron.

ŁK: Chyba 77 stron.

SW: Dokładnie. Więc jest naprawdę spory. Pogadaliśmy sobie i nie będziemy omawiali go punkt po punkcie. Ustaliliśmy, że to jest kobyła, to jest kawał raportu. Polecamy, aby usiąść i go przeczytać, bo tam jest dużo ciekawych rzeczy. W tym odcinku powiemy, co każdy z nas znalazł, zaznaczył i co nas de facto zainteresowało. A część rzeczy powiemy, że pogadamy o nich później.

ŁK: Pierwszą rzeczą, którą należy powiedzieć, to to, że to jest świetny snapshot rynkowy – nie odjeżdża od realiów, które się widzi na rynku. To jest pierwsza rzecz, którą trzeba sobie powiedzieć.

SW: Tak. Chociaż realia nas miejscami trochę przeraziły.

ŁK: (śmiech) Ale są. Dwie rzeczy na początek z demografii. Kłóciliśmy się, czy o tym mówić, czy nie, bo na to zwróciłem uwagę. Ciekawostką jest, że lata doświadczenia, które są demograficznie pokazane, pokazują pięknie rozkład Gaussa. Czyli z punktu widzenia matematyki i statystyki idealnie powinno obrazować to, co się dzieje. I taką ciekawą zmianą – której sami autorzy raportu nie wiedzą, co to jest – jest skok w ludziach oddających swój głos w tej ankiecie pomiędzy: 3 lata i 5 lat doświadczenia, jak i bardzo duże zmniejszenie się rok do roku ludzi z 16 i więcej latami doświadczenia. To jest taka ciekawostka, która spowodowała, że wygląda teraz to jak rozkład Gaussa.

SW: Tak, bo poprzedni raport (sprzed roku) miał wzrost liniowy. Czyli liczba ludzi w konkretnych przedziałach rosła liniowo – najwięcej było powyżej 16 lat. To jest totalnie dziwne, patrząc jeszcze na to, jakie systemy i jakie klastry zostały pogrupowane.

ŁK: Do których zaraz sobie przejdziemy. I druga rzecz, która mówi, że ten snapshot jest dobry, jest pokazanie, jak ludzie zidentyfikowali swoje role przy wyborze odpowiedzi. Czyli de facto mamy część deweloperską, DevOpsową i SRE połączone razem, operation Ops i managerzy to… Prawie że ta cała część jest rozłożona po 1/4 tego raportu plus procentowe zrzuty na resztę. To pokazuje, że odpowiadali ludzie, którzy w teorii powinni być mocno zaangażowani w to, jak to wygląda.

SW: Tak. I to głównie ludzie z back-endem technologicznym.

ŁK: Tak.

SW: Dobra. Przechodzimy.

ŁK: Dobra. Demografia obrobiona, przejdźmy do… Więc od czego zaczynasz?

SW: Zaczynam od tego, że jak mówimy: DevOps Report, to zawsze mówiliśmy o 4 metrykach, a jest 5 metryk. I tak – przypomnienie, bo znowu będzie, że skrótów nie rozwijamy i nie rozwijamy tego, co się dzieje. Normalne 4 metryki, które były, to: lead time for changes (czas do zmiany); deployment frequency (jak często wrzucamy wersje), MTTR, czyli Mean Time To Recovery, (ile czasu nam zajmuje, jak coś się wywali) i change failure rate (kontrmetryka). Kontrmetryki są super ważne, do pierwszej, czyli lead time for changes, czyli jak często coś wywalamy. I to były 4 metryki DevOpsowe, które istniały od zawsze. Natomiast teraz jeszcze jest 5 metryka. I to fajnie pokazuje, jak ten raport się przesuwa z takiego technologicznego do bardziej relacyjnego. Tak to z reguły bywa. Operational Performance. Wydaje mi się, że nazwa nie najlepiej dobrana, ale chodzi o to, jak często zespół dostarcza to, co chcą użytkownicy. Czyli mierzy, czy nasza praca idzie w piach, czy praca naszego zespołu faktycznie dostarcza wartość organizacji. I jak się tą metrykę dorzuci, jak się ma tą świadomość, to ten raport się zupełnie inaczej czyta – jest mocno managerski, mocno organizacyjny. To jest dla mnie pierwsza najważniejsza rzecz, która tutaj została pokazana.

ŁK: No i klastry, które wynikły z tego podziału i dodania tej nowej metryki. Bo to dość ciekawie obrazuje podziały, które są.

SW: Tak. Bo de facto są włożone 4 klastry. Jest: starting, flowing, slowing i retiring. I to w ogóle daje super kontekst temu raportowi. W ogóle jest wielka sekcja kontekst w raporcie, która pokazuje, że nie w każdym projekcie musimy mieć te najwyższe wartości wymaksowane. Starting – nazwa tłumaczy trochę sama z siebie. Czyli zespół zaczyna z dobrymi praktykami. Flowing – to taki główny tryb tak naprawdę. Zespół się najbardziej rozwija, często wypuszczane jest – mniej więcej co godzinę zmiany. Generalnie to taki aktywny development. Slowing – wydevelopowaliśmy już coś i powoli, powoli przechodzimy do utrzymania. Wydawnictwo jest mniej więcej raz na dzień. Ostatni jest retiring, czyli mamy…

ŁK: Czyli pomiędzy tygodniem a miesiącem wydawnictwo. Chyba, czy nie?

SW: Tak, większa…

ŁK: Tak, tak. Beetween once per week and once per month.

SW: Tak. No i ostatni jest retiring – mamy soft, który jest po prostu w trybie utrzymania i musimy z nim żyć.

ŁK: Przy czym jeżeli popatrzymy na ten slowing, tak zupełnie szczerze, to poza głównym początkiem projektu to jest wystarczająca prędkość dla większości projektów.

SW: Tak, zdecydowanie. Ale co mnie zdziwiło w kontekście tego, co się dzieje, a szczególnie przedziału wiekowego, to że slowing to jest 34% projektów, które zostały tak zakwalifikowane. A mówimy że pracują tam ludzie o średnim przebiegu doświadczenia. Generalnie tam jest przedział 5–6 lat i 6 z kawałkiem. Więc większość systemów jest de facto zbudowanych i przechodzimy w ich utrzymanie. Ciekawe.

ŁK: Tak, bo jest tak, że flowing ma 17%, retiring 21%. Więc to jest właśnie ciekawe w tym. Dla mnie, idąc dalej, to jest… Bo wcześniej były podziały na bazie 4 poprzednich metryk. W poprzedniej wersji były 4 poziomy, które określały jak performuje nasz zespół. Czyli mieliśmy: elite, high, medium i slow. W tym roku postanowiono, i to jest ciekawe, skasować elite, zmerdżować to z high i urealnić metryki. Okazuje się, że prawidłowo teraz większość rynku to medium, co jest też prawdą. Czyli częstość deploymentu jest właśnie pomiędzy raz w tygodniu do raz w miesiącu. Zmiany dokładnie tak samo. Time restore service pomiędzy jednym dniem a jednym tygodniem. Failure rate pomiędzy 16 a 30%. I patrząc się na to, to jest 70%…

SW: Rynku

ŁK: …rynku według respondendów, o tak. Bo to trzeba powiedzieć.

SW: Tak. Ale nie dodałeś jednej rzeczy. Czemu usunięto elite? Bo okazało się, że bycie w grupie elite, nie przekłada się na jakość – nie ma wartości tak naprawdę. Więc gonienie za króliczkiem, że będziemy deployowali super często, żeby tylko deployować super często, okazało się de facto trochę bez sensu.

ŁK: Tak. I ta metryka dowożenia tego, co powinniśmy dowozić użytkownikom, świetnie to pokazuje.

SW: Tak. Na mnie ten raport zrobił duże wrażenie pod tym kątem, że dodanie 5 metryki pokazuje, że ten raport przeszedł z takiego czysto softwerowego do software plus organizacja firmy, tego jak działamy (nie tylko IT, ale wszystkie rzeczy dookoła IT, które się dzieją). Super. Jedna rzecz super ważna dla mnie, to było to, że okazało się, że zespoły w trybie retiring, czyli te, które stanowią 21% zespołów, które de facto są na wygaszeniu, dostarczają najwyższy poziom zadowolenia funkcjonalności. Czyli dostarczają dokładnie to, co użytkownicy chcieli.

ŁK: Bo jest znane.

SW: To by było sensowne.

ŁK: Bo jest już znane. Tak. Wiesz co, może teraz przejdźmy do – jak jesteśmy przy rzeczach organizacyjnych – kultury, która nieźle została tutaj wyróżniona.

SW: Tak. Westrum Organizational culture. Obydwaj wyłapaliśmy, że to jest super.

ŁK: Dobra. Został zrobiony podział, de facto podział kultury zespołów organizacji na 3, przepraszam.

SW: 3

ŁK: Zastanawiam się… te opisy mi się akurat nie podobają, bardziej ich funkcje i takie, co określają, czyli: power oriented, rule oriented i performance oriented. I to jest… Czyli pathological…

SW: Jest patologiczny, biurokratyczny i generative, przyrostowy. Ja bym powiedział, że to jest określenie super, ono pasuje doskonale tak naprawdę. Tu bym się z tobą nie zgodził. To jest to… Jak czyta się ten opis patologiczny zespołu, to po prostu każde zdanie pasuje idealnie tak naprawdę. Bo o jakich zespołach mówimy? Niska kooperacja, że wszystkie informacje o… feedback de facto ubijamy, bo go nie chcemy.

ŁK: I posłaniec jest zabijany z wiadomością.

SW: Tak. Dokładnie. To jest w ogóle super wykonane, de facto. Nawet że nie tylko oburzamy się na feedback, oburzamy się też na osobę, od której go dostajemy. Czyli w ogóle osobowo traktujemy. Jest… Nie ma dostępu do rzeczy nowych, zabijamy innowacyjność tak naprawdę. Obwiniamy ludzi za problemy z wdrożeniami, czyli kompletnie nie monitorujemy procesu. Co tam dalej jest… Odpowiedzialności zawężają się w zespole, czyli tworzymy silosowanie wiedzy. To jest idealny opis patologii, co się dzieje. Dla mnie to jest… Dobrze, tak to wygląda de facto. Dalej idziemy, już pociągnę dalej. Mamy część biurokratyczną i to też fajnie pokazuje. To są zespoły, które mają sztywno narzucone reguły i po prostu się ich trzymają. Czyli chodzą… w takim cuglu, że tak musimy robić i nie wiele więcej możemy poza te ramy wyjść. A na koniec mamy generative. I to są zespoły, i to bardzo mocno podkreśla, jak ważny jest to całe kaizenowe podejście, cały czas ulepszamy nasze procesy i staramy się być coraz lepsi. Nie musi być super, ważne, żeby ciągle było lepiej. Więc dla mnie… powiedziałbym, że tak – podpisuję się pod tym rękami i nogami, jak najbardziej. Opis jest fenomenalny.

ŁK: Tutaj tak. Ten jest świetny. No i performance oriented, czyli generative. Jest zaprzeczeniem wszystkiego, co usłyszeliśmy poprzednio, czyli to jest ten tryb, który prowadzi tak naprawdę do wytwarzania. I dobrym powiedzeniem jest sobie tutaj, bo można powiedzieć, że nie ma kultury obwiniania. Jakbym miał podsumować jednym, może dwoma zdaniami to: nie ma kultury obwiniania oraz wyciągamy wnioski.

SW: Tak. Na prawdę dużo w raporcie jest poświęcone temu, żeby cały czas się rozwijać. Dlatego usunięcie tego elite. Raport wyraźnie mówił: co organizacje powinny robić. I to był taki raport w absolutach: „Tak wszyscy róbcie, będzie lepiej". A teraz jest dużo więcej w kontekście: „Ok, taki jest trend rynku, pewnych rzeczy nie rozumiemy, czemu się tak naprawdę dzieją, pewne rzeczy korelują się też negatywnie". Na przykład bardzo ważnym tematem jest to, że okazało się – to też złapaliśmy we dwóch – że było to, że im nowszy stos technologiczny, tym większy jest burnout w zespole. I to jest przerażające. Im bardziej mamy loosely–coupled architecture, czyli luźnie podaną architekturę, tym większy jest burnout zespołu. Zespoły, które ze sobą dużo rozmawiają, będą bardziej podatne, ale ta wiedza płynie wszędzie. Okazuje się, że ludzie dłużej w takich zespołach siedzą i lepiej pracują. I nie wiemy czemu. Przerażające. Ale właśnie to pokazuje… Raport bardzo mocno pokazuje, jaki jest kontekst i nie każdy element tego raportu należy aplikować do każdej sytuacji. Jak to mówimy w IT od dawna: context is the king de facto. Tak.

ŁK: Tak. I lecąc właśnie. Może przechodząc płynnie z tej kultury na te niespodzianki. To, co poruszyłeś, co mnie troszeczkę zaskoczyło, ale też chyba pokazuje, że może być to prawdą właśnie. Niektóre rzeczy technologiczne: im bardziej mamy wyrafinowany stos, tym może prowadzić do szybszego wypalenia po całości. Tutaj też to jest ciekawie zauważone w tym, że pojawiło się dużo młodych. I tak jak ten… Nabywanie tego stosu. Jeżeli popatrzymy, nauka tego stosu idzie latami, że tak powiem. Poznajesz ten stos. Kiedy wpadasz jednak na większy projekt i masz tego poznać więcej, to obciążenie kognitywne robi się naprawdę spore, jeżeli popatrzymy na ilość rzeczy, które powinieneś rozumieć i umieć.

SW: To jest takie gonienie króliczka de facto cały czas. Mamy frameworki, które się aktualizowały, będziemy cały czas podbijali wersje, będziemy cały czas mieli coś do zrobienia. Czasami musimy sobie powiedzieć: „Stop, ok. Jest jak jest". I zostawiamy pewne rzeczy i dowozimy wartość biznesową de facto. Bo to jest ten cały słynny żart, jak się nabijaliśmy parę lat temu z ludzi stawiających projekt na Nodzie, że de facto w 5 dni przygotowali się do ruszenia z projektem. Bo trzeba było wszystko skonfigurować. Odnośnie ciekawostek: dla mnie jest jedno fajne zdanie, które złapałem. Akurat nie było w tych ciekawostkach, tylko było gdzieś na starcie, ale było bardzo, bardzo ważne. Jedno zdanie, które mówi, że praktykowanie szybkich, skalowalnych, takich high–performing zachowań w dziedzinie softwaru nie powinno być praktykowane – nie dowozi to żadnych wartości, jeżeli organizacja jako cała, reszta organizacji, nie jest winna. I to mi pokazuje po prostu, że jeżeli jesteś w organizacji, która jest waterfollowa, i jest wszystko od góry do dołu, to nie sil się, nie wprowadzaj pewnych praktyk, bo to po prostu nie zadziała. I nie ma sensu tego robić.

ŁK: Dla mnie to jest… nie pamiętam… Na którejś uczelni ktoś wrzucił na zasadzie pytania, że testerzy w teamie scrumowym nie wyrabiają się na sprinty z przetestowaniem, żeby dowieść inne rzeczy. W sensie wiesz… takie typowe waterfoll, ale jesteśmy zwinni. I dla mnie to było szyderstwo – to przejdźcie po prostu na zwykłego kanbana zamiast scruma i problem rozwiązany.

SW: Tak, bo nie będzie tych interakcji. Swoją drogą, ja kanbana akurat bardzo lubię.

ŁK: Jak używasz reguł i tablicy, wtedy jest dobry.

SW: Tak, zgadza się jak najbardziej.

ŁK: Dobra. I z ciekawostek o SRE i w ogóle reliability. I to jest dość mocne: raport wyraźnie pokazuje, że koszty prowadzenia SRE – jeżeli patrzymy na to jak to się definiuje po googlowemu, skąd wyszedł cały ten trend i podejście – SRE kosztuje dużo zanim zacznie się zwracać. I potrzebuje czasu i dojrzałości, praktyki zanim będzie widać jej efekty.

SW: Ok, więc biorąc, wdrożenie jest kosztowne i długo, długo nie widzimy zwrotu. Musimy przez pewną barierę się przebić i dopiero wtedy faktycznie ta krzywa zaczyna rosnąć dość szybko.

ŁK: Tak. I druga sprawa, że projekty… Tez ciekawostka. Nasze delivery performance może również spaść, bo zespoły muszą się przystosować do nowego modelu. To, o czym też jest to właśnie wyraźnie wspomniane: musimy pójść w dół, żeby to się odbiło.

SW: Tak. Kolejny mega interesujący temat… Fajnie, że ktoś to nazwał w końcu i to może ubije część ruchu, w którym się nie podobają, w którym działają od jakiegoś czasu. To jest to, że jest wyraźne powiązanie pomiędzy elastycznością organizacji do pracy, do tego jak ludzie pracują i jak sobie czas organizują względem zadowolenia i względem ich wydajności. Czyli cały ruch Appla „Wracajmy do biura, bo wszyscy muszą być w biurze 5 dni w tygodniu i koniec. Siedź cicho", to pokazuje, że to nie jest dobry kierunek. Mikrozarządzanie, żeby wszystkich widzieć, bo jak ich nie widzimy to nie pracują. To się tak ze sobą nie wiąże. To jest super fajne podsumowanie i bardzo dobrze, że ktoś to opisał. I to też potwierdza się z moimi doświadczeniami. Zdecydowanie.

ŁK: Dobra. To tutaj mamy dalej. Masz coś jeszcze z…

SW: Nie.

ŁK: Tak tutaj zerknę. Dobra. Ja chcę teraz przejść do takich rzeczy, które mnie trochę zaskoczyły w liczbach, ale… Jest pokazane… W praktyce jest to może jasne, ale to, co mnie najbardziej zaskoczyło: continuous integration została… Porządne continuous integration zostało wyróżnione jako jedna z dominujących praktyk, pokazujących że w porównaniu do reszty, ci high-performance mają zetapowane porządnie CI/CD. Raczej głównie CI: continuous integration. To mocno wybija się na tle całości.

SW: Ty mówisz, zaciekawiło, ja mówię: przeraziło.

ŁK: O tak.

SW: Ale… znaczy… Jak padł pomysł, aby omówić ten raport, to moja reakcja była taka: „Jezu, kolejny raz będziemy mówili o tym samym. Kolejny raz będziemy mówili o tym, że częste oddawanie jest sensowne. Kolejny raz będziemy mówili o tym, że posiadanie CI/CD ma wartość i będziemy cały czas tłukli to samo: co powinniśmy robić, a nie robimy". Więc ten raport mimo… przyjemnie zaskoczył. Ale fakt, że jest duży nacisk w zespole – jak powiedziałeś – na CI/CD, że powinno być, mnie zasmucił bardzo. To jest takie… Dalej tego nie robimy. Jezu!

ŁK: Tak. Druga sprawa, która ciekawie pokazuje, to jest trunk–based development. Obok CI pokazuje, że ma to wartość. I de facto benefity w całości widzą dopiero ludzie z dużym doświadczeniem.

SW: A to mi znowu pokazało, jak fajnie ten raport jest pokazany na skali organizacji. Bo trunk–based development może każdy sobie zrobić, ale to wymaga innego podejścia do sprzedaży, innego podejścia do produktu i w ogóle to wymaga onboardingu całej organizacji na nowy system pracy. I to znowu pokazuje, jak bardzo ważny jest kontekst organizacji: że samo ID żeby szabelką nie wymacha, musi być zaangażowanie reszty, tak naprawdę całego środowiska.

ŁK: Trzeba sobie powiedzieć, co w ogóle wiesz… Trunk–based development trzeba sobie powiedzieć… Oddzielmy to od monorepa, bo to jest też istotne oddzielenie tego, że to nie jest podejście mono, tylko sama praktyka wykorzystania. I tak, trzeba sobie powiedzieć, że dobrze to wygląda, kiedy soft może iść do przodu. Tak realnie nie musi mieć kompatybilności innych rzeczy. I inaczej to będzie wyglądało, jak jesteś firmą produktową i jeszcze oferujesz np. dedicated SAP albo instalacje jeszcze on-prem czy gdzieś tam pochowane, a inaczej będzie, gdy dostarczasz software wewnątrz organizacji. Co, nie oszukujmy się, jak popatrzymy, robi pewnie z 80% naszych słuchaczy i rynku. I ten software wewnętrzny, ten trunk–based development jest naprawdę realną rzeczą do osiągnięcia, jak się przesiądziemy.

SW: Tak. Dla wewnętrznego klienta jak najbardziej. Dla produktowych jest to dużo trudniejsze, ale właśnie tam wymaga całego onboardingu produktu, jeżeli chodzi jako o organizacji i firmie. Jeszcze jedna rzecz, która mnie zaciekawiła. To już jest taka moja refleksja. Jest wyraźnie napisane, że wykorzystanie chmury w znaczący sposób koreluje się bardzo mocno z firmami i organizacjami, które są lepiej, bardziej wydajne, bo są bardziej inne. Mnie zastanawia jedna rzecz: czy to jest to, że po prostu bardziej zwinne organizacje dorosły do tego, żeby używać chmury? Nie wydaje mi się, żeby sama chmura, sama z siebie nagle zmieniała wszystko i była takim trochę… Bo trochę tak to wygląda, że taki silver bullet. Wydaje mi się, że to bardziej kwestia tego, że to firma dojrzewa do tego, że to chmura będzie benefitem i potem chmura staje się de facto akceleratorem zmian. Bo daje dużo możliwości, ludzie widzą, czemu pewne rzeczy należy robić…

ŁK: Raczej pozwala Ci w ogóle uelastycznić pewną rzecz. Jeżeli governance i inne rzeczy są dobrze zrobione wokół tego.

SW: Tak.

ŁK: W szczególności wewnętrzne.

SW: Ale jeszcze jedną rzecz robi chmura bardzo ważną: pokazuje liczby. Pokazuje liczby odnośnie kosztów, wydajności. Pokazuje dużo więcej liczb, więc jest nam łatwiej mierzyć. Bo problem z DevOps Reportem z poprzednich lat był taki, że czasami ciężko jest niektóre z tych 4 metryk mierzyć. A chmura daje dużo lepsze możliwości. Nie do wszystkich – wiadomo, ale do części dużo lepiej nam pokazuje.

ŁK: Raczej tak. Wiesz co, teraz przeszedłbym trochę na tabelki, które wcześniej miały większą wartość, Szymon się śmiał, i muszę mu przyznać rację, że ten kontekst kulturowy i organizacyjny w tym roku jest ciekawszy. Ale co do tabelek, i ten wzrost rok do roku, ciekawostką jest, że przy osobach oddających odpowiedzi, najważniejszy jest spadek: No Cloud.

SW: Znaczący.

ŁK: Że mamy względem rok do roku o –50%. I następną rzecz, którą tutaj widzę, jest dla mnie ciekawa i która mówi, że jest to raport mocno w kontekście technologicznym: powyżej 50% odpowiadających mówiło o multi–cloudzie.

SW: Dla mnie to był szok.

ŁK: I mówiło o multi–cloudzie de facto z tej puli 62% największym benefitem, który tutaj mówili to jest availability. Jeżeli mówimy o multi–cloudzie. To, przepraszam, pokazuje, że rynek patologicznie nie potrafi zając się avability na jednej platformie.

SW: Hm… Zastanawiam się, czy to jest: nie umie, czy też metryki, której mi tu brakuje, to jest to, jak duże firmy brały udział. W sensie… No bo…

ŁK: Zaczekaj, nie, jest do tego metryka. Bo ja patrzyłem. Poczekaj. Bo ja patrzyłem na demografię. Tylko 16% jest powyżej 10 000.

SW: No bo multi–cloud jest trudny. I jest drogi.

ŁK: Tak. Jest drogi.

SW: Nie wszyscy go potrzebują. Nie oszukujmy się, naprawdę nie wszyscy go potrzebują.

ŁK: Tak, i to też jest naciągane w większości przypadków, bo poza corowymi biznesowo systemami, to nie ma sensu. Albo regulacyjnymi. Bo to jeszcze inna kwestia. Są kwestie biznesowe, które są i prokurmentowe, które są bardziej istotne. I to dla mnie jest przerażająco ciekawe. Jako wskazywanie i… takie… to jest taka rzecz w raporcie, która mnie…. Jak miałbym powiedzieć jedną rzecz, która mnie przeraża, nawet ten multi–cloud w tym miejscu bardziej mnie przeraża niż to mówienie o CI i kontroli wersji.

SW: Nie. To mnie zaciekawiło w sensie: po co? Bo naprawdę w większości sytuacji nie widzę sensu. Jak to się mówi: na duże firmy i core systemy. Też, kurczę, nie zawsze. Bo tak naprawdę, bym powiedział, że duże firmy, duże systemy… Dla firm, które serwują coś użytkownikom końcowym tak naprawdę.

ŁK: Ciebie to nie tylko użytkownikom. Pomyśl sobie, że masz Sapa-a spiętego mocno z produkcją. Taką fizyczną. Ktoś wymyślił, że jednak tego Sapa-a, który powinien być przy fabryce, przeniesie do cloudu. To nagle okazuje się, ze SLA na czas recovery 5 minut jest istotny.

SW: Tak. Tylko zazwyczaj… Powiem ci, że mam fabrykę i się dziwię, czemu nie zrobiliśmy high bride clouda. Czyli on-prem i cloud. Bo to ma dużo większy zasięg tak naprawdę.

ŁK: Tak, więc to jest takie… To jest duża ciekawostka, jaki to jest kierunek myślenia. Dla mnie jest on, przepraszam, trochę bym rzucił tekstami, że miliony much nie mogą się mylić, ale nie będę nikogo obrażał. Dla mnie po prostu, no sorry, nakład pracy, żeby użyć, zrobić multi–cloud dla aplikacji versus zysk tego w ability jest… no nieistotny.

SW: A mnie nie przeraża kompletnie nakład pracy na zrobienie tego. Mnie przeraża nakład pracy na utrzymanie tego wszystkiego. Bo trzeba upgade’ować, trzeba mieć ludzi od tego, trzeba propagować wiedzę, trzeba być zgodnym, trzeba konfigurować… Utrzymanie. W IT zabija nas z reguły utrzymanie systemów. Co fajnie nam też przechodzi de facto do jednej gałęzi, której nie poruszymy, a tylko rzucimy, że jest, a omówimy innym razem…

ŁK: Wiesz co…

SW: To jest supply chain, o którym wspomniałeś.

ŁK: Tak. Supply chain tutaj, w tym raporcie, i to jest szok akurat, dostał cały duży swój rozdział.

SW: Jeden z większych rozdziałów tak naprawdę, bo akurat tabelki, o których mówiliśmy, to jest końcóweczka, kontekst ma bardzo dużą sekcję i właśnie supply chain, bezpieczeństwo. I to pokazuje… To się zgadzam pod tym strasznie, że ile kosztuje nas utrzymanie software’u, biblioteki, zależności zewnętrznych i będzie kosztowało nas coraz, coraz więcej. I wydaje mi się, że to będzie prowadziło do centralizacji, od kogo bierzemy usługi. Po prostu.

ŁK: I bardzo mocnej radykalizacji. Zamknięcia stosu, który stosujemy w firmach.

SW: Czyli wracamy się z tym do sytuacji sprzed 15 lat, powiedzmy sobie.

ŁK: No, klasyka. Tak, supply chain to jest w ogóle rzecz… No, musimy w najbliższym czasie zrobić o tym oddzielny odcinek i się przebić i pozbierać tą wiedzę, jak tylko znajdziemy czas.

SW: W najbliższym, w jak najbliższym bym powiedział.

ŁK: Tak, tak. Najbliższym numerami odcinków.

SW: Tak.

ŁK: Przed 100 zdążymy. Dobra, i ostatnia rzecz, która jest całą pochodną tego: gdzie deploymentujemy? Co deploymentujemy? Kontenery prowadzą – 54%. I ciekawostka, pewnie mocno napędzana AWS–em: 42% VMs w cloud. I to obstawiam, że to jest…

SW: AWS

ŁK: AWS Way. AWS, który rozumiem, a reszta to już jest… Reszta jest taka jak była, ale właśnie te kontenery i VMs w cloudzie było ciekawostką. I ten function as a service ma też dużą… Jest tego dużo.

SW: Ale jest dużo SAAS-a, de facto. Jest coraz więcej…

ŁK: Tak, dużo SAAS-a tylko brakowało mi tutaj dobrze definicji, czym jest ten SAAS.

SW: Tak. To, co właśnie powiedziałeś.

ŁK: Dlatego nie chcę tego poruszać, co jest rozumiane przez SAAS, bo zabrakło mi tutaj mocno definicji tego. A function as a service przy tym jak mówimy, że jest tyle tej chmury i jest wydzielony z SAAS–a to zupełnie mnie nie dziwi. Bo przy tych VMs-ach w cloudzie czy kontenerach i tak tego kleju integracyjnego wokół potrzeba dużo innych takich działalności.

SW: Będzie. Tak. Przy czym to się w ogóle procentowy, ile osób korzysta. Ja co do SAAS-a, jakbym miał strzelać… Dorzucę jeszcze jedną rzecz: że to są często manager services. Czyli, że providerzy coraz częściej wystawiają swój software jako managed usługi u różnych producentów chmurowych.

ŁK: Wiesz co… To od razu dając przykład. MongoDB Atlas, czyli MongoDB utrzymywane przez MongoDB w różnych cloudach. Czy baza Snowflake czy Elastic utrzymywany.

SW: Jak każdy provider. Reddit też ma swoje… Wszyscy coś tam swojego mają generalnie. Więc obstawiam, że to jest ten element i on bardzo cieszy.

ŁK: Dobra. To jedna rzecz, na którą byś zwrócił uwagę z tego raportu, żeby się zagłębić. Nie mówić już o całym, tak krótko mówiąc.

SW: Dobrze. Pierwsze 15 stron, bo tam jest omówiony kontekst. I tam jest… Czemu? Bo ten kontekst jest jak kubeł zimnej wody. Taki: nie rób tych rzeczy, jeżeli, to ma sens, jeżeli… To jest taki… Nie chcę, boję się, żeby ktoś w to wszedł, zaczął od środka i powiedział: „O! To teraz tu będę wojował", bo potem będzie miał ogromne wypalenie, że to nie pasuje do jego projektu, organizacji, dojrzałości software’u itd. Pierwsze 15 stron. Tam jest kontekst. Najważniejszy.

ŁK: Tak. A ja bym właśnie powiedział: to. I dla mnie tutaj będzie metryka właśnie tego clasteringu, tego podziału zespołów, w tych właśnie pierwszych 15 stron. To taki crème de la crème zobaczenia sobie na te klastry: starting, flowing, slowing, retiring. To jest taki crème de la crème tego raportu i podsumowania, o którym właśnie mówisz, żeby zobaczyć sobie to.

SW: Tak. Ja bym jeszcze powiedział: to jest raport, o ile poprzednie raporty były techniczne, to jest raport, który śmiało można wysłać do manageróew i wyżej nawet.

ŁK: Tak. I dobrze można nim… Inaczej… Pewne racje można udokumentować właśnie przez pokazanie tych metryk, jeżeli trzeba coś zmienić.

SW: Tak, dobrze.

ŁK: To co, kończymy?

SW: Kończymy. trzymajcie się, hej!

ŁK: Trzymajcie się, na razie!