Molte organizzazioni stanno parlando e stanno iniziando ad abbracciare la migrazione del sistema verso il cloud, come parte di una strategia IT globale per utilizzare i cloud pubblici.
La migrazione dal cloud locale al cloud pubblico consente alle organizzazioni di scegliere tra una varietà di alternative, ognuna con i suoi propri benefici, requisiti di conoscenza e modello di prezzi diversi (rispetto al modello di licenza on-premise).
In questo articolo, esaminerò i diversi metodi, con i loro pro e contro e cercherò di spiegare quale metodo e' piu' adatto e in quale scenario.
Migrazione Lift & Shift In questo metodo
il cliente sceglie un sistema esistente dall'ambiente on-premise, rivedendo le risorse necessarie per eseguire il sistema in un ambiente cloud (numero di CPU / quantità di memoria e spazio su disco richiesto), la versione del sistema operativo (presupponendo che il provider cloud disponga di un'immagine per questo sistema operativo), verificando con il fornitore del software la possibilità di eseguire il sistema in un ambiente cloud (problemi di licenza) e distribuendo tutti i componenti software su un server virtuale nell'ambiente cloud (o eseguendo la migrazione dell'intero sistema, supponendo che il provider cloud offra un servizio gestito per la migrazione del sistema).
Questo è il metodo più comune e il più semplice (rispetto ad altre alternative ...) per la migrazione al cloud e la maggior parte dei fornitori di cloud (Infrastruttura come servizio) supporta questo metodo, ma dovremmo prendere in considerazione, dal punto di vista dei costi, questo il metodo è considerato costoso (in termini di costi e utilizzo delle risorse) se confrontato con l'acquisto di hardware fisico per 3-5 anni.
I modi più comuni per ridurre i costi del server sono:
· Ridimensionare le dimensioni del server (numero di CPU / quantità di memoria) in base all'utilizzo effettivo
· Acquista l'istanza riservata per 1 o 3 anni in anticipo
· Utilizzo di istanze Spot per server che non richiedono disponibilità di 24x7 o per applicazioni che possono sopravvivere a tempi di inattività temporanei, senza danneggiare l'intero servizio
Passaggio a micro-servizi e contenitori
In questo metodo, l'organizzazione avvia la migrazione dall'applicazione monolite (un sistema in cui tutti i componenti si collegano tra loro e che devono essere distribuiti insieme) allo sviluppo basato su micro-servizi, in cui ciascun componente viene eseguito in modo indipendente (di solito all'interno del proprio contenitore) e può essere sostituito, aggiornato e ridimensionato verticalmente secondo necessità e indipendentemente dal resto dei componenti del sistema.
È possibile eseguire container su server virtuali (l'intera gestione, l'aggiornamento e il ridimensionamento sono responsabilità del cliente) o come parte di un servizio gestito (come il servizio di cluster gestiti Kubernetes).
Questo metodo richiede ai team dello sviluppatore di sapere come impacchettare le loro applicazioni all'interno di contenitori, occuparsi del ridimensionamento, monitorare le attività dei contenitori (e le comunicazioni tra contenitori) e occuparsi di argomenti di sicurezza (come chi può accedere a un contenitore o la comunicazione tra contenitori non è crittografata, ecc.)
Questo metodo è adatto per le organizzazioni che desiderano modificare la propria architettura di applicazioni corrente o che stanno sviluppando nuove applicazioni. Le moderne applicazioni vengono sviluppate oggi come container e consentono al cliente di migrare tra gli ambienti on-premise verso il cloud pubblico e con le opportune regolazioni tra diversi fornitori di cloud (una volta risolti argomenti come la connettività ai servizi del fornitore di cloud corrente come l'accodamento dei messaggi, archiviazione, registrazione, ecc.)
Passare a Serverless / Funzione come servizio
Con questo metodo, il cliente non è responsabile della manutenzione del sistema operativo, della disponibilità del sistema o della scala. A causa del fatto che l'intera infrastruttura è stata gestita dal fornitore cloud, il fornitore si occupa della scala, come richiesto dalle esigenze dell'applicazione.
Questo metodo è adatto per servizi basati su eventi, con tempi di esecuzione brevi (da pochi secondi a pochi minuti). Come parte del passaggio ad applicazioni moderne, ci sono molti scenari per scegliere un linguaggio di sviluppo specifico, caricare il codice in un ambiente cloud gestito (Serverless), selezionare la potenza di calcolo desiderata (quantità di memoria, che influenza il numero di CPU) e creare trigger per eseguire la funzione.
È possibile incorporare funzionalità Serverless, come parte della moderna architettura di micro-servizi.
Il modello di determinazione del prezzo per questo metodo si basa sulla quantità di tempo in cui la funzione era in esecuzione e sulla quantità di memoria utilizzata per eseguire la funzione.
Casi d'uso comuni per Serverless: elaborazione delle immagini, analisi dei dati da dispositivi IoT, ecc.
Questo metodo non è adatto a tutte le applicazioni (a causa di brevi intervalli di esecuzione) e non tutti i linguaggi di sviluppo sono attualmente supportati da tutti i fornitori di servizi cloud.
Per esempio:
· AWS Lambda (attualmente) supporta nativamente le seguenti lingue: Java, Go, PowerShell, Node.JS, C #, Python, Ruby
· Funzioni di Azure (attualmente) supportano nativamente le seguenti lingue: Java, JavaScript, C #, PowerShell, Python, True Script
· Google Cloud Functions (attualmente) supporta nativamente le seguenti lingue: Python, Go, Node.JS
· Le funzioni Oracle (attualmente) supportano nativamente i seguenti linguaggi: Java, Python, Node.JS, Go, Ruby
Migrazione ai servizi gestiti (SaaS / PaaS)
In questo metodo, l'organizzazione sceglie un SaaS esistente (come Messaggi, CRM, ERP, ecc.) O PaaS esistenti (come Database, Archiviazione, ecc.)
Questo metodo comprende molti scenari in cui l'organizzazione vorrebbe consumare il servizio esistente, senza la necessità di mantenere l'infrastruttura (sistema operativo, archiviazione, backup, aspetti di sicurezza, ecc.). Dopo aver scelto un servizio esistente, l'organizzazione inizia a migrare i dati verso il servizio gestito, configura i diritti di accesso corretti, a volte configura la connettività VPN tra l'ambiente on-premise e l'ambiente cloud, configura il backup (in base al servizio supporta questa funzionalità) e utilizza il servizio
Il modello di prezzo cambia tra i fornitori di cloud (a volte si basa su prezzi mensili e talvolta su potenza di calcolo consumata o spazio di archiviazione consumato).
Maturare e rendere trasparenti i fornitori di servizi cloud, rivelare informazioni di fatturazione mensili accurate.
Inoltre, i fornitori di servizi cloud esperti sanno come gestire gli aspetti di privacy, bassi e normativi (come la conformità al GDPR e altre normative sulla privacy) utilizzando accordi di elaborazione dei dati.
Sommario
In questo articolo, ho esaminato i vari metodi di utilizzo ottimale del servizio cloud. Come possiamo vedere, non tutti i metodi sono adatti a tutti gli scenari o tutte le organizzazioni, ma non c'è dubbio che il futuro sarà il cloud e i servizi gestiti.
La mia raccomandazione per le organizzazioni: concentrati su ciò che apporta valore alla tua organizzazione (come banche, commercio, vendita al dettaglio, istruzione, ecc.), Forma i tuoi team IT e di sviluppo sui futuri cambiamenti tecnologici e migra la responsabilità di mantenere la tua infrastruttura aziendale verso i fornitori che si sono specializzati sull'argomento.
