La portabilità del cloud è una strategia per costruire applicazioni cloud-native scalabili e resilienti. Quando si parla di cloud-native, la portabilità del cloud è spesso implicita. Il cloud-native è un approccio architetturale allo sviluppo e alla distribuzione di applicazioni che massimizza l'elasticità e l'agilità delle risorse di cloud computing. Tuttavia, quando i team iniziano a lavorare con un unico fornitore di cloud e costruiscono intorno a strumenti e servizi gestiti specifici per quel fornitore iniziale, possono diventare rapidamente bloccati dal fornitore.
Un carico di lavoro portatile è un carico di lavoro che può essere facilmente migrato, distribuito e gestito in diversi ambienti informatici e piattaforme infrastrutturali. Consente alle aziende di evitare il vendor lock-in e di mantenere la flessibilità nelle loro strategie cloud.
Se iniziate con un approccio agnostico al cloud e sfruttate strumenti che possono essere utilizzati con qualsiasi provider di cloud, avrete la flessibilità necessaria per apportare modifiche in base alle vostre esigenze. Una strategia portatile consente inoltre di capire meglio come vengono utilizzate le risorse e perché, nonché di diversificare le risorse cloud o di cambiare fornitore in base alle esigenze delle applicazioni e dell'azienda.
Progettazione della strategia di portabilità del cloud
Se state iniziando o state riconsiderando la vostra architettura di applicazioni cloud, ecco cinque passi per progettare un carico di lavoro portatile di successo.
Identificare i requisiti
Il primo passo per ottenere un carico di lavoro trasportabile è identificare oggettivamente i requisiti del carico di lavoro. Ho visto troppo spesso che questo processo viene contaminato dalla soggettività, perché gli occhi si posano sui servizi attraenti di un provider cloud prima che questa fase iniziale sia stata completata. Pertanto, l'enfasi va posta sull'individuazione dei requisiti prima di di prendere in considerazione i fornitori di cloud.
Si tratta di un approccio essenziale per comprendere le funzionalità e le caratteristiche necessarie per soddisfare tutti i deliverable, per poi identificare gli stack software, le dipendenze e gli altri componenti per soddisfare tali esigenze. Avere una prospettiva oggettiva e più scarna come questa è come vedere la nuvola attraverso un obiettivo grandangolare. Evidenzia una serie di funzionalità che possono essere eseguite sulle primitive dell'infrastruttura cloud di base che esistono su qualsiasi provider.
Identificare i punti di blocco
Sia che l'applicazione sia ancora in fase di costruzione o di progettazione, sia che sia già stata sviluppata e distribuita su una piattaforma cloud, valutate l'attuale design dell'architettura per identificare i componenti e i servizi specifici di quella piattaforma.
Se avete individuato dei punti di blocco del fornitore, dedicate del tempo a valutarne i motivi. Iniziate rispondendo alle seguenti domande.
- È stata scelta una soluzione, o almeno presa in considerazione, per accelerare il rollout o il time-to-market?
- La soluzione si basava sulla consultazione o sul supporto/interoperabilità con altri servizi della piattaforma?
- Quali erano i costi al momento della scelta di quella soluzione rispetto a quelli attuali?
Dopo aver risposto a queste domande, si può iniziare a tracciare una mappa delle soluzioni open source ideali o di altre soluzioni alternative che forniscono le stesse o simili funzionalità, valutare gli sforzi necessari per l'implementazione e sviluppare un piano di esecuzione. Se dopo tutte le valutazioni si sceglie ancora di rimanere con un servizio specifico per la piattaforma, bisogna assicurarsi di avere una strategia di uscita. Il cloud vendor lock-in si presenta in due forme: architettonica e operativa. Una strategia di uscita ben ponderata da un servizio cloud proprietario può alleviare entrambe le preoccupazioni.
Costruire per la scalabilità e l'operatività
La scalabilità orizzontale e la distribuzione possono essere ottenute utilizzando tecnologie di bilanciamento del carico in combinazione con la containerizzazione, le immagini di calcolo, la gestione della configurazione e la separazione dei componenti stateful e stateless. Lo stato dovrebbe essere dichiarativo, ove possibile, mantenuto e gestito da un'unica fonte di verità e replicato e sincronizzato automaticamente.
Progettazione per la modularità
Le architetture monolitiche possono diventare ingombranti e quasi impossibili da gestire, il che riduce la flessibilità necessaria per apportare modifiche in modo portatile. Pertanto, i carichi di lavoro dovrebbero essere progettati con modularità, con componenti disparati chiaramente definiti e che funzionano insieme come un sistema ad accoppiamento libero. Un design cloud-native offre un processo efficiente di aggiornamento o sostituzione dei singoli componenti senza influenzare l'intero carico di lavoro, favorendo così la manutenibilità, l'adattabilità e... la portabilità!
Tutto come codice
Se state sviluppando applicazioni cloud-native, dovreste avere familiarità con un approccio dichiarativo alla distribuzione. Cercate di codificare ogni parte del vostro carico di lavoro: applicazione, infrastruttura e gestione della configurazione. Con questo approccio è possibile automatizzare la distribuzione di nuovi ambienti (ad esempio, dev, staging, test) o replicare gli ambienti esistenti. Questo faciliterà il processo di implementazione blue/green e vi aiuterà a recuperare rapidamente in caso di disastro.
Un approccio GitOps offre un unico pannello di vetro per ottenere la portabilità, con i vantaggi in termini di affidabilità delle pipeline di automazione per standardizzare le distribuzioni, una maggiore visibilità per la conformità/auditing e l'applicazione delle policy come codice. Per saperne di più, consultate la nostra guida gratuita GitOps per la portabilità nel cloud.
Cercate aiuto per progettare una strategia di portabilità sul cloud computing di Akamai? Contattate i nostri esperti di cloud per una consulenza.
Commenti (1)
Thanks for info!