La strategia Lift & Shift per il Cloud. Quali sono i pro e i CONTRO?

By on
 

Le strategie di approccio al cloud per la migrazione del parco applicativo non sono sempre le stesse e dipendono da una serie di fattori che nulla hanno a che vedere con la bontà di un provider di servizi cloud.

Vediamo in dettaglio quali sono i fattori che dobbiamo considerare e quale potrebbe essere la ricaduta in termini di costo economico da sostenere. Esistono moltissime “filosofie di pensiero” per il cloud. Questo breve articolo mette in evidenza gli aspetti concreti che possono aiutarci a capire se l'approccio Lift & Shift è, a lungo termine,  veramente pagante in termini economici e, soprattutto, come scegliere un approccio piuttosto che un altro.

LIft & Shift

L'approccio Lift & Shift permette di spostare un'applicazione su una piattaforma cloud senza riprogettare l'applicazione. Questo approccio è noto anche come “re-hosting”. In sostanza l’azienda ad un certo punto decide di liberarsi dei costi del proprio “hardware on premise” con costi di manutenzione divenuti molto elevati e che non restituiscono più nulla in termini di R.O.I. Questa modalità garantisce immediatamente che flussi di lavoro, logica e dati aziendali siano “spostati” semplicemente da un hardware “proprietario” verso uno virtuale di un datacenter cloud (Hosting). Nella sostanza non è mutato nulla in termini di architettura applicativa. Le applicazioni esistenti se hanno architettura “monolitica” saranno “monolitiche” anche nella migrazione al cloud.

In una prima valutazione economica in effetti l’azienda recepisce una “riduzione” dei costi che dipende da:

  • Hardware non più proprietario,
  • Percorso immediato verso il cloud senza nessuna riprogettazione applicativa,
  • Processi di Disaster recovery garantiti dall’infrastruttura di hosting in cloud compresi nel contratto cloud,
  • Possibilità di aumentare le risorse hardware in modo esponenziale azzerando i costi di manutenzione sull’hardware legacy proprietario.

Se volessimo racchiudere questi concetti in una immagine la nostra applicazione verrebbe appunto “shiftata” da sinistra a destra. 

Rehosting-Lift&Shift

Questa modalità di utilizzo del cloud è assolutamente limitativo e nel lungo periodo imprevedibile; ad esempio, nel caso di aumentato fabbisogno di risorse e soprattutto di nuove funzionalità di business, si dovrà tener conto delle limitazioni imposte dall’infrastruttura di hosting per una moltitudine di vincoli non ultima la sicurezza e, pertanto, l’apparente “riduzione del costo” nel breve periodo si tramuterebbe in problemi e costi non più facilmente identificabili nel lungo periodo. Inoltre, i servizi cloud native in continua evoluzione non sarebbero utilizzabili a causa dell’obsolescenza dell’applicazione non ristrutturata per i nuovi servizi.

Quali sono le altre possibilità?

Quando si decide di accedere ad un progetto di “Porting in cloud” il primo dei seguenti approcci è quello che viene considerato il “meno costoso” ma in realtà le cose sono ben diverse e vediamo perchè:

  • IaaS (Infrastructure as a Service) - spesso interpretato con “Rehosting” o come lift & shift, in cui l’applicazione banalmente viene installata sull’Host senza alcuna modifica (quindi costi di spostamento bassi, ma costi elevatissimi per le operazioni di utilizzo in quanto non vengono sfruttate minimamente le funzionalità di efficienza dei servizi cloud native
  • PaaS (Platform as a service) – altrimenti identificato come “Refactoring”. In questa modalità la piattaforma tecnologica e l’infrastruttura sono quelle messe a disposizione dal provider. Quindi il “codice sorgente applicativo” proprietario può essere utilizzato in “container” utilizzando tutti i framework disponibili messi a disposizione dal cloud provider. Ovviamente questo approccio potrebbe avere dei rischi dovuti alla transizione nel nuovo ambiente e imprevedibili blocchi dovuti ai framework usati. Altresì non sarebbe possibile usare le funzionalità “custom” in quanto non disponibili nella piattaforma PaaS estremamente utili per la sicurezza e in un'ottica di standardizzazione.
  • SaaS (Software as a Service) – Come sappiamo questa modalità di utilizzo si riferisce alla metodica di sostituire tutto o in parte il parco applicativo con applicazioni standard pacchettizzate usate appunto come servizio. Il vantaggio immediato identificato è che se i requisiti utente cambiano rapidamente, questo approccio evita il tempo e l'investimento necessari per sviluppare le nuove funzionalità  che come sappiamo potrebbero lievitare a dismisura se non ben gestiti. Di contro la semantica dei dati potrebbe essere incoerente con quella aziendale proprietaria e si avrebbe una dipendenza dal vendor.

La vera rivoluzione, quindi, risiede nei servizi e infrastruttura del cloud nativo che nel lungo periodo riducono in modo drastico i costi di esercizio del parco applicativo e dell’infrastruttura “proprietaria” di cui si farà a meno. Ma le applicazioni per poter migrare a questo “nuovo mondo” hanno la necessità di un restyling completo. Per restyling si intende modernizzare sia l’architettura, che da “monolitica” dovrà trasformarsi in “microservizi”, che le funzionalità di business che dovranno essere “autoconsistenti” ossia dovranno utilizzare i servizi nativi del cloud e non più i servizi proprietari dell’infrastruttura monolitica. Da quanto detto è evidente che ogni applicazione dovrà essere riprogettata e sviluppata in modalità tale da poter operare in ambiente cloud.

Le applicazioni con questo approccio traggono pieno vantaggio dalle strutture di cloud computing e per questo vengono definite applicazioni cloud native (o, in inglese, Native Cloud Applications, NCA).

La modernizzazione delle applicazioni potrebbe spaventare ma esistono strumenti come CAST Highlight e CAST Imaging che aiutano in modo semplice la transizione delle applicazioni da monolitiche in NCA contenendo al minimo i costi di trasformazione. Possiamo identificare 4 pilastri fondamentali a cui una applicazione NCA deve rispondere:

CloudNativeServicesCAST

  • Microservizi (indipendenti e che colloquiano tramite Interfacce API standardizzate)
  • Container
  • Processi di Devops (Sviluppo e messa in produzione)
  • Processi di Continuous Delivery

 

 

In conclusione, quindi, tra i vari approcci al cloud, nella realtà solo l’approccio nativo (o perlomeno ibrido verso la transizione completa) consente ad un'azienda di beneficiare appieno dei benifici del cloud con risparmi in temini di tempo e costi.

In un prossimo articolo vedremo la roadmap che si dovrebbe seguire per convertire una applicazione monolitica in NCA minimizzandone il costo di trasformazione.