- Platformų inžinerija sukuria abstrakcijos sluoksnius, naudodama IDP, kad sumažintų kūrėjų pažintinę krūvį.
- Jis pagrįstas produkto principu, kai infrastruktūra siūloma kaip standartizuota savitarnos sistema.
- Jos tikslas – optimizuoti programinės įrangos tiekimo ciklą naudojant optimizuotus maršrutus arba „Auksinius kelius“.
Tikriausiai pastebėjote, kad pastaruoju metu technologijų sektoriuje vis dažniau vartojamas terminas „platformų inžinerija“ . Tai neatsitiktinai; matome, kaip įmonės bando išspręsti chaosą, kurį kartais sukelia nekontroliuojamas debesijos ir mikropaslaugų augimas, ieškodamos būdo, kaip kūrėjams nereikėtų būti absoliučiai visko ekspertais vien tam, kad galėtų įdiegti pakeitimą gamyboje.
Iš esmės kalbame apie sociotechninę discipliną, kuri orientuota į vidinių programinės įrangos platformų kūrimą ir priežiūrą . Idėja paprasta, bet galinga: sukurti aplinką, kurioje kūrimo komanda turėtų viską, ko jai reikia, lengvai prieinamą, dirbtų autonomiškai, nereikėtų atidaryti užklausų ir laukti dienų, kol kas nors iš operacijų sukurs jiems serverį ar S3 saugyklą.
Ką tiksliai apima platformos inžinerija?
Kitaip nei kiti metodai, ši disciplina orientuota į vidinės kūrėjo platformos (IDP) kūrimą . Įsivaizduokite ją kaip savotišką infrastruktūros „prekybos automatą“. Užuot vargęs su nesibaigiančiais konfigūracijos failais, kūrėjas pasiekia portalą, kuriame gali diegti savo paslaugas laikydamasis iš anksto patvirtintų standartų.
Šis modelis neatsirado iš niekur; tai natūrali „DevOps“ evoliucija . Nors „DevOps“ mums suteikė bendradarbiavimo ir automatizavimo filosofiją, platformų inžinerija šias koncepcijas paverčia konkrečiais įrankiais. Jos pagrindinis tikslas – kovoti su kognityvine našta – tuo didžiuliu jausmu, kuris kyla, kai programuotojas turi vienu metu valdyti kodą, saugumą, stebimumą ir infrastruktūrą.
Šį požiūrį palaikantys ramsčiai
- Produkto mąstysena: Štai esmė. Platforma nėra projektas su fiksuota pabaigos data, o gyvas produktas. Kūrėjai yra klientai, o platformos komanda turi įsiklausyti į jų skundus ir nuolat tobulinti.
- Savitarna: Tikslas – pašalinti liūdnai pagarsėjusį „TicketOps“. Siekiama, kad kūrimo komanda būtų savarankiškas, pasiekdami išteklius per API arba interneto portalus, nepriklausydami nuo tarpininkų.
- Auksiniai takai: Tai iš anksto nustatyti ir optimizuoti diegimo keliai. Jei kūrėjas laikosi auksinio standarto, jis žino, kad jo programa pagal numatytuosius nustatymus atitinka saugumo ir atitikties reglamentams reikalavimus, nors labai ypatingais atvejais jam leidžiama nuo to nukrypti.
Kodėl tai šiandien taip būtina?
Dabartinė ekosistema yra įrankių džiunglės. Tarp „Kubernetes“, „Terraform“, hibridinių debesų ir saugumo reglamentų lengva pasiklysti. „Platform Engineering“ padeda valdyti šį sudėtingumą, abstrahuojant tankiausias technines detales, kad komanda galėtų sutelkti dėmesį į tai, kas iš tikrųjų svarbu: verslo vertės kūrimą.
Be to, griežtai reguliuojamuose sektoriuose atitikties ir saugumo užtikrinimas yra didelis galvos skausmas. Integravus šias taisykles tiesiai į platformą, atitiktis pasiekiama automatiškai. Kūrėjams nereikia skaityti 100 puslapių saugumo vadovo; platforma tiesiog neleidžia jiems diegti jokių pažeidžiamų elementų.
Realus poveikis organizacijai
Kai tai įgyvendiname teisingai, nauda jaučiama visais lygmenimis. Įmonės lygmeniu sumažėja veiklos sąnaudos ir standartizuojami procesai , todėl kiekvienai komandai nereikia išradinėti dviračio iš naujo. Komandoms tai reiškia mažesnę trintį ir daug sklandesnį koordinavimą tarp skirtingų sričių.
Programuotojui ši patirtis yra transformuojanti. Jie jaučiasi labiau įgalinti, nes jiems nereikia laukti kitų, ir gali daug greičiau gauti reikšmingų rezultatų . Mažiau laiko reikia skirti „Kubernetes YAML“ grumtynėms, o tai reiškia daugiau laiko verslo logikos rašymui ir mažesnę riziką patirti baisų perdegimą dėl pernelyg didelio operacinio sudėtingumo.
Pagrindiniai SRE ir DevOps skirtumai
Labai dažnai šias sąvokas painiojame, tačiau jos turi skirtingas paskirtis. „DevOps“ – tai bendroji filosofija, panaikinanti ribas tarp kūrimo ir operacijų. Kita vertus, svetainės patikimumo inžinerija (SRE) orientuota į sistemos stabilumą, prieinamumo ir našumo valdymą taikant standartines apkrovos ribas (SLO) ir klaidų biudžetus.
Kita vertus, platformos inžinierius yra atsakingas už įrankio (IDP), kuris leidžia efektyviai atlikti visus aukščiau išvardintus veiksmus, kūrimą. Nors SRE daugiausia dėmesio skiria gamybos sistemos sveikatai, platformos inžinierius daugiausia dėmesio skiria kūrėjo patirčiai (DevEx), kad užtikrintų, jog kelias nuo programuotojo nešiojamojo kompiuterio iki debesies būtų kuo trumpesnis ir saugesnis.
Kaip suburti platformos inžinerijos komandą
Nerekomenduojama bandyti diegti didelio masto produktų per naktį. Idealiu atveju reikėtų pradėti nuo ploniausios perspektyvios platformos – minimalios perspektyvios versijos, kuri patenkintų svarbiausius komandos poreikius. Galite pasinaudoti SRE arba „CloudOps“ komandų vidiniais talentais, tačiau labai svarbu, kad jos perimtų į produktą orientuotą mąstyseną.
Komandoje paprastai išsiskiria konkretūs vaidmenys. Platformos produktų vadovas filtruoja naudotojų poreikius ir nustato veiksmų plano prioritetus. „DevEx“ inžinieriai sutelkia dėmesį į sąsajos ir darbo eigų intuityvumą, o infrastruktūros inžinieriai kuria vidinį variklį, užtikrindami, kad platforma būtų keičiamo dydžio ir patikima.
Įprasti įrankiai ir technologijos
Šios ekosistemos kūrimas paprastai apima kelių komponentų derinimą. Infrastruktūra kaip kodas (IaC) yra esminis dalykas automatizuojant aplinkos kūrimą. Taip pat svarbūs konteinerių organizavimo įrankiai, tokie kaip „Kubernetes“ ir CI/CD įrankiai, kurie užtikrina sklandžius, nenutrūkstamus tiekimo srautus.
Vizualinis branduolys paprastai yra vidinis kūrėjo portalas (IDP) , kuris veikia kaip vizualizacijos ir autentifikavimo sluoksnis. Šie įrankiai užtikrina skaidrų valdymą ir, kad įmonės standartai būtų taikomi nematomu, bet efektyviu būdu kiekviename diegime.
Šio požiūrio taikymas reiškia paradigmos pokytį, kai infrastruktūra nustoja būti kliūtimi ir tampa akseleratoriumi. Sutelkdamos pastangas į techninės trinties mažinimą ir savarankiškumo skatinimą per savitarną, įmonės ne tik pagerina pristatymo greitį, bet ir sukuria daug patrauklesnę bei sveikesnę darbo aplinką techniniams talentams, užtikrindamos, kad technologijos visada būtų priemonė verslo tikslams pasiekti, o ne savitikslis tikslas.