- A platformfejlesztés az IDP-k segítségével absztrakciós rétegeket hoz létre a fejlesztők kognitív terhelésének csökkentése érdekében.
- Termékalapú megközelítésen alapul, ahol az infrastruktúrát szabványosított, önkiszolgáló módon kínálják.
- Célja a szoftverszállítási ciklus optimalizálása optimalizált útvonalak vagy Arany Utak használatával.
Valószínűleg észrevetted, hogy a platformmérnökség kifejezés az utóbbi időben mindenhol felbukkan a tech szektorban . Ez nem véletlen; azt látjuk, hogy a vállalatok megpróbálják megoldani a felhő- és mikroszolgáltatások ellenőrizetlen növekedése által okozott káoszt, és olyan módot keresnek a fejlesztők számára, hogy ne kelljen mindenben szakértőnek lenniük ahhoz, hogy egy változást éles környezetben is bevezessenek.
Alapvetően egy szocio-technikai tudományágról beszélünk, amely a belső szoftverplatformok tervezésére és karbantartására összpontosít . Az ötlet egyszerű, mégis erőteljes: olyan környezetet teremteni, ahol a fejlesztőcsapat minden szükséges dologgal könnyen elérhető, önállóan dolgozhatnak anélkül, hogy ticketeket kellene nyitniuk és napokat kellene várniuk arra, hogy valaki az operatív részlegtől szervert vagy S3 vödröt hozzon létre számukra.
Mit is foglal magában pontosan a platformmérnökség?
Más megközelítésekkel ellentétben ez a tudományág egy belső fejlesztői platform (IDP) építésére összpontosít . Gondoljon rá úgy, mint egyfajta infrastruktúra-"árusító automatára". A végtelen konfigurációs fájlokkal való bajlódás helyett a fejlesztő egy portálhoz fér hozzá, ahol előre jóváhagyott szabványoknak megfelelően telepítheti szolgáltatásait.
Ez a modell nem a semmiből született; a DevOps természetes fejlődésének eredménye . Míg a DevOps az együttműködés és az automatizálás filozófiáját adta nekünk, a Platform Engineering ezeket a koncepciókat konkrét eszközökké alakítja. Elsődleges célja a kognitív terhelés leküzdése – az a túlterhelő érzés, amely akkor keletkezik, amikor egy programozónak egyszerre kell kezelnie a kódot, a biztonságot, a megfigyelhetőséget és az infrastruktúrát.
Az ezt a megközelítést alátámasztó pillérek
- Termékfelfogás: Íme a kulcs. A platform nem egy fix befejezési dátummal rendelkező projekt, hanem egy élő termék. A fejlesztők az ügyfelek, és a platformcsapatnak meg kell hallgatnia a panaszaikat, és folyamatosan fejlesztenie kell a rendszert.
- Önkiszolgálás: A cél a hírhedt "TicketOps" felszámolása. A fejlesztőcsapat célja, hogy... önellátó, API-kon vagy webes portálokon keresztül, közvetítők igénybevétele nélkül férhet hozzá az erőforrásokhoz.
- Arany utak: Ezek előre definiált és optimalizált telepítési útvonalak. Ha a fejlesztő az aranystandardot követi, akkor tudja, hogy alkalmazása alapértelmezés szerint megfelel a biztonsági és szabályozási követelményeknek, bár nagyon különleges esetekben eltérhet ettől.
Miért olyan szükséges ez ma?
A jelenlegi ökoszisztéma eszközök dzsungelét alkotja. A Kubernetes, a Terraform, a hibrid felhők és a biztonsági szabályozások között könnyű eltévedni. A Platform Engineering segít kezelni ezt a komplexitást azáltal, hogy absztrahálja a legsűrűbb technikai részleteket, így a csapat arra koncentrálhat, ami igazán számít: az üzleti érték generálására.
Továbbá a szigorúan szabályozott szektorokban a megfelelőség és a biztonság biztosítása komoly fejfájást okoz. Azáltal, hogy ezeket a szabályokat közvetlenül a platformba integrálják, a megfelelőség automatikus. A fejlesztőknek nem kell egy 100 oldalas biztonsági kézikönyvet elolvasniuk; a platform egyszerűen megakadályozza őket abban, hogy sebezhető elemeket telepítsenek .
Valódi hatás a szervezetre
Ha ezt helyesen valósítjuk meg, az előnyök minden szinten érezhetők. Vállalati szinten a működési költségek csökkennek, a folyamatok szabványosulnak , megakadályozva, hogy minden csapat újra feltalálja a spanyolviaszt. A csapatok számára ez kevesebb súrlódást és sokkal gördülékenyebb koordinációt jelent a különböző területek között.
A fejlesztő számára az élmény transzformatív. Nagyobb önbizalommal rendelkeznek, mivel nem kell másokra várniuk, és sokkal gyorsabban tudnak hatásos eredményeket elérni . Kevesebb idő a Kubernetes YAML-lel való birkózással, ami több időt jelent az üzleti logika írására, és kisebb kockázatot jelent a túlzott működési komplexitás miatti rettegett kiégésre.
Főbb különbségek az SRE és a DevOps között
Nagyon gyakori, hogy ezeket a fogalmakat összekeverik, pedig különböző küldetésük van. A DevOps az az általános filozófia, amely lebontja a fejlesztés és az üzemeltetés közötti elválaszthatatlanságot. Másrészt a Site Reliability Engineering (SRE) a rendszer stabilitására, a rendelkezésre állás és a teljesítmény kezelésére összpontosít standard terhelési korlátok (SLO) és hibakeretek segítségével.
A platformmérnökség ezzel szemben felelős az eszköz (az IDP) felépítéséért, amely lehetővé teszi a fentiek hatékony megvalósítását. Míg az SRE az éles rendszer állapotára összpontosít, a platformmérnök a fejlesztői élményre (DevEx) összpontosít , hogy a programozó laptopjától a felhőig tartó út a lehető legrövidebb és legbiztonságosabb legyen.
Hogyan állítsunk össze egy platformmérnöki csapatot?
Nem ajánlott tömeges, egyik napról a másikra történő telepítést megkísérelni. Ideális esetben egy „legvékonyabb életképes platformmal” kell kezdeni , egy olyan minimálisan életképes verzióval, amely a csapat legsürgetőbb igényeit elégíti ki. Kihasználhatja az SRE vagy a CloudOps csapatok belső tehetségét, de létfontosságú, hogy termékközpontú gondolkodásmódot alkalmazzanak.
A csapaton belül jellemzően kiemelkednek a specifikus szerepkörök. A Platform Termékmenedzser szűri a felhasználói igényeket és rangsorolja az ütemtervet. A DevEx mérnökök a felület és a munkafolyamatok intuitívvá tételére összpontosítanak, míg az Infrastruktúra Mérnökök a belső motort építik, biztosítva a platform skálázhatóságát és robusztusságát.
Gyakori eszközök és technológiák
Ennek az ökoszisztémának a kiépítése jellemzően több komponens kombinálását jelenti. Az infrastruktúra, mint kód (IaC) alapvető fontosságú a környezetek létrehozásának automatizálásához. A konténervezérelt eszközök, mint például a Kubernetes és a CI/CD eszközök, amelyek súrlódásmentes, folyamatos kézbesítési folyamatokat tesznek lehetővé, szintén szerepet játszanak.
A vizuális mag jellemzően a belső fejlesztői portál (IDP) , amely vizualizációs és hitelesítési rétegként működik. Ezek az eszközök átlátható irányítást tesznek lehetővé, és biztosítják, hogy a vállalati szabványokat láthatatlanul, mégis hatékonyan alkalmazzák minden telepítés során.
Ennek a megközelítésnek az alkalmazása paradigmaváltást jelent, ahol az infrastruktúra már nem akadály, hanem gyorsító tényezővé válik. Azáltal, hogy erőfeszítéseiket a technikai súrlódások csökkentésére és az önkiszolgálás révén az autonómia előmozdítására összpontosítják, a vállalatok nemcsak a szállítási sebességet javítják, hanem sokkal vonzóbb és egészségesebb munkakörnyezetet teremtenek a műszaki tehetségek számára, biztosítva, hogy a technológia mindig az üzleti célok elérésének eszköze legyen, és ne öncél.