Uno dei mantra della trasformazione digitale è la modernizzazione delle applicazioni. Scopriamo cosa significa farlo in ottica serverless


Uno dei mantra più diffusi della trasformazione digitale è costituito dalla modernizzazione delle applicazioni. Ma cosa vuol dire? Quando ha davvero senso farla? Come facilmente intuibile, non esiste un’unica risposta, altrimenti non saremmo probabilmente nemmeno qui a porci queste domande. O probabilmente sarebbe più corretto affermare che non esiste una soluzione immediata e risolutiva nei confronti di tutti questi interrogativi, il che rende fondamentale valutare caso per caso ogni singola esigenza, in ogni specifico contesto.

La prima considerazione da fare è quella che ci consente di capire perché il notevole sforzo che comporta trasformare e migrare un’applicazione abbia realmente un senso. L’obiettivo di modernizzare è infatti orientato alla creazione di un nuovo valore di business a partire da un’applicazione legacy tradizionale, a cominciare dal rendere più snello l’intero ciclo di vita che la caratterizza.

Se consideriamo l’applicazione come un programma che consente di eseguire una funzione specifica da parte di un utente o di un’altra applicazione, siamo preferibilmente dalle parti del cosiddetto Function-as-a-Service (FaaS). Si tratta di un modello basato sul cloud, del tutto trasparente, almeno sulla carta, rispetto all’infrastruttura IT necessaria per eseguire una funzione software. In altri termini, corrisponde alla condizione in cui lo sviluppatore deve preoccuparsi esclusivamente di scrivere il codice necessario per eseguire una determinata funzione quando si verifica un determinato evento.

Il FaaS consente l’impiego di un’architettura serverless, che consente un ulteriore livello di astrazione rispetto alla virtualizzazione del PaaS (Platform-as-a-Service), che avviene a livello del sistema operativo, ad esempio per creare e gestire i container, ambienti di runtime più leggeri e semplici da configurare rispetto alla classica macchina virtuale.

Rispetto al cointainer tradizionale, il container stateless delle architetture serverless è quindi ancora più semplice da gestire per lo sviluppatore finale, anche se strutturarlo lato server costituisce un’operazione tutt’altro che elementare, e nemmeno spendibile in tutti i contesti di sviluppo, per via della sua effimera natura.

Sulla base di questa premessa, ciò che leggerete nelle prossime righe intende scoprire insieme il percorso di modernizzazione delle applicazioni verso la dimensione del cloud. Questo viaggio immaginario ci consentirà di capire come l’approccio serverless, pur avendo ancora molta strada da fare, vada sin d’ora oltre il FaaS, configurandosi al di là della prerogativa per lo sviluppo software. L’approccio serverless è sempre più orientato a semplificare le operazioni per un’ampia gamma di utenti finali, in ambiti dove, scusate il gioco di parole, risulta probabilmente persino più serverless rispetto al suo impiego per lo sviluppo software duro e puro.

Modernizzazione delle applicazioni: dalla migrazione del software legacy alle app cloud native

Senza farci troppe illusioni, è importante sottolineare come non tutte le applicazioni possono essere modernizzate, almeno a partire dalla loro interezza monolitica. Dopo un accurato assessment ci si rende spesso conto di limiti oggettivi. Alcune app non possono essere virtualizzate se non riprogrammandole integralmente, mentre altre non ha proprio senso concepirle in un ecosistema cloud, ad esempio per via di alcune dipendenze legacy che non possono essere ridefinite in alcun modo. Tutto questo senza entrare nel merito dei contesti, spesso indipendenti dall’applicazione stessa, che vogliono l’azienda soggetta a particolari condizioni di privacy e sicurezza dei dati che ne vietano di fatto la conservazione in cloud.

Smaltita questa non troppo incoraggiante premessa, migrare una app in cloud costituisce ormai una prassi, al punto che sono ormai storicizzati alcuni approcci fondamentali, altrimenti noti come le cinque “R”della app migration, secondo la teorizzazione proposta da Gartner già nel lontano 2011:

  • Rehost (Lift & Shift): consiste nello spostamento dell’applicazione con criteri di minimo intervento dall’infrastruttura on-premise ad un IaaS (Infrastructure-as-a-Service), che ne replica di fatto le funzionalità sui server fisici e virtuali disponibili in cloud pubblico o privato.
  • Refactor: rispetto al lift & shift prevede un intervento più radicale sul software originale, ai fini di migrare l’applicazione in PaaS (Platform-as-a-Service) dove sono disponibili sistemi operativi ed ambienti di esecuzione orientati ai microservizi, come nel caso dei container.
  • Revise: rispetto al lift & shift prevede la trasformazione del software legacy per sfruttare in maniera più profonda ed efficiente le potenzialità dell’infrastruttura in cloud, senza limitarsi al semplice hosting, ma esplorando i servizi cloud native. Ciò accade ad esempio rimpiazzando un database legacy con uno disponibile in cloud, in modo da ottenere un sistema di gestione dei dati più efficiente ed integrato con i servizi di business analytics e business intelligence esclusivi di tale ecosistema.
  • Rebuild: l’approccio ricostruttivo agisce in maniera selettiva sull’applicazione legacy, in funzione delle parti che ha più senso migrare in cloud. Un esempio è dato dai web service (cloud-hosted browser e app mobile), che di fatto combinano il refactor e il revising, sviluppando un nuovo front-end cloud native, quando il back-end rimane tradizionale e continua ad essere disponibile sul data center on-premise. In molti casi si tratta di creare una nuova interfaccia utente, più facilmente accessibile. Per tale motivo, molti sviluppatori con considerano il rebuild una vera e propria migrazione in cloud dell’applicazione.
  • Replace: consiste nella sostituzione integrale dell’applicazione legacy con una nuova applicazione cloud native SaaS (Software-as-a-Service). Si tratta di un’operazione molto comune nel caso delle applicazioni più orizzontali, come le e-mail, le fatture elettroniche o le piattaforme di collaborazione in streaming, dove insistere sulle versioni legacy comporterebbe più svantaggi che altro, sotto tutti i punti di vista. Nel caso delle applicazioni core, la scelta migratoria si fa ovviamente più complessa ed occorre valutare attentamente tutti i pro e i contro derivanti dai vari approcci migratori, sempre che migrare abbia effettivamente un senso.

Per quanto riguarda le operazioni da effettuare, il percorso di modernizzazione delle applicazioni parte dalla decomposizione dell’architettura monolitica originale in vari microservizi, per disaccoppiare le funzioni principali. Tali microservizi vengono successivamente containerizzati in PaaS, ossia eseguiti in ambienti runtime che contengono lo stretto necessario per svolgere tale operazione. Sulla base di questo sforzo, è inoltre opportuno capire quali funzioni possono essere eseguite in ambienti serverless, in quanto basate nello specifico su un evento, e procedere di conseguenza.

Tra le funzioni che si prestano fisiologicamente al serverless ritroviamo i sistemi di gestione dei dati, su tutti il processo ETL, i chatbot/voicebot ed in generale tutte quelle applicazioni caratterizzate da carichi di lavoro dai picchi anche molto elevati, ma di breve durata, anche se imprevisti, in quanto tale condizione è facilmente associabile ad un evento, dotato di un inizio e di una fine.

Architettura serverless per la modernizzazione delle applicazioni: tutti i vantaggi di un server che c’è, ma non si vede

I vantaggi di un’architettura serverless non si limitano alla virtualizzazione più estrema di tutte le risorse IT necessarie per eseguire una funzione. Il suo minimalismo deriva dal fatto che la funzione stessa, essendo basata su un evento specifico, cessa quando viene meno la condizione che ha avviato la sua esecuzione. In questo modo, il provider riesce ad eseguire la funzione per lo stretto tempo necessario al suo scopo, ottimizzando al massimo l’allocazione e il relativo dispendio di risorse. Questo concetto è logicamente estendibile, almeno per quanto concerne alcuni aspetti parziali.

In gran parte delle progettualità minimaliste, il risultato di estrema semplicità che tutti possono apprezzare in front-end, nasconde in back-end, sotto il cofano, dietro la facciata, una complessità notevole, derivante dallo sforzo necessario per celare i dettagli dell’intera struttura funzionale alla base di un determinato servizio.

Nel contesto di un’architettura serverless, i server fisici e virtuali necessari per eseguire le funzioni non spariscono per magia, sono sempre presenti e sono anche più complesse da gestire lato provider. Il suffisso “less” è infatti relativo alla percezione dell’utente finale, lo sviluppatore che predispone il codice necessario per eseguire la funzione soltanto al verificarsi di un determinato evento.

I vantaggi di questa attività asincrona, tipica del cloud, coincidono da un lato con la scalabilità estrema dell’elaborazione serverless, che consente di automatizzare del tutto il provisioning delle risorse IT necessarie per eseguire un carico di lavoro event driven, che rimangono attive soltanto in quel determinato periodo. Si tratta pertanto di una condizione molto meno dispendiosa, se paragonata alla disponibilità di risorse che rimangono molto spesso inutilizzate, in quanto sempre disponibili, come accade ad esempio nel PaaS.

Il FaaS, che si basa sul concetto serverless, è quindi la condizione che si rivela di fatto più pertinente al famigerato “pay per use” dei modelli a servizi. In effetti, si paga soltanto per ciò che si esegue, senza tempi morti. Nel momento in cui la funzione cessa, il tassametro non corre più.

Si tratta di un vantaggio spesso cruciale quando si tratta di fare valutazioni di business, anche considerando come i provider di tali servizi garantiscono una condizione di elevata scalabilità, fornendo in tempo reale le risorse necessarie a soddisfare picchi improvvisi o situazioni di carico elevate ma di durata limitata, senza rischiare in alcun modo un downtime dell’applicazione.

Oltre lo sviluppo software. Approccio serverless per semplificare il rapporto quotidiano con la tecnologia

Per quanto il serverless si sposi alla perfezione con molte situazioni applicative, immaginare un software esclusivamente basato sull’esecuzione di funzioni basate su eventi è al momento molto complesso. Per quanto moderna e modernizzabile in ogni singolo aspetto, un’applicazione cloud native al momento equivale infatti alla sapiente combinazione di vari ambienti di runtime, che spaziano dal container in perenne esecuzione al container stateless che vive giusto il tempo di espletare l’evento a cui viene collegata una specifica funzione.

Nell’ampio universo che costituisce il mercato dell’information technology, ci si è ovviamente posti il problema di adottare l’approccio serverless anche in altri ambiti, che non siano soltanto quelli pensati in maniera esclusiva per gli sviluppatori, ma possano trovare ampio riscontro presso la generica utenza aziendale. Anche in questo caso si tratta di sviluppare soluzioni capaci di eliminare la presenza percettiva dell’infrastruttura hardware e software necessaria per svolgere una specifica funzione. Il concetto viene esteso ai task comuni, non soltanto allo sviluppo software.

Per porci in quest’ottica, dobbiamo dunque sfidare le ire dei puristi e slegarci, almeno per un attimo, dall’associazione ricorrente tra il FaaS e il serverless, per proiettare quest’ultimo nel contesto di sviluppare servizi in cloud che consentano all’utente finale di pensare esclusivamente a ciò che deve fare, esattamente come farebbe un dev alle prese con un container stateless.

Nel caso di un dipendente comune, un’operazione comune potrebbe essere l’archiviazione di un documento. Un tempo era necessario procedere manualmente in ogni fase, scannerizzando il supporto cartaceo e procedere con decine di interazioni con altrettanti sistemi.

L’utente doveva preoccuparsi di tutto, perdendo letteralmente le proprie giornate ad eseguire operazioni di routine, a bassissimo valore aggiunto per il business. Fortunatamente il progresso ci assiste ed oggi possiamo impiegare soluzioni in cloud interamente automatizzate, che grazie all’Intelligenza Artificiale consentono di acquisire, classificare e archiviare in modo corretto ed estremamente rapido qualsiasi documento da gestire in azienda.

La gestione documentale è soltanto uno degli esempi che potremmo citare in merito ad un processo estremamente variegato e complesso, che può essere reso “serverless” sia concettualmente che a livello operativo. Si tratta di concetti che le grandi aziende hanno già adoperato da tempo nei loro processi. La sfida del mercato IT, attraverso l’instancabile azione dei system integrator e dei solution provider, è oggi quella di creare situazioni serverless alla portata di tutti, in modo da facilitare radicalmente la vita delle PMI e della maggior parte degli enti pubblici.