Strategia di alto livello
Una volta che un'organizzazione ha stabilito di essere pronta a passare al cloud, occorre prendere una serie di decisioni specifiche per il contesto. Avere una strategia generale e orientativa è fondamentale.
Definire i suoi obiettivi e i problemi che spera di risolvere con la sua strategia di migrazione al cloud può aiutare a garantire che le strategie aziendali e tecnologiche siano allineate. Cosa spera di ottenere?
- Sta cercando di ridurre i costi o di migliorare il time to market?
- Sta lottando per attrarre e trattenere personale qualificato?
- Sta cercando di migliorare la qualità dei suoi prodotti o servizi?
- Questi obiettivi sono urgenti o a lungo termine?
- Ha dei requisiti di conformità che devono essere soddisfatti quando passa al cloud?
Questi fattori sono fondamentali per determinare la strategia di migrazione al cloud.
Selezione del fornitore
Per un'organizzazione relativamente piccola con una serie omogenea di requisiti di carico di lavoro, una strategia cloud a fornitore unico potrebbe essere la più appropriata, in quanto non è necessario investire in più fornitori di cloud per la ridondanza tecnica o per evitare il vendor lock-in.
Un'organizzazione molto più grande, come una banca globale con diversi carichi di lavoro e vari livelli di requisiti tecnici, sarebbe più propensa a perseguire una strategia multi-cloud, in quanto ciò offrirebbe a ciascun team di progetto la flessibilità di scegliere il fornitore più adatto alle proprie esigenze. Inoltre, è più probabile che le organizzazioni più grandi abbiano dei requisiti di conformità interni ed esterni da soddisfare, che possono richiedere la capacità di spostare i carichi di lavoro tra i fornitori di cloud con un preavviso relativamente breve.
Una strategia ibrida, in cui sono coinvolti sia un data center tradizionale che uno o più fornitori di cloud, può avere senso anche per le aziende di medie e grandi dimensioni, soprattutto se la transizione al cloud durerà diversi anni. Questa strategia può anche essere rilevante se c'è la necessità di evolvere le tattiche di migrazione al cloud in modo più dinamico, man mano che si impara di più sull'implementazione delle tecnologie cloud all'interno della propria azienda.
Le sei R
Una volta determinati i suoi obiettivi di migrazione al cloud e la strategia del fornitore, il passo successivo è decidere come migrare i carichi di lavoro al cloud.
Per prima cosa, dovrà condurre un audit della sua applicazione esistente. Questo può darle un'idea del livello e della natura del lavoro necessario per passare al cloud. Durante questo audit, può classificare le sue applicazioni in base all'approccio che vuole che i team che ne sono responsabili adottino per la loro migrazione al cloud. AWS delinea sei "strategie di migrazione comuni". Queste possono essere applicate in modo trasversale, oppure ogni team può scegliere la strategia più adatta alla propria struttura in quel momento, a seconda delle dimensioni dell'organizzazione e della complessità coinvolta.
1. Rehost
La prima e più semplice strategia consiste nel rehosting della sua applicazione (noto anche come "lift and shift"). Si tratta di spostarli da server fisici in esecuzione in un data center a server virtuali in esecuzione nel cloud. In genere, questo non richiede modifiche al codice e relativamente poche modifiche ai processi e alle tecnologie circostanti, come il networking. Può anche consentire alla sua organizzazione di sviluppare le competenze e l'esperienza cloud necessarie per altre pratiche cloud-native.
2. Ripiattaforma
Conosciuto anche come "lift, tinker and shift", questo approccio è simile al rehosting, ma fa un passo avanti integrando una serie di servizi cloud fondamentali a livello di applicazione. Ad esempio, AWS IAM (Identity and Access Management) potrebbe essere integrato nella sua applicazione per sostituire o integrare i sistemi IAM più tradizionali orientati ai data center.
3. Riacquisto
Conosciuto anche come "drop and shop", questo approccio prevede la sostituzione di un'applicazione esistente on-premise con un servizio su licenza basato sul cloud. Ciò può comportare la modifica del modello di licenza utilizzato dalla sua azienda, la riduzione dei costi di manutenzione e, potenzialmente, un percorso più rapido e semplice per l'aggiornamento.
4. Refactor/Ricerca
Un approccio più cloud-native consiste nel prendere le basi di codice esistenti e modificarle o estenderle per lavorare con i servizi cloud più moderni. Un esempio è quello di containerizzare il codice della sua applicazione, eseguire la configurazione ed eseguirla all'interno di un servizio Kubernetes basato sul cloud, come EKS di Amazon o AKS di Azure. Ciò può comportare una sostanziale riscrittura della base di codice esistente per consentirne il funzionamento e aumentare la scalabilità; una riscrittura completa può persino essere necessaria per utilizzare strumenti veramente cloud-nativi (ad esempio, strumenti serverless come AWS Lambda o Azure Functions).
5. Andare in pensione
Con le ultime due strategie "passive", i carichi di lavoro non vengono affatto migrati nel cloud. L'audit del carico di lavoro potrebbe far emergere sistemi ridondanti o non più degni di essere mantenuti. Queste applicazioni possono essere ritirate.
6. Conservare
L'ultima strategia "passiva", la ritenzione, prevede che la sua applicazione rimanga in funzione e scelga di non migrare nel cloud per il prossimo futuro. Ci sono diverse possibili ragioni per conservare la sua applicazione al di fuori del cloud, tra cui:
- Vincoli normativi sul luogo in cui l'applicazione può essere eseguita o elevati requisiti di conformità interna in materia di sicurezza.
- Mission-criticality of software that can make planning a move to cloud technologies earlier in the migration cycle too risky and uncertain
- Non esiste un business case per l'interruzione causata dallo spostamento dell'applicazione.
- I sistemi legacy non sono supportati negli ambienti cloud
Da dove cominciare
Oltre a decidere la strategia generale e a classificare l'approccio tattico per carico di lavoro, dovrà pianificare come costruire l'infrastruttura cloud per supportare il movimento dei carichi di lavoro. Un approccio è quello di lasciare che ogni team scelga come costruire i propri sistemi nel cloud. Tuttavia, questo approccio presenta diversi svantaggi, in quanto i team possono duplicare gli anti-pattern di implementazione e ripetere gli errori degli altri o violare le regole di Conformità interne/esterne.
Un approccio alternativo consiste nel creare un tipo di "centro di eccellenza" centralizzato o un team di infrastruttura cloud. Questo team può scegliere di creare i sistemi principali su cui gli altri team possono eseguire i loro carichi di lavoro.
Quando si tratta di stabilire questi guard rail, ci sono alcuni elementi di design che dovrebbero essere prioritari rispetto ad altri.
Conti
L'unità di base della sua architettura cloud è l'account cloud. L'utilizzo di un unico account per tutta l'organizzazione non è quasi mai scalabile, in quanto si finisce per superare i limiti dell'account. È quindi importante determinare i confini del conto. L'account verrà utilizzato per rappresentare una particolare business unit, un singolo team o un gruppo di servizi software? Come funzionerà con il suo reparto finanziario? Chi dovrebbe ricevere la fattura? È importante capire questo aspetto fin dall'inizio, perché i costi possono aumentare rapidamente.
IAM
La prossima unità di base dell'architettura è il sistema di gestione dell'identità e dell'accesso. Man mano che la sua infrastruttura cloud cresce, dovrà considerare le implicazioni sulla sicurezza dell'accesso degli utenti ai vari servizi e dati cloud, e prima è meglio è. Imporre queste regole in modo retroattivo su sistemi già in funzione può essere complicato.
Collegamento in rete
La migrazione al cloud comporta la virtualizzazione della rete esistente o una riprogettazione completa. Il servizio VPC (AWS) o VNet (Azure) le consente di impostare una rete isolata per eseguire un insieme separato di servizi all'interno del suo account. Occorre considerare attentamente la comunicazione via internet tra i servizi della sua organizzazione e le risorse di rete di base, come gli indirizzi IP.
Migrazione dei dati
Mentre è facile spostare i servizi di calcolo nel cloud, la migrazione dei dati può essere un po' più impegnativa. I grandi archivi di dati possono essere infrastrutture grandi e complesse, che richiedono un'attenta pianificazione per essere spostate. Ciò richiede una comprensione sufficientemente approfondita di come spostare i suoi dati nel cloud rispettando gli standard di performance, conformità e operatività della sua organizzazione.
CONCLUSIONI
Una volta chiarita la strategia cloud di alto livello, lo sviluppo di una strategia di migrazione cloud di successo richiede una pianificazione meticolosa e la considerazione di ogni aspetto della sua attività. Il passo successivo è la scelta della strategia di cloud vendor più adatta a lei, che si tratti di una semplice migrazione da un solo fornitore, di un approccio multi-cloud o di una strategia ibrida. Infine, dovrà progettare la sua migrazione al cloud considerando innanzitutto i componenti infrastrutturali chiave, prima di iniziare l'integrazione delle applicazioni.
Spero che questo post sia stato interessante e prezioso.
La invitiamo a leggere i prossimi post del blog sui container/Kubernetes e sui servizi serverless.
Se sta iniziando il suo viaggio verso il cloud, forse le interesserà leggere il mio nuovo white paper sulle Cinque migliori pratiche per una migrazione sicura di cloud .
Può leggere di più sulle soluzioni di Check Point Cloud Security qui o programmare una demo con uno degli ingegneri di Check Point Cloud Security qui.
Per capire come progettare e implementare architetture cloud sicure, consulti questo white paper.
Feedback