Applicazioni tradizionali VS applicazioni Cloud Native
Abbiamo già sottolineato l’importanza di avere applicazioni flessibili e performanti, un obiettivo oggi difficilmente raggiungibile con applicazioni tradizionali concepite secondo un approccio monolitico. Esse non permettono un’evoluzione rapida, non riescono a tenere il passo con le nuove tecnologie e, di conseguenza, l’impresa che le usa probabilmente faticherà a rimanere competitiva.
PER APPROFONDIRE:
- Applicazioni Cloud Native vs applicazioni tradizionali: confronto completo
- Microservizi e applicazioni Cloud Native VS applicazioni monolitiche
Nel caso si utilizzino una o più applicazioni legacy con architettura monolitica, è quindi consigliabile avviare la migrazione verso un’architettura Cloud Native. Questo processo si basa sulla scomposizione di monoliti e applicazioni altamente accoppiate in componenti più semplici.
Perché affrontare questo percorso? Adottare i principi Cloud Native, in ambito di sviluppo ex-novo oppure di modernizzazione, permette di ottenere risultati significativi:
- in ottica strategica, il Cloud Native concretizza vantaggi come la velocità di delivery e l’ottimizzazione della user experience che permettono al business di lavorare meglio e aumentare i profitti;
- in ottica operativa, consente di supportare i developers nella collaborazione con le Operations e nell’organizzazione del lavoro in modalità agile.
Per sviluppare e progettare applicazioni moderne e/o per modernizzare quelle esistenti, la prassi migliore è seguire la metodologia che prende il nome di 12Factor e che include una serie di principi e buone pratiche per rendere l’applicazione Cloud Native (di questo parleremo più avanti).
LEGGI ANCHE:
- Cloud vs Cloud Native: cosa sono? Una guida introduttiva
- Cos’è la CNCF (Cloud Native Computing Foundation)?
Scopri di più nella Guida alle Applicazioni Cloud Native
Un focus sulla modernizzazione del parco applicativo
I 4 pilastri delle applicazioni Cloud Native: Microservizi, Container/Orchestrators, APIs, DevOps
Le architetture applicative, le tecnologie e i framework metodologici alla base dello sviluppo Cloud Native permettono congiuntamente di supportare le esigenze delle imprese che chiedono all’IT flessibilità, velocità di risposta, performance ed efficienza.
Sintetizzando, i pilastri alla base delle soluzioni Cloud Native sono quattro:
- ARCHITETTURA: Microservizi
- INFRASTRUTTURA: Containers / Orchestrators
- COMUNICAZIONE: APIs / Service Mesh
- PROCESSI: DevOps, CI/CD
Di seguito li vediamo brevemente, se invece vuoi approfondire puoi leggere questo articolo: perché il Cloud Native é la risposta ad un mercato moderno e mutevole
ARCHITETTURA: Microservizi
L’architettura a microservizi suggerisce un nuovo modello per la costruzione delle applicazioni, basato su singole unità funzionali indipendenti. Ogni funzione può quindi essere compilata, implementata o modificata senza compromettere il funzionamento dell’intera applicazione. Su ogni microservizio lavora un piccolo team espressamente dedicato e specializzato.
I vantaggi? Sicuramente da citare la riduzione della complessità architetturale e la possibilità di scalare e distribuire su ambienti diversi la singola funzionalità. Aumenta anche la resilienza complessiva dell’applicazione, poiché un disservizio su un microservizio non andrà a intaccare il funzionamento degli altri servizi.
Un altro beneficio deriva dalla riduzione dei tempi di sviluppo e del time-to-market, poiché si può agire su singoli componenti senza fermare o rallentare l’operatività legata agli altri microservizi. Da considerare anche il miglioramento della capacità di risposta dei developers e della qualità del software (grazie alle skills e al know-how focalizzati).
PER APPROFONDIRE: Microservizi (Microservices): cosa sono e perché usarli?
INFRASTRUTTURA: Containers / Orchestrators
I container sono istanze virtuali di un ambiente di runtime completo che ospitano l’intera applicazione (costruita in modalità Cloud Native o secondo un’architettura monolitica) o i microservizi (singolarmente o in cluster), permettendone l’esecuzione indipendentemente dall’infrastruttura sottostante.
La containerizzazione, che può essere realizzata con strumenti specifici come ad esempio Docker, si rivela quindi una tecnica estremamente efficace in ambienti ibridi e Multi Cloud: il disaccoppiamento tra le componenti hardware e software garantisce infatti la piena portabilità delle applicazioni su sistemi differenti, senza distinzione tra datacenter on-premise e infrastrutture in Cloud.
Containerizzare le applicazioni significa eliminare le inefficienze di funzionalità e performance che potrebbero insorgere nello spostamento tra ambienti eterogenei. Il rovescio della medaglia è la crescita di complessità nella gestione dei container, soprattutto quando il numero di applicazioni da implementare, distribuire e manutenere è particolarmente elevato. Il ricorso a piattaforme per l’orchestrazione dei container, come Kubernetes, si rivela la soluzione ideale.
LEGGI ANCHE:
- Case study di successo, tre aziende che usano i container e Kubernetes
- Cos'è l'orchestrazione dei container e come farla con Kubernetes
COMUNICAZIONE: APIs / gRPC, Service mesh
Quando si progetta e costruisce un’applicazione Cloud Native, la comunicazione diventa una decisione progettuale significativa.
Sono molte le domande a cui dare risposta: in che modo un'applicazione client front-end comunica con un microservizio back-end? In che modo i microservizi comunicano tra loro? Quali sono i principi, i modelli e le best practice da considerare quando si implementa la comunicazione in applicazioni Cloud Native?
Le strategie da attuare sono molteplici e vanno valutate attentamente in fase di progettazione. Possiamo affidarci a pattern consolidati come: API Gateway / Management, gRPC, Service mesh.
L’utilizzo di un'architettura modulare a microservizi consente di basare tutta la comunicazione fra i vari componenti dell’applicazione su protocolli leggeri e agnostici dal punto di vista tecnologico. Questo costituisce un ulteriore passo verso la riduzione della complessità del deployment, permette di governare la complessità architetturale e incrementa il livello di indipendenza degli sviluppatori che possono concentrare i loro sforzi sulla business value piuttosto che su aspetti infrastrutturali.
PROCESSI: DevOps, CI/CD, Gitops
DevOps è un framework metodologico che facilita la collaborazione tra Developers e Operations, abilitando processi efficienti ed efficaci per la gestione del ciclo di vita del software. DevOps riprende gli stessi principi delle metodologie per lo sviluppo Agile (ad esempio, Scrum), enfatizzando la creazione di sinergie tra i team.
Lo scopo delle pratiche DevOps è semplice: eliminare la tradizionale carenza di comunicazione tra chi sviluppa l’applicazione e chi la gestisce una volta rilasciata, favorendo una condivisione delle responsabilità.
Come? Ad esempio grazie alle pratiche di CI/CD e GitOps, metodi per la distribuzione frequente dell’app agli utenti in cui l’automazione riveste un ruolo centrale.
- CI - Continuous Integration: i cambiamenti al codice apportati dai diversi team vengono convogliati costantemente verso un repository centrale, permettendo l’allineamento delle attività condotte in parallelo all’interno di un unico progetto
- CD - Continuous Delivery: i rilasci sono effettuati con un altissimo livello di frequenza.
- GitOps è un modo di implementare la Continuous Deployment / Continuous Delivery per le applicazioni Cloud Native. Si concentra su un'esperienza incentrata sullo sviluppatore anche per quel che riguarda le attività inerenti l’infrastruttura, utilizzando strumenti con cui gli sviluppatori hanno già familiarità, quali Git e i tool di di Continuous Deployment. Per approfondire dai un’occhiata al nostro talk e alle slide.
Ma quali sono in concreto i benefici del framework? Tra i tanti ricordiamo la possibilità di snellire e rendere più agili i processi, con un conseguente incremento della velocità di rilascio; la maggiore qualità dell’applicazione, dovuta all’automazione che riduce gli errori umani e al feedback continuo tra i due team; la maggiore affidabilità e la scalabilità dell’applicazione.
Passare al Cloud Native: come modernizzare un’applicazione legacy
Enunciati i principi base dello sviluppo Cloud Native, bisogna tuttavia tenere in conto che le aziende hanno costruito negli anni un patrimonio di applicazioni legacy che oggi devono poter funzionare anche nei moderni ambienti Cloud. Riscrivere completamente l’intero parco applicativo in chiave Cloud Native sarebbe un’impresa titanica e sconsiderata. Esistono infatti diverse vie per modernizzare un’applicazione portandola sul Cloud e bisogna ponderare il corretto approccio valutando caso per caso.
Ecco un breve excursus delle opzioni percorribili:
- il rehosting (anche denominato Lift&Shift) consiste nella semplice migrazione dell’applicazione in Cloud, senza apportare modifiche. Da utilizzare qualora la perdita di funzionalità e performance fosse nulla o minima;
- il refactoring prevede piccole modifiche al codice sorgente per eliminare le inefficienze o i malfunzionamenti dell’applicazione, garantendo prestazioni ottimali o comunque adeguate anche sul Cloud;
- il rearchitecting introduce alcune proprietà e tecniche tipiche della progettazione Cloud Native, dai container alle API, intervenendo profondamente sulla struttura dell’applicazione;
- il rebuilding è un’operazione più drastica, che implica la riscrittura da zero dell’applicazione, secondo le pratiche Cloud Native e con l’obiettivo di ricostruire tutte le funzionalità. Poiché è una procedura complessa e costosa, si consiglia solo per applicazioni business critical e in presenza di gravi anomalie di funzionamento;
- il replacing infine corrisponde alla sostituzione del software con una soluzione SaaS pronta all’uso, equivalente per funzionalità e utilizzo.
LEGGI ANCHE: Application modernization: cos'è e quali sono i vantaggi
La modernizzazione inizia dalla tecnologia
Scopri gli strumenti IT più innovativi per la Cloud Transformation
Sviluppo di un’applicazione Cloud Native
Al fine di sviluppare correttamente un’applicazione Cloud Native si consiglia di procedere secondo la metodologia Twelve-Factor, che definisce dodici principi generali per costruire software di nuova generazione oppure modernizzare i software legacy, garantendo performance, portabilità e scalabilità in ambienti Cloud. Il modello Twelve-Factor punta ad ottimizzare le tempistiche di sviluppo e velocizzare la messa in produzione del software, aggiungendo qualità, flessibilità e portabilità del codice.
Vediamo tre buone pratiche da seguire: replicabilità delle dipendenze, separazione tra codice e configurazioni, approccio stateless.
Replicabilità delle dipendenze
La corretta esecuzione di un’applicazione dipende strettamente da una serie di componenti tecnologiche associate, ad esempio le librerie fornite dai vendor oppure le funzionalità del sistema operativo sottostante. La containerizzazione permette di pacchettizzare tutte le dipendenze dell’applicazione all’interno di un sistema di runtime completo, che può essere facilmente trasportato in ambienti differenti, on premise oppure in Cloud, di progettazione, testing o produzione.
Separazione tra codice e configurazioni
Ogni ambiente può richiedere configurazioni diverse, ad esempio possono variare le credenziali di accesso a un servizio oppure le connessioni al database. Se le applicazioni tradizionali contengono internamente al codice e ripropongono come costanti le configurazioni, i principi Twelve-Factor suggeriscono il disaccoppiamento attraverso tecniche specifiche. Ad esempio, utilizzando le variabili di ambiente, le configurazioni vengono messe a disposizione dell’applicazione ma sono richiamate dal sistema di runtime al momento dell’esecuzione, senza risiedere direttamente nella codebase.
Approccio stateless
Un’altra caratteristica fondamentale delle applicazioni moderne è il comportamento stateless dei processi, ovvero non assume che il suo comportamento possa dipendere da esecuzioni precedenti né che le componenti, come memoria e file-system, siano condivise e persistenti tra esecuzioni consecutive.
Ogni workload tradizionale può essere modernizzato e portato in Cloud senza affrontare un refactoring completo. Con le giuste modifiche è possibile rendere un’applicazione più semplice da scalare orizzontalmente, più resiliente agli errori e più performante, potendo sfruttare nativamente ogni servizio messo a disposizione dal Cloud vendor.
PER APPROFONDIRE: Come sviluppare un’applicazione Cloud Native
I benefici per l’azienda nello scegliere un’applicazione Cloud Native
Le imprese che scelgono di ricorrere alle applicazioni Cloud Native ottengono significativi risultati in termini di business e competitività. Innanzitutto, possono disporre di applicazioni ottimizzate per ambienti ibridi e Multi Cloud, garantendo agli utenti servizi più efficaci e una migliore user experience.
Grazie alle pratiche DevOps si accelerano il time-to-market e i ritorni sulle attività di sviluppo. I rilasci frequenti permettono agli utilizzatori di beneficiare immediatamente dei miglioramenti apportati all’applicazione, senza dovere attendere mesi per la release definitiva. Molto spesso infatti per progettare un applicativo o finalizzare una modifica richiesta possono occorrere mesi, con il rischio che nel frattempo le esigenze del business siano cambiate.
La progettazione Cloud Native è infine a prova di futuro: la scalabilità e la portabilità delle applicazioni moderne permette un utilizzo ottimale nel tempo, indipendentemente dall’evoluzione dell’infrastruttura sottostante.
I vantaggi dell’approccio Cloud Native per il team di sviluppo
Convenienti per l’intera organizzazione, le applicazioni Cloud Native aggiungono vantaggi specifici anche per i team di sviluppo.
Ad esempio, il ricorso alle API permette di riutilizzare funzionalità già sviluppate senza dover riscrivere il codice da zero, guadagnando ore di lavoro. I container assicurano la migrazione delle applicazioni in ambienti diversi senza la necessità di apportare modifiche, grazie al disaccoppiamento con l’hardware sottostante: si riduce così l’effort degli sviluppatori. Gli strumenti di automazione (per l’orchestrazione dei container o la gestione dei processi CI/CD) riducono al minimo le attività ripetitive e time-consuming degli sviluppatori, che possono quindi focalizzarsi sulle attività indispensabili.
La collaborazione tra team multidisciplinari molto specializzati, così come l’adozione delle pratiche DevOps, porta infine a un incremento della qualità del software. Ciò contribuisce a elevare la percezione che l’azienda ha nei confronti della funzione IT, vista sempre più come abilitatore di business e non solo come centro di costo.
LEGGI ANCHE:
Infrastructure as code: cos’è e vantaggi
Cos'è GitOps e quando adottarne le pratiche?
FinOps: cos'è? Perchè passare alla gestione finanziaria del Cloud
Applicazioni Cloud Native: da dove partire?
Realizzare un’applicazione Cloud Native o modernizzare il parco applicativo grazie all’approccio Cloud Native non è banale: queste operazioni richiedono infatti un’approfondita conoscenza dei processi e delle tecnologie necessarie. Il rischio, in caso contrario, è di incorrere in perdite di efficienza e di denaro.
LEGGI ANCHE: I requisiti del partner tecnologico per la transizione verso il Cloud Native
L’esperienza fatta con i nostri clienti ci ha portati a comprendere che il percorso verso il Cloud Native è scandito da 4 tappe ben precise:
- Fase propedeutica di raccolta dati e definizione iniziale della strategia Cloud Native.
- Fase di definizione della strategia, inclusi tempistiche, metodologie, tools e KPI da monitorare.
- Fase di implementazione della strategia Cloud Native sia a livello metodologico sia a livello tecnologico.
- Fase di delivery e messa in opera delle soluzioni e check-up periodico di validazione della strategia attuata e dei KPI definiti.
l primo punto è concretizzato nel nostro Assessment Cloud Native: richiedi ora l’analisi che ti permetterà di elaborare una strategia Cloud Native efficace.
