Skip to content
Insight

Sviluppare un’architettura per il Cloud: perché (e come) scegliere un partner per farlo

Sviluppare un’architettura per il Cloud: perché (e come) scegliere un partner per farlo

Abbiamo già effettuato una rapida analisi dei benefici che la migrazione in cloud può offrire alle applicazioni software e visto come essi siano concretizzabili in modo variabile in base alle specifiche di ciascuna applicazione e alle modalità con cui si decide di attuare la migrazione. Ci concentriamo ora su un fattore non visibile all’utilizzatore ma fondamentale nel definire per lo meno tre caratteristiche base di un software, ovvero la sua qualità attuale, la capacità di essere evoluto e manutenuto in modo efficace ed efficiente e la possibilità di trasformare in reali vantaggi i benefici promessi dal cloud (per maggiori dettagli è possibile vedere il White Paper “Creare prodotti digitali enterprise”) . Stiamo parlando dell’architettura dell’applicativo in Cloud.

Migrare un applicativo in cloud: perché ripensarne l’architettura?

È idea comune quella secondo cui la via meno onerosa per “migrare un applicativo in Cloud” sia quella di spostare “semplicemente” un applicativo esistente ed operativo su di un server on premise ad una macchina virtuale in Cloud. Ma siamo certi che sia davvero la più facile? E soprattutto, siamo certi che sia la più consigliabile? In questo modo, infatti, si rischia di non sfruttare molti dei potenziali  vantaggi di questa migrazione. 

Attuare un “Lift & Shift” (nome tecnico che indica il puro trasferimento di un software esistente, senza alcuna modifica, in cloud) permette infatti di sfruttare “l’infrastruttura Cloud” limitatamente, sostituendo l’impiego di hardware fisico con dell’hardware virtuale (che dovrà comunque essere gestito). Si può ottenere così un guadagno in termini di resilienza e scalabilità verticale, ma ci si espone a limitazioni importanti e pratiche non sicure. Per esempio, da un lato si sacrifica il vantaggio della scalabilità orizzontale, uno dei principali vantaggi del cloud. Dall’altro, un applicativo che probabilmente basava la sicurezza sull’accesso attraverso VPN, e mantiene questa pratica in cloud, è una pericolosa stortura.  

Infine, con il Lift&Shift si rinuncia di fatto a sfruttare la possibilità di ricorrere a un Managed Service Provider (MSP), un fornitore di servizi gestiti che scarica l’azienda dalla gestione e manutenzione dell’infrastruttura cloud, convertendo l’attività in un costo noto e gestito. Quanto influisce questo sul ROI della migrazione? Be’, potenzialmente molto. Grazie a questi servizi, infatti, è possibile ridurre i rischi operativi e garantire maggiore elasticità sull’uso delle risorse. Il tutto si traduce in una maggiore continuità e performance operative del servizio e in una gestione mirata e puntuale dei costi, che, di conseguenza, si riducono sensibilmente.

 

Integrare nell’architettura cloud i servizi gestiti 

Architettura dell’applicazione: cosa comprende?

Ripensare l’architettura del tuo applicativo è il primo passo necessario per sfruttare questi vantaggi.  Ma questo ripensamento non deve limitarsi al solo codice del servizio.  Deve invece includere anche tutti gli elementi ad esso collaterali. I componenti di cui un applicativo software ha bisogno per funzionare, possono infatti  essere tanti e di diversa natura. 

Quali sono questi elementi? Ad esempio:

  • i database , relazionali o non relazionali, a cui esso si appoggia
  • le procedure di backup e storage a lungo termine
  • il sistema di  caching delle risorse statiche
  • l’integrazione con servizi funzionali all’attività di business, come applicativi destinati a gestire l’invio email, i pagamenti, le registrazioni,…


Servizi gestiti: cosa sono e perchè integrarli

Già stilare un elenco di questi servizi può rendere più immediata la comprensione del vantaggio di ricorrere a soluzioni gestite: basta immaginare le risorse necessarie a controllare direttamente la configurazione, la sicurezza, l’affidabilità e la manutenzione di ognuno di questi componenti e processi e confrontarle con le proposte di servizi gestiti offerti dagli MSP. 

Riprendendo l’elenco precedente, possiamo pensare ad integrare nel prodotto digitale servizi gestiti come:

  •  database con gestione automatica del failover su una replica del database in caso di problemi con l’istanza principale
  • procedure di backup automatiche ed integrate con storage long term e ad alta affidabilità, completamente gestite dal MSP 
  • content delivery network (CDN) estremamente potenti ed efficienti per aiutare a eseguire il caching dei contenuti in modo più efficiente e contemporaneamente abbattere il rischio di DDoS
  • servizi di invio mail gestiti, con metriche di bouncing e delivery 


Opportunità da analizzare a lungo termine

Ricorrere a servizi gestiti offre l’opportunità di distribuire la complessità di software aziendali su servizi che possono essere facilmente integrati e non richiedono grandi sforzi da parte del team di sviluppo interno. Si tratta però di un processo che deve essere operato da figure esperte, con preparazione specifica sugli ambienti cloud. Scelte sbagliate possono trasferire sul software aziendale un potenziale di rischio futuro dipendente da fattori esterni al codice dell’applicativo stesso. La varietà di servizi disponibili deve dunque essere attentamente scrutinata e integrata in modo coerente ed efficace.

 

Ti piace leggere?

A noi piace scrivere, dai un’occhiata alle nostre guide e approfondimenti

Library di Innovazione Digitale
       .--.                   .---.
   .---|__|           .-.     |~~~|
.--|===|--|_          |_|     |~~~|--.
|  |===|  |'\     .---!~|  .--|   |--|
|%%|   |  |.'\    |===| |--|%%|   |  |
|%%|   |  |\.'\   |   | |__|  |   |  |
|  |   |  | \  \  |===| |==|  |   |  |
|  |   |__|  \.'\ |   |_|__|  |~~~|__|
|  |===|--|   \.'\|===|~|--|%%|~~~|--|
^--^---'--^    `-'`---^-^--^--^---'--'

Ripensare l’architettura in ottica Cloud Ready

Con il ricorso ai componenti gestiti si riesce a ridurre i rischi operativi e a potenziare il prodotto semplificando al contempo la gestione dei servizi accessori. Tuttavia, un altro aspetto su cui è doveroso concentrare l’attenzione in fase di revisione di un software destinato a venire migrato in cloud è quello del miglioramento della scalabilità orizzontale e resilienza.

 

Scalabilità  orizzontale e verticale di un servizio in cloud: due approcci  a confronto.

In Cloud come al di fuori di esso, la capacità di un’infrastruttura di calcolo può venire scalata in due dimensioni: verticale ed orizzontale.

La scalabilità verticale prevede che il potenziamento avvenga accrescendo la capacità di elaborazione della macchina su cui gira il servizio digitale, senza coinvolgere server ulteriori e senza la necessità di particolari capacità dell’applicativo. 

La scalabilità orizzontale si realizza invece affiancando al server iniziale nuovi nodi che funzionino come una singola unità logica. Si tratta di un’opzione che accresce in modo virtualmente illimitato le capacità di calcolo del sistema (contribuendo al contempo alla sua affidabilità), ma che richiede che venga progettata l’integrazione nell’architettura esistente.

In cloud, tutto ciò avviene su macchine virtuali e con una rapidità e flessibilità notevolmente superiori a quelle di un’infrastruttura on  premise, sia in ottica di accrescimento, sia di riduzione. In questo modo, il cloud contribuisce sensibilmente a rendere più cost efficient la gestione dei picchi di traffico. In questo contesto, affidarsi al supporto di un MSP permette di gestire la potenza usufruendo di risorse on demand e reserved in modo corretto, spendendo budget per l’architettura solo quando è necessario, e comprimendo le spese in modo controllato.

 

Dal monolite ai microservizi

L’organizzazione dell’architettura dell’applicativo è un elemento chiave per definire le sue capacità di sfruttare l’elasticità delle risorse computazionali offerte dal Cloud. Applicativi “di vecchia scuola”, basati sul concetto di architettura monolitica faticheranno molto infatti a trasformare i potenziali del Cloud in vantaggi reali, sia perchè difficilmente permetteranno di integrare servizi gestiti, sia perchè difficilmente supporteranno la scalabilità orizzontale.

Ecco perché molto spesso risulta più conveniente mettere mano al codice del servizio digitale per integrare, in misura più o meno rilevante, elementi tipici di un approccio Cloud Native, a partire da un’architettura a microservizi. 

Si crea così un prodotto basato su componenti applicativi più piccoli e disaccoppiati, opportunamente isolati e containerizzati, per la cui orchestrazione, monitoraggio e gestione del ciclo di vita è nuovamente possibile ricorrere a servizi gestiti.

 

Attenzione al fai da te: scegliere il partner ideale per definire un’architettura cloud di successo

La gestione di una migrazione in Cloud richiede inevitabilmente skill mirate, difficilmente presenti in reparti IT tradizionali. Ecco perché la cooperazione con un partner specializzato è spesso l’elemento discriminante nel successo (o fallimento) di una simile iniziativa.

 

Competenze necessarie per progettare un’architettura cloud

Il partner che supporterà la ridefinizione dell’architettura  del servizio in modo funzionale al cloud deve necessariamente:

  • conoscere molto bene i servizi offerti dal Cloud Vendor, per scegliere quelli più consoni da integrare nel prodotto digitale. Questo vuol dire in buona sostanza essere in grado di valutare rischi e opportunità di ogni tecnologia adottata, come la sua longevità, la stabilità odierna e la stabilità garantita nel futuro della tecnologia stessa; 
  • avere solide competenze su sviluppo ed architettura software, per sfruttare al meglio il Cloud occupandosi di definire sia la parte di adozione dei servizi gestiti in Cloud che su quella di revisione del software per renderlo davvero Cloud-ready (o addirittura, Cloud-native).
  • saper comprendere il business model e gli indicatori economici del cliente, per allineare le offerte dei Cloud Vendor con le necessità dell’azienda, e mettere la stessa in grado di avere report significativi e comprensibili su risorse, costi e investimenti.


Bottega52 come partner per ridisegnare i servizi digitali in ottica Cloud Ready

Bottega52 è un partner Cloud-Native dotato di tutte le competenze indispensabili per gestire il design (o re-design) dell’architettura dei servizi digitali destinati ad operare in cloud: una solida competenza tecnica, un costante aggiornamento su tool e tendenze di mercato e non solo. Oltre a essere un fornitore di servizi gestiti (MSP), Bottega52 offre Cloud Migration Workshop per affiancare i team IT del cliente nella definizione del processo di migrazione in cloud. I workshop producono un documento di fattibilità a disposizione del cliente per le future attività.

Bottega52 combina a tutto questo anche un’approfondita capacità di comprensione del business e di gestione delle dinamiche di product design, configurandosi a tutti gli effetti come un prezioso alleato anche nella gestione delle attività di definizione delle specifiche di prodotto.

Coerentemente con l’approccio in ottica Risk Management al tema delle operations (descritto nel White Paper Digital “Digital service a supporto del business”), Bottega52 assicura infine la tenuta in opera dei servizi operanti in Cloud, configurandosi così come un partner capace di affiancare le aziende lungo l’intero ciclo di vita del servizio digitale. 

 

Hai visto qui?

Abbiamo molti altri articoli da leggere, vai a vedere!

Insights52
,---------------------------------------.---------.    
|                                       |         |    
|    ,-----------------------------.    |    .    |    
|    |                             |    |    |    |    
|    |    ,-------------------.    |    |    |    |    
|    |    |                   |    |    |    |    |    
|    |    `----     ,----     |    |    |    |    |    
|    |              | @       |    |    |    |    |    
|    |    ,---------"---------:    |    `----'    |    
|    |    |                   |    |              |    
|    `----:    ,---------.    |    `---------.    |    
|         |    |         |    |              |    |    
|    .    |    |    .    |    |     ---------'    |    
|    |    |    |    |    |    |                   |    
:----'    |    |    |    |    |    ,--------------:    
|         |    |    |    |    |    |              |    
|    .    |    `----'    |    |    |     ----.    |    
|    |    |              |    |    |         |    |    
|    `----"---------     |    |    `---------'    |    
|                        |    |                   |    
`------------------------'    `-------------------'