Gestione multi-cloud

"Multi-cloud" è spesso usato come termine strategico — un motivo per diversificare rispetto a un unico fornitore, negoziare prezzi migliori o soddisfare un requisito di residenza dei dati. La gestione multi-cloud è lo strato operativo più circoscritto che sta alla base di quella strategia: gli strumenti e i processi che permettono a un team infrastrutturale di eseguire realmente i workload su più provider senza trattare ciascuno come un lavoro a sé. Senza di essa, "multi-cloud" nella pratica significa una console separata, un set di credenziali separato e una terminologia diversa per ogni provider, e nessun luogo unico in cui rispondere a una domanda di base: quale infrastruttura esiste in questo momento, e chi l'ha modificata per ultimo.

Ogni provider fornisce la propria console, CLI, modello IAM e vocabolario per gli stessi elementi di base — una macchina virtuale, un security group, una zona DNS, un volume di storage. Questa frammentazione è il vero problema che la gestione multi-cloud risolve. Si parte dalla discovery: connettere un account provider e vedere immediatamente un inventario di ciò che vi è già in esecuzione, prima che qualcosa venga migrato o modificato. Da lì si applica un unico flusso di lavoro coerente alle azioni comuni del ciclo di vita — provisioning, avvio, arresto, ridimensionamento, eliminazione — indipendentemente dal provider su cui si trova una risorsa. Le implementazioni più solide gestiscono la configurazione in tempo reale e in modo sincrono direttamente presso il provider, anziché tramite una copia in cache nel proprio database, cosicché una modifica effettuata tramite lo strumento sia la stessa che si vedrebbe accedendo alla console del provider stesso.

La gestione multi-cloud va oltre il ciclo di vita del compute, estendendosi alle parti delle operazioni che creano un rischio reale quando sono incoerenti tra provider diversi. Il controllo degli accessi deve funzionare allo stesso modo ovunque — single sign-on, permessi basati sui ruoli ed elevazione dei privilegi soggetta ad approvazione per le azioni sensibili, invece di un modello di identità diverso per ogni provider. Ogni modifica deve essere attribuibile, ed è per questo che un audit trail esteso a tutti i provider connessi conta qui più che in un setup single-cloud — è la differenza tra una domanda a cui si può rispondere e un'indagine. E poiché il costo dell'infrastruttura è una delle prime cose che diventa illeggibile tra più provider, la visibilità sui costi e il rilevamento delle anomalie devono stare nello stesso luogo del provisioning, non in un foglio di calcolo separato riconciliato una volta al mese. Molti team gestiscono anche infrastrutture che non sono affatto cloud — server on-premise o bare-metal — e si aspettano che la stessa disciplina di monitoraggio e patching si estenda anche lì.