Ogni presentazione di una piattaforma di gestione hybrid cloud inizia nello stesso punto: un diagramma con i tuoi server on-premise a sinistra, un cloud pubblico a destra, e una freccia tra i due etichettata migrazione. La freccia è il prodotto. È anche il motivo per cui la maggior parte di questi progetti si arena, perché la freccia costa diciotto mesi e il valore arriva solo alla fine. La domanda più utile è cosa potresti gestire da un unico posto già domani, senza spostare né riscrivere nulla.

L'hybrid non è una scelta architetturale che la maggior parte dei team ha fatto di proposito. È ciò che ottieni dopo un decennio: un rack di hardware proprio che fa ancora girare la cosa che nessuno può spostare facilmente, un ERP che nessuno vuole toccare, workload su un hyperscaler perché un cliente lo ha chiesto, compute più economico da qualche parte in Europa perché qualcuno ha fatto i conti, e qualche server in una struttura di colocation che precede metà del team attuale. Nessuno l'ha progettato. Tutti devono gestirlo.

Perché l'hybrid di solito significa due team

Il costo pratico dell'hybrid è organizzativo. Le risorse cloud si gestiscono in un browser con token API e tag; il parco fisico si gestisce con SSH, uno strumento di configurazione e la memoria storica dell'azienda. Due toolchain, due modelli mentali, due set di runbook, e di solito due gruppi di persone che descrivono il lavoro dell'altro come il lato legacy o il lato costoso. L'inventario diventa un merge di export. La revisione degli accessi diventa due revisioni degli accessi. Gli incidenti che attraversano il confine diventano una discussione su di chi sia il problema.

La risposta standard dei vendor è far somigliare un lato all'altro: installare uno stack di private cloud sul tuo hardware, oppure spostare tutto sul cloud pubblico e chiuderla lì. Entrambe sono strategie legittime ed entrambe sono enormi. Condividono anche un'assunzione che vale la pena mettere in discussione - che l'unificazione debba avvenire a livello di infrastruttura. Non è così. La maggior parte di ciò che un team ha davvero bisogno di unificare vive un piano più sopra: inventario, accessi, registro delle modifiche, costi e capacità di agire.

Cosa una piattaforma di gestione hybrid cloud non deve fare

Una piattaforma di gestione hybrid cloud si guadagna il suo posto per ciò che rifiuta di richiedere. Non deve richiederti di spostare un workload prima di diventare utile. Non deve richiedere un agent su ogni macchina per mostrarti il tuo parco cloud, né un account cloud per mostrarti i tuoi rack. Non deve diventare una nuova dipendenza nel tuo percorso critico - se va giù, i tuoi sistemi continuano a funzionare e perdi visibilità, non disponibilità. E non deve tenere in ostaggio la tua infrastruttura in un formato proprietario.

Per questo abbiamo costruito Sencai import-first. Colleghi un account provider con credenziali scoped e le tue istanze, reti e storage esistenti appaiono così come sono, non come cose da ricreare. Nessuno che valuta una piattaforma di infrastruttura ha un'infrastruttura vuota, e un prodotto che mostra valore solo dopo che hai ricostruito qualcosa al suo interno si è organizzato per far fallire la propria demo. La prima sessione dovrebbe mostrarti il tuo parco, comprese le parti che avevi silenziosamente dimenticato.

Parti da ciò che esiste già

Sul lato cloud questo significa undici provider dietro un'unica interfaccia: Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode di Akamai e Oracle Cloud. Non un'astrazione al minimo comune denominatore che nasconde tutto ciò che è interessante - reti, regole firewall e record DNS vengono creati e modificati direttamente presso il provider, quindi quello che vedi è quello che il provider ha realmente, e qualsiasi cosa configuri continua a funzionare anche se smetti di usarci domani mattina.

Sul lato fisico, un host agent porta i tuoi server nello stesso inventario: una macchina nel tuo rack, in una cage di colocation, o una macchina presso un provider con cui non ci integriamo direttamente. Si affianca alle risorse cloud invece di stare in una sezione separata, perché il punto centrale è che "cosa gestiamo" deve avere una sola risposta. Per i team i cui vincoli escludono del tutto un control plane hosted, esiste un'edizione on-premise con licenza annuale e supporto incluso.

La metà on-premise non è legacy

In questo mercato c'è un'assunzione pigra secondo cui l'hardware di proprietà sia uno stato transitorio verso qualcosa di meglio. A volte lo è. Spesso è la risposta corretta: workload pesanti e prevedibili di cui possiedi l'ammortamento, dati che una normativa o un contratto tengono dentro un edificio specifico, requisiti di latenza che nessuna regione può soddisfare, e hardware con ancora anni di vita utile davanti. Trattare quel parco come di serie B nei tuoi strumenti non ne accelera il pensionamento. Significa solo che viene monitorato peggio.

Un unico control plane su entrambe le metà cambia piccole cose che si sommano. La spesa viene tracciata su tutti i provider con dei limiti, così la domanda su quanto costa un ambiente ha una sola risposta invece di cinque export. Ruoli e inviti sono per organizzazione, quindi la revisione degli accessi è una sola revisione. E ogni modifica, cloud e on-premise allo stesso modo, finisce nella stessa audit trail append-only e concatenata tramite hash, esportata con l'hash di ogni voce e quello della voce precedente, così un auditor può verificare la sequenza in modo indipendente.

Cosa ti offre un unico control plane

L'inquadramento onesto è che niente di tutto ciò rende l'hybrid semplice. Due modelli di hosting hanno comunque due tipi di guasti, due processi di procurement e due strutture di costo, e nessuna interfaccia lo elimina. Quello che elimina è la tassa che paghi per il confine: gli inventari duplicati, la seconda revisione degli accessi, l'incidente in cui nessuno sa dire cosa stava facendo il lato on-premise in quel momento. Quella tassa la paga il tuo team più piccolo, in continuazione, ed è per questo che l'hybrid sembra peggiore di quanto sia realmente.

Quindi il test che imporremmo a qualsiasi piattaforma di gestione hybrid cloud, compresa la nostra, è breve. Riesci a vedere tutto ciò che gestisci, noleggiato e di proprietà, in un'unica lista, entro un'ora, senza migrare nulla? Riesci a dire chi ha cambiato cosa il mese scorso, su entrambi i lati del confine? Riesci a rispondere a quanto costa tutto questo senza aprire cinque console? Se sì, l'hybrid torna a essere semplice infrastruttura. Se no, non hai una piattaforma, hai un'altra console.