To jest 249. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o Platform Engineering. 

Wszystko, co potrzebujesz, notatka, linki, transkrypcja czekają na Ciebie na porozmawiajmyoit.pl/249. 

Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz, lub podzielenie się odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

Cześć, mój dzisiejszy gość to inżynier oprogramowania od ponad dekady, związany zawodowo z BlueSoft. Imał się różnych zajęć w IT, zaczynał jako analityk i programista, by potem posmakować ścieżki menadżera, a następnie z niej zawrócić w kierunku architektury i trafić na temat platform engineering, którym zajmuje się od czterech lat, zanim to było modne. Obecnie więcej gada niż robi, ale po to, by wszyscy dookoła pracowali w lepiej zorganizowanym środowisku. Udziela się na YouTube, jest liderem Polskiej Społeczności Inżynierów Platform oraz współzałożycielem Polskiej Społeczności Architektów IT. Od niedawna przekazuje wiedzę studentom na Polsko-Japońskiej Akademii Technik Komputerowych. Moim i Waszym gościem jest Krzysztof Hałasa. 

 

Cześć, Krzysztof, bardzo miło mi gościć Cię w podcaście.

 

Cześć, Krzysztof, mój imienniku. Tak się zastanawiam, jak nasi widzowie teraz, jak będziemy sobie tak krzysztofować, ogarną, kto jest kto. Ale myślę, że damy radę. Będą mieli taką małą zagwozdkę intelektualną, żeby rozpoznawać nasze głosy. 

 

Tak jest. Wiesz, dwóch Krzysztofów w jednym podcaście to już zaczyna się dobrze, ale jednak dzisiaj skupimy się głównie na tym temacie, który mam wrażenie, że pojawia się coraz częściej gdzieś na jakichś blogach, YouTubach, internetach, na konferencjach, w TechRadarach, więc warto pewnie o nim tutaj powiedzieć i też skorzystać z twojego doświadczenia. Mowa tutaj oczywiście o Platform Engineeringu, czyli inżynierii platform. To jest ten temat, którym się specjalizujesz, masz dużo do powiedzenia, więc dzisiaj spróbuję tę wiedzę z ciebie wyciągnąć. 

Ale zanim do tego przejdziemy, to chciałbym Cię tak klasycznie i standardowo zapytać o to, czy słuchasz podcastów, no i może masz jakieś ciekawe audycje, o których chciałbyś powiedzieć? 

 

To ja odpowiem nietypowo dość, bo więcej słucham podcastów tak prywatnie niż zawodowo, aczkolwiek bardzo często te obszary potrafią mi się przenikać. Najczęściej słucham Radia Naukowego i Podcastu Historycznego, jakby tak bardziej hobbystycznie. Jeżeli chodzi o IT, to tam mam kilka takich podcastów albo bardziej może kanałów na YouTubie, które słucham po prostu w formie podcastu bez wideo. Tak najczęściej to mam GOTO Conference i Continuous Delivery z takich anglojęzycznych. 

Polskojęzycznych, powiem szczerze, słucham bardzo mało i nawet nie będę Ci w stanie wymienić nazw. To głównie wynika z tego, że ja się uczę raczej przez wzrok niż przez słuch, dlatego jak coś potrzebuję zawodowo, to wolę przeczytać jakiegoś bloga, wolę przeczytać jakąś książkę, tych książek to czytam całkiem sporo, niż posłuchać podcastu i podcast i w ogóle słuchanie traktuję bardziej jako rozrywkę, która tam też trochę ma mnie ubogacić. Natomiast wszystkim dookoła polecam odwrotnie, niż ja robię, bo jakby imersja w temacie na pewno jest lepsza, jeżeli się go słucha. Zwłaszcza w temacie, który gdzieś tam być może jest jakoś tam zawodowo związany i może nie jest naszym hobby, bo tak się składa, że IT jest chyba największym moim hobby, dlatego nie mam problemu z osiągnięciem tej imersji w formie czytanej, czy w formie takiej warsztatowej. 

 

Jasne, każdy ma inne preferencje, inaczej lubi się uczyć. Dobrze, to weźmy na tapet ten Platform Engineering. Czy Ty widzisz w tym pojęciu swego rodzaju buzzword, który tak de facto ciężko jest wytłumaczyć w jednym zdaniu, czy też może jakieś konkretne według Ciebie definicje możemy tutaj rzucić do eteru? Bo często mówisz o tym, że ten Platform Engineering to jest taki DevOps trochę w nowym wydaniu. Czy tak faktycznie jest? Jak Ty w ogóle definiujesz Platform Engineering? 

 

Ja myślę, że to jest nazwanie czegoś, co w IT już jest od dawna. Od naprawdę bardzo dawna, od kiedy w ogóle DevOps się pojawiło jako takie. Tylko nie było tak nazwane. Po prostu nikt tego nigdy nie nazwał. O co chodzi z tym Platform Engineeringiem? Podam przykład. Jak idziemy do salonu samochodowego i kupujemy sobie samochód, to jak jesteśmy zwykłymi kierowcami, no to przeważnie mówimy: dobra, to chcę mniej więcej taki model, bo mi się podoba taka wersja wyposażenia, bo jest fajna, taki kolor, super, nie? I gdzieś tam taki przedział cenowy. I ten sprzedawca albo nam pomaga wybrać, albo wręcz już przychodzimy do niego z gotowym pomysłem na nasz samochód i tylko tam dopytuje jakieś szczegóły typu kolor tapicerki, whatever, prawda? 

I generalnie myśmy się przyzwyczaili, że to tak działa, natomiast to nie zawsze tak działało. Sto lat temu, jak się kupowało samochody, to podejrzewam, że rozmowa była dużo bardziej techniczna. Tzn. musieliśmy temu wykonawcy samochodu, którym była manufaktura, powiedzieć dużo więcej naszych preferencji, typu pewnie czy silnik chcemy mieć sto lat temu elektryczny czy spalinowy, bo wtedy też już były, tylko się nie przyjęły w tamtym czasie, ile chcemy mieć siedzeń, jaka ładowność itd., dlatego że samochody nie były tak wystandaryzowane. 

Dzisiaj gdybyśmy przyszli do salonu samochodowego, a sprzedawca by nas zapytał, słuchaj, a Ty chcesz mieć te cylindry pracujące tam w pionie, w poziomie czy w takim? Chcesz, żeby mieszanka paliwowa miała 80% benzyny, 20% tlenu? Zmyślam teraz, bo się totalnie na tym nie znam, ale jakby nam zaczął zadawać tego typu pytania, a tłoki to mają być kute czy spawane, to byśmy prawdopodobnie z tego salonu samochodowego wyszli i stwierdzili, że ten dostawca to jakiś odklejony jest i jakaś jedna wielka nerdoza się tu uprawia. 

Natomiast w IT bardzo często właśnie tak to działa, czyli przychodzi programista do admina i mówi: słuchaj, ja mam taką apkę do zbudowania dla tego mojego biznesu, chcemy mieć tam 100 użytkowników. Chcę, żeby się integrowała z CRM-em i SAP-em i chce, żeby miała wysoką dostępność. Ja ją będę pisał, ja potrzebuję wszystkiego, żeby napisać tę aplikację. Po czym admin go pyta, a jaki rząd IP-ków mam Ci zarezerwować? I ten programista robi takie wielkie oczy, bo nie zna się na administratorce. 

I Platform Engineering trochę jakby próbuje odwrócić tę sytuację, tzn. jako DevOpsi, jako administratorzy, jako sieciowcy, jako ludzie od infrastruktury przestajemy mówić w naszym języku do programistów, czyli nie pytamy go np. o namespace’y na Kubernetesie, nie pytamy go o jakieś takie naprawdę niskopoziomowe rzeczy, tylko pytamy: drogi programisto, co ty chcesz osiągnąć? Czyli tak jakbyśmy potraktowali programistę, klienta tego nowoczesnego salonu samochodowego, to Platform Engineering jest de facto właśnie takim podejściem do DevOps, czyli dalej automatyzujemy, dalej robimy wszystko to, co robiliśmy w DevOpsie, ale dokładamy do tego tą taką, powiedzmy, programistocentryczność, tę klientocentryczność jakby i to takie podejście produktowe, czyli nie, że ja mam teraz projekt postawienia OpenShifta, tylko ja muszę mojej organizacji dostarczyć zasoby do tego, jakby zdolności do tego, żeby moi programiści szybko uruchamiali aplikacje biznesowe. 

I tym jest Platform Engineering, więc jest to z jednej strony trochę dla ludzi, którzy chcą się podpiąć pod buzzword i niekoniecznie rozumieją, czym Platform Engineering jest, to wiele osób się skupia tylko i wyłącznie na portalach dla programistów i mówią, że Platform Engineering to jest stawianie instancji backstage’owych, to jest tam robienie orkiestracji na crossplane’ach itd. To jest absolutna bzdura, to jest totalne zaprzeczenie tego, czym Platform Engineering de facto jest. Bo możesz nie mieć portalu dla programistów, możesz nie mieć tej orkiestracji, a dalej mieć Platform Engineering. 

Ja powiem coś więcej, możesz mieć wirtualne maszyny, możesz mieć stare dziesięcioletnie Jenkinsy, ale jak udostępniasz to jako usługę, tak żeby ten programista nie musiał się wgłębiać, jak to działa i dawać Ci tam 40 różnych parametrów do tego, żebyś Ty łaskawie mógł to skonfigurować, to masz platformę, nie? Więc cała masa ludzi myśli, że to jest właśnie ten backstage, ten crossplane itd., a to tak naprawdę chodzi o pewną mentalność admina. Mentalność administratora, mentalność sieciowca, mentalność devopsa, który orientuje się na tego programistę, a nie orientuje się na technologię. 

 

Jasne. To odczepiliśmy się od tego buzzwordu, wiemy, czym jest platform engineering. Chciałbym Cię zapytać, czy według Ciebie istnieje pewna wielkość, skala firmy czy projektu, gdzie z punktu widzenia pracodawcy jest sens inwestować w taki zespół Platform Engineeringowy, że tak to nazwę. 

Bo wiesz, jak sobie ruszamy z jakimś projektem albo nie ma on jeszcze takiego zapotrzebowania na różnego typu usługi itd., to jesteśmy sobie jakoś tam w stanie sami poradzić, nie ma takiej potrzeby. 

Więc myślę, że tutaj nie ma takiej swego rodzaju heurystyki, że osiągamy jakąś tam wielkość, jakąś złożoność, jakakolwiek byśmy chcieli to mierzyć, i wtedy dopiero ten platform engineering wnosi tę największą wartość, ale może mnie wyprowadzisz z błędu i powiesz, że jak najbardziej jest sens w to inwestować już od początku, bo to nam coś przyspiesza, ułatwia, ustawia pewne praktyki. 

 

To powiem tak, ci od buzzwordów powiedzieliby Ci, że tak, że wszędzie, zawsze i koniecznie, a ja Ci powiem, że rzadko. Co to znaczy rzadko? Rzadko to znaczy, Platform Engineering moim zdaniem ma sens, jeżeli masz więcej niż pięć zespołów programistycznych, bo dla pięciu to już się zaczyna gdzieś tam kalkulować, jeżeli dostarczasz software samodzielnie albo konfigurujesz ten software samodzielnie, albo masz wielu vendorów, którzy Ci to robią i chcesz, żeby robili to w sposób gdzieś tam w miarę ustandaryzowany, wtedy ma to sens. 

Pewnie ma to też sens, jeżeli wiesz, że ta aplikacja biznesowa będzie bardzo złożona, to wtedy jakby wyciągnięcie przed nawias zarządzania wszystkimi narzędziami do tego, żeby zbudować tę aplikację, to też będzie miało sens po to, żeby odciążyć ten zespół, który tę aplikację będzie budował. Natomiast jak masz taką standardową, powiedzmy, małą organizację, która tam ma, nie wiem, trzy zespoły wytwórcze, to powiem szczerze, że ja sensu nie widzę, dlatego że platforma jest pewną inwestycją. 

My po pierwsze musimy wybrać sobie wystandaryzowane narzędzia do tego, żeby robić software na nich, co też już jest przy małej organizacji być może nawet zaburzyć pewną zwinność tych trzech zespołów, jakie mamy. I wtedy ta zwinność vs standaryzacja nam się przestaje kleić. Potem musimy te narzędzia opakować w usługę, czyli musimy nałożyć na nie pewną warstwę abstrakcji, zarówno taką organizacyjną, jak i technologiczną, porobić te orkiestratory itd. po to, żeby takie żądanie programisty, że ja chcę budować nowy software, orkiestrować w tych wszystkich narzędziach. Czyli jak ja chcę robić nowy software, to tam na Kubernetesie muszę porobić namespaces, w Observability muszę porobić jakieś indeksy, muszę stworzyć jakieś miejsce w bazie danych, muszę stworzyć jakieś repo kodu, repo artefaktów, itd. Przestrzeń na to, żeby ci programiści mogli robić ten swój software. 

To raczej działa w dużej skali. Jak robisz to często, to automatyzacja tego typu i osobny zespół, który się tym zajmuje, ma sens. Jak robisz to raz, albo robisz to rzadko, to wyciąganie tego do osobnego zespołu trochę mija się z celem, bo ten zespół się będzie nudził. Platform Engineering fajnie działa na pewno w dużych organizacjach, w średnich organizacjach, które gdzieś tam dużo dowożą softu same albo dużo skupują i zarządzają vendorami, natomiast w takich mniejszych firmach czy jeżeli kupujemy gotowe produkty z półki, to ja nie wiem, czy my tego faktycznie potrzebujemy. 

To jest zawsze jakaś tam decyzja. Te pięć zespołów podałem jako taki gdzieś tam przykład. To nie zawsze musi być pięć. To może być dziesięć, to może być trzy. Zawsze warto najpierw zbadać, jak organizacja dostarcza software i jak pozyskuje w ogóle software, czy to dostarcza, czy kupuje itd. I na tej podstawie gdzieś tam zbudować sobie business case. Na pewno są pewne powtarzalne rzeczy, które występują często, które warto platformie oddać, tak żeby programiści się skupiali na tej swojej aplikacji już bardziej biznesowo niż technologicznie. 

To raczej działa w dużej skali. Jak robisz to często, to automatyzacja tego typu i osobny zespół, który się tym zajmuje, ma sens. Jak robisz to raz, albo robisz to rzadko, to wyciąganie tego do osobnego zespołu trochę mija się z celem, bo ten zespół się będzie nudził. Platform Engineering fajnie działa na pewno w dużych organizacjach, w średnich organizacjach, które gdzieś tam dużo dowożą softu same albo dużo skupują i zarządzają vendorami, natomiast w takich mniejszych firmach czy jeżeli kupujemy gotowe produkty z półki, to ja nie wiem, czy my tego faktycznie potrzebujemy.

 

Dzięki za takie fair postawienie sprawy. Nie próbujesz tutaj na siłę ewangelizować, tylko faktycznie mówić, jak rzeczy wyglądają. Jestem w związku z tym ciekawy, skąd, w jaki sposób pojawiło się u Ciebie zainteresowanie Platform Engineeringiem, bo wcześniej pracowałeś jako analityk, jako programista, jako menadżer. Miałaś okazję obserwować, jakie są efekty Twojej pracy, takie bezpośrednie. Miałaś okazję dostawać feedback od różnych grup, od klientów pewnie też, to zawsze jest takie, że tak powiem, pomocne w wykonywaniu tych naszych obowiązków, jakiś rodzaj uznania, widzimy efekty swojej pracy. 

W przypadku platform engineeringu, no nie wiem, zastanawiam się, czy te efekty pracy są na tyle od razu widoczne i czy to uznanie, to podziękowanie za tę pracę jest wystarczające. W związku z tym jestem ciekaw, skąd u Ciebie właśnie takie zainteresowanie w ogóle tym obszarem IT się pojawiło. 

 

One się pojawiło z hejtu. W sensie może bardziej z takiego wkurzenia na to, że ja lubię rzeczy robić dość szybko. Ja lubię rzeczy wypuszczać na produkcję bardzo szybko. Zdarzało mi się to zrobić za szybko. I potem gdzieś były z tym związane problemy, ale bardzo lubię testować pewne rzeczy. Taki mam charakter, że raczej jestem niecierpliwy, jeżeli chodzi o takie zawodowe tematy. 

I jak byłem tym architektem, byłem tym programistą kiedyś, to zawsze mnie wkurzało, że np. na infrastrukturę ja muszę tyle czekać. Albo, że zrobiłem swój software, po czym przychodziło wredne security i mi tam pałowało ten mój software. Albo, że jak chciałem wejść na produkcję, to musiałem jakichś tam DevOpsów prosić o pipeliny, żeby tego nie wrzucać ręcznie. Czasem na tyle się nie mogłem doczekać, że wrzucałem ręcznie i potem z tego były problemy. To już stare dzieje są, natomiast gdzieś tam, mimo że jestem inżynierem IT, to zawsze bardziej wolałem tematy biznesowe niż technologiczne. 

Mnie, powiem szczerze, nigdy pisanie kodu dla kodu nie jarało. Mnie nigdy nie jarała optymalizacja kodu. Mnie nigdy nie jarało pisanie pięknego kodu. To pewnie wielu się teraz obruszy. Natomiast mnie bardziej jarało to, żeby zobaczyć, że ten biznes z tego kodu korzysta i żeby to przynosiło po prostu kasę organizacji. 

I Platform Engineering mi się wziął z tego, że gdzieś tam pracując dla BlueSoftu w 2020 roku trafiłem na taki duży projekt transformacji w takim dużym banku na Ukrainie, który jakby miał pomysł na to, żeby bardzo dużo softu po prostu zrobić na nowo, bo mieli wcześniej stare legacy systemy, które tam nie odpowiadały temu biznesowi. I jedną z takich strategicznych decyzji, jakie podjął ten bank po namowie mojego mentora, który mnie wtedy szkolił jak robić consulting, właśnie żeby zainwestować w platformę. To się wtedy chyba nawet jeszcze nie nazywało Platform Engineering, albo się zaczynało nazywać platform engineering. Natomiast ja się zajarałem, bo to mi od razu otworzyło w głowie, mówię: kurde, te wszystkie rzeczy, które mnie wkurzały do tej pory, to ja mogę teraz samemu sobie z przeszłości naprawić. 

Więc ja się zaangażowałem w to DevOpsowanie nie jako devops, bo ja nigdy nie byłem adminem, nigdy nie byłem sieciowcem. Ja się totalnie nie znam na networkingu na przykład. Natomiast byłem analitykiem. Ja mniej więcej jestem w stanie zdekomponować zadania na mniejsze i powiedzieć, jaka jest moja potrzeba, a potem tę potrzebę przekuć w jakieś rozwiązanie. I to robiłem jako analityk, jako architekt, więc stwierdziłem, dobra, to teraz zrobię to samo, tylko klientem moim będzie programista. I potraktuję programistę jak klienta, jako mój biznes, i ja temu biznesowi postaram się zbudować system do robienia i utrzymywania innych systemów. 

I od tamtej pory się to wzięło. Popełniłem całą masę błędów, robiąc to. Wypracowałem sobie pewien framework taki analityczny podchodzenia do tych tematów, badania tego, czego ci programiści potrzebują i tak od czterech lat to robię. Z coraz większymi sukcesami, bo oczywiście na początek jak się coś robi, to wiadomo, zwłaszcza w temacie, który jest nowy, to wiadomo, że tam płynęliśmy w różnych dziwnych kierunkach. Natomiast dzisiaj jest to nadal moja jakaś tam zajawka, bo widzę, ile to korzyści biznesowych przynosi. Nie tylko tym programistom, ale w ogóle temu, jak to transformuje organizację. 

Więc tak trochę naokoło. Nie od DevOpsa. Ja się Kubernetesa uczyłem dopiero jako Platform Engineer, a nie jako architekt. Więc zupełnie od innej strony mam wrażenie potrzebem do tematu DevOpsowania niż taka standardowa ścieżka. 

 

Mam wrażenie, że to jest takie dosyć unikalne tutaj podejście, które prezentujesz, że tak naprawdę widzisz w tym korzyści dla biznesu, niekoniecznie wychodzisz od tej strony technicznej. Mam wrażenie, że to się najczęściej właśnie tutaj pojawia z tej strony, że widzimy korzyści od strony technologii, od strony procesu tego technologicznego, a nie przełożenie tego na biznes.

 

Jest to naturalne, prawda? Jakby dla środowiska DevOpsów i administratorów jest to naturalne, bo jakby oni patrząc z swojej perspektywy, jak mam Platform Engineering, mam orkiestratory, to nie muszę, nie wiem, ręcznie robić namespaces, tak? Albo nie muszę tam ręcznie do Argo Project dopisywać czegoś. I jakby on widzi w tym korzyść, bo on oszczędza czas. W szerszej perspektywie ten czas oszczędzony u niego to jest najmniejszy pikuś. Najwięcej korzyści jest wszędzie dookoła. Przez to, że ci ludzie, którzy faktycznie potrzebują wpisać coś do Argo Project, to na niego nie czekają. Jakby policzyć jego czas vs czas tych 14 innych osób, to nagle się okazuje, że tutaj naprawdę spore kasy można zaoszczędzić.

 

No dobrze, to skoro wiemy, że jest dużo korzyści stojących za Platform Engineeringiem, to pewnie wyobrażam sobie, że są takie dwie drogi albo dwa sposoby, na jakie ten Platform Engineering się pojawia w organizacji. Jeden taki ten oddolny, o którym tutaj mówimy, czyli inżynierowie po prostu widzą korzyści z codziennej pracy, z ułatwiania, z automatyzacji, przyspieszania, albo drugi gdzieś może rzadszy, mam wrażenie, gdzie kierownik, menadżer, szef gdzieś na jakiejś konferencji od kogoś innego się dowiedział, że coś takiego istnieje i może warto to u nas wprowadzić.

Ale skoro mamy tutaj tych inżynierów, którzy jak gdyby najszybciej pewnie zauważą taką potrzebę, to jak oni są w stanie sprzedać tę koncepcję, jak zarazić zarząd, kierownictwo do tego, że idźmy w tym kierunku, warto coś tutaj w tym kierunku zrobić?

 

To jest super fajne pytanie i takie super istotne, bo powiedziałeś o dwóch ścieżkach, oddolnej i odgórnej i ja preferuję odgórną i teraz powiem dlaczego. Na początku mi się wydawało, że ten oddolny nurt jest lepszy, bo my rozumiemy, co mamy zrobić jako inżynierowie, my widzimy korzyści itd., to po prostu zacznijmy to robić, zacznijmy budować te orkiestratory, zacznijmy udostępniać te usługi itd., tylko to wyjdzie, to raczej wyjdzie w organizacji, która już jest jako tako zwinna, czyli takiej organizacji, która już ma pewne myślenie produktowe, już od tego zespołu DevOpsowego jest oczekiwany bardziej biznesowy rezultat, powiedzmy. Mają pewne SLA itd. na takie bardziej już biznesowe rzeczy. Biznesowe z ich perspektywy, czyli np. dostępność środowisk, albo onboarding programisty itd., to naturalnie wtedy ta platforma im wyjdzie.

Natomiast organizacje, które dopiero zaczynają i które są w tych core’owych zespołach IT poukładane bardzo silosowo, to znaczy, że mamy gości od baz danych, mamy gości od infrastruktury, mamy osobny zespół security, osobny zespół od sieci, osobny zespół od kawki itd., to oddolnie to nie wyjdzie. I teraz, dlaczego to nie wyjdzie? Dlatego, że platforma to jest przede wszystkim zmiana mentalna i zmiana organizacyjna. Tzn. my patrzymy na IT jako na centrum usługowe, a nie jako centrum kosztowe i nie jako centrum, powiedzmy, kompetencyjne.

Musimy trochę zmienić filozofię działania firmy. Czasem musimy wręcz przeorganizować sobie zespoły. Musimy stworzyć sobie zespół platformy, który będzie miał władzę w tych wszystkich narzędziach, których potrzebuje, żeby świadczyć swoją sługę, to znaczy musi mieć admina na tym Kubernetesie, musi mieć administracyjny dostęp do jakichś tam sieci, nie sieci itd., co w dużych silosowo poukładanych organizacjach często się ze sobą gryzie, dlatego, że ci ludzie, którzy dzisiaj odpowiadają za to, na przykład ci sieciowcy, to się boją, że ci platformowcy im coś zepsują i potem jak coś się zepsuje, to oni będą musieli naprawiać, ich KPI będą leciały w dół itd.

Dlatego jest to bardziej zmiana organizacyjna niż technologiczna i jakby zmiany organizacyjne od dołu nie da się zrobić, znaczy, nie da, jest to bardzo trudne i jakby bardzo dużo krwi się wyleje, zanim to dojdzie do góry, gdzie góra zauważy potrzebę tej zmiany. Dlatego ja wolę, szczerze mówiąc, właśnie od góry zaczynać. Czyli nawet pogadać z tymi inżynierami i nawet jeżeli to oni mają iść do tej góry, to żeby mieli argumenty.

I przeważnie używam argumentu kasy, bo z góry najlepiej się po prostu gada albo efektywnością, albo kasą, co jest de facto tą samą rzeczą, tylko inaczej zmierzoną. I liczę np., ile trwa onboarding nowego dewelopera w organizacji. Ile ten developer zarabia, jak on zarabia 150 zł za godzinę i on przez tydzień nie jest w stanie napisać linijki kodu, bo coś tam trzeba mu jeszcze tam dostarczyć, to już jest realna kasa. Jakiś jeden przykład.

Drugi przykład. Odpalacie nową inicjatywę albo stara inicjatywa gdzieś tam zaczyna mieć jakieś problemy wydajnościowe, to to ile Wam zajmuje, żeby przygotować wszystko do uruchomienia tej nowej inicjatywy, albo żeby np. naprawić te problemy wydajnościowe, zwiększyć infrastrukturę, pamięć czy cokolwiek, dorzucić serwerków. Ile Wam to zajmuje?

Albo ile macie problemów z security? Np. jak macie proces wytwórczy, to ile w tym procesie wytwórczym zajmuje analiza, development, a potem ile od takiego czegoś, co już jest gotowe, powiedzmy wewnętrznie przetestowane przez programistów do wrzucenia na produkcję. Jaki to jest czas? I jakby w tym czasie to są wszystkie takie elementy, które normalnie platforma adresuje w kilkanaście minut.

I ja w tym czasie po prostu liczę ten czas. Mówię, słuchajcie, jeżeli 14 developerów, to jest fajny przykład, macie 60 deweloperów w organizacji. I na każdy release, na każdą jakąś nową inicjatywę średnio tydzień Wam zajmują takie technologiczne aspekty. I macie powiedzmy jeden release w miesiącu per zespół. Czasem oczywiście jak będzie nowy zespół, to będzie dużo dłużej trwało, istniejący zespół tam powiedzmy 3 dni, no ale jakby summa summarum będzie to tylko tydzień, co i tak jest szybko przy dużych organizacjach, to to kosztuje 5 mln zł rocznie to jakbyśmy te 5 mln zł wzięli i podpalili, i tak co roku.

Za to można już platformę zbudować, za ułamek tej kwoty można zbudować platformę i można te tematy zaadresować. Ja sobie patrzę, jak organizacja działa, robię sobie takie ćwiczenie np. value stream mapping z różnymi zespołami i patrzę, ile im takie powtarzalne z perspektywy procesu wytwórczego zadania zajmują i w tym szukam po prostu biznes case’a dla platformy.

 

Bo to jest jakiś rodzaj inwestycji, ale inwestycja, która relatywnie szybko zacznie się tutaj spłacać. Warto w tym kierunku iść. Ale czy według Ciebie są jakieś alternatywy, powiedzmy, do tego podejścia? Czy takie, wiesz, ułożenie tych narzędzi, tych kompetencji DevOpsowych w firmie w myśl właśnie Platform Engineering jest najlepszym, co udało nam się do tej pory osiągnąć? Czy też może znasz jakieś inne podejścia?

 

To nie jest najlepsze, co nam się udało osiągnąć, bo jakby z samego faktu tego, że to jest inwestycja, że to jest standaryzacja pewnych narzędzi DevOpsowych, przez standaryzację niestety odbieramy sobie czasem trochę pewnej elastyczności. Dobrym przykładem jest AI. Np. jeżeli mamy poukładany platformowo zespół i wchodzi zupełnie nowy obszar do organizacji, to ja bym tego obszaru nie dawał platformie, bo jakby standaryzacja na dzień dobry może nie jest najlepszym pomysłem. Może najpierw właśnie pozwólmy na pewien chaos. Niech sobie te zespoły faktycznie same poeksperymentują z różnymi rzeczami i dopiero potem, jak będziemy mieli dane, to może dopiero to standaryzujmy.

Więc platforma nie tylko taka DevOpsowa, nie wiem, Data’owa, nie Data’owa, tu można naprawdę wiele różnych platform budować. One się nadają do rzeczy, które już są w miarę wygrzane i powtarzalne. DevOpsowanie moim zdaniem dzisiaj jest już wygrzane i powtarzalne. Nie wiem, 6 lat temu, 7 lat temu jeszcze nie było.

Był Kubernetes i on zawsze był wiodący, ale mieliśmy masę różnych jeszcze jakichś alternatyw do tego. Mieliśmy tego Serverlessa, który gdzieś tam cały czas próbuje znaleźć swoje miejsce i być może będzie w ogóle przyszłością Platform Engineeringu, ale jakby to są rzeczy, w których gdzieś tam tych praktyk może jeszcze nie ma do końca jakby wygrzanych, zwłaszcza w takich standardowych biznesach, bo tam Netflixy, Spotify to wiadomo, że to mają, ale to jakby robienie transformacji cyfrowej, bo Netflix robi, to trochę głupi pomysł jest, na inną dyskusję, myślę.

Natomiast w takich standardowych obszarach warto robić platformę. W obszarach, gdzie np. kupujemy systemy, które mają specyficzne wymagania, specyficzny runtime itd., to nie ma sensu, bo albo ograniczamy sobie wybór dostępnych produktów na rynku, które możemy dla biznesu kupić, albo będziemy musieli wejść w batalię z tym vendorem, żeby tam nam dostosował do platformy. Będą zespoły jakieś R&D, które być może standardowe narzędzia platformowe dla nich będą niewystarczające, bo wymagają lepszej latencji na przykład, albo wymagają większej elastyczności w uruchamianiu, cokolwiek. Data jest dobrym przykładem.

Jak dasz Kubernetesa Date to ona bardzo szybko zabije tego Kubernetesa. W przypadku Daty to może lepiej dać Cloud’a, dać jakiegoś Serverlessa, czy dać możliwość uruchamiania instancji spotowych i niech oni sobie na tym działają sami, bo ten runtime jest bardzo blisko tej logiki. W przypadku takich klasycznych biznesowych zastosowań, klasycznych biznesowych aplikacji, które sami piszemy, platforma super. Natomiast to jest taki jeden przykład, więc raczej rzadziej właśnie platforma niż nie platforma. To nie jest Złoty Graal na pewno. Zresztą nic  w IT nie jest Złotym Graalem.

 

Właśnie, miałem o to zapytać, czy wiesz, takie porównanie, może porównanie to źle powiedziane, ale czy takie przyłożenie zwinności do Platform Engineeringu nie gryzie się ze sobą, tak? Czy to są takie dwa suwaki, że jak jeden przesuwasz, to drugi się automatycznie odsuwa, czy jesteśmy w stanie jakoś to pogodzić, a może po prostu trzeba patrzeć na konkretny przypadek, przykład i dobierać sobie, jak bardzo chcemy mieć tą platformę sztywną, a ile dajemy pola na zwinność, jak z Twojego doświadczenia to wynika?

 

To jest tak, najpierw zdefiniujmy sobie zwinność. Jak ja rozumiem zwinność, bo nie wszyscy chyba rozumieją to podobnie. Ja rozumiem zwinność jako zwinność w podejmowaniu decyzji biznesowych i w realizacji tych biznesowych feature’ów, czy dostarczania wartości dla biznesu. I ja w tym widzę zwinność.

Dobór np. języka oprogramowania platforma moim zdaniem powinna dawać. Czyli jeżeli mamy zespół, który w większości kompetencyjnie ogarnia Pythona, a platforma do tej pory wspierała tylko Javę, to warto tę platformę do tego Pythona dostosować. Dać jakąś demo aplikację, która jakby się buduje, ma CI/CD itd. i niech oni sobie dalej działają. Natomiast dla mnie zwinność nie polega na tym, że zespół ma być niezależny we wszystkim. On ma być niezależny w realizacji biznesowego celu. I myśmy mu powinni dać narzędzia do tego, żeby on to mógł robić.

Bo jeżeli np. on musi sam postawić Kubernetesa, sam sobie zrobić runtime itd., to on właśnie traci na tej zwinności. Bo on się skupia na rzeczach, które musi zrobić po to, żeby zrealizować swój cel. To jak mu to odetniemy, to on będzie moim zdaniem bardziej zwinny niż był.

Oczywiście platforma wprowadza pewną standaryzację, jeżeli chodzi o technologię, runtime itd. Wiele osób może się kłócić, że o to właśnie tracimy tę zwinność, natomiast ja właśnie uważam odwrotnie. My tę zwinność umożliwiamy platformom, bo przez to, że to wszystko jest wystandaryzowane, to właśnie potem nie przyjdzie mi zespół security i nie będzie mnie trzymał dwa tygodnie przed wejściem na produkcję. Czyli ja jestem niezależny od nich, bo ja już prekonfigurowane pewne techniczne elementy, które już są compliant z tym wszystkim, co ja mam w firmie.

Ja nie muszę czekać na DevOpsa, który mi pipeline napisze, bo platforma mi go daje na dzień dobry. Ja nie muszę teraz czekać na bazę danych, na repozytoria, na cokolwiek, bo to wszystko od platformy dostaję tam w 2 minuty, czy tam w 15 minut. Więc jakby ta zwinność taka wynikająca z self-serwisu, jaki ja sobie na platformie mogę jako developer doświadczyć, bez proszenia wszystkich dookoła o różne rzeczy.

Natomiast oczywiście runtime’u sobie nie wybiorę. Jeżeli będę chciał sobie uruchamiać coś na VM-ce, a organizacja nie wspiera VM-ki, to niestety będę musiał na tym Kubernetesie uruchamiać. Na dwoje babka wróżyła. Zależy to, jak definiuje zwinność.

 

Tutaj opisujesz, mam wrażenie, taki etap docelowy albo końcowy, gdzie mamy już tę platformę na tyle rozwiniętą, że daje nam ona spore możliwości w kontekście realizowania kolejnych pomysłów biznesowych, tak bym to nazwał, ale od czegoś trzeba zacząć. Jak wspominałeś swoje początki z tą właśnie przygodą, mówiłeś, że wiele różnych błędów popełniłeś, popełniliście, więc co na bazie tych doświadczeń byś teraz doradził tym, którzy właśnie z platformą chcą u siebie rozpocząć?

 

To będzie taka odpowiedź na poziomie strategicznym i na poziomie egzekucji, na poziomie takiego delivery. Na poziomie strategicznym to my musimy wiedzieć, że chcemy tę platformę zbudować. Czyli musi być decyzja w organizacji i musi być namaszczenie tego platform ownera, że on pewne rzeczy może w tej organizacji robić. Tzn. może mieć admina na tych różnych narzędziach, które być może kiedyś były w rękach innych zespołów, tudzież może własne narzędzia powołać. Gdzieś tam pewnie z architekturą korporacyjną musi być też dogadany itd. Więc na takim poziomie strategicznym musi taka decyzja paść.

Na poziomie wykonawczym, to jak każdy inny system, jaki budujemy, powinniśmy zacząć od analizy. Bardzo, bardzo, bardzo mało inicjatyw platformowych, tak jak obserwuję rynek, zaczyna się od analizy. Przeważnie się zaczyna od deploymentu backstage’a i na próbie orkiestracji jakichś tam namespaces’ów, co w krótkim terminie może nawet będzie przydatne, bo pokażemy już jakiegoś MVP, jakiegoś PoC-a i otworzymy dyskusję, natomiast zamknięcie tego projektu tylko w DevOpsowym światku skończy się tym, że devopsi będą się świetnie bawić nowymi narzędziami, ale niekoniecznie będą ułatwiali developerom życie.

Więc najpierw musimy zobaczyć, jak ci nasi developerzy pracują, jak oni mają dzisiaj praktyki, jak bardzo oni są dojrzali w tych praktykach. Podam taki przykład. Jak mamy organizację taką średnią, która ma mocno napięte deadline’y itd., developerów, którzy raczej nie devopsowali do tej pory dużo, to np. takie pipeliny CI/CD powinny być w platformie, czyli inżynierowie platformy powinni się zajmować tymi papilenami, tworzyć je, najlepiej wystandaryzowane i upewniać się, że one działają.

Natomiast jak mamy organizację, która ma trochę większą dojrzałość, mamy organizację, która naprawdę różne rzeczy, różne systemy pisze i np. quality checki będą zupełnie inne dla jednego systemu, dla drugiego systemu itd., tudzież mamy bardzo różne praktyki, czy to z powodów jakichś tam historycznych, czy tak sobie wybraliśmy, czy tak nas sytuacja rynkowa zmusiła, że mamy zespoły, które naprawdę pracują w różnych językach, to być może to CI/CD faktycznie powinno być po stronie zespołów.

Tylko takie rzeczy trzeba przeanalizować, za co powinna platforma odpowiadać, za co powinny zespoły odpowiadać, bo można przegiąć w dwie strony. Jak platforma będzie taka, że infantylizuje developerów, to oni się wkurzą. Inżynierowie lubią mieć jednak decyzyjność. Oni się wkurzą, że tej decyzyjności nie mają, tudzież nie mają jakichś uprawnień. Z drugiej strony, jak platforma będzie bardzo otwarta, a będziemy mieli zespoły, które tak średnio devopsowały i nagle im powiemy: no to sobie namespace’y w Terraformie zmieniajcie, to też oni polegną i bardzo szybko zacznie być bloker, więc to trzeba znaleźć taki złoty środek w każdej organizacji, dlatego tak ciężko jest też kupić gotową platformę z rynku.

Tylko takie rzeczy trzeba przeanalizować, za co powinna platforma odpowiadać, za co powinny zespoły odpowiadać, bo można przegiąć w dwie strony. Jak platforma będzie taka, że infantylizuje developerów, to oni się wkurzą. Inżynierowie lubią mieć jednak decyzyjność. Oni się wkurzą, że tej decyzyjności nie mają, tudzież nie mają jakichś uprawnień. Z drugiej strony, jak platforma będzie bardzo otwarta, a będziemy mieli zespoły, które tak średnio devopsowały i nagle im powiemy: no to sobie namespace’y w Terraformie zmieniajcie, to też oni polegną i bardzo szybko zacznie być bloker, więc to trzeba znaleźć taki złoty środek w każdej organizacji, dlatego tak ciężko jest też kupić gotową platformę z rynku.

 

Tak, Platform Engineering ma takie zadatki na teren technologiczny, mam wrażenie, ale myślę, jeśli tutaj mowa o trendach technologicznych, że nie da się pominąć dwóch mega istotnych trendów, czyli AI i automatyzacji, które wszędzie gdzieś tam swoje macki mają. Jak one wpływają na Platform Engineering w tym obecnym wydaniu?

 

Najlepszą odpowiedzią na to byłoby: nie wiem. Ale to nie wiem nie wynika z tego, że nie wiem, tylko dlatego, że chyba cały rynek jeszcze nie wie. Są różne próby, np. developerzy zamiast na portalu komunikowali się z platformą za pomocą jakiegoś chata wspieranego AI, czyli zamiast tam sobie wyklikiwać, że chcą nowe środowisko, to żeby z tym chatem właśnie porozmawiać i żeby ten chat zaczął sam dochodzić do tego, że dobra, czyli tak, ten developer będzie robił to, to będzie potrzebował tego, tego i tego.

Ja tu widzę pewną gigantyczną wartość i trochę game changer, dlatego że mając tak uniwersalny interfejs, jakim jest chat, my możemy stworzyć platformę w organizacji, która ma różne prędkości swojego IT. Tzn. ma zespoły zarówno bardzo dojrzałe, jak i bardzo niedojrzałe, i próbuje zachować wszystkie te zalety platformy i jednocześnie nie doprowadzić do chaosu. W tym widzę naprawdę duży trend, który pewnie się będzie pojawiał niedługo.

Pojawiają się już pierwsze wdrożenia. Osobiście jeszcze nie robiłem takiego wdrożenia, ale pojawiają się już pierwsze próby właśnie ubrania portalu dla programistów w chata, żeby ten chat gadał z programistami. To taki jakiś jeden przykład.

Na pewno AI będzie częścią platformy na takiej zasadzie, że jak już przetestujemy, będziemy mniej więcej wiedzieli, jakie modele językowe, czy jakie AI do jakich przypadków,  to też platforma będzie w stanie takie rzeczy na siebie wziąć. I np. developer nie będzie potrzebował się uczyć, jak indeksować jakieś tam dane wejściowe, tylko po prostu będzie ładował te dane wejściowe do platformy i platforma mu będzie tworzyła chat dla jego biznesu, który będzie mógł potem łatwo np. zinkorporować do swojej aplikacji biznesowej.

Albo będziemy mieli AI, które np. będą bardziej proaktywnie działały, jeżeli chodzi o operacyjne możliwości dawane programistom. Dzisiaj, jeżeli programista chce coś zbugfiksować, to platforma mu daje dashboard z tą aplikacją, tam ma wszystkie metryki, wszystkie logi są w jednym miejscu itd., ale już np. takie bugfiksowanie, że tam szuka czegoś w tych logach, patrzy, jaki jest root cause itd, to już musi zacząć robić sam.

I oczywiście są takie narzędzia w platformach, że tam ifami potrafią lecieć po różnych rzeczach i takie bardzo podstawowe rzeczy potrafią naprawić, natomiast to trzeba zakodować. A przy AI nie trzeba będzie tego kodować. Jeżeli damy AI-owy interfejs, który sam będzie leciał po logach i na podstawie logów będzie się uczył, jak dany system działa, to być może za chwilę pewne takie proste rzeczy albo rzeczy, które były podobne do tego, co już kiedyś wystąpiły, będzie w stanie naprawić i wtedy ten inżynier operacyjny będzie dostawał case’a, którego AI nie rozwiązał. On już będzie wiedział, że to nie jest non-issue.

Albo bardzo duże prawdopodobieństwo jest, że to nie jest non-issue i ja się tu faktycznie muszę zgłębić, platforma może powiedzieć mu, że to i to próbowałem i to nie zadziałało. To jest gigantyczna oszczędność czasu. Jest takie rozwiązanie, które właśnie w BlueSoftcie rozwijamy, ono się nazywa CodeZilla, które właśnie to adresuje. I to jest też część platformy. Więc w tym widzę wartość AI.

Oprócz tego, że gdzieś tam pewnie platforma może też inkorporować w sobie jakiegoś tam co-pilota itd., który będzie pomagał tym programistom budować aplikacje, czy pomagał tym devopsom budować narzędzia platformowe. Takie typowe zastosowanie. To jest pewnie jakiś tam ułamek możliwości zastosowania AI. Na razie mam wrażenie, że wszyscy się tego uczymy. Jakieś tam pierwsze case studies się pojawiają. Natomiast gdzieś tam chyba jak mamy ten Gartner’s hype cycle, to pewnie za chwilę będziemy na tym dole, gdzie się trochę rozczarujemy możliwościami AI. Póki co wszyscy są na hype i póki co wszyscy testują.

 

Tak. Coraz częściej gdzieś tam słyszę takie pogłoski o tym, że ta zima następna przyjdzie, ale jak sobie patrzę na te różne konferencje od OpenAI czy Google’a, to tak się zastanawiam, czy ona faktycznie będzie. Zobaczymy, oczywiście czas pokaże. Natomiast tak podsumowując to, co powiedziałeś, to uproszczenie, ułatwienie, a jednocześnie podniesienie tego developer experience, to są właśnie pewnie te elementy, czy takie korzyści, które wynikają z zastosowania AI i automatyzacji w Platform Engineeringu.

Wiesz, coraz częściej też mam wrażenie, pojawiają się w ogóle oferty pracy tak stricte dedykowane do platform i inżynierów. Nieraz to jest troszkę ukryte pod pojęciem jakiegoś tam DevOps Engineera, który de facto będzie się tym zajmował, ale też chciałbym Cię zapytać z Twojej perspektywy, jakie są takie główne, kluczowe umiejętności, kompetencje, które taki inżynier platformy powinien znać, wiedzieć, mieć doświadczenie, aby być atrakcyjnym na rynku pracy?

 

Podzieliłbym to na dwie kategorie, na inżyniera platformy, jakiego wspomniałeś i na architekta, tudzież jakiegoś tam managera platformy. Będą to troszkę inne kompetencje, troszkę inny nacisk. Zacznę od tego drugiego, bo ostatnio właśnie ciekawa oferta pracy była od XTB, takiego właśnie managera platformy. I oni dokładnie napisali tak ofertę, jak ona powinna być na taką osobę napisana. Tzn. powiedzieli, że będzie miała wpływ w organizacji na to, jak tą platformę zbudować, były napisane strategiczne cele platformy oraz było napisane, co ta osoba powinna potrafić.

I co taki menedżer powinien potrafić? On przede wszystkim powinien wiedzieć, jak software delivery life cycle wygląda i gdzieś tam przejść tę ścieżkę naprawdę w te i we w te. Pracować w utrzymaniu, pracować w delivery itd., bo dzięki temu on będzie rozumiał tego klienta swojego, czyli tego programistę, czy tego gościa od operacji. Musi myśleć produktocentrycznie, musi znać metody analityczne, żeby dojść do tego, w jaki sposób zbudować produkt. Musi umieć zbudować biznes case’a na ten produkt itd., itd. To z jednej strony.

Z drugiej strony musi rozumieć technologię, jaka jest za tym, pod tą platformą. Musi rozumieć, jak Kubernetes działa i jakie daje możliwości. Musi wiedzieć, jakie możliwości daje Serverless, jakie są koszty tego wszystkiego, jak działają narzędzia observability, jak działają narzędzia, które gdzieś tam, code quality nam sprawdzają, jakieś Sonar Cuby czy Selenium itd. Menedżer czy architekt raczej na takim poziomie koncepcyjnym i mniej więcej ograniczeń tych narzędzi. No fajnie, jak potrafi sam te narzędzia postawić w takiej dojrzałości, żeby się nadawały na produkcję, natomiast ja bym powiedział, że to nie jest jakiś super must. Natomiast to jest super must dla tego inżyniera, który będzie robił.

Czyli jakby inżynier taki platformowy oprócz tego powinien być DevOpsem, czyli jakby cały ten stack DevOpsowy powinien znać, Kubernetes, CI/CD, przynajmniej jakaś jedna technologia do pisania pipeline’ów, przynajmniej jakieś podstawy sieci itd., więc taki mix typowego DevOpsa.

Przy platformie ja bym nałożył jeszcze dwie rzeczy. Pierwsza rzecz to umiejętności analityczne. Fajnie jakby on mi potrafił wskazać kilka metod analitycznych, jakie może stosować do tego, żeby wyciągnąć od programisty, czego on potrzebuje. Jakby pogadał z takim programistą, to zdecydowanie. Bo jeżeli on nie będzie w stanie używać języka programisty, to raczej jego menedżer powinien go przykrywać w takim zespole platformowym. A jego dążeniem powinno być to, żeby przestał być przykrywany. Więc to jest jakaś tam jedna umiejętność.

A druga umiejętność, no to fajnie, jak jednak ogarnia trochę frontend. Po to, żeby tego backstage’a jak już dojdzie do budowania portalu, to fajnie, żeby potrafił to robić. To nie musi być rocket science, bo to są przeważnie systemy kierowane wewnętrznie, więc one nie muszą być super piękne. Natomiast jakieś tam podstawy warto znać, jakieś technologii frontendowej, no i standardowy stack DevOpsowy, Terraformy itd.

 

Tych obszarów wiedzy, doświadczenia trochę jest. Czy jesteś w stanie polecić jakieś źródła, miejsca, gdzie się tego można poduczyć, dowiedzieć, zaczerpnąć trochę inspiracji?

 

Dużo się pojawia w CNCF-ie ostatnio fajnych white paperów. Na Slacku CNCF-u jest taka grupka Working Group Platforms i tam dużo właśnie takich tematów platformowych, zarówno tych strategicznych, jak i technologicznych się pojawia, więc warto tam sobie czytać, co CNCF wypuszcza i patrzeć, co tam robią. To jest jakaś tam jedna rzecz.

Druga rzecz to kolejny Slack, już dedykowany stricte Platform Engineering, platformengineering.org. Tam też się pojawia bardzo dużo różnych materiałów, też są rozpisywane ścieżki karier dla platform inżynierów itd. Już bardziej skupione na tej części Platform Engineeringu, a nie tylko na technologicznej, jak w CNCF przeważnie jest, więc tam warto na pewno sobie śledzić.

Dużo jest meetupów. Platformengineering.org organizuje naprawdę całą masę meetupów. Myśmy też zaczęli w Polsce je organizować. Pierwszy zorganizowaliśmy w październiku i właśnie kolejny będzie 21 maja. Robimy w takiej formie raz on-site, raz online, więc tam też można inżynierów platform sobie spotkać.

Oprócz takich standardowych lektur, standardowych metod, z jakich devopsi się uczą, devopsowania, to warto też czytać pewne książki, które trochę bardziej odpowiadają o konceptach typu Team Topologies, typu Project to Product, typu Engineering Devops jest naprawdę bardzo fajną książką, która powstała jeszcze przed Platform Engineeringiem chyba, a bardzo dużo o Platform Engineeringu mówi, tylko być może niekoniecznie to tak nazywa.

Swojego bloga polecam też, tam dużo piszę.

 

Jasne, do tego jeszcze wrócimy. Ale już tak na koniec chciałbym Cię zapytać w takim kontekście, że chcemy pewne rzeczy standaryzować za pomocą tego podejścia związanego z platformą. Z drugiej strony IT i cała ta technologia informatyczna strasznie pędzi do przodu. Wszystkie te technologie, które wspierają aplikacje, się po prostu zmieniają. Jak w związku z tym widzisz rozwój Platform Engineeringu właśnie w kontekście tego, że te różne technologie, które są kiedy przykrywane przez Platform Engineering, tak szybko też się zmieniają?

 

To jest trudne pytanie. Zacznę od takiego dołu. Powiedzmy ten stack taki typowo DevOpsowy zaczął się już stabilizować. Już raczej wszyscy wiedzą mniej więcej, że używają Kubernetes, a już raczej wszyscy mają jakiś wystandaryzowany stack, do automatyzacji jest DLC i do utrzymania, więc to się gdzieś tam mniej więcej już stabilizuje.

W Platform Engineeringu obecnie mamy bardzo duży boom właśnie na te portale i na te orkiestratory i tego się zaczyna pojawiać od cholery. Więc tu pewnie będzie jeszcze jakiś tam obszar, powiedzmy, kiedy tu jacyś liderzy, wiodące technologie będą musiały się wybić. Dzisiaj widzę, że to Backstage i CrossPlane prawdopodobnie będzie, ale pewności nie mam, bo cała masa produktów zbudowanych wokół Platform Engineering, gotowych się pojawia.

Więc gdzieś tam wydaje mi się i to też tak jak obserwuję, co np. duzi gracze mówią, typu tam Red Hat, typu Github, Microsoft, dostawcy chmurowi, oni już też zaczęli budować swoje takie narzędzia platformowe, czyli jakby swoje platformy dedykowane pod jakiś tam konkretny rodzaj dojrzałości inżynierów, którzy potem z tych narzędzi będą korzystać. W Google to będzie pewnie dość duża dojrzałość jednak. W Azure może niekoniecznie. Ale to na razie takie tendencje widzę, że ci duzi gracze zaczęli w to się bawić trochę.

Natomiast wydaje mi się, że ten AI nam tutaj sporo zmieni. Bo ja nagrałem taki filmik o bardzo kontrowersyjnym tytule: Dlaczego AI programistów zastąpi? Mnie się wydaje, że pisanie kodu to faktycznie może zostać przez to AI zastąpione, natomiast to, co nie zostanie zastąpione, to analiza biznesowa i analiza systemowa, bo tego AI dzisiaj jeszcze nie potrafi robić dobrze. Nawet podałem przykład rozmowy z chatem, gdzie ten chat po prostu wyszedł na debila.

Chat nie potrafi za bardzo intencji rozumieć. On potrafi rozumieć kontekst, ale niekoniecznie potrafi rozumieć intencje i on traktuje intencje i kontekst jakby jako jedno. Kontekst to znaczy, że ja potrzebuję czegoś i potem mi się wydaje, że żeby to coś osiągnąć, to ja potrzebuję takiego i takiego narzędzia. I przeważnie jak biznes przychodzi do programisty, to już mówi: słuchaj, ja potrzebuję CRM-a, który tam ma to, to i tamto. A nie zawsze on tego CRM-a potrzebuje. Dobry programista zapyta: dobra, ale po co ci ten CRM? Co Ty chcesz osiągnąć z tym CRM-em? No i się zaczyna dyskusja.

Chat dzisiaj chyba nie za bardzo zadaje takie pytania. On raczej wybierze to, co myśmy mu napisali, to wynika z działania tego chata, technologicznego działania. On po prostu szuka wektorów bliższych temu, co myśmy mu napisali, a nie się zastanawia, że coś, co jest zupełnie czymś innym, niż my mu piszemy, to jest de facto to, o co nam chodzi. A programista to zauważy, bo rozumie konteksty kulturowe itd.

Więc przyszłość Platform Engineeringu, wracając do pytania, wydaje mi się, że będzie wyglądała tak, że będą te chaty, z którymi programista, które będą gdzieś tam wbudowane w to ideę i jakby większość tego kodu będą generowały. Ten programista będzie w większości pisał chatowi, co on potrzebuje w kodzie, niż może sam pisał ten kod i potem będzie klikał deploy i ten chat będzie z tą platformą zintegrowany i ten deployment się będzie działał gdzieś tam pod spodem.

De facto to jest nadal programowanie, tylko kolejna warstwa abstrakcji. Kiedyś pisaliśmy w Asemblerze, potem zaczęły się języki takie bardziej składniowe pojawiać. Myślę, że teraz to jest kolejny etap. Programowanie polega na myśleniu bardziej niż na robieniu czegoś. Więc jakby im więcej tego robienia zdejmiemy z programistów, tym więcej oni czasu będą mogli na myślenie i na wskazywanie kierunków temu AI-owi dawać, niż tam walczyć z null pointerem znowu.

De facto to jest nadal programowanie, tylko kolejna warstwa abstrakcji. Kiedyś pisaliśmy w Asemblerze, potem zaczęły się języki takie bardziej składniowe pojawiać. Myślę, że teraz to jest kolejny etap. Programowanie polega na myśleniu bardziej niż na robieniu czegoś. Więc jakby im więcej tego robienia zdejmiemy z programistów, tym więcej oni czasu będą mogli na myślenie i na wskazywanie kierunków temu AI-owi dawać, niż tam walczyć z null pointerem znowu.

 

To jest oczywiście narzędzie, kolejne narzędzie, inteligentne tylko z nazwy póki co, więc tak do tego podchodźmy. Świetnie, w dzisiejszej rozmowie Krzysztof Hałasa tłumaczył, czym jest Platform Engineering i zachęcał do rozważenia zbudowania platformy w Waszych projektach.

Krzysztof, bardzo Ci dziękuję za ten czas, za tę rozmowę i proszę, powiedz, gdzie Cię można znaleźć w sieci, gdzie możemy odesłać do tych Twoich materiałów, które też dotyczą Platform Engineeringu.

 

Dzięki również. Znajdziecie mnie na pewno na LinkedInie pod moim imieniem i nazwiskiem. Znajdziecie mnie na moim blogu khalasa.com. Niedawno, pół roku temu niecałe, wypuściłem kurs o tych strategicznych elementach Platform Engineeringu, czyli jakby nie dowiecie się nic na temat konfigurowania Kubernetesa z tego kursu, natomiast dowiecie się, po co to robić i kiedy. Tam mnie też znajdziecie.

Znajdziecie mnie na uczelni na Polsko-Japońskiej Akademii Technik Komputerowych, gdzie na magisterskich wykładam Platform Engineering. Chyba jestem póki co jedyny, który to robi, razem z Patrykiem Bąkiem, moim partnerem biznesowym, powiedzmy. Na różnych konferencjach mnie na pewno znajdziecie, na meetupach Platform Engineering, które gdzieś tam właśnie z Patrykiem i z BlueSoftem dzisiaj współorganizujemy.

I na YouTubie, @khalasa-com, tam znajdziecie mój kanał poświęcony Platform Engineeringowi. Jak dopiszecie jeszcze do tego /global, to znajdziecie to samo po angielsku, więc dużo tego mnie. Będę z lodówki niedługo wyskakiwał z tym Platform Engineeringiem.

 

Dla każdego coś miłego zatem. Oczywiście wszystkie te linki będą w notatce do odcinka. No i co Krzysztof, jeszcze raz bardzo Ci dziękuję za rozmowę. Do usłyszenia i cześć.

 

Dzięki, Krzysztofie. 

 

I to na tyle z tego, co przygotowałem do Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media. Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o Platform Engineeringu. 

Do usłyszenia w następnym odcinku. Cześć!