Skykontrollplan
En skykontrollplan består av grensesnittene, API-ene og tjenestene som lar deg provisjonere, konfigurere og administrere infrastruktur — atskilt fra dataplanet, som faktisk kjører arbeidsbelastningene dine og flytter trafikken din. Hver leverandør har sin egen; begrepet dekker også systemer som administrerer flere leverandører som ett plan.
All infrastruktur har to atskilte lag. Dataplanet er selve infrastrukturen: de virtuelle maskinene som kjører applikasjonen din, nettverket som flytter pakker mellom dem, disken som betjener lese- og skriveoperasjoner. Kontrollplanet er alt du bruker til å bestemme hvordan infrastrukturen skal se ut og til å endre den — API-et, konsollet, CLI-en, tillatelsessystemet som avgjør hvem som får lov til å gjøre en endring. Når du oppretter en VM i et skykonsoll, endrer størrelsen på en disk, eller åpner en brannmurport, opererer du kontrollplanet. Instansen som starter opp, de ekstra gigabytene som blir tilgjengelige, trafikken som begynner å flyte — det er dataplanet som reagerer på det kontrollplanet ba det gjøre.
Skillet blir mer nyttig når et team bruker mer enn én leverandør. AWS har et kontrollplan. Det samme har Google Cloud, Azure, Hetzner og alle andre leverandører — hver med sitt eget konsoll, sin egen API-utforming, sine egne påloggingsopplysninger, sin egen idé om hva en «security group» eller en «brannmurregel» kalles. Et team som bruker tre skyer og tjue bare-metal-servere, opererer i realiteten tre eller fire atskilte kontrollplan side om side, i tillegg til hva de enn bruker til å administrere serverne som ikke befinner seg i noen sky i det hele tatt. Ingenting tvinger disse kontrollplanene til å stemme overens med hverandre, og ingenting utenfor din egen prosess sørger for at en endring gjort i ett av dem er synlig for noen som ser på et annet.
«Skykontrollplan» brukes også i en snevrere betydning — i Kubernetes er kontrollplanet API-serveren, scheduleren og controller-manageren som bestemmer hvor pods kjører, i motsetning til kubelettene og containerne som faktisk kjører dem på nodene. Et «multi-cloud»- eller «samlet» kontrollplan utvider samme idé på tvers av leverandører: ett sted å se og handle på infrastruktur som fysisk befinner seg i flere ulike kontoer, regioner og leverandører, i stedet for ett grensesnitt per leverandør. Det erstatter ikke de underliggende leverandørenes kontrollplan — en forespørsel ender fortsatt opp som et API-kall til AWS, eller Hetzner, eller flåteagenten på en bare-metal-boks — det ligger foran dem, slik at personen som gjør endringen, bare trenger å lære ett system.
Hvorfor skillet har operasjonell betydning
De fleste infrastrukturhendelser og revisjonshull kan spores tilbake til problemer med kontrollplanet, ikke dataplanet: en endring ingen loggførte, en tillatelse ingen trakk tilbake, en brannmurregel åpnet i én leverandørs konsoll som ingen andre i teamet kan se. Når hver sky har sitt eget kontrollplan og sitt eget revisjonsspor, blir «hvem endret dette, og når» et spørsmål du besvarer ved å logge inn på tre eller fire forskjellige konsoller og sammenligne tidsstempler for hånd — eller ved ikke å besvare det i det hele tatt. For team underlagt compliance-rammeverk som NIS2 er dette gapet ikke bare upraktisk: endringshistorikk, tilgangskontroll og hendelsesbevis er nettopp det en revisor eller en tilsynsmyndighet spør om først, og et fragmentert kontrollplan er grunnen til at slikt bevis ofte ikke finnes på ett sted.
Hvordan Sencai passer inn
Sencai er et kontrollplan som ligger over de opprinnelige: det kobler til kontoer på tvers av elleve skyleverandører pluss on-premise- og bare-metal-servere gjennom en lettvekts flåteagent, og kartlegger det som allerede kjører i det øyeblikket en konto kobles til — ingen migrering nødvendig. Derfra fungerer provisjonering, oppstart, stans, endring av størrelse og sletting av instanser på samme måte uansett leverandør. Du kan koble til eksisterende kontoer (ingenting flyttes, påloggingsopplysningene kan fortsatt tilbakekalles hos leverandøren), eller la Sencai provisjonere og fakturere kapasitet direkte, og kombinere begge deler i én organisasjon. Hver handling på tvers av alle tilkoblede leverandører havner i én enkelt hash-kjedet revisjonslogg med kun tillegg, slik at «hvem endret dette, og når» er et oppslag, ikke en etterforskning.
Se inventar og provisjonering →