Cerca
Blog

Transizione al Cloud: a che punto siamo?

Parte 1

Didascalia

La Pubblica Amministrazione è chiamata ormai da vari anni a progettare la propria transizione al cloud, in base alle disposizioni normative del Regolamento attuativo previsto dall'articolo 33-septies del Decreto-Legge n.179/2021. In particolare, tale Regolamento ha fissato al 28 febbraio 2023 il termine per la trasmissione dei piani di migrazione da parte delle Amministrazioni e il completamento delle attività di migrazione entro il 30 giugno 2026 (che per pura casualità coincide con la data di conclusione del PNRR).

Il primo passo previsto dalla strategia cloud era la classificazione dei dati e dei servizi gestiti dalle PA, secondo il modello predisposto da ACN (Agenzia per la Cybersicurezza Nazionale) che prevedeva il seguente schema.


 

Una volta classificati i dati e i servizi, era necessario predisporre il Piano di migrazione, secondo lo schema predisposto dal Dipartimento della Trasformazione Digitale (DTD), indicando quale tra le seguenti tipologie:

  1. "Modalità A - trasferimento in sicurezza dell’infrastruttura IT": migrazione verso il cloud effettuata secondo la strategia di migrazione Lift&Shift (anche detta Rehost), ovvero la migrazione dell’intero servizio dell’amministrazione, comprensivo di applicazioni e dati su un hosting cloud senza apportare modifiche agli applicativi, ovvero replicando il servizio esistente in un ambiente cloud;
  2. "Modalità B - aggiornamento in sicurezza di applicazioni in cloud”: migrazione verso il cloud effettuata secondo le seguenti strategie: 
    • repurchase/replace: si intende la migrazione del servizio dell’amministrazione verso una soluzione nativa in cloud, in genere erogata in modalità Software as a Service; 
    • replatform: si intende la riorganizzazione dell’architettura applicativa sostituendo intere componenti del servizio in favore di soluzioni Cloud native in modo da usufruire dei benefici dell’infrastruttura Cloud; 
    • re-architect: ha come obiettivo quello di ripensare significativamente l’architettura core di un applicativo in ottica cloud, attraverso un processo di redesign iterativo ed incrementale che miri ad adottare appieno i servizi cloud-native offerti dai cloud service provider per massimizzare i benefici che ne derivano.

Facciamo un attimo il punto sulle strategie sopra menzionate.

1. Rehosting ("Lift and Shift")

Descrizione:

Il rehosting consiste nello spostare un'applicazione così com'è, senza apportare modifiche significative, da un'infrastruttura on-premise al cloud.

Quando utilizzarlo:

  • Per applicazioni legacy che non richiedono adattamenti immediati.
  • Per migrazioni rapide senza interrompere il funzionamento.

Vantaggi:

  • Tempi di migrazione rapidi.
  • Costi iniziali contenuti.
  • Riduzione immediata della necessità di infrastruttura fisica.

Svantaggi:

  • Non ottimizza i costi operativi (potrebbe non sfruttare appieno i vantaggi del cloud).
  • Non è progettato per sfruttare la scalabilità e le caratteristiche native del cloud.

Esempi di utilizzo:

  1. Migrazione di un database aziendale:
    • Un'azienda utilizza un database Oracle on-premise. Per ridurre i costi operativi, migra il database su una macchina virtuale senza modificarne la struttura.
  2. Hosting di un sito web tradizionale:
    • Un sito web basato su un'applicazione LAMP (Linux, Apache, MySQL, PHP) viene spostato su una VM in Google Cloud Compute Engine, replicando l'ambiente originale.
  3. Ambiente ERP legacy:
    • Un sistema ERP su Windows Server viene spostato in Microsoft Azure tramite Azure Migrate, continuando a funzionare senza cambiamenti.

 

2. Repurchasing ("Sostituzione")

Descrizione:

Invece di migrare un'applicazione esistente, si sostituisce con una soluzione SaaS (Software as a Service) che offre funzionalità simili o migliori.

Quando utilizzarlo:

  • Per applicazioni standard (es. CRM, ERP, email) che possono essere facilmente sostituite con soluzioni cloud.
  • Quando i costi di migrazione superano i benefici.

Vantaggi:

  • Soluzioni pronte all'uso, con aggiornamenti automatici.
  • Riduce drasticamente la complessità gestionale.

Svantaggi:

  • Dipendenza dal fornitore SaaS.
  • Personalizzazioni limitate.

Esempi di utilizzo:

  • Sostituire un CRM custom on-premise con altri in modalità SaaS.
  • Passare da un software di gestione documentale interno a Microsoft 365 o Google Workspace.

 

3. Replatforming ("Refactoring")

Descrizione:

Questo approccio implica modifiche parziali all'applicazione per sfruttare alcune funzionalità native del cloud, come database gestiti, container o funzioni serverless.

Quando utilizzarlo:

  • Per migliorare le prestazioni o ridurre i costi operativi rispetto a un semplice rehosting.
  • Quando l'applicazione richiede un adattamento minimo per essere più efficiente nel cloud.

Vantaggi:

  • Permette di sfruttare parzialmente i vantaggi del cloud (ad esempio, scalabilità automatica).
  • Costi di migrazione inferiori rispetto al completo reengineering.

Svantaggi:

  • Richiede un investimento di tempo e risorse maggiore rispetto al rehosting.
  • Non sempre compatibile con applicazioni legacy rigide.

Esempi di utilizzo:

  • Spostare un'applicazione web on-premise a un container Docker.
  • Utilizzo di un database gestito come Amazon RDS o Azure SQL.

 

4. Revisione Architetturale ("Rearchitecting")

Descrizione:

Si tratta di ridisegnare completamente l'architettura di un'applicazione per sfruttare al massimo le capacità offerte dal cloud, come il serverless computing, i microservizi e lo storage distribuito.

Quando utilizzarlo:

  • Per applicazioni strategiche che richiedono elevata scalabilità, flessibilità o resilienza.
  • Quando l'applicazione non è compatibile con l'infrastruttura cloud.

Vantaggi:

  • Ottimizzazione completa delle prestazioni, dei costi e della scalabilità.
  • Migliora la resilienza e la capacità di risposta ai picchi di carico.

Svantaggi:

  • Processo complesso e costoso.
  • Richiede tempo e competenze avanzate.

Esempi di utilizzo:

  • Sviluppo di un'applicazione basata su microservizi che utilizza Amazon Lambda o Azure Functions per la logica serverless.
  • Ridisegno di un'applicazione monolitica in servizi separati.

 

Conclusione di questa prima parte

La domande che ci dobbiamo porre sono le seguenti:

  • Abbiamo chiaramente definito una strategia di migrazione al cloud? Ovvero abbiamo chiari quali obiettivi vogliamo raggiungere?
  • Il Piano di migrazione consegnato nel 2023 è ancora valido?
  • Sono stati valutati attentamente costi/benefici o il caso di verificarli?

Consip mette a disposizione vari contratti per la fornitura sia di consulenza specialistica per lo studio di fattibilità che per le attività di analisi, ma... anche queste attività costano e non poco.