Finalmente si parla di Cloud in modo pragmatico e questo permette di portare la conversazione su contenuti di sano pragmatismo. Questo è frutto di un aumento esponenziale delle competenze e conoscenze.
Basta guardare al dato delle certificazioni: nelle maggiori nazioni europee le offerte di lavoro permanenti che citano Cloud Skills come competenze necessarie sono aumentate del 49% in 18 mesi. I dati provengo dagli osservatori del lavoro Europei.
Aumentano, ovviamente, figure con esperienza diretta e tutto questo migliora la qualità delle soluzioni implementate sulle piattaforme IaaS. Questa consapevolezza permette di guardare allo IaaS come una piattaforma di distribuzione (deployment) delle applicazioni. Piattaforma dotata di strumenti a grana fine, un modello tecnologico che mette a disposizione componenti che possono essere usate in modo assolutamente arbitrario (dove sono finite le matrici di compatibilità?) da parte dell’architetto di sistema.
In buona sostanza, un architetto che utilizzi gli elementi cloud per disegnare la sua soluzione, oltre che del risultato finale, è responsabile, anche, della implementazione delle “-ilities”di sistema. Parliamo di prestazionalità, scalabilità, affidabilità, resilienza e cosi via (in inglese molti di questi attributi terminano in ility da qui le “ilities”). I cloud provider lasciano agli utilizzatori ampia scelta di funzionalità architetturali da selezionare per ottenere, ad esempio, i 9 necessari per il modello di affidabilità, oppure i meccanismi di sicurezza a corredo, quelli di bilanciamento di carico ecc.
Questo significa, che a differenza del passato, dove si assumevano queste funzionalità come primariamente implementate dai vendor dei sistemi IT o forniti dall’IT, oggi è necessario (da parte dell’architetto) riprendersi carico di un aspetto primario come la progettazione di sistema. I modelli di protezione del dato, di protezione della infrastruttura nel cloud non sono orientati al business ma agli elementi fondativi della infrastruttura stessa. In altri termini un cloud provider non protegge un workload applicativo, protegge una istanza e un volume. La progettazione di sistema, che deve essere eseguita a livelli, deve prevedere per ognuno di essi il soddisfacimento o meno dei requisiti da raggiungere.
Semplificando, è possibile scegliere il piano applicativo o infrastrutturale ove implementare quelle caratteristiche di base del sistema. Ad esempio, è possibile raggiungere la piena affidabilità usando il livello applicativo, o di computing o anche di storage o tutti insieme.
Per questo motivo è fondamentale vedere il Cloud (IaaS appunto) semplicemente come un altro target di installazione (deployment), sapendo che alcune funzionalità vanno esplicitamente configurate, o acquisite e non date per scontato. IaaS è un new hardware di cui è necessario conoscere le caratteristiche e come ottenere quelle ilities di sistema fondamentali al raggiungimento degli obiettivi di business.
In questo contesto la domanda diventa: per avere una strategia multi-cloud devo progettare lo stesso sistema differenti volte in funzione di quanti siano gli ambienti cloud (new hardware) da mettere in obiettivo? E nel caso in cui volessi portare una applicazione in modo nativo nel cloud (Lift and shift), devo adeguarmi ogni volta alla piattaforma target?
Giusto per completezza, cosa si intende per Lift and Shift e quando viene utilizzato come modello di migrazione in cloud?
Ogni enterprise ha, oggi, una strategia Cloud che prevede un assessment applicativo. Nella maggioranza dei casi questo assessment ha tre conclusioni (tipicamente):
- Application decommisioning
- Lift and Shift appunto
- (Ri)-scrivere le applicazioni usando gli strumenti nativi del cloud
Queste sono le opzioni per portare in cloud un workload applicativo.
Nel secondo caso, la scelta dei clienti cade in una strategia IaaS, seguita da una eventuale adozione del PaaS. Solo dopo una matura migrazione nel cloud, si prende in considerazione il modello SaaS che di fatto rimpiazza l’applicazione iniziale stessa.
Nel terzo caso la direzione è completamente diversa.
Nel caso di ridisegno applicativo, la strategia prevede un modello SaaS , solo nel caso nessun SaaS soddisfi i requisiti, si prende in considerazione il PaaS e solo nel caso in cui nulla sia disponibile si passa a considerare un modello IaaS.
Esiste molta letteratura nel caso in cui sia necessario intraprendere una riscrittura applicativa, a me interessa focalizzare l’attenzione invece sul caso Lift and Shift ossia in caso in cui si voglia portare una applicazione in cloud mantenendone intatte le caratteristiche applicative e infrastrutturali. La domanda da porsi diventa.
Esiste un modo di rendere il “Lift and Shift” indipendente da cloud provider scelto?
Abbiamo un modello di scelta quasi binario, a portata di mano:
- O si usano soluzioni di disintermediazione (a livello di virtualizzazione e/o di astrazione della componente storage)
- Oppure si utilizzano servizi “PaaS-like” per replicare le funzionalità primarie della applicazione stessa (da un DB al DB as a service, da un Identity Manager allo IAM services del provider e cosi via)
Una cosa è certa, l’affermazione: “spostandomi in un cloud provider, riesco a rendermi indipendente dai dettagli tecnologici” è solo confinata ad una analisi di alto livello, e lasciatemi dire, superficiale, del vero impatto di un deployment applicativo in ambiente cloud.
Errore grave, matita rossa quindi.
Un esempio nel mondo dello storage? Ogni volume che viene utilizzato in cloud desume la conoscenza della componente tecnologica necessaria e soprattutto con quali prestazioni si necessita. E se quel volume raggiunge la sua massima espansione? Ne devi prendere un altro? E quale è la misura di limite nel cloud A e nel cloud B e nel cloud C? Come queste misure hanno impatto sul modello della infrastruttura applicativa?
Ho parlato di Volumi, che sono unità tecnologiche che nulla (o poco) hanno a che vedere con il concetto di dato a livello applicativo. Proteggere un volume non significa, automaticamente, proteggere i dati della applicazione. La condizione non è ne necessaria e alcune volte nemmeno sufficiente purtroppo.
Il tema qui non è il giusto o sbagliato, il tema è uscire da affermazioni generali ed entrare in una fase di consapevolezza necessaria per una progettazione razionale che utilizzi tutti gli strumenti possibili (IT tradizionale e in cloud) in modo armonico. Per fare questo è comunque necessaria una nuova competenza tecnologica.
Il primo passo, è quindi, quello della consapevolezza, ossia riconoscere nello IaaS un (semplice) moderno piano di esecuzione delle nostre applicazioni, come un moderno hardware scalabile e efficiente. Facendo cosi diventa più semplice fattorizzarlo (includerlo) nelle strategie IT e estrarne il massimo valore (risolvere il compromesso usabilità vs quantità di uso).
Quindi, nell’ottica di fattorizzare il cloud nella strategia aziendale abbiamo tre opzioni:
- Progettazione applicativa (da zero) che utilizzi standard indipendenti dalla infrastruttura (potenziale lock-in a livello ambiente applicativo)..
- Progettazione di sistema in funzione del cloud provider prescelto (potenziale lock-in nella tecnologia del cloud provider, es. AWS vs Azure vs Google).
- Utilizzare livelli di intermediazione di accesso alla infrastruttura (potenziale lock in vendor o tecnologia individuata)
I livelli di intermediazione di accesso alla infrastruttura (Cloud) sono necessarie in tutte quelle situazioni in cui la metodologia di migrazione in cloud è improntata ad un modello Lift and Shift e ove è assolutamente necessario (nel caso dello storage) introdurre concetti di Efficienza nella gestione dei dati per tenere sotto controllo l’economicità del cloud stesso.
Il livello di intermediazione diventa imprescindibile quando la strategia cloud deve prevedere il modello Multi-Cloud per definizione finalizzato sia a migliorare l’economicità (supporto alla dual vendor strategy) che ad implementare meccanismi di protezione incrociati da cloud provider per non rimanere vincolato al funzionamento di solo uno di essi.
