Mivel a szoftverfejlesztés egyre összetettebbé válik, elérkezhet az ideje, hogy a fejlesztők és az operációs rendszerek szakemberei ismét elváljanak egymástól. De lehetséges-e a múlt hibáinak megismétlése nélkül?
A Devops kéz a kézben jelent meg az agilis módszerek és a felhőalapú számítástechnika megjelenésével a 2000-es évek végén, amikor a szoftverek elkezdték felfalni a világot. A “fejlesztés” és a “műveletek” szép portékája a devops megpróbálta összehozni a két korábban különálló csoportot, amelyek a szoftverek létrehozásáért és telepítéséért feleltek. Ez egybeesett azzal is, vagy akaratlanul is előhozta, hogy a szoftvermérnököknek szigorítaniuk kellett felhasználói visszajelzéseiket, és gyakrabban kell frissíteniük a termelési rendszerbe.
Míg sok szervezet megragadta ezt a lehetőséget, hogy összehozzon két szakembercsoportot a gyakori problémák korábban lehetetlen sebességű megoldására, mások a devopok megjelenését a fejlesztők licenceként tekintették arra, hogy felelősséget vállaljanak az üzemeltetési feladatokért, és megpróbáltak egy szuper csapatot összeállítani félig mitikus, teljes veremfejlesztők.
“A fejlesztők többnyire nem akarnak működési aggályokkal foglalkozni” tweetelt Devops For Dummies szerző és az Amazon Web Services közösségi elkötelezettségért felelős vezetője, Emily Freeman.
Freeman egyértelműen megütött, több száz megjegyzés érkezett a fejlesztőktől, akik nem is akartak műveleteket végezni.
“Fejlesztő vagyok, és nem akarok működési aggályokkal foglalkozni” – válaszolta Scott Pantall, a Chipotle gyorséttermi cég szoftvermérnöke.
„A fejlesztőknek és az operátoroknak szorosan együtt kell működniük differenciált szerepekkel. A csapatok közötti empátia az igazi lényeg” – kommentálta Andrew Gracey, a SUSE fejlesztői evangélistája.
Noha a működési és biztonsági kérdések „balra” és a szoftverfejlesztők területére való áthelyezésének koncepciója egyértelműen megvannak a maga előnyei, ugyanakkor veszélyes szűk keresztmetszetet is teremthet.
„Ha túl sok területre vonzza a fejlesztőket, akkor lábon lövi magát. Ez más készségek” – mondta James Brown, a Kubernetes tárolási specialistája, Ondat vezető terméke az InfoWorldnek.
Vagy ahogy Nick Durkin, a Harness műszaki igazgatója fogalmazott: “Az emberek kezdik felismerni, hogy nem bérelnénk villanyszerelőt a vízszerelés elvégzésére.”
A felelősség „hatalmas” növekedése
Míg a vállalati szoftverfejlesztők száma soha nem volt ekkora, a műszaki műveletek szaktudása némileg háttérbe szorult, noha leterheltségük nőtt.
Ahogy azt a devops mérnöke és korábbi rendszeradminisztrátora, Mathew Duggan írta tavaly, miközben az üzemeltetők “még mindig rendelkeztek minden korábbi felelősséggel, hogy megbizonyosodjanak arról, hogy az alkalmazás elérhető, felügyelt, biztonságos és megfelelő-e”, a szoftverek szállításával is megbízták őket. és fenntartani. csővezetékek, “lerakják az alapot ahhoz, hogy a fejlesztés lehetővé tegye a kód gyors és biztonságos kiadását a mi közreműködésünk nélkül.”
Ezek a növekvő felelősségek hatalmas átképzési erőfeszítéseket eredményeztek, és a felhőalapú tervezés és az infrastruktúra, mint kódolási készségek egyre fontosabbá váltak.
“Véleményem szerint a helyzet még soha nem volt ilyen kilátástalan” – írta Duggan. „A fejlesztést teljesen túlterhelték a felelősségi körük (RIP QA) jelentős növekedése, valamint a gyorsasággal kapcsolatos irreális vezetői elvárások.”
Lehet, hogy ez a nyomás kezd árulkodni.
“Hihetetlenül nagy kihívás egy olyan szervezet felépítése, amely eléri az iteratív harmónia ilyen szintjét, amely hosszú ideig tart” – írta Tyler Jewell, a Dell Technologies Capital ügyvezető igazgatója egy kutatási feljegyzésében. “Ahogy a rendszerek egyre bonyolultabbakká válnak, és a végfelhasználói visszajelzések növekszenek, az ember számára egyre nehezebb meggondolni, milyen hatással lehet egy változás a rendszerre.”
A probléma felismerése
A helyzet nem biztos, hogy olyan reménytelen, mint Duggan és mások gondolják, bár jelentős átrendeződést igényelhet a technikai csapatokban és felelősségükben.
“Nem arról van szó, hogy megterheljük a fejlesztőt, hanem arról, hogy a fejlesztőket a megfelelő időben a megfelelő információkkal látjuk el” – mondta Durkin, Harness. „Nem akarnak mindent konfigurálni, de azt igen, hogy a megfelelő időben kapjanak információt ezekből a rendszerekből, hogy a műveletek, a biztonsági és az infrastrukturális csapatok zökkenőmentesen működhessenek. A fejlesztők nem törődnek vele, hacsak el nem törik valami.”
Nigel Simpson, a Walt Disney Company vállalati technológiai stratégiáért felelős korábbi igazgatója azt szeretné, ha a vállalatok „felismernék ezt a problémát, és dolgoznának rajta annak érdekében, hogy a fejlesztőknek ne kelljen aggódniuk a gépek működése miatt – és térjenek vissza a szoftverkészítéshez, ezt csinálják a legjobban.”
Fontos megjegyezni, hogy a devops egy kontinuum, és megvalósítása szervezetenként változik. Csak azért, mert a fejlesztők most is elvégezhetnek bizonyos műveleteket, még nem jelenti azt, hogy mindig meg kell tenniük.
“Az infrastruktúra fejlesztői irányítása nem egy mindent vagy semmit” javaslat” – írta Lydia Leong, a Gartner elemzője. „A felelősség megosztható az alkalmazás életciklusa között, így kihasználhatja a „megépíted, te futtatod” előnyeit anélkül, hogy szükségszerűen egy szelídítetlen és feltérképezetlen vadonba ugorná a fejlesztőket, és szerencsét kívánna nekik a túléléshez, mert ez „nem infrastrukturális és üzemeltetési csapat probléma. ‘ többé.”
Más szavakkal: “Rendben van, ha fejlesztőinek teljes önkiszolgáló hozzáférést biztosítanak a fejlesztői és tesztkörnyezetekhez, és lehetővé teszik az infrastruktúra kiépítését éles kódsablonokként anélkül, hogy teljes felelősséget vállalnának a termelésért” – írta Leong.
Ahogy Brown van Ondat látja, a Kubernetes konténerek összehangolása a két csapat közötti rétegként jelenik meg, elválasztva az aggodalmakat, így a fejlesztők a kódjukra összpontosíthatnak, és a műveletek biztosíthatják, hogy a mögöttes infrastruktúra és a csővezetékek optimalizálva legyenek a futtatáshoz. „Ne tekerjünk vissza azokhoz a csapatokhoz, amelyek nem beszélnek egymással” – mondta Brown.
A VMware „State of Kubernetes in 2022” (A Kubernetes állapota 2022-ben) című jelentése szerint a 776 válaszadó 54%-a mondta azt, hogy a jobb fejlesztői hatékonyság volt a fő oka a Kubernetes alkalmazásának, és több mint egyharmada (37%) mondta azt, hogy a kezelői hatékonyságot szeretné javítani.
“Ne essen abba a tévhitbe, hogy mindenkit szakértővé próbálunk tenni” – írta e-mailes hírlevelében Kaspar von Grunberg, a Humanitec alapítója. “A nagy teljesítményű csapatokban kevés a Kubernetes magas szintű szakértője, és magas az absztrakció szintje, hogy mindenki más kognitív terhelése alacsony legyen.”
Devops meghalt
Ha a devopok korszaka valóban a végéhez közeledik, vagy ha a ragyogás éppen kezd alábbhagyni, mi a következő lépés?
A Site Reliability Engineering (SRE), amely a Google-ból nőtt ki, miközben saját, devops-szal kapcsolatos növekedési fájdalmaitól szenvedett, népszerű megoldásnak bizonyult.
„Alapvetően ez történik, amikor megkérünk egy szoftvermérnököt, hogy tervezzen meg egy műveleti funkciót” – mondja gyakran Ben Treynor, a Google mérnöki részlegének alelnöke és az SRE keresztapja.
Vegyük a két nagy pénzintézetet, a Vanguardot és a Morgan Stanley-t, amelyek nehezen találták egyensúlyban a fejlesztői és az operátori feladatokat, miközben inkább felhőalapú gyakorlatokra tértek át.
A központi működési szinten és az egyes fejlesztői csapatokon belüli SRE biztonsági burkolat bevezetésével mindkét vállalat megerősítette azt a bizalmat, hogy megtalálják a megfelelő egyensúlyt a fejlesztői sebesség és a működési stabilitás között.
Ugyanakkor az SRE funkciót is kritizálták. Az SRE-elvek megállapítását „néha félreértik, mint az operatív csapat újramárkáját” – jegyezte meg Trevor Brosnan, a Morgan Stanley fejlesztői és vállalati technológiai architektúrájának vezetője.
“Ez egy árnyalatnyi megoldandó probléma” – mondta Christina Yakomin, a Vanguard telephely-megbízhatósági mérnöke. “Az SRE bevezetése azt az érzést kelti az emberekben, hogy a műveleteket visszazárjuk ebbe a szerepkörbe.” Ehelyett a Yakomin arra akarja ösztönözni a Vanguard fejlesztőit és üzemeltetési szakértőit, hogy osszanak meg felelősséget a biztonságért, és biztosítsák, hogy a megosztott platformokkal rendelkező csapatok teljes körű működési felelősséget vállaljanak értük.
Éljen a platform technológia
A házon belüli fejlesztői platform ötlete, vagy a platformtervezés tudományága szintén úgy jelent meg, hogy a szervezetek megadják a fejlesztőknek a szükséges eszközöket, kiegészítve a megfelelő szervezeti védőkorlátokkal, hogy a fejlesztők a lehető legjobb munkát végezzék. csinálni.
A házon belüli fejlesztői platform jellemzően azokból az API-kból, eszközökből, szolgáltatásokból, tudásból és támogatásból áll, amelyekre a fejlesztőknek szüksége van ahhoz, hogy kódjukat élesbe vigyék, és egy vállalati szabványú platformot alkotnak, amelyet egy speciális szakértői vagy terméktulajdonos csapat tart fenn.
“A Devops meghalt, éljen a platformtervezés” tweetelt szoftvermérnök és devops kommentátor, Sid Palas. „A fejlesztők nem szeretik az infrastruktúrát, a vállalatoknak szükségük van az infrastruktúra feletti ellenőrzésre, ahogy fejlődnek. A platformtervezés lehetővé teszi ennek a két ténynek az együttélését.”
Brandon Byars, a Thoughtworks szoftvertanácsadó technológiai vezetője azt mondja, hogy gyakran “úgy látja, hogy ez a részleg jól működik a platformmérnöki csapatokban, és igyekeznek kiküszöbölni a fejlesztők súrlódásait, miközben a gombjaikat pörgetni akarják”. Azonban hozzáteszi: “Ahol ez nem működik jól, az a fejlesztők megkérése, hogy mindezt központosított szakértelem és szerszámtámogatás nélkül végezzék el.”
A szoftverfejlesztési és üzemeltetési csapatok közötti egyensúlyozást minden olyan szervezet ismeri, amely a devops elvek megvalósításán dolgozott mérnöki csapataiban. Ez egyben egy egyensúlyozási aktus is, amely egyre összetettebbé válik a felhőalapú komplexitás korszakában.
Copyright © 2022 IDG Communications, Inc.