Prieš kokius penkerius metus visi kalbėjo apie DevOps kaip apie stebuklingą lazdelę, kuri išspręs visas problemas tarp kūrėjų ir infrastruktūros komandų. Realybėje gavosi kitaip – daugelis įmonių tiesiog perkėlė senas problemas į naują terminologiją, o kūrėjai vis tiek gaišta valandas bandydami suprasti, kaip užsidiegti savo aplikaciją staging aplinkoje. Būtent iš šios nusivylimo bangos ir išaugo platform engineering – kryptis, kuri per pastaruosius kelerius metus tapo viena karščiausių temų IT pasaulyje.
Kas iš tikrųjų yra platform engineering
Jei paklaustumėte dešimt inžinierių, ką reiškia platform engineering, gautumėte dešimt skirtingų atsakymų. Bet iš esmės tai disciplina, kurios tikslas – sukurti vidinę savitarnos platformą, leidžiančią kūrėjams patiems, be nuolatinės pagalbos iš infrastruktūros komandos, diegti, testuoti ir valdyti savo aplikacijas.
Skirtumas nuo klasikinio DevOps yra subtilus, bet svarbus. DevOps buvo idealas – kultūra, kur kūrėjai ir operacijos dirba kartu, dalinasi atsakomybe. Praktikoje tai dažnai virsdavo tuo, kad kiekvienas kūrėjas turėdavo tapti pusiau infrastruktūros ekspertu, mokėti Terraform, Kubernetes YAML failus, CI/CD konfigūracijas. Kognityvinė apkrova išaugo iki neįtikėtinų dydžių. Platform engineering sako: gerai, palikime infrastruktūros sudėtingumą specialistams, o kūrėjams duokime paprastą, patogų sąsają, per kurią jie gauna viską, ko reikia, vienu paspaudimu.
Kodėl senasis modelis nustojo veikti
Įsivaizduokite vidutinio dydžio kompaniją su penkiasdešimt mikroservisų. Kiekvienas kūrėjas, norėdamas paleisti naują servisą, turi susipažinti su Kubernetes klasterio konfigūracija, service mesh nustatymais, secrets valdymu, monitoringo integracija ir dar dešimčia kitų dalykų. Infrastruktūros komanda tampa kliūtimi – kiekvienas tiketas laukia savaitę, nes SRE komanda turi tik keturis žmones penkiasdešimčiai komandų.
Būtent čia ir atsiranda platform engineering vertė. Vietoj to, kad kiekvienas kūrėjas iš naujo išrastų dviratį, platformos komanda sukuria abstrakciją – tarkim, vieną YAML failą arba paprastą web sąsają, kurioje kūrėjas pasako „man reikia naujo serviso su PostgreSQL duomenų baze ir Redis kešu“, o visa kita įvyksta automatiškai per iš anksto paruoštus šablonus.
Svarbu suprasti, kad tai nėra bandymas atimti kontrolę iš kūrėjų ar sugrąžinti senąjį centralizuotą IT skyrių, kuris viską darydavo per tiketų sistemą. Priešingai – idėja yra suteikti daugiau savarankiškumo, bet tuo pačiu sumažinti sudėtingumą.
Vidinė kūrėjų platforma – ne produktas, o produktinis mąstymas
Terminas, kurį verta žinoti, – Internal Developer Platform (IDP). Tai nėra vienas konkretus įrankis, kurį galima nusipirkti ir įdiegti per savaitgalį. Tai visas sluoksnis, apjungiantis infrastruktūros valdymą, CI/CD konvejerius, sekretų valdymą, monitoringą ir dokumentaciją į vieną nuoseklią patirtį.
Ir čia slypi didžiausia klaida, kurią daro daugelis įmonių – jos traktuoja platformos kūrimą kaip vienkartinį infrastruktūros projektą, o ne kaip produktą su savo naudotojais. Jūsų kūrėjai yra jūsų platformos klientai. Jei platforma nepatogi, lėta ar neintuityvi, kūrėjai ją tiesiog ignoruos ir grįš prie senų įpročių – rankinio kubectl komandavimo ar tiesioginio darbo su debesijos konsole.
Todėl geros platformų komandos elgiasi kaip produkto komandos: renka atsiliepimus, matuoja naudojimo metrikas, daro interviu su vidiniais naudotojais, iteruoja. Tai visiškai kitoks mąstymas nei tradicinis „infrastruktūra kaip paslauga vidaus komandai be jokios atsakomybės už naudotojo patirtį“.
Įrankiai, kuriuos verta pažinti
Rinkoje jau susiformavo gana aiškus įrankių rinkinys, ant kurio dažniausiai statomos platformos:
- Backstage – Spotify sukurtas ir vėliau CNCF perduotas atviro kodo projektas, tapęs de facto standartu vidinių developer portalų kūrimui. Jame galima susirinkti servisų katalogą, dokumentaciją, šablonus naujų projektų kūrimui.
- Crossplane – leidžia valdyti debesijos resursus per Kubernetes API, kuriant savo abstrakcijas virš AWS, GCP ar Azure resursų.
- Argo CD ir Flux – GitOps įrankiai, automatizuojantys diegimą pagal Git repozitorijos būseną.
- Terraform ir OpenTofu – infrastruktūros kaip kodo pagrindas, dažnai slepiamas po patogesniu sluoksniu, kad kūrėjams nereikėtų rašyti HCL kodo tiesiogiai.
- Humanitec arba Port – komerciniai sprendimai, orientuoti būtent į platform orchestration, jei nenorite viską statyti nuo nulio.
Svarbu neapsigauti – nei vienas iš šių įrankių savaime nesukurs jums platformos. Jie yra tik plytos. Architektūra ir sprendimai, kaip tos plytos sudėliojamos, priklauso tik nuo jūsų komandos konteksto.
Auksiniai takeliai – koncepcija, be kurios viskas subyra
Vienas populiariausių terminų šioje srityje – golden path arba paved road. Idėja paprasta: platformos komanda paruošia iš anksto patikrintą, saugumo ir geriausios praktikos reikalavimus atitinkantį kelią, kuriuo kūrėjas gali eiti be papildomų klausimų. Nori naujo mikroserviso Node.js kalba su PostgreSQL baze? Yra šablonas. Nori event-driven serviso su Kafka? Irgi yra šablonas.
Svarbiausia – tai neturi būti prievarta. Geras auksinis takelis yra toks patogus, kad kūrėjai patys jį renkasi, nes taip greičiau ir paprasčiau, o ne todėl, kad kitaip elgtis draudžiama. Jei kūrėjas nori nueiti savo keliu – tegul eina, bet tada jis prisiima ir atsakomybę už tai, kad viskas veiks teisingai, atitiks saugumo politikas ir bus palaikoma.
Praktikoje tai reiškia, kad platformos komanda investuoja laiką ne į draudimus ir apribojimus, o į tai, kad teisingas kelias būtų tiesiog patogiausias.
Dažniausios klaidos, kurias matau vėl ir vėl
Dirbant su įmonėmis, kurios bando įsivesti platform engineering praktikas, pastebimi tam tikri pasikartojantys scenarijai, kurie beveik visada baigiasi nesėkme.
Pirma klaida – platformos kūrimas be aiškaus vidinio kliento supratimo. Komanda užsidaro kambaryje, sugalvoja „idealią“ architektūrą, o po pusmečio paaiškėja, kad niekas ja nesinaudoja, nes ji neatliepia realių kūrėjų poreikių.
Antra – per didelis abstrakcijos lygis per anksti. Bandymas iš karto sukurti universalų sprendimą visoms galimoms situacijoms dažnai baigiasi tuo, kad platforma tampa per sudėtinga net patiems jos kūrėjams. Geriau pradėti nuo vieno konkretaus, dažno naudojimo atvejo ir plėsti palaipsniui.
Trečia – platformos komandos suvokimas kaip antrarūšės palaikymo funkcijos, o ne strateginės investicijos. Jei organizacija nemato platformos kaip produkto su savo biudžetu, komanda ir prioritetais, ji greitai virsta tiketų vykdymo tarnyba, tiksliai tuo, ko ir buvo bandoma išvengti.
Kaip pradėti, jei jūsų organizacijoje dar nieko panašaus nėra
Nereikia iš karto pirkti brangios komercinės platformos ar samdyti dešimties žmonių komandos. Pradžioje verta:
- Pasikalbėti su kūrėjais ir surašyti tris ar penkis dažniausius skausmo taškus – kur jie sugaišta daugiausia laiko, kas jiems labiausiai erzina.
- Pasirinkti vieną konkretų procesą (dažniausiai – naujo serviso sukūrimas arba diegimas į produkciją) ir jį automatizuoti pirmiausia.
- Sukurti minimalų servisų katalogą, net jei tai tik paprastas Backstage diegimas su keliais šablonais.
- Matuoti rezultatus – kiek laiko dabar užtrunka naujo serviso paleidimas, palyginti su ankstesniu būdu.
- Nebijoti mažų žingsnių. Platforma, kuri sprendžia vieną realią problemą gerai, vertingesnė nei ambicinga, bet niekad neužbaigta didžioji vizija.
Vietoj išvadų: ką iš tikrųjų reikia įsiminti
Platform engineering nėra madingas žodis, kurį galima tiesiog pridėti prie komandos pavadinimo ir tikėtis stebuklo. Tai realus darbas, reikalaujantis produktinio mąstymo, nuolatinio dialogo su kūrėjais ir kantrybės, nes rezultatai matosi ne per savaitę, o per mėnesius ir metus.
Jei norite vieno praktinio patarimo, kurį verta pasiimti iš šio straipsnio – pradėkite nuo klausimo ne „kokį įrankį naudoti“, o „kokia konkreti problema šiandien vagia kūrėjų laiką“. Įrankiai ateis ir keisis, Backstage šiandien gali būti pakeistas kažkuo kitu po penkerių metų, bet principas – sumažinti kognityvinę apkrovą ir suteikti savarankiškumą be chaoso – išliks aktualus nepriklausomai nuo technologinės mados.
Ir dar vienas dalykas, kurį verta prisiminti – platforma niekada nebus „baigta“. Tai gyvas produktas, kuris auga kartu su organizacija. Jei jūsų platformos komanda vieną dieną pasakys „viskas, mes baigėme, dabar tik palaikysime“, greičiausiai tai reiškia, kad ji jau atsilieka nuo realių poreikių. Geriausios platformos komandos, kurias esu matęs, elgiasi lygiai taip pat, kaip geriausios produkto komandos – jos klausosi, testuoja, klysta ir taiso, o svarbiausia – niekada nepamiršta, kad galutinis tikslas yra ne pati platforma, o laimingesni, greitesni ir mažiau frustruoti kūrėjai kitoje virvės pusėje.
