Platform engineering
W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Krzysztofem Hałasa o platform engineering.
Posłuchaj naszej rozmowy w wersji audio 🎧 👇
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.
👉 Czytaj dalej: https://porozmawiajmyoit.pl/poit-249-platform-engineering/
