Multi-cloud-hantering

"Multi-cloud" används ofta som en strategisk term — ett skäl att diversifiera bort från en enskild leverantör, förhandla fram bättre priser eller uppfylla ett krav på datalokalisering. Multi-cloud-hantering är det smalare, operativa lagret under den strategin: verktygen och processerna som gör att ett infrastrukturteam faktiskt kan köra arbetsbelastningar hos flera leverantörer utan att behandla var och en som ett separat jobb. Utan det innebär "multi-cloud" i praktiken en separat konsol, en egen uppsättning autentiseringsuppgifter och egen terminologi för varje leverantör, och ingen enskild plats för att besvara en grundläggande fråga: vilken infrastruktur finns just nu, och vem ändrade den senast.

Varje leverantör levererar sin egen konsol, CLI, IAM-modell och terminologi för samma underliggande byggstenar — en virtuell maskin, en säkerhetsgrupp, en DNS-zon, en lagringsvolym. Den fragmenteringen är det egentliga problem som multi-cloud-hantering löser. Det börjar med upptäckt: att ansluta ett leverantörskonto och omedelbart se en inventering av vad som redan körs där, innan något migreras eller ändras. Därifrån tillämpas ett konsekvent arbetsflöde på vanliga livscykelåtgärder — provisionering, start, stopp, storleksändring, borttagning — oavsett vilken leverantör en resurs finns hos. De starkare implementationerna hanterar konfigurationen live och synkront hos leverantören själv, snarare än via en cachad kopia i sin egen databas, så att en ändring gjord genom verktyget är samma ändring du skulle se genom att logga in i leverantörens egen konsol.

Multi-cloud-hantering sträcker sig bortom livscykeln för beräkningsresurser, in i de delar av driften som faktiskt skapar risk när de är inkonsekventa mellan leverantörer. Åtkomstkontroll måste fungera på samma sätt överallt — single sign-on, rollbaserade behörigheter och godkännandestyrd behörighetseskalering för känsliga åtgärder, i stället för en egen identitetsmodell per leverantör. Varje ändring måste kunna knytas till en person, vilket är varför en granskningslogg som täcker alla anslutna leverantörer betyder mer här än i en miljö med en enda molnleverantör — det är skillnaden mellan en fråga som går att besvara och en utredning. Och eftersom infrastrukturkostnad är en av de första sakerna som blir svåröverskådlig mellan leverantörer hör kostnadsöversikt och avvikelsedetektering hemma på samma plats som provisionering, inte i ett separat kalkylark som stäms av en gång i månaden. Många team driver också infrastruktur som inte alls är moln — on-premise eller bare-metal-servrar — och förväntar sig samma disciplin kring övervakning och patchning även där.