La migrazione verso il cloud accelera: si sta passando dal “se” al “quando”.

Ma stiamo prevedendo tutte le implicazioni che questo passaggio comporta all’interno di un’azienda?

Ho provato ad avere un quadro un po’ più chiaro facendo 4 chiacchiere con due figure che lavorano ad Imola Informatica da tempo e che hanno grande esperienza e preparazione: Luca Acquaviva e Luca Poli.

Luca Acquaviva lavora a Imola Informatica da oltre 10 anni, è un Enterprise Architect interessato a progetti di trasformazione tecnologica e architetturale, progettazione di architetture e sistemi distribuiti, progettazione e implementazione di processi e di adozione di nuove metodologie. È specializzato in architetture distribuite: SOA e Microservices e si occupa da qualche anno di Cloud e DevOps.

E proprio a lui chiedo: quali sono i motivi per cui definisco una strategia per il cloud? O più semplicemente, perché voglio trasferirmi in cloud?

In effetti, questa è la prima domanda da porsi, perché quando si decide di evolvere il proprio modello operativo bisogna avere piena consapevolezza di quali siano le proprie esigenze e quali gli obiettivi che si vogliono raggiungere. Provando a spiegare un po’ più in dettaglio, devo fare diverse valutazioni:

• Quali sono i vantaggi per cui decido di spostarmi in cloud?
• Quali aspetti tecnologici, organizzativi e culturali sono impattati?
• Quali scenari sono interessanti e praticabili?
• Quali sono le mie tipologie di workload e quali di queste possono trarre vantaggio da uno spostamento in cloud?
• Quali dati posso portare e come posso farlo?
• Come posso uniformare i processi e rendere trasparente il porting?

Dare risposta a queste domande è fondamentale per fare chiarezza sugli obiettivi, selezionare i modelli cloud più vantaggiosi e arrivare alla definizione di una strategia di adozione, che non può considerare solo aspetti tecnologici. Iniziamo rispondendo alla prima di queste domande.

I motivi che spingono alla decisione di passare al cloud possono essere di diversa natura. Si possono avere vantaggi ad esempio dati  dall’offloading e da una maggiore capacità di scalabilità: questo avviene quando non si dispone di sufficienti risorse “in casa” ma si ha necessità di aumentarle senza essere costretti ad acquistarle. Un altro caso può essere quando si ha bisogno semplicemente di alta affidabilità e di soluzioni di disaster-recovery, oppure scegliere di sfruttare servizi (SaaS) offerti in cloud senza sviluppare né gestire soluzioni internamente (es. CRM).

Decidere di passare al cloud non costituisce solo una scelta tra un trasferimento totale o parziale, bisogna individuare gli scopi della transizione, le tipologie di workload che si vogliono portare in cloud e, soprattutto, cosa va modificato nel modello operativo al fine di uniformare ed automatizzare i modelli e processi di provisioning e renderne il più possibile trasparente la gestione.

Conviene allora fare alcune valutazioni:

• mi baso sulle specificità di un cloud provider fissato? Oppure conviene mantenere astrazione dal provider cloud ragionando di processi disaccoppiati e in ottica multicloud? Forse, così, si avrebbe una gestione uniforme indipendentemente dal cloud provider per poi ri-mappare a valle eventuali specificità del singolo cloud provider.
• Esistono già dei processi per la transizione o vanno ideati ex novo?
• Esistono framework di riferimento (Cloud Adoption Framework) che indirizzano i vari aspetti della trasformazione (Business, Organizzativo, Culturale, Tecnologico). Questi, indipendentemente dal cloud provider selezionato, possono essere utilizzati come base per guidare il processo di trasformazione.

Un paio di link utili come esempio:

Framework per l’adozione di Google Cloud: https://cloud.google.com/adoption-framework

AWS Cloud Adoption Framework: https://aws.amazon.com/it/professional-services/CAF/

Altra valutazione indispensabile per un accorto processo di migrazione in cloud è capire quale impatto potrà avere questa modifica rispetto all’intera infrastruttura.

Visti i molteplici fattori in gioco nel passaggio in cloud, è chiaro che serve trovare una strategia, cioè fissare un piano d’azione, e serve avere piena consapevolezza dell’ambiente in cui si opera grazie a una attenta analisi sui possibili effetti dell’intervento che si va ad eseguire.

Altro ambito da non sottovalutare è quello strategico. Per fare luce su alcuni aspetti, questa volta mi rivolgo a Luca Poli.

Luca Poli lavora ad Imola Informatica da quasi 6 anni, con un background in industrial IOT, si è interessato alla progettazione di architetture efficienti ed integrazioni eterogenee. Da qualche anno si occupa di processi e modelli di SDLC e Devops.

La mia domanda per Luca è: posso adottare una strategia big-bang o devo fare degli step incrementali? Quali sono gli aspetti da considerare e gli step da seguire?

È raro che si scelga di passare al cloud attraverso un cambiamento radicale come il big-bang e cioè una strategia implementata immediatamente senza alcun periodo di transizione. Si deve sempre tenere in considerazione il contesto in cui ci si trova. Molto raramente la strategia di adozione del cloud può vedere un approccio radicale quale il big-bang poiché essa non può prescindere dal contesto in cui si incardina.

La maggior parte degli ambienti “enterprise” infatti ha infatti alle spalle attività – e quindi strati tecnologici – decennali.

Un esempio di passaggio in cloud è quello di migrazione da un paradigma applicativo-infrastrutturale classico: questa migrazione va pianificata e richiede molti passaggi intermedi. Gli aspetti da considerare dipendono in parte dal “livello di maturità” con cui ci si approccia al nuovo modello.

Questo esprime il suo maggior valore se visto nella sua comune accezione di architettura distribuita, la quale obbliga ad un ripensamento sia delle modalità in cui le applicazioni sono costruite, sia dell’approccio alla gestione dell’infrastruttura.

Per riassumere, i passaggi possono essere:

• ripensare il comparto applicativo in ottica di cloud-readiness;
• potenziare, e definire se serve, i processi automatici e di compensazione per gestire il ciclo di vita di applicazioni cloud-ready;
• gestire e ripensare integrazioni con stack “legacy” che richiedono un tempo lungo di migrazione o che non possono essere migrati affatto;
• evolvere la cultura e delle competenze interne per la gestione di un nuovo paradigma infrastrutturale/architetturale;
• gestire con padronanza gli aspetti di sicurezza legati ad un’infrastruttura distribuita;
• rinnovare la cultura e l’adeguamento tecnico del monitoring, essendo in contesto applicativo-infrastrutturale necessariamente diverso;

Ma quindi cosa può andare in cloud? Tutto? Solo una parte?

La scelta di cosa debba essere portato in cloud parte necessariamente – come indicato da Luca – dall’individuazione degli scopi della transizione e delle tipologie di workload interessate, avendo sempre chiaro il valore che ci si prefigge di ottenere.

Tipicamente gli scenari appena discussi vedono una migrazione di alcuni workload – i quali ad esempio possono beneficiare di una maggiore scalabilità – in un contesto di integrazione con altri tradizionali.

Questa dicotomia è spesso più sfumata di quanto non sembri a prima vista; in contesti di alta maturità lo scenario applicativo è molto variegato e si distribuisce tra applicazioni in cloud pubblico, applicazioni gestite tramite cloud privato, SAAS, etc…

Finora abbiamo evidenziato solo alcune delle valutazioni necessarie per la migrazione al cloud. Ci sono però numerosi altri aspetti da prendere in considerazione, e ne esamineremo presto alcuni. Alla prossima!