Da realtà italiane come Il Giornale o Zambon ai colossi dell’entertainment come Netflix, oggi sempre più aziende scelgono di modernizzare le loro applicazioni legacy e realizzare applicazioni Cloud Native. Questo approccio permette di sfruttare appieno le potenzialità delle nuove tecnologie di sviluppo e delivery, così come le opportunità offerte dalle tecnologie Cloud.
Oggigiorno in molti casi le applicazioni enterprise tradizionali concepite secondo un approccio monolitico non garantiscono più flessibilità e performance sufficienti. Soprattutto fanno fatica ad evolversi e rimanere al passo con le tecnologie moderne, perdendo quindi di competitività sul mercato.
Il processo di migrazione ad un’architettura Cloud Native si basa spesso sulla scomposizione di monoliti e applicazioni altamente accoppiate in componenti più semplici. L’applicazione viene segmentata sia verticalmente (architetture multi-tier, containerizzazione, microservizi) che orizzontalmente, tramite l’uso di middleware e servizi iperscalabili forniti dal vendor. Così facendo si assicura il massimo della flessibilità e delle performance.
Vi proponiamo dunque un confronto tra le due diverse tecniche di sviluppo, Cloud Native e tradizionale. Evidenzieremo i benefici della modernizzazione applicativa analizzando alcuni aspetti chiave. Ecco, per cominciare, uno specchio riassuntivo delle principali differenze:
Le applicazioni Cloud Native vengono progettate per operare all’interno di infrastrutture immutabili, ovvero che non cambiano dopo il deploy.
I container incapsulano l’applicazione e tutte le sue dipendenze, permettendole di funzionare come un pacchetto a sé stante. I container vengono deployati su sistemi di orchestrazione come Kubernetes, in grado di fornire scalabilità automatica e strategie di self-healing.
Il contenuto del pacchetto, compresa la configurazione dei servizi, può essere modificato solo eseguendo un nuovo deploy, e di conseguenza assicurando tutta la filiera di QA e test automatici, garantendo che quanto va online rispetti sempre i comportamenti attesi.
Le applicazioni tradizionali vengono spesso progettate in modo disgiunto dall’infrastruttura su cui verranno distribuite.
Spesso il deploy di queste applicazioni necessita di molti interventi manuali (per configurazione e gestione delle dipendenze) che vengono eseguiti direttamente sull’ambiente di produzione e non rientrano in una filiera di QA automatizzata. I costi dei singoli deploy tendono a crescere, mentre l’affidabilità scende ed è più probabile portare in produzione errori o malfunzionamenti che impongono rapidi interventi e pezze manuali.
Il cane si morde la coda e diventa estremamente difficile e costoso scalare l’applicazione, così come creare ambienti di prova su cui testare modifiche ai servizi.
Un'architettura applicativa Cloud Native si basa sempre su una qualche soluzione che astrae l’ambiente necessario all’applicazione dall'infrastruttura sottostante.
Invece di configurare, aggiornare e mantenere i sistemi operativi, con tutte le complessità che questo comporta, soprattutto su ambienti di produzione, il team si concentra sul proprio software e ciò di cui ha bisogno per funzionare.
Esistono molte soluzioni e su molti livelli, sia on-premise che fornite dai vendor. Ad esempio Kubernetes, Amazon ECS o Google Cloud Run sono soluzioni differenti, ma condividono l’obiettivo di disgiungere applicazione e sistema operativo.
L'architettura delle applicazioni tradizionali spesso dipende fortemente dal sistema operativo sottostante, come dall'hardware, dall'archiviazione e dai servizi di supporto.
Queste dipendenze rendono la migrazione e la scalabilità dell'applicazione su una nuova infrastruttura complessa e rischiosa, senza considerare la difficoltà di allineare gli ambienti di sviluppo, di test e di operations così da garantire l’identico funzionamento su ognuno di essi.
“Sul mio computer funziona” è una tipica frase che sentiamo nelle conversazioni tra sviluppatori e operatori nelle aziende che adottano modelli tradizionali, ed è il sintomo di queste problematiche.
Un’applicazione Cloud Native automatizza il provisioning e la configurazione dell'infrastruttura, riallocando dinamicamente le risorse in base alle esigenze del momento. Realizzare applicazioni su runtime Cloud permette una immediata ottimizzazione di scalabilità, utilizzo delle risorse locali, orchestrazione dei processi sulle risorse globali disponibili e recupero in caso di errori per ridurre al minimo i tempi di inattività.
Le logiche di gestione delle risorse sono configurabili direttamente a livello applicativo, così che le valutazioni su questo fronte possano essere fatte già in fase di progettazione e realizzazione e non subite a valle da operatori che non hanno conoscenza delle logiche applicative.
Tradizionalmente la soluzione infrastrutturale è progettata e dimensionata su stime di carico, ipotesi sulla natura e le richieste dell’applicazione nel worst-case e sulle caratteristiche tecniche della facility selezionata.
Lunghe e spesso irrilevanti fasi di collaudo e stress test sull’infrastruttura approntata devono precedere la messa in produzione dell’applicazione, introducendo ritardi e possibili rilavorazioni. La soluzione è spesso sovradimensionata in base a contingenze che tengano in conto i massimi picchi di carico, implicando quindi costi fissi anche nei frequenti periodi di basso/medio carico e senza garanzia di poter scalare nel caso in cui le previsioni di carico massimo fossero sbagliate al ribasso.
Il Cloud Native supporta le pratiche DevOps, che combinano persone, processi e strumenti, promuovendo una stretta collaborazione tra le funzioni di sviluppo e operative, per accelerare e agevolare la messa in produzione del codice.
PER APPROFONDIRE: Cos'è DevOps e come introdurlo
Processi di deploy snelli implicano maggior velocità e meno costi, permettendo di effettuare più deploy, più frequentemente. Questa configurazione facilita rilasci frequenti di nuove funzionalità e strategie di roll-forward in caso di problematiche.
L’approccio tradizionale prevede un trasferimento over-the-wall del codice finale dell'applicazione dagli sviluppatori alle operations.
I sistemisti si trovano a operare applicazioni di cui sanno poco o nulla, su infrastrutture di cui gli sviluppatori sanno poco o nulla. Le priorità organizzative hanno la precedenza sul valore consegnato all’utente finale, con conseguenti conflitti interni, consegne lente e compromesse e basso morale del personale.
I team DevOps rendono disponibili i singoli aggiornamenti software per il rilascio non appena sono pronti e validati dal business.
Le organizzazioni che rilasciano software ricevono più rapidamente feedback e possono rispondere in modo più efficace ed efficiente alle esigenze dei mercato.
La continuous delivery si implementa grazie all’automazione di test e QA e alla riduzione di costi e tempi dei deploy che insieme permettono rilasci piccoli, frequenti e con elevate probabilità di successo.
Il software viene rilasciato periodicamente, in genere a distanza di settimane o mesi, sebbene spesso molte delle nuove funzioni fossero già pronte molto prima del rilascio e non avessero particolari dipendenze.
Le funzionalità che i clienti desiderano arrivano in ritardo e l'azienda perde opportunità di competere, acquisire clienti e aumentare i ricavi. La curva di adozione da parte degli utenti è più lenta poiché questi ricevono molte nuove funzionalità in una sola volta e faticano a fornire feedback o ad apprendere l’uso di intere nuove parti di applicativo.
Rilasci più grandi implicano tempi di collaudo più lunghi e meno probabilità di successo, con più complessità da gestire in caso di corner-case o imprevisti.
L'architettura a microservizi scompone le applicazioni in piccole componenti verticali, modulari, indipendenti e liberamente accoppiabili.
Lo sviluppo delle diverse componenti viene assegnato a team più piccoli e indipendenti tra loro, il che rende possibili aggiornamenti frequenti e non vincolati, una scalabilità più granulare e capacità di ripristino in caso di failover senza influire sugli altri servizi.
Con questa configurazione, i team devono definire chiare interfacce di comunicazione tra i servizi. Ciò richiede analisi architetturale e promuove una chiara comprensione dei workflow applicativi, rendendo trasparente e documentato il funzionamento delle singole componenti. A sua volta questo formalismo facilita il riuso di componenti ben documentati da parte di altri fornitori coinvolti o altre unità di business.
Le architetture monolitiche raggruppano molti servizi disparati in un unico pacchetto di distribuzione, rendendo di fatto i servizi interdipendenti e inficiando l’agilità nelle fasi di sviluppo e di distribuzione.
Ciò che avviene dentro al monolite è opaco e troppo spesso non documentato. L’ingresso di nuovi programmatori è difficoltoso: il codice di un’applicazione complessa è difficile da leggere e consegna il “come” l’applicazione funziona, ma non il “perché”.
Questa conoscenza rischia quindi di dover essere maturata di nuovo al prossimo progetto e molto budget viene investito nel ricostruire componenti già presenti, a partire dall’analisi di dominio e con il rischio di creare disallineamenti.
L'automazione dell'infrastruttura su larga scala elimina i tempi di inattività dovuti a errori umani.
Mentre le persone tendono a commettere errori quando in sovraccarico e costretti ad attività ripetitive, l'automazione non soffre di questi problemi, replicando fedelmente le medesime procedure a prescindere dalla dimensione dell’infrastruttura di distribuzione.
Sebbene già le operation tradizionali abbiano ormai abbracciato, nei casi più virtuosi, sistemi di automazione del provisioning (di VM o di macchine fisiche), il Cloud Native spinge questo concetto ancora oltre: un'architettura realmente Cloud Native indirizza l'automazione degli interi sistemi, non solo del provisioning.
Una gestione tradizionale dell’infrastruttura prevede che operatori umani creino e gestiscano manualmente server, reti e volumi di archiviazione.
Su larga scala, diagnosticare correttamente i problemi è un lavoro molto complesso e difficile per operatori umani. Scalare manualmente un servizio complesso può diventare un lavoro titanico per un’équipe di sistemisti a cui viene affidata la responsabilità di ogni livello di servizio, dalla buona salute dell’hardware alla corretta configurazione del livello applicativo.
La ripetitività connaturata a questi esercizi incrementa il rischio di errore e non è infrequente scoprire che l’origine di un malfunzionamento era un servizio non aggiornato in mezzo a un pool di altri servizi.
Un’architettura a container rende incredibilmente agevole il recupero in caso di failover. Anche in caso di un problema di larga scala, i singoli container, immutabili e autocontenuti, possono essere deployati automaticamente con le stesse procedure di delivery, in un altro data center.
I volumi (sempre esterni ai container) e i servizi di storage come database e CDN, sono facilmente ridondabili con strategie multi-zona e persino multi-vendor e i backup sono generalmente configurabili come servizio aggiuntivo sul principali public Cloud. La durabilità dei dati in Cloud è infine largamente più alta di qualsiasi singolo dispositivo fisico.
La maggior parte delle architetture tradizionali soffre di una mancanza di backup automatizzato, ripristino di emergenza o concetti relativi alla continuità aziendale.
Per garantire un disaster-recovery efficace lo staff dovrebbe promulgare policy e procedure ferree a tutti i livelli (dai team di sviluppo agli operatori), revisionare e testare frequentemente la qualità e la completezza degli archivi di backup, assicurarsi che gli automatismi di ripristino funzionino e garantire una dislocazione dei dati che tenga conto di un possibile problema locale di ampia scala (incendi, crolli, problematiche elettriche gravi, etc).
Purtroppo il costo di tali procedure rende quasi certo che, al verificarsi di un reale problema, le procedure siano obsolete o errate, i backup incompleti o vetusti, la documentazione mancante e il personale chiave impreparato.
Dalla comparazione emerge chiaramente che l’architettura Cloud Native contribuisce a:
Ecco perché le aziende dovrebbero intraprendere da subito il percorso di migrazione verso i nuovi paradigmi Cloud Native, al fine di trarre i maggiori benefici dalle nuove infrastrutture ibride, eterogenee e distribuite.