Il cloud ibrido descrive le connessioni tra ambienti cloud diversi. Multicloud significa utilizzare servizi di almeno due fornitori cloud. Le due caratteristiche possono coesistere: un’azienda può collegare un cloud privato ai servizi pubblici di due fornitori e adottare entrambi gli approcci.
Iniziate identificando l’ambiente in cui le applicazioni vengono eseguite: dove vengono utilizzate, chi fornisce servizi cloud e quali sono le dipendenze che collegano i sistemi. Questa descrizione è più utile che scegliere un’etichetta. Indica chi deve gestire l’accesso, la connettività, gli aggiornamenti e la risoluzione dei problemi.
Distinguere prima tre concetti
Un cloud privato non deve necessariamente trovarsi in ufficio
Un cloud privato serve una singola organizzazione. Può operare all’interno dell’azienda o tramite un operatore esterno. Un server di ufficio standard non diventa automaticamente un cloud. La definizione di cloud di NIST include l’accesso autonomo su richiesta, l’accesso alla rete, un pool di risorse condivise, la flessibilità e l’utilizzo misurato.
Chiariamo il modello effettivo prima di confrontare. Un server che esegue un software di contabilità configurato manualmente da un amministratore può essere definito un sistema locale. Non etichettarlo semplicemente come un cloud privato per creare un diagramma di presentazione.
Un ambiente IT ibrido è più ampio del cloud ibrido
Secondo la definizione di NIST, un cloud ibrido combina infrastrutture cloud separate che rimangono distinte, ma sono connesse tramite tecnologie che consentono la portabilità dei dati e delle applicazioni. Collegare un cloud privato a un cloud pubblico è un esempio comune. È comunque necessario progettare e testare il meccanismo di portabilità specifico.
I fornitori possono utilizzare il termine in modo più ampio. Ad esempio, AWS descrive un modello ibrido attraverso il data center di un’azienda e un fornitore di servizi cloud. Concordate sulla terminologia quando si discute di un progetto. In questo articolo, una combinazione di sistemi locali e servizi cloud è un ambiente IT ibrido. Utilizziamo la definizione rigorosa di cloud quando è applicabile.
Il multicloud conta i fornitori, non i server
Due regioni di un unico fornitore di servizi cloud non creano automaticamente un ambiente multicloud. Due fornitori creano un ambiente del genere anche quando le loro applicazioni non scambiano dati. L’etichetta non garantisce la gestione unificata, la portabilità dei carichi di lavoro o il failover in caso di disastro.
Chiariamo cosa si intende considerare. Un’azienda può utilizzare l’infrastruttura cloud di un fornitore e le applicazioni pronte all’uso di un altro. Per un inventario completo delle dipendenze cloud, ciò significa più fornitori. Per un progetto di migrazione di un’applicazione su server, è necessario distinguere le piattaforme di infrastruttura dai servizi pronoti all’uso. L’utilizzo di quest’ultimi non implica la portabilità dell’applicazione tra di essi.
Confrontare i modelli in base alle attività operative
|
Domanda |
Ambiente ibrido |
Multicloud |
Che cosa registrare |
|---|---|---|---|
|
Che cosa viene combinato |
Sistemi locali e cloud, oppure cloud diversi collegati tra loro |
Servizi di due o più fornitori cloud |
Un elenco di sistemi, fornitori e connessioni |
|
Perché serve la connettività |
Per determinate dipendenze tra ambienti |
Quando devono interagire applicazioni di fornitori diversi |
Direzioni dello scambio di dati e requisiti applicativi |
|
Come funziona l’accesso |
Gli account locali e cloud possono richiedere coordinamento |
Ogni fornitore ha ruoli e confini amministrativi propri |
La fonte delle identità e il responsabile dell’assegnazione dei permessi |
|
Chi risolve un guasto |
Distinguere componenti locali, cloud e connessione |
Distinguere piattaforme, integrazioni e connessione |
Un responsabile dell’intero servizio |
|
Se un’applicazione può essere spostata |
Dipende da formati, licenze, dati e integrazioni |
Un secondo fornitore non garantisce la portabilità |
Un percorso di migrazione verificato per lo specifico carico di lavoro |
|
Se esiste un’opzione di ripristino |
Solo se è stata progettata e provata |
Il secondo cloud può svolgere un compito completamente diverso |
Uno scenario di guasto e l’esito della prova |
|
Che cosa includono i costi |
Hardware, servizi cloud, connettività e assistenza |
Servizi da diversi fornitori, scambio di dati e competenze specifiche |
Un unico modello di costo con un responsabile per ciascuna categoria |
Non esiste un fornitore ideale in termini di sicurezza, prezzo o affidabilità. Queste qualità dipendono dai componenti specifici e dal lavoro del team. Confrontare i progetti per la stessa attività aziendale e gli stessi requisiti di risultato.
Distinguere un progetto deliberato da una raccolta casuale di abbonamenti
Diversi dipartimenti possono acquistare servizi da diversi fornitori senza un progetto condiviso. Questo scenario crea già diverse dipendenze nel cloud, anche se nessuno lo ha pianificato come un ambiente multicloud. Innanzitutto, identificare i proprietari degli abbonamenti, gli account amministrativi, i metodi di pagamento e i dati in ciascun servizio. Mantenere i servizi utili, ma chiarire i confini di responsabilità sconosci.
Se un fornitore soddisfa i requisiti e il team non ha motivo di aggiungere un secondo, l’eccessiva complessità è inutile. Avere più cloud non è una fase obbligatoria della crescita aziendale. Distinguere la necessità di una specifica funzione dalla necessità di un’opzione di ripristino per la stessa applicazione. Queste attività richiedono soluzioni diverse.
Tre configurazioni dell’ambiente per una piccola impresa
I seguenti esempi mostrano tre possibili configurazioni. Confrontatele con i vostri sistemi e verificate le connessioni, l’accesso e le responsabilità in ogni caso.
Un sistema in ufficio e un fornitore cloud
Configurazione: dipendenti, un’applicazione locale e il suo database, e posta elettronica nel cloud da un unico fornitore. Registrate separatamente qualsiasi connessione tra l’applicazione e la posta elettronica. Si tratta di un ambiente IT ibrido. Se il componente locale è un server standard, il termine ibrido cloud non è necessario.
La domanda principale qui non è il numero di cloud. Verificate se l’applicazione può funzionare senza connessioni esterne, dove i dipendenti effettuano l’accesso e come vengono inviate le notifiche. Anche un’applicazione locale può dipendere dalla verifica esterna delle licenze o da un elenco nel cloud.
Due fornitori cloud senza server locale
Configurazione: dipendenti, un sistema di vendita nel cloud fornito da A, un sito web nel cloud fornito da B, e scambio di richieste tra il sito web e il sistema di vendita. Si tratta di un ambiente multicloud. Due fornitori da soli non creano un ambiente ibrido. Ciò richiede infrastrutture cloud separate connesse tramite meccanismi per la portabilità dei dati e delle applicazioni.
Verificate il proprietario dello scambio, il formato dei dati, i limiti dell’interfaccia e la gestione degli errori. Se il sito web è disponibile ma le richieste non raggiungono mai il sistema di vendita, uno stato di funzionamento per entrambe le piattaforme non raggiunge l’obiettivo aziendale. Monitorate l’esito del trasferimento.
Un cloud privato e due fornitori pubblici
Configurazione: il cloud privato dell’azienda, il cloud pubblico A per un’applicazione, il cloud pubblico B per un’attività di analisi separata, e connessioni concordate per il trasferimento dei dati. Se le infrastrutture si connettono tramite meccanismi per la portabilità dei dati e delle applicazioni, il design combina ibrido cloud e multicloud.
Un piccolo team ha bisogno di una forte motivazione per questo design. Ad esempio, un sistema esistente potrebbe richiedere un ambiente privato mentre due servizi cloud soddisfano diversi requisiti confermati. Se un cloud deve gestire il picco di carico, verificate la compatibilità dell’applicazione, la capacità disponibile, i limiti e il trasferimento dei dati tempestivo. La crescita delle risorse non avviene automaticamente. Desiderare l’indipendenza da un singolo fornitore non dimostra che il team può supportare entrambe le piattaforme e spostare il carico di lavoro tra di esse.
Verificare connessioni, accesso e responsabilità
Mappare i flussi di dati e i punti di guasto
Per ogni connessione, specificare l’utente mittente, l’utente destinatario, il tipo di dati, la frequenza di scambio e l’interruzione accettabile. Separare il traffico aziendale, l’accesso all’utente, l’accesso amministrativo e il monitoraggio. Possono utilizzare percorsi diversi e avere conseguenze di errore differenti.
Successivamente, chiedere cosa succede se la connessione, la directory degli account o l’interfaccia dell’applicazione diventano inaccessibili. Definire la coda delle operazioni non elaborate, il processo di riprova e il metodo per rilevare le transazioni mancanti. Misurare un’operazione reale sotto carico previsto lungo l’intero percorso di scambio. Un secondo fornitore non garantisce una latenza inferiore. Una connessione tra piattaforme non garantisce uno scambio di dati corretto.
Coordinare l’accesso e il ciclo di vita delle autorizzazioni
Definire la fonte dell’account, i proprietari dei gruppi e il processo di rimozione dell’accesso. Se alcuni sistemi non supportano l’autenticazione a più fattori, includere i loro account separati nei processi di assunzione, modifiche dei ruoli e dimissioni. Il supporto dell’autenticazione a più fattori non significa ruoli identici in ogni servizio.
Separare il lavoro quotidiano dalle azioni amministrative. Verificare l’autenticazione a più fattori, gli account di integrazione, la scadenza dei segreti e un metodo controllato per il recupero dell’accesso amministrativo. Non combinare tutte le autorizzazioni in un unico account per comodità.
Assegnare un responsabile dell’intero servizio
Ogni piattaforma può soddisfare i propri impegni, mentre il processo complessivo rimane interrotto. Assegnare a qualcuno che è responsabile dell’intero problema e coordina il team locale, i fornitori e l’operatore di connettività. Registrare i contatti, i confini di responsabilità e il processo di escalation nel registro del servizio.
Il tipo di servizio influisce su come viene suddiviso il lavoro. Con una macchina virtuale, l’azienda può possedere il sistema ospite e l’applicazione. Con un’applicazione cloud pronta all’uso, può gestire l’accesso e le impostazioni. I servizi cloud non eliminano la responsabilità per i dati e gli account. Verificare l’ambito del lavoro nella documentazione e nel contratto del servizio scelto, piuttosto che affidarsi alla parola “multicloud”.
Valutare portabilità e resilienza senza promesse
Un secondo fornitore non elimina la dipendenza dal primo
Un’applicazione può dipendere dalle interfacce di una piattaforma, dal formato del database, dal servizio di identità e dalle licenze. Un contenitore semplifica l’impacchettamento di una parte dell’applicazione, ma non rende identici i database esterni o i permessi di accesso tra le diverse piattaforme cloud. Verificare la portabilità dell’intera catena di lavoro.
Descrivere il percorso di uscita: quali dati è possibile esportare, in che formato, chi può accedere all’esportazione e dove l’applicazione funzionerà successivamente. Verificare le connessioni ripristinate e il funzionamento degli utenti. Se la migrazione non è stata testata, registrarla come limitazione piuttosto che come funzionalità disponibile.
Cloud diversi non sostituiscono un piano di ripristino
Se l’email utilizza un provider e il sito web un altro, il sito web non diventa un sistema di recupero email. Eseguire la stessa attività su un’altra piattaforma richiede un’applicazione compatibile, dati aggiornati, accesso, routing e una procedura di failover testata. Un provider di identità o di connettività può rimanere un singolo punto di errore.
Registrare il risultato necessario in caso di guasto e confermarlo tramite test. Un piano dettagliato di disaster recovery e le scelte di backup sono compiti separati. Identificare quale dipendenza richiede tale piano e chi lo mantiene.
Calcolare il costo della maggiore complessità
Riunire costi e monitoraggio in un’unica vista
Aggiungere i costi per lo scambio di dati, le connessioni, gli strumenti di gestione, le licenze, il supporto e il tempo di specialisti alle fatture del fornitore. Il beneficio di un singolo servizio può scomparire una volta che l’integrazione è inclusa. I termini di trasferimento dei dati variano a seconda del servizio e del percorso. Calcolare i flussi effettivi, piuttosto che solo il volume di archiviazione.
Utilizzare etichette comuni per i proprietari delle risorse, gli scopi e gli ambienti, ove possibile. Consolidare i costi per servizio aziendale e monitorare le deviazioni. Un’etichetta condivisa non elimina le differenze tra le fatture e le regole di due piattaforme.
Verificare i limiti di un pannello di gestione comune
Un pannello di controllo unificato è utile quando mostra le risorse e gli eventi di cui hai bisogno. Verifica i suoi ambiti: piattaforme e operazioni supportate, freschezza dei dati e comportamento in caso di interruzione della connessione. Alcune operazioni, indagini e impostazioni potrebbero comunque richiedere gli strumenti forniti dal provider.
Monitora i processi aziendali, non solo i server. Per la gestione degli ordini, è utile avere una visione chiara delle transazioni, delle code e degli errori. Definisci chi riceve gli avvisi, chi li verifica e come il team distingue i dati obsoleti del pannello di controllo da un sistema sano.
Concordare le regole prima di automatizzare le operazioni ripetute
Una piccola azienda non ha sempre bisogno di una piattaforma di orchestrazione separata. Inizia definendo le regole per l’assegnazione delle risorse, la verifica delle modifiche e la rimozione dei componenti indesiderati. Quindi, scegli uno strumento che riduca il lavoro manuale in base alle tue esigenze. L’automazione senza regole comuni risulterà semplicemente in impostazioni incoerenti più rapidamente.
Per ogni azione automatizzata, definisci i permessi, un registro dei risultati e un processo di ripristino. Verifica chi gestisce il flusso di lavoro quando il provider modifica la sua interfaccia e chi può eseguire l’attività se lo strumento fallisce. Un team di sviluppo dedicato, container e un’orchestrazione complessa dovrebbero seguire i requisiti dell’applicazione. Non sono funzionalità obbligatorie per l’ambiente multicloud.
Completare la lista di controllo prima di aggiungere un fornitore
|
Domanda |
Che cosa registrare |
|---|---|
|
Quale compito risolve il nuovo servizio |
Un requisito che l’ambiente attuale non può soddisfare |
|
Quali sistemi dipendono gli uni dagli altri |
Una mappa dei flussi di dati, degli accessi e degli accessi amministrativi |
|
Quali dati passano da un ambiente all’altro |
Tipi di dati, percorsi e luoghi di trattamento consentiti |
|
Che cosa funziona senza connettività esterna |
Funzioni disponibili e procedura per riprendere le attività |
|
Chi concede e revoca le autorizzazioni |
Il responsabile del processo e l’elenco degli account separati |
|
Chi risponde del risultato complessivo |
Il responsabile del servizio e i contatti dei partecipanti |
|
Come è stata verificata la portabilità |
L’esito di una prova o una limitazione esplicita |
|
Che cosa accade se un fornitore non è disponibile |
Uno scenario operativo e un requisito di ripristino separato |
|
Come vengono resi visibili errori e costi |
Fonti degli eventi, responsabili e componenti di costo |
|
Se il team dispone di capacità sufficienti |
Competenze richieste, sostituti del personale e ambito dell’assistenza |
|
Come uscire dal servizio |
Formati di esportazione, accesso, tempi e condizioni di cessazione |
Tradurre i vincoli sui dati in requisiti specifici: posizioni di elaborazione consentite, accesso del personale, registri e condizioni di supporto. L’implementazione locale o un singolo cloud privato da soli non dimostrano la conformità. Verificare l’applicabilità in tutto il sistema e gli obblighi attuali dell’azienda.
Dopo aver completato la checklist, assegnare un responsabile e una condizione di decisione per ogni domanda aperta. Se è necessario un nuovo servizio solo per una funzione, testare quella funzione con uno scambio di dati reale e accesso dell’utente. Decidere sull’espansione dopo aver verificato i risultati, piuttosto che osservare una dimostrazione di una piattaforma generale.
Scegliere l’ambiente per un’esigenza confermata
Innanzitutto, descrivere applicazioni, fornitori e dipendenze. Quindi, identificare dove è necessaria l’integrazione e quali capacità il team può supportare. Un ambiente ibrido connette i componenti necessari, mentre un ambiente multicloud offre la possibilità di scegliere servizi da diversi fornitori. Un processo funzionante con responsabili chiari e limiti dimostra i vantaggi.
Per valutare le connessioni esistenti e i requisiti di gestione, discutere infrastruttura cloud e ibrida Includendo i sistemi, i fornitori e le dipendenze problematiche. Iniziare con un elenco di sistemi, fornitori e dipendenze problematiche.
