Molnets kontrollplan
Ett kontrollplan för molnet är det lager av gränssnitt, API:er och tjänster som låter dig provisionera, konfigurera och hantera infrastruktur — skilt från dataplanet, som faktiskt kör dina arbetsbelastningar och flyttar din trafik. Varje leverantör har sitt eget; termen omfattar även system som hanterar flera leverantörer som ett enda plan.
All infrastruktur har två separata lager. Dataplanet är själva infrastrukturen: de virtuella maskiner som kör din applikation, nätverket som flyttar paket mellan dem, disken som hanterar läsningar och skrivningar. Kontrollplanet är allt du använder för att bestämma hur den infrastrukturen ska se ut och för att ändra den — API:et, konsolen, CLI:t, behörighetssystemet som avgör vem som får göra en ändring. När du skapar en VM i en molnkonsol, ändrar storlek på en disk eller öppnar en brandväggsport använder du kontrollplanet. Instansen som startar, de extra gigabytena som blir tillgängliga, trafiken som börjar flöda — det är dataplanet som svarar på vad kontrollplanet sa åt det att göra.
Skillnaden blir mer användbar när ett team använder mer än en leverantör. AWS har ett kontrollplan. Det har även Google Cloud, Azure, Hetzner och alla andra leverantörer — var och en med sin egen konsol, sin egen API-utformning, sina egna autentiseringsuppgifter, sin egen uppfattning om vad en 'security group' eller en brandväggsregel kallas för. Ett team som kör tre moln och tjugo bare-metal-servrar hanterar i praktiken tre eller fyra separata kontrollplan sida vid sida, plus vad de än använder för att hantera de servrar som inte finns i något moln alls. Inget tvingar dessa kontrollplan att stämma överens med varandra, och inget utanför er egen process gör en ändring som görs i ett av dem synlig för någon som tittar på ett annat.
'Kontrollplan för molnet' används också i en snävare betydelse — inom Kubernetes är kontrollplanet API-servern, schemaläggaren (scheduler) och controller-manager som avgör var pods körs, till skillnad från kubelets och de containrar som faktiskt kör dem på noderna. Ett 'multi-cloud'- eller 'enhetligt' kontrollplan utökar samma idé över flera leverantörer: en enda plats för att se och agera på infrastruktur som fysiskt finns i flera olika konton, regioner och leverantörer, istället för ett gränssnitt per leverantör. Det ersätter inte de underliggande kontrollplanen hos respektive leverantör — en förfrågan slutar fortfarande som ett API-anrop till AWS, Hetzner, eller fleet-agenten på en bare-metal-server — det placerar sig framför dem så att personen som gör ändringen bara behöver lära sig ett system.
Varför skillnaden har operativ betydelse
De flesta infrastrukturincidenter och luckor i granskningsspåret går tillbaka till problem i kontrollplanet, inte i dataplanet: en ändring som ingen loggade, en behörighet som ingen återkallade, en brandväggsregel som öppnades i en leverantörs konsol som ingen annan i teamet kan se. När varje moln har sitt eget kontrollplan och sitt eget granskningsspår blir "vem ändrade det här, och när" en fråga du besvarar genom att logga in i tre eller fyra olika konsoler och jämföra tidsstämplar för hand — eller genom att inte besvara den alls. För team som omfattas av regelverk som NIS2 är den luckan inte bara opraktisk: ändringshistorik, åtkomstkontroll och incidentbevis är precis vad en revisor eller tillsynsmyndighet frågar efter först, och ett fragmenterat kontrollplan är anledningen till att sådana bevis ofta inte finns samlade på ett ställe.
Så här passar Sencai in
Sencai är ett kontrollplan som ligger ovanpå de ursprungliga: det ansluter till konton hos elva molnleverantörer samt lokala servrar och bare-metal-servrar via en lättviktig fleet-agent, och inventerar det som redan körs i samma ögonblick som ett konto ansluts — ingen migrering krävs. Därifrån fungerar provisionering, start, stopp, storleksändring och borttagning av instanser på samma sätt oavsett leverantör. Du kan ansluta befintliga konton (inget flyttas, autentiseringsuppgifterna förblir återkallningsbara hos leverantören) eller låta Sencai provisionera och fakturera kapacitet direkt, och blanda båda inom en och samma organisation. Varje åtgärd hos varje ansluten leverantör hamnar i en enda append-only, hash-kedjad granskningslogg, så "vem ändrade det här, och när" blir en fråga, inte en utredning.
Se inventering och provisionering →