Platform engineering – czym różni się od DevOps?

Platform engineering to zaawansowana techniczna dyscyplina inżynieryjna, która dostarcza wewnętrzne platformy deweloperskie ułatwiające błyskawiczne wdrażanie oprogramowania. W przeciwieństwie do DevOps, który w swojej istocie jest filozofią kulturową i metodyką pracy zespołowej, inżynieria platformowa skupia się na budowie konkretnego, namacalnego produktu dla wewnętrznych programistów. Prawidłowe zrozumienie granic i różnic między tymi dwoma obszarami to obecnie jedno z najważniejszych wyzwań stojących przed architektami IT w nowoczesnych korporacjach technologicznych.

Kultura zacierania barier między obszarami rozwoju oprogramowania (Dev) a jego utrzymaniem (Ops) zrewolucjonizowała rynek, przyspieszając cykle wydawnicze. Szybko jednak okazało się, że model pozbawiony odpowiednich narzędzi ma poważne luki, które drastycznie obciążają samych twórców kodu.

Skąd wziął się kryzys w DevOps i dlaczego potrzebujemy inżynierii platformowej?

Klasyczne, rygorystyczne podejście „You Build It, You Run It” obciążyło programistów obowiązkiem zarządzania całą, wysoce skomplikowaną infrastrukturą chmurową. Zamiast skupiać się wyłącznie na pisaniu logiki biznesowej, deweloperzy zmuszeni byli stać się jednocześnie ekspertami od sieci, ról IAM, klastrów Kubernetes oraz zaawansowanych pipeline’ów CI/CD. Taka ewolucja roli programisty na masową skalę okazała się niezwykle trudna do utrzymania w praktyce.

Konsekwencją tego zjawiska stał się drastyczny wzrost Cognitive Load (obciążenia poznawczego). Jest to termin zaadaptowany z psychologii poznawczej, doskonale opisujący sytuację, w której pamięć robocza inżyniera zostaje przeładowana nadmiarem informacji i wymuszoną nauką pobocznych konfiguracji. Spada przez to nie tylko wydajność, ale również motywacja. Jak wykazują obszerne analizy badawcze opublikowane przez [Źródło 1], przedsiębiorstwa dysponujące dojrzałymi zespołami platformowymi potrafią skutecznie zredukować to obciążenie u programistów nawet o 40% do 50%.

Platform Engineering, DevOps i SRE – kluczowe różnice w praktyce

DevOps układa fundamenty i buduje drogi pod automatyzację, SRE zarządza ruchem i reaguje na awarie, a Platform Engineering tworzy inteligentny system GPS dla programisty. To najlepsza miejska analogia pozwalająca zobrazować różnice ról w nowoczesnym cyklu życia oprogramowania. Inżynier DevOps działa zazwyczaj przy konkretnym projekcie, inżynier platformowy (Platform Engineer) natomiast podchodzi do pracy w duchu „Platform as a Product”, traktując innych programistów w organizacji jak swoich wymagających klientów.

Czego nie dowiesz się ze zwykłych poradników? Problem Tool Sprawl i architektura IDP

Niekontrolowany rozrost narzędzi technologicznych (tzw. Tool Sprawl) to cichy morderca budżetów IT, którego Inżynieria Platformowa wprost eliminuje. Kiedy poszczególne zespoły mają zbyt dużą wolność, każdy dział zaczyna korzystać z innej bazy danych, innego systemu logowania czy frameworka CI/CD. Organizacja traci spójność, a przeniesienie programisty do innego projektu wiąże się z wielotygodniowym okresem wdrażania. Antidotum na ten narastający chaos jest zbudowanie struktury IDP (Internal Developer Platform).

IDP to centralny, jednolity portal samoobsługowy, wewnątrz którego za pomocą kilku prostych interfejsów ukryty jest cały zaawansowany stos technologiczny firmy. Niezwykle istotnym elementem budowy nowoczesnych portali IDP jest platforma open-source o nazwie Backstage. Rozwijana pierwotnie przez inżynierów Spotify, dostarcza potężne ramy (katalogi usług, Software Templates) pozwalające na tworzenie wewnątrzfirmowych portali deweloperskich. Dzięki takim platformom, postawienie gotowego środowiska testowego z pełnym monitoringiem to kwestia zaledwie kilku kliknięć myszą, bez generowania ticketów do działu infrastruktury.

Koncepcja „Golden Path”, czyli wolność w ramach odpowiedzialności

Złota Ścieżka (z ang. Golden Path lub Paved Road) to seria wysoce ustandaryzowanych i fabrycznie skonfigurowanych szablonów wdrożeniowych, pełniących rolę bezpiecznej ramy pracy dla programisty. Jeśli koder podąża wyznaczoną ścieżką dostarczoną przez inżynierów platformowych, jego nowa aplikacja z automatu spełnia wyśrubowane normy bezpieczeństwa, audytów i wewnętrznego compliance (podejście Security by Design).

Bardzo często błędnie uważa się to za ograniczenie innowacji. Prawda jest zupełnie inna, co świetnie punktują eksperci branżowi z [Źródło 2]. Architektura „Złotej Ścieżki” opiera się na koncepcji wyboru i dorosłości technicznej. Programista zawsze ma prawo odrzucić gotowy szablon i zboczyć z trasy, by eksperymentować z nowym stosem technologicznym. Wtedy jednak traci darmowe wsparcie i musi przyjąć na siebie pełną, rygorystyczną odpowiedzialność za bezpieczeństwo i awarie stworzonego przez siebie komponentu.

Perspektywa z okopów: Jak obciążenie poznawcze zabija produktywność?

W mojej codziennej audytorskiej praktyce najczęstszym grzechem przedsiębiorstw jest wdrożenie tytułu zawodowego „DevOps” do umów o pracę, bez zmiany fundamentalnych procesów w organizacji. Przypominam sobie audyt w znanej instytucji finansowej, która w teorii całkowicie przeszła na metodyki zwinne. Zszokowało mnie, gdy deweloperzy wykazali, że na uzyskanie odpowiednich uprawnień IAM i postawienie czystej bazy instancji do testów musieli czekać nawet trzy tygodnie. Kod powstawał w kilka dni, ale utykał w proceduralnym bagnie infrastrukturalnym.

Przełomem nie było dokupienie droższych narzędzi. Sytuację diametralnie zmieniło powołanie niezależnego zespołu zajmującego się wyłącznie Inżynierią Platformową. Grupa ta zbudowała uproszczone API w postaci wewnętrznego portalu deweloperskiego. Czas oczekiwania na nowe środowisko spadł z dwudziestu dni roboczych do dziesięciu minut. Ta redukcja tarcia i stresu poznawczego była ogromnym zastrzykiem motywacyjnym dla całego pionu deweloperskiego.

Przyszłość i statystyki rynkowe: Zaskakująco szybka adopcja Platform Engineeringu

Inżynieria platformowa błyskawicznie staje się standardem w korporacyjnych działach IT, o czym świadczą jednoznaczne, miażdżące prognozy wiodących analityków. Zgodnie ze szczegółowymi badaniami opublikowanymi przez [Źródło 3], przewiduje się, że do 2026 roku aż 80% dużych organizacji, w których pisze się oprogramowanie, zatrudni dedykowane zespoły inżynierów platformowych. Jest to jeden z najszybciej absorbujących się trendów na współczesnym rynku inżynierii systemowej.

Korelację tej dyscypliny ze skutecznym uprawianiem filozofii DevOps potwierdzają też obszerne, cykliczne analizy. Z obszernego raportu opublikowanego przez [Źródło 4] jasno wynika, że aż 94% firm zadeklarowało wymierne korzyści we wdrażaniu praktyk DevOps, zaledwie chwilę po wdrożeniu pierwszych elementów platform. Ten sam raport potwierdza, że ponad 51% ankietowanych firm z sukcesem zaimplementowało inicjatywy związane z Platform Engineering, a 43% posiada tego typu wyspecjalizowane zespoły od przynajmniej 3-5 lat.

Wdrożenie Inżynierii Platformowej nie oznacza wycofania się z filozofii DevOps. Stanowi raczej niezbędny ewolucyjny krok, zapewniający technologiczne i organizacyjne rusztowanie, na którym kultura odpowiedzialności i prędkości może swobodnie funkcjonować w dużej skali.

Podsumowanie

Platform Engineering różni się od DevOps tym, że przekuwa abstrakcyjne idee i dobre praktyki we wdrożony, mierzalny i użyteczny produkt dla koderów, jakim są portale samoobsługowe (IDP). DevOps zainicjował potężną zmianę w kulturze wytwarzania oprogramowania, promując ścisłą współpracę. Niestety, wymóg doskonałej wiedzy o infrastrukturze chmurowej przygniótł deweloperów olbrzymim długiem poznawczym (Cognitive Load). Inżynieria Platformowa wyrasta bezpośrednio z tego konfliktu, będąc w pełni technologicznym ratunkiem.

Konsolidacja używanych narzędzi, niwelowanie problemu zwanego Tool Sprawl oraz standaryzowanie tras wdrażania kodu za pomocą wyznaczonych „Złotych Ścieżek” powoduje, że praca staje się powtarzalna i wysoce bezpieczna. Dedykowane zespoły platformowe stały się rdzeniem krwiobiegu każdej dużej, postępowej organizacji technologicznej – traktują swoich własnych programistów jak najbardziej lojalnych, ale i wymagających klientów oprogramowania wewnętrznego.

Bibliografia i źródła

• [Źródło 1] DORA: Analizy produktywności i redukcji obciążeń u programistów w zaawansowanych technologicznie firmach (google.com)
• [Źródło 2] Baza wiedzy na temat platform kontenerowych, architektury Kubernetes oraz koncepcji Golden Paths w modelu cloud-native (redhat.com)
• [Źródło 3] Prognozy strategiczne i raporty dotyczące najszybciej rozwijających się technologii i adopcji Platform Engineeringu w IT (gartner.com)
• [Źródło 4] Puppet State of DevOps Report: Platform Engineering Edition (puppet.com)

FAQ – najczęściej zadawane pytania