Coraz częściej można spotkać tezę (nie tylko w memach), że nadchodzi koniec DevOps.
Czy to prawda? Co jest przyczyną takich twierdzeń? Co przyniesie przyszłość?
Zapraszam na trochę dłuższy niż zwykle newsletter.

Zamieszanie z DevOps

Od początku z DevOps było zamieszanie związane z definicją. Bo czym tak właściwie to jest?
Kultura? Stanowisko? Połączenie Dev i Ops, czyli co dokładnie?
Zacznijmy od stanowiska. Wciąż jest wielu ludzi, którzy powtarzają, że DevOps to nie stanowisko, a kultura. Ja też kiedyś byłem taką osobę. My swoje, a rynek swoje. Spójrz na oferty pracy - mnóstwo jest tam ofert dla inżynierów DevOps, a w organizacjach często określa się “ludzi od DevOps” jak tych zajmujących się… no właśnie czym dokładnie?
Automatyzacją? Czy ten kto automatyzuje jest automatycznie DevOps-em? I tak i nie. Bo możesz automatyzować procesy w fabryce produkującej samochody (tam też większość jest oparta o jakieś oprogramowanie) i czy wtedy możesz mówić, że “DevOpsujesz”? Ciężka sprawa.
A może DevOps to nowe, modne określenie na adminów/ops-ów? Sam kiedyś zaczynałem jako taki admin (mówię o tym w drugim odcinku podcastu) i nie zgodzę się, że to to samo co obecnie DevOps.
W końcu w worek DevOps wrzucane są nie tylko stanowiska, ale też produkty czego najlepszym przykładem jest Azure DevOps lub funkcja Auto DevOps w GitLab. Do tego Kanban, Scrum, Jira, CI/CD i mamy niezły kocioł.
Na popularności DevOps wyrosły takie określenia jak DevSecOps (rozmawiam o tym w tym odcinku), MLOps i pewnie wkrótce może i AIOps.
A jak w ogóle zostać takim DevOps? To też nie jest jasne, ale jeśli wciąż masz mętlik to polecam mój artykuł, gdzie opisuję najważniejsze umiejętności.
No i najważniejsza rozterka - czy DevOps to kultura? Niektórzy wręcz oburzają się na określanie tego w inny sposób. A jak jest w rzeczywistości?

Narzędzia czy kultura

Szacunek, wspieranie, słuchanie, blameless post-mortem, bezpieczeństwo w grupie (projekt Arystoteles w Google) i wiele innych rzeczy mówiących nam, że liczy się kultura i bez tego ani rusz.
I znowu - i tak i nie. Nic nie jest proste jak już widzisz to z szerszej perspektywy i doświadczyłeś “wdrażania kultury DevOps”. Nie ma uniwersalnego przepisu na dobrą kulturę w organizacji - są tylko wskazówki i badania mówiące co działa.
Zawsze w zespole i w organizacji jest jakaś kultura. Co najwyżej może być toksyczna i uniemożliwiająca organizacji pójście do przodu.
Każda organizacja to zbiór ludzi o różnym temperamencie, doświadczeniach i poglądach. Do tego wystarczy, aby liderzy organizacji mieli inny styl przywództwa i będzie to mieć olbrzymi wpływ na kulturę (głównie przez promowanie dobrych i zwalczanie złych zachowań).
Dołącz do tego uwarunkowania kulturowe kraju i dowiesz się, że taki “polski DevOps” to nie to samo co “brytyjski” lub “niemiecki DevOps” bowiem inaczej będzie przebiegać komunikacja, inny będzie stosunek do hierarchii itp.
To co jest według mnie to najważniejsze to, że kojarzenie DevOps z kulturą to błąd. Te wszystkie truizmy, wyświechtane frazesy może i dobrze wyglądają na prezentacjach dla menedżerów, podobają się paniom (i panom!) z HR oraz zarządowi, ale realnie wygląda to inaczej.
Jestem zdania, że kultura jest niezbędna, ale warto postawić na budowanie rozwiązań, a kulturę rozwijać w trakcie. Po drodze wyjdzie i tak, że wąskie gardła uniemożliwiające postęp nie będą technologiczne, a kulturowe i trzeba będzie je jakoś rozwiązać. To bardziej przypomina ewolucję i selekcję naturalną (również tą trudniejszą dotyczącą członków zespołu) niż gotowe przepisy.
My pracujący na co dzień z technologią lubimy konkrety i mamy dobry radar na bullshit. Chcemy tworzyć, usprawniać, naprawiać i dążyć do mistrzostwa przez automatyzację i dobór dobrych narzędzi.
A to co warto budować to platformy.

Platform Engineering następcą DevOps?

I na białym rumaku wjeżdża Platform Engineering, czyli konkrety nakierowane na rozwiązywanie problemów - tworzenie platform dla aplikacji i wszystkiego co jest potrzebne do ich działania.
Nie mówimy tu o tworzeniu kultury tylko budowaniu platform. To praktyki oparte o nowoczesne technologie (oczywiście kontenery, Kubernetes, projekty CNCF) dla różnych środowisk - tych na on-prem i na chmurze.
Ważniejsze obok narzędzi są jednak praktyki i taktyki. Z mojej perspektywy można traktować Platform Engineering jako wykorzystanie DevOps, Site Reliability Engineering, Cloud Native i wszystkiego czego dowiedzieliśmy się do tej pory do tworzenia platform dla aplikacji.
A co z kulturą? Tu nie ma przepisów na ten element, bo jest już to oczywiste, że nie stworzysz dobrego rozwiązania bez szczerego feedbacku, dobrych post-mortem nakierowanych na usprawnienia i innych elementów. Po prostu skupiasz się na rozwijaniu platformy.
Taka platforma (niektórzy określają ją jako Internal Developer Platform) ma służyć uruchamianiu mikroserwisów, monolitów (sic!), trenowaniu modeli dla AI oraz zapewnianiu wszystkiego co jest potrzebne wokoło.
Tak najkrócej - nie potrzebujemy Kubernetes, Cloud, GitOps tylko platform zbudowanych na tych lub innych technologiach. Na tym skupia się Platform Engineering właśnie.

⏰ Szkolenie o kontenerach już w tą środę

Już w tą środę 8 maja o godzinie 19:00 poprowadzę szkolenie online o tym jak łatwo tworzyć dobre obrazy kontenerów.
Możesz jeszcze się zarejestrować tutaj.