Il multi-cloud è un'idea orribile nel 90% dei casi, ma abbiamo riscontrato delle eccezioni. Questo articolo spiega come i team vincenti si preparano per il trambusto quotidiano delle configurazioni multi-cloud.
Negli ultimi anni, le aziende hanno adottato strategie multi-cloud nel tentativo di aumentare la flessibilità e la scelta e ridurre il vincolo dei fornitori. Secondo il report sullo stato del cloud 2020 di Flexera, la maggior parte delle aziende adotta il multi-cloud, con il 93% delle aziende che ha una strategia multi-cloud. In un recente sondaggio Gartner sugli utenti del cloud pubblico, l'81% degli intervistati ha affermato di lavorare con due o più fornitori. Il multi-cloud rende così tante cose più complicate che hai bisogno di una dannata buona ragione per giustificarlo. In Humanitec, vedono centinaia di team operativi e di piattaforme all'anno e spesso sono sorpreso che ci siano diversi validi motivi per passare al multi-cloud. Osservo anche che i team che hanno successo sono quelli che prendono sul serio il rimodellamento dei flussi di lavoro e delle configurazioni degli strumenti.
Che cos'è il multi-cloud computing?
In parole povere, multi-cloud significa: un'applicazione o più parti di essa sono in esecuzione su diversi fornitori di cloud. Questi possono essere pubblici o privati, ma in genere includono almeno uno o più provider pubblici. Può significare che l'archiviazione dei dati o servizi specifici sono in esecuzione su un provider cloud e altri su un altro. L'intera configurazione può essere eseguita su diversi provider cloud in parallelo. Questo è diverso dai servizi cloud ibridi in cui un componente è in esecuzione in sede e altre parti dell'applicazione sono in esecuzione nel cloud.
Perché adottare l'approccio multi-cloud?
Se non hai una ragione molto specifica, di solito consiglio vivamente di stare lontano dal multi-cloud. Come afferma l'autore e architetto aziendale Gregor Hohpe: "L'eccessiva complessità è la punizione della natura per le organizzazioni che non sono in grado di prendere decisioni". Il multi-cloud aumenta significativamente la complessità dei flussi di lavoro degli sviluppatori, del personale, degli strumenti e della sicurezza. Il rischio principale rimane l'aggiunta di ridondanza ai flussi di lavoro. Se stavi già lottando con la gestione di dozzine di script di distribuzione in versioni diverse per un'infrastruttura di destinazione, tutto questo raddoppia quando passi al multi-cloud.
Spesso il multi-cloud avviene involontariamente. Ad esempio, l'eredità è un colpevole comune di un approccio multi-cloud in cui generazioni di team hanno scelto fornitori particolari in base a ciò di cui avevano bisogno in un determinato momento. Man mano che le persone se ne andavano, nuove persone sono entrate a bordo, aggiungendo altri fornitori in base alle preferenze personali e alle competenze senza dover sottoscrivere le soluzioni cloud legacy. Ciò può accadere anche quando un'azienda viene acquisita da un'altra con le proprie preferenze sul posto di lavoro.
In Humanitec, analizzano e lavorano con centinaia di team di piattaforme e otteniamo un primo piano della loro configurazione operativa. Sembrava controintuitivo, ma negli ultimi due anni si sono imbattuti in diversi motivi validi e convincenti per adottare il multi-cloud.
Evita il blocco del fornitore del cloud
Le aziende possono optare per un approccio multi-cloud per evitare il rischio di vincoli ai fornitori di cloud. Se le tue applicazioni basate su cloud dipendono da funzionalità proprietarie specifiche per le offerte della tua piattaforma cloud ( Amazon Kinesis , ad esempio), questo può lasciarti in uno stato di vincolo del fornitore cloud. Ciò significa che sei vincolato alle modifiche alle offerte di prodotti e il prezzo aumenta senza possibilità di scegliere se cambiare fornitore. Avere i dati bloccati in un singolo provider aumenta anche il rischio se qualcosa va storto. Inoltre, l'utilizzo di un solo provider cloud potrebbe rivelarsi vincolante man mano che un'azienda cresce. Tuttavia, come afferma Gregor Hohpe:
“Molte aziende sono affascinate dall'idea di implementazioni multi-cloud portatili e escogitano piani sempre più elaborati e complessi (e costosi) che le manterranno apparentemente libere dal vincolo del provider cloud. Tuttavia, la maggior parte di questi approcci nega il motivo stesso per cui vorresti passare al cloud: basso attrito e la possibilità di utilizzare servizi ospitati come archiviazione o database ".
Ottimizzazione delle funzionalità e dei prezzi
Fondamentalmente, l'utilizzo di più fornitori offre l'opportunità di ottenere i migliori servizi di vari fornitori di cloud. Ogni fornitore di cloud è diverso quando si tratta di funzionalità e prezzi. Uno può eccellere nell'integrazione con tecnologie specifiche, uno è più bravo nell'hosting di VM, un altro può offrire un supporto migliore e un altro ancora può essere più economico. Un'azienda può scegliere di dare la priorità a un provider cloud più costoso in quanto offre una maggiore sicurezza per i dati costosi mentre ne utilizza un altro per i dati meno critici.
Inoltre, mentre i carichi di lavoro possono essere creati per essere indipendenti dal fornitore, alcuni sono meglio serviti da piattaforme cloud specifiche. Le app che utilizzano API native di AWS come le competenze di Alexa vengono servite al meglio utilizzando Amazon Web Services, ad esempio.
Conformità e riduzione del rischio
La minimizzazione del rischio e le normative e i requisiti di conformità sono comuni alle imprese mission-critical come infrastrutture pubbliche, sanità e banche. Possono essere richiesti, ai sensi delle normative HIPAA, per archiviare i dati dei pazienti in locale o in un cloud privato, ad esempio. Tali settori possono anche scegliere di eseguire strutture parallele su diversi fornitori di cloud, il che significa che se uno dei principali fornitori di cloud dovesse fallire, in un caso di ripristino di emergenza potrebbe semplicemente continuare a funzionare su un altro fornitore.
Altri esempi si possono trovare nel settore bancario. La conformità lì, ad esempio, richiede che i sistemi non possano essere soggetti a shock di prezzo. Un'alternativa deve quindi essere disponibile nell'ipotetico caso in cui un fornitore di servizi cloud aumenti improvvisamente i propri prezzi in modo brusco.
Requisiti legali e applicazione geografica
A volte l'attività aziendale in un determinato paese richiede un approccio multi-cloud. Mentre in genere esegui la tua architettura per impostazione predefinita su un grande fornitore statunitense (come AWS, Azure, GCP), per far funzionare la tua app in Cina o Russia ti verrà richiesto di eseguire su un fornitore cinese o russo.
Edge Computing
I modelli distribuiti come l'Edge Computing sono un modo comune per supportare applicazioni IoT mission-critical utilizzando analisi predittive, come veicoli autonomi, tecnologia smart city, produzione industriale e monitoraggio remoto, come le raffinerie di petrolio off-shore. Viene inoltre utilizzato per pre-elaborare dati come video e dati mobili a livello locale. L'edge computing è utile in scenari che richiedono una maggiore latenza dei dati con ritardi e tempi di inattività minimi o nulli. Ne consegue che mentre l'edge computing fa il lavoro pesante di raccolta, elaborazione e analisi all'edge, i dati che vanno al cloud per un'elaborazione più profonda e storica sono di dimensioni significative (i dati di un'auto connessa da soli sono circa 6 TB) e possono più gestibile in un cloud designato.
Sfide con le configurazioni multi-cloud
Come accennato in precedenza, tali ambienti multi-cloud possono creare un'abbondanza di sfide impreviste.
Come osserva Kelsey Hightower, potrebbe compromettere in modo significativo la tua efficacia come organizzazione.
Competenza e carenza di specialisti del cloud
Gli sviluppatori che lavorano con lo stesso provider di servizi cloud nel tempo, acquisiscono una conoscenza approfondita del dominio dei suoi strumenti, processi e configurazioni specifici. Questa conoscenza è integrata nelle capacità e nei risultati di un'azienda e genera un valore significativo. Il passaggio a fornitori multipli frantuma questa esperienza come gli sviluppatori hanno ora fare i conti con riqualificazione, relearning e certificazione. Quanto è trasferibile lo skillset esistente? Qual è il costo (tempo, finanziario e frustrazione dello sviluppatore) nell'aggiornamento delle competenze? Hai bisogno di assumere nuovo personale con conoscenze specialistiche? Trovo che anche con le cose più semplici come la gestione delle autorizzazioni ci siano enormi differenze per ogni provider. Hai mai provato ad applicare ciò che hai imparato a GCP in termini di IMAP su AWS? In bocca al lupo.
La mancanza di un'unica interfaccia
Le configurazioni multi-cloud sono difficili da gestire perché è difficile tenere traccia di ciò che è in esecuzione e dove. Ciò include connettività di rete, allocazione del carico di lavoro su cloud, velocità di trasmissione dati, archiviazione, backup e ripristino di emergenza. Può essere difficile integrare informazioni provenienti da fonti diverse e acquisire una comprensione dei movimenti all'interno e attraverso più cloud. Ogni fornitore di servizi cloud può avere la propria dashboard con API specifiche e le proprie regole di interfaccia, procedure e protocolli di autenticazione. C'è anche la sfida della migrazione e dell'accesso ai dati.
Gestione di più processi di deply e delivery
Una configurazione multi-cloud richiede più pipeline di distribuzione che aggiungono ulteriore complessità. Dalla gestione dei file di configurazione al provisioning del database alle pipeline di distribuzione: con ogni provider cloud, la quantità di lavoro aumenta notevolmente, distogliendo gli sviluppatori da altre attività essenziali. Una maggiore complessità può anche aumentare i carichi di lavoro sui team operativi. Una maggiore attrezzatura e più livelli di astrazione significano anche un maggior rischio di configurazione errata.
Integrazione, portabilità e interoperabilità
L'integrazione di più fornitori di cloud con l'applicazione e i database esistenti può essere impegnativa. I cloud in genere differiscono quando si tratta di API, funzioni e containerizzazione. Sei in grado di migrare i componenti su più di un cloud senza dover apportare modifiche importanti in ogni sistema? Come funziona l'interoperabilità tra i tuoi cloud pubblici e privati?
Cloud Sprawl
Technopedia definisce il cloud sprawl come la proliferazione incontrollata della presenza del cloud di un'organizzazione. Si verifica quando un'organizzazione controlla, monitora e gestisce in modo inadeguato le sue diverse istanze cloud, dando luogo a numerose singole istanze cloud che possono essere dimenticate ma continuano a utilizzare risorse o incorrere in costi poiché la maggior parte delle organizzazioni paga per i servizi cloud pubblici. Nessun venditore ti dirà che stai utilizzando troppe macchine quando i soldi continuano ad arrivare.
Oltre a costi inutili, la proliferazione incontrollata del cloud comporta il rischio di integrità dei dati e problemi di sicurezza. I carichi di lavoro non gestiti o non monitorati possono essere eseguiti in ambienti di controllo qualità o sviluppo / test utilizzando dati di produzione reali e pongono come potenziali vettori di attacco per gli hacker.
Sicurezza
Come accennato con il cloud sprawl, una delle maggiori sfide che probabilmente dovrai affrontare con un ambiente multi-cloud è la sicurezza. I protocolli di sicurezza possono differire tra i cloud e possono richiedere un'ampia personalizzazione. È essenziale poter vedere la sicurezza dell'intero ambiente multi-cloud in qualsiasi momento per prevenire attacchi informatici e rispondere alle vulnerabilità della sicurezza.
Funzioni e servizi del fornitore in silos
Sebbene ci siano somiglianze con i fornitori di cloud, ci sono anche offerte, funzionalità e servizi di fornitori in silos per rendere il loro prodotto più avvincente di quelli dei loro concorrenti. Un ambiente multi-cloud è più complesso se la mancanza di funzionalità equivalenti crea difficoltà, come la replica dell'architettura.
Come sopravvivere alle sfide multi-cloud
Standardizzare al denominatore comune più basso
Più le cose variano nel cloud, peggio diventa per te. Cerca tutto ciò che ti aiuta a standardizzare i livelli, quindi devi preoccuparti di meno di cambiare contesto nei vari cloud provider. Ci sono alcuni scenari in cui ciò è impossibile. Il materiale di autenticazione menzionato sopra è un esempio. Devi solo occupartene e questo richiederà la specializzazione di almeno un collega.
Ma quando ti muovi più in alto nello stack, ci sono strategie che puoi usare. Ad esempio, il provisioning delle risorse con script IaC o l'utilizzo di Terragrunt è uno di questi. A mio parere, è quasi necessario assicurarsi che i carichi di lavoro siano rigorosamente containerizzati. Nessun container, nessun multi-cloud. Successivamente, assicurati di utilizzare le offerte Kubernetes gestite (e solo quelle). Sì, i K8 possono essere una bestia, ma uniformano le configurazioni e le pratiche su tutta la linea e ci sono ottimi livelli operativi che possono aiutarti a gestirlo.
Definisci un'unica fonte di verità per le configurazioni (Singole source of truth)
Gestire le configurazioni è già abbastanza difficile su un cloud, specialmente se lavori con script non strutturati o non hai la tua merda insieme se si tratta di controllo delle versioni. Ma se lo ottimizzi in modo da non utilizzare script non strutturati ma definisci un modello di base che funziona per tutti i cloud (con Kubernetes come denominatore comune) diventa molto più semplice. Se uno sviluppatore desidera modificare qualcosa, applica le modifiche a questo modello tramite una CLI / API o un'interfaccia utente e al momento della distribuzione crei manifesti per ogni distribuzione. Quindi instradate i manifest a un cluster specificato e salvate semplicemente le informazioni deploy = manifest + target-cluster. In questo modo hai una struttura e una cronologia definite e verificabili di tutte le distribuzioni nei cloud. Forse vuoi anche creare una dashboard che mostri quale stato di quale configurazione è applicata a quale cluster? Questo renderà tutto molto più semplice.
Multi-cloud astratto interamente dagli sviluppatori di applicazioni
Se pensi che il multi-cloud stia interessando solo per il team operativo, ti sbagli. Il multi-cloud interrompe pesantemente anche i flussi di lavoro del team di sviluppo delle applicazioni. I tempi di attesa per nuovi ambienti, colleghi o parti di infrastruttura aumentano in modo significativo. Quello che vedo molto è che i team rispondono con infiniti slot di training per portare i loro front-end al passo sui charts di helm. La verità è che non gliene frega niente. Usa l'approccio di gestione della configurazione delineato sopra, fornisci loro un'interfaccia utente o una CLI intuitiva e lascia che l'unico punto di contatto che hanno con i cloud sia la specifica del tipo di ambiente e del fornitore di cloud che vogliono avviare. Non farlo, e il tuo team operativo sarà l'help-desk esteso che scende nelle attività di TicketOps.
Piattaforme di sviluppo interne
Poiché eseguono praticamente tutte le operazioni sopra descritte, standardizzano le configurazioni, aiutano i team operativi a orchestrare l'infrastruttura, distribuisce i log in modo che ogni sviluppatore possa eseguire il rollback, fornire un livello RBAC sopra tutti i cloud per gestire le autorizzazioni, e ti aiuta a gestire gli ambienti e le variabili di ambiente tra cloud, carichi di lavoro e applicazioni. Puoi costruirli da soli o prenderli fuori dalla scatola e valgono ogni centesimo. Ogni squadra d'élite li ha, come GitHub o Zalando, ma anche squadre sempre più piccole come Sport1 li hanno.
Fonte: dzone.com
