Cloud control plane
Un cloud control plane è il livello di interfacce, API e servizi che permette di effettuare il provisioning, configurare e gestire l'infrastruttura — distinto dal data plane, che esegue effettivamente i workload e instrada il traffico. Ogni provider ne fornisce uno proprio; il termine indica anche i sistemi che gestiscono più provider come un unico piano.
Ogni infrastruttura è composta da due livelli distinti. Il data plane è l'infrastruttura stessa: le macchine virtuali che eseguono l'applicazione, la rete che instrada i pacchetti tra di esse, il disco che gestisce le operazioni di lettura e scrittura. Il control plane è tutto ciò che si usa per decidere come deve essere quell'infrastruttura e per modificarla — l'API, la console, la CLI, il sistema di permessi che decide chi è autorizzato ad apportare una modifica. Quando si crea una VM in una console cloud, si ridimensiona un disco o si apre una porta sul firewall, si sta operando sul control plane. L'istanza che si avvia, i gigabyte aggiuntivi che diventano disponibili, il traffico che inizia a fluire — tutto questo è il data plane che risponde a ciò che il control plane gli ha indicato di fare.
La distinzione diventa più utile quando un team utilizza più di un provider. AWS ha un control plane. Lo stesso vale per Google Cloud, Azure, Hetzner e ogni altro provider — ciascuno con la propria console, la propria struttura di API, le proprie credenziali, una propria definizione di cosa sia un 'security group' o una 'firewall rule'. Un team che gestisce tre cloud e venti server bare-metal sta in realtà operando tre o quattro control plane separati in parallelo, oltre a qualsiasi strumento usi per gestire i server che non si trovano in alcun cloud. Nulla obbliga quei control plane a essere coerenti tra loro, e nulla al di fuori del proprio processo interno rende visibile, a chi guarda un altro sistema, una modifica effettuata in uno di essi.
'Cloud control plane' viene usato anche in un'accezione più ristretta — all'interno di Kubernetes, il control plane è l'API server, lo scheduler e il controller-manager che decidono dove eseguire i pod, distinto dai kubelet e dai container che li eseguono realmente sui nodi. Un control plane 'multi-cloud' o 'unificato' estende la stessa idea a più provider: un unico punto da cui vedere e agire sull'infrastruttura che risiede fisicamente in account, region e vendor diversi, invece di un'interfaccia per ogni provider. Non sostituisce i control plane sottostanti dei singoli provider — una richiesta finisce comunque per diventare una chiamata API verso AWS, verso Hetzner, o verso il fleet agent su un server bare-metal — si colloca davanti a essi in modo che chi effettua la modifica debba imparare a usare un solo sistema.
Perché questa distinzione conta operativamente
La maggior parte degli incidenti infrastrutturali e delle lacune di audit ha origine da problemi del control plane, non del data plane: una modifica che nessuno ha registrato, un permesso che nessuno ha revocato, una regola firewall aperta nella console di un provider che nessun altro membro del team può vedere. Quando ogni cloud ha il proprio control plane e la propria traccia di audit, "chi ha modificato cosa e quando" diventa una domanda a cui si risponde accedendo a tre o quattro console diverse e confrontando i timestamp a mano — oppure non rispondendo affatto. Per i team soggetti a framework di conformità come NIS2, questa lacuna non è solo scomoda: lo storico delle modifiche, il controllo degli accessi e le evidenze degli incidenti sono esattamente ciò che un auditor o un'autorità di controllo chiede per prima cosa, e un control plane frammentato è il motivo per cui quelle evidenze spesso non esistono in un unico posto.
Come si inserisce Sencai
Sencai è un control plane che si colloca sopra quelli nativi: si connette agli account di undici cloud provider, oltre a server on-premise e bare-metal tramite un fleet agent leggero, e inventaria ciò che è già in esecuzione nel momento stesso in cui un account viene collegato — senza necessità di migrazione. Da quel momento, il provisioning, l'avvio, l'arresto, il ridimensionamento e l'eliminazione delle istanze funzionano allo stesso modo indipendentemente dal provider. È possibile collegare account esistenti (nulla viene spostato, le credenziali restano revocabili presso il provider) oppure lasciare che sia Sencai a effettuare il provisioning e a fatturare la capacità direttamente, combinando entrambi gli approcci all'interno della stessa organizzazione. Ogni azione, su ciascun provider connesso, viene registrata in un unico audit log append-only con concatenazione hash, così che "chi ha modificato cosa e quando" diventi una query, non un'indagine.
Vedi inventario e provisioning →