Co to jest platform engineering: poradnik dla deweloperów
Summary
Platform engineering to praca nad budowaniem wewnętrznej utartej ścieżki, którą zespoły mogą samodzielnie używać do tworzenia, wdrażania i monitorowania usług. Różni się od DevOps fokusem na użytkownika i od SRE celami adopcji. Opłaca się dla organizacji z 20 lub więcej zespołami, ale małe grupy mogą zacząć od prostego skryptu. Poznaj, kiedy to wdrażać, jakie narzędzia wybrać i jak zacząć bez budowania niewłaściwej rzeczy.
Jest 22:10, a nowy pracownik próbuje uzyskać środowisko stagingowe od dwóch dni. Złożył trzy zgłoszenia, wkleił ten sam błąd Terraform'a na Slack'u dwa razy, a wciąż nie wie, który z czterech szablonów CI jest tym właściwym. Ten obraz to cała odpowiedź na pytanie „co to jest platform engineering": to praca nad budowaniem wewnętrznej utartej ścieżki, aby nikt nie musiał przedzierać się samotnie przez zaroślą, i traktowanie tej drogi jako produktu z użytkownikami.
W praktyce zespół platform buduje wewnętrzną platformę dla deweloperów (IDP): narzędzia samoobsługowe, które pozwalają innym devom tworzyć usługi, wdrażać i widzieć, co jest uruchomione, bez czekania na człowieka. Oto co się psuje w praktyce, gdy to pominiesz: każdy zespół wymyśla własne wdrażanie, a wiedza żyje w głowach trzech osób.
Co to jest platform engineering, bez bzdur słownych
Najczystsza definicja, którą znam, pochodzi ze społeczności platformengineering.org: projektowanie i budowanie platform, które dają zespołom możliwości samoobsługowe dla powtarzających się części ich pracy. Pozbądź się słownictwa, a otrzymasz trzy ruchome części.
Po pierwsze, wewnętrzna platforma dla deweloperów. To nie jeden produkt, który kupujesz. To cienka warstwa szablonów, pipelinów, API i dokumentacji, która siedzi na szczycie narzędzi, które już prowadzisz (konto w chmurze, Kubernetes, CI, sekrety, monitoring) i ukrywa ostre krawędzie.
Po drugie, zespół platform. Mała grupa inżynierów, których klientami są inni inżynierowie. Ich wynikiem nie są funkcje dla użytkowników końcowych. Ich wynikiem jest szybkość, z jaką wszyscy inni mogą dostarczać.
Po trzecie, myślenie produktowe. Platforma ma użytkowników, zaplanowaną pracę, metryki adopcji i zespół dyżurny. Jeśli nikt jej nie używa, upadła, bez względu na to, jak elegancka jest architektura.
Gartner przewidywał, że do 2026 roku 80% dużych organizacji inżynieryjnych będzie mieć zespoły platform, w stosunku do 45% w 2022 roku. Traktuj to jako marker trendu, a nie obietnicę. Ta sama plotka z branży mówi, że duża część tych zespołów ma problemy z wykazaniem wpływu, co jest dokładnie tym, dlaczego reszta tego artykułu poświęca czas na to, co idzie nie tak.
Czym się różni od DevOps i SRE?
Wersja skrócona: DevOps to kultura, SRE to dyscyplina niezawodności, platform engineering to kształt zespołu, który produktyzuje oba.
DevOps mówił, że deweloperzy i operacje powinni dzielić się odpowiedzialnością za uruchamianie oprogramowania. Dobry pomysł. W firmie 15-osobowej działa, bo wszyscy mogą widzieć wszystko. W firmie 300-osobowej cicho zamieniło się w „każdy squad musi również zostać ekspertem od Kubernetes'a", co nie jest czymś, na co się wszyscy zgodzili.
SRE skupia się na celach niezawodności: budżetach błędów, odpowiedzi na incydenty, pojemności. Zespół platform również dba o niezawodność, ale jego główna metryka jest inna. Mierzy, jak długo dev czeka między „mam pomysł na usługę" a „działa w produkcji z logami i alertami".
Platform engineering to odpowiedź na obciążenie poznawcze, które DevOps pozostawił. Zamiast prosić każdego deva o naukę całego łańcucha narzędzi, dajesz mu wspierany domyślny zestaw i trzymasz wiedzę ekspercką wewnątrz platformy. Trzy powody, by to robić, jeden powód, by nie: opłaca się tylko, gdy liczba zespołów lub usług jest na tyle duża, że duplikacja boli. Przejdziemy do tego progu poniżej.
Co dokładnie dostarczalny zespół platform?
Zapomnij o diagramach architektury. Oto jak wygląda ostateczna lista pracy zespołu platform w normalny wtorek.
Szablon usługi. Jedna komenda lub jeden przycisk w portalu tworzy repozytorium z pracującym pipeline'em, Dockerfile'em, health check'ami, konfiguracją logowania i podstawowym dashboardem. Dev zmienia logikę biznesową, nie rury.
Ścieżka wdrażania. Push do master, testy się uruchamiają, artefakt jest budowany i promowany przez środowiska z tymi samymi krokami za każdym razem. Bez per-teamowych kuriozów.
Środowisko na żądanie. Środowisko podglądu na pull request, automatycznie rozdzielane. To funkcja, za którą dev Ci dziękuje.
Sekrety i dostęp. Kredencjały krótkotrwałe, jedno miejsce, aby je poprosić, dziennik audytu. Nudne, i rzecz, która Cię ratuje w przeglądzie bezpieczeństwa.
Obserwość domyślnie. Każda usługa stworzona z szablonu dostarczalne metryki, logi i ślady bez konieczności ich podłączania. Stack jak Grafana zwykle siedzi za tą warstwą, i jej bezpłatna opcja oraz open source'owe opcje odpowiadają małemu zespołowi.
Zauważ, co brakuje na tej liście: niestandardowo zbudowany portal z trzema miesiącami roadmap'y. Portal to ostatnia rzecz, którą dodajesz, nie pierwsza.
Złote ścieżki: pomysł, który sprawia, że reszta działa
Złota ścieżka to wspierany, stanowczy sposób robienia częstego zadania. Jest szybsza niż robienie tego ręcznie i bezpieczniejsza niż improwizowanie, i kluczowo jest opcjonalna. Deweloperzy mogą opuścić ścieżkę, gdy mają rzeczywisty powód. Po prostu biorą na siebie odpowiedzialność, która z tym idzie.
Istnieje przydatne rozróżnienie w wpisie Octopusa o ścieżkach utartych a złotych: droga brukowana to szeroka, dobrze utrzymana powierzchnia, podczas gdy złota ścieżka to konkretna zalecana trasa dla danego zadania. Moim doświadczeniu różnica liczy się mniej niż zasada u podstawy. Wygrywasz, czyniąc właściwy sposób łatwym sposobem, nie zakazując innych sposobów.
Oto, jak wygląda najmniejsza możliwa złota ścieżka. To jedna komenda scaffoldu, którą dev wykonuje raz:
platform new service payments-api --template node-api --env preview,staging,prod --owner team-checkout
Za tą jedną linią siedzi repozytorium, pipeline, DNS, fragment bazy danych, alertami i zapis właściciela. Komenda jest trywialna. Trudna część to sześć miesięcy zgody na to, co oznacza „node-api", i utrzymywanie jej na bieżąco, gdy Node, twój obraz bazowy lub Twój dostawca chmury się zmienia.
Testowane, nie optymalne, i oto dlaczego to robimy: przeciętna złota ścieżka, którą 80% zespołów używa, bije doskonałą, którą przyjmuje 10%, bo pierwsza daje ci dźwignię, aby ulepszyć wszystko naraz.
Kiedy to jest warte, kiedy to jest rozproszeniem?
To jest sekcja, którą większość postów pomija. Platform engineering nie jest darmowy, i dla wielu zespołów to zły ruch.
Przegląd platformengineering.org sugeruje, że organizacje zwykle zaczynają odnosić korzyści, gdy przejdą przez około 20 do 30 użytkowników platform. Czytam to jako przybliżoną podłogę, a nie zasadę. Poniżej tego, wspólny README, dobry szablon CI i jedna osoba, która się troszczy, zrobi więcej niż formalny zespół platform.
Warte, gdy:
Masz więcej niż kilka zespołów, a każdy zbudował własny pipeline wdrażania.
Nowych devów zajmuje tygodnie, a nie dni, aby dostarczyć pierwszą zmianę.
Ten sam typ incydentu się powtarza, ponieważ każda usługa podłączyła własne alerty.
Bezpieczeństwo lub zgodność prosi o spójność, którą nie możesz dostarczyć, prosząc ładnie.
Pomiń, gdy:
Jesteś jednym zespołem pięciu osób. Napisz skrypt, nie platformę.
Jeszcze nie wiesz, jak wyglądają Twoje usługi. Standaryzacja zbyt wcześnie zamraża złe decyzje.
Propozycja to „zbudować portal" bez listy bólów, które usuwa.
Dla samotnych builderów i małych zespołów side-project'ów uczciwa konkluzja jest prostsza. Nie potrzebujesz zespołu platform, ale potrzebujesz nawyków: jeden powtarzalny skrypt wdrażania, jeden szablon dla nowych projektów, jeden dashboard, który sprawdzasz. To platforma jednej osoby, i zaoszczędzi Ci weekend co miesiąc.
Narzędzia, które ludzie faktycznie łączą
Nie ma pojedynczego „produktu platform engineering". Zespoły montują stack, a części wpadają do kilku wiadr.
Dla portalu i katalogu, wiele zespołów używa Backstage'a lub alternatywy hostowanej, która daje przeszukiwalną listę usług, właścicieli i dokumentów. Do provisioning'u, Terraform lub OpenTofu plus narzędzie GitOps, takie jak Argo CD lub Flux. Do CI i dostarczania, cokolwiek już masz, opakowane w wspólne szablony.
Dwa wiaderka zasługują na bliższe spojrzenie, ponieważ decydują, czy platforma wydaje się godna zaufania.
Obserwość. Jeśli deweloperzy nie mogą zobaczyć, co robi ich usługa, nie będą ufać platformie, która ją wdrożyła. Datadog daje Ci gładką jedną panelę na całej infrastrukturze, APM i logach, po cenie za hosta, która szybko rośnie. Open source'owy stack Grafany kosztuje Cię czas operacyjny zamiast opłat licencyjnych. Wybieraj na podstawie tego, czy Twoim niedostatkiem jest pieniądz czy uwaga.
Dokumenty i jakość. Platforma bez dobrej dokumentacji to kolejka biletów w przebraniu. Narzędzia docs-as-code trzymają przewodniki obok repozytorium, który opisują, i bramy jakości kodu w CI trzymają szablony w uczciwości.
Żaden z nich nie jest wymagany. To przykłady warstwy, gdzie zespół platform spędza czas: wybieranie domyślnego, podłączanie go do szablonu, i posiadanie ścieżki uaktualnienia.
Jak zacząć bez budowania niewłaściwej rzeczy
Większość upadających wysiłków platform dzieli ten sam wzorzec. Zaczynają zbyt dużo, budują przez miesiące, zanim jeden zespół go dotyka, i optymalizują dla slajdu roadmap'y zamiast adopcji. Naprawy to bez połysku.
Wybierz jedno bolesne, częste zadanie. „Utwórz nową usługę" i „uzyskaj środowisko podglądu" to zwyczajni zwycięzcy. Przepytaj trzech deweloperów i obejrzyj, jak to robią. Policz kroki i minuty.
Zbuduj najcieńszą wersję, która usuwa większość bólu. Repozytorium szablonu i wspólny plik pipeline'u się liczą. Daj to jednemu przyjaznnemu zespołowi i siedź obok nich, gdy go używają. Napraw to, co się psuje, potem zaoferuj to drugiemu zespołowi.
Śledź dwie liczby: jak długo od „nowa usługa" do „uruchomiona w produkcji", i ile zespołów dobrowolnie korzysta ze ścieżki. Jeśli druga liczba jest płaska, platforma jest mandatem, a mandaty się niszczą.
Zatrudniaj ją jak zespół produktu. Inżynierowie platform to nie DevOps z nowym tytułem. Materiał platformengineering.org zauważa, że inżynierowie platform zarabiają około 27% więcej niż profesjonaliści DevOps, co mówi Ci, że rynek widzi mieszankę produktu i inżynierii jako odrębne, trudniejsze zadanie.
Jeden więcej powód, aby to robić teraz: najnowsza zwrot to to, że „użytkownik" platformy nie jest już tylko człowiekiem. Agenci kodowania otwierają pull requesty, uruchamiają testy i proszą o środowiska. Platforma z czystymi szablonami, jasnymi uprawnieniami i dokumentami czytelnymi dla maszyny jest znacznie bezpieczniejszym miejscem dla agenta do pracy niż stos kuriozowych repozytoriów.
Kredencjały krótkotrwałe, środowiska podglądu i spójny pipeline to rzeczy, które utrzymują błędy agenta w gałęzi do wyrzucenia. Jeśli Twoja platforma nie może powiedzieć wdrażania człowieka od zautomatyzowanej, dodaj to przed dodaniem czegokolwiek innego.
Co powinieneś budować dalej?
Jeśli kierujesz zespołem 30 deweloperów i każdy squad ma swój pipeline, mały zespół platform z jedną złotą ścieżką jest prawdopodobnie Twoim wysoko-dźwiękowym najemem. Jeśli jesteś samotnym devem z trzema side projectami, skopiuj pipeline Twojego najlepszego projektu do repozytorium szablonu tego weekendu i to nazwij.
W każdym razie pytanie, które jest warte zabrania do Twojej sesji planowania, to konkret: które pojedyncze zadanie Twoi deweloperzy powtarzają najczęściej, i co by trzeba, aby uczynić to joiem jednej komendy?