Serverless computing: un nuovo paradigma del cloud

Il serverless computing è uno dei paradigmi che stanno sperimentando una rapida crescita in ambito cloud. Quali sono i suoi effettivi vantaggi? Cosa lo differenzia dagli altri modelli?

Con l’avvento del serverless computing sviluppatori e reparti IT hanno avuto negli ultimi anni la possibilità di concentrarsi sulle attività strategiche, tralasciando mansioni onerose dal punto di vista temporale quali, ad esempio, la pianificazione, l’approvvigionamento e la manutenzione delle risorse di calcolo. Nato nel 2008 con l’introduzione di Google App Engine, il serverless computing ha ricevuto uno slancio definitivo nel 2014, anno di nascita di ASW Lambda.

È bene chiarire subito che siamo nell’ambito del cloud computing. Com’è noto tre sono i modelli di cloud computing principali, che si differenziano per il diverso livello di controllo, la flessibilità e la gestione delle risorse:

• Infrastructure as a Service (IaaS), che ingloba gli elementi fondamentali di base dell’infrastruttura, tra cui aspetti di rete, macchine (virtuali o su hardware dedicato) e storage.
• Platform as a Service (PaaS), con cui ci si svincola dalla gestione dell’infrastruttura sottostante (hardware e sistemi operativi) in modo da concentrarsi sulla distribuzione e sulla gestione delle applicazioni. Con questo modello non è più necessario dedicarsi all’approvvigionamento delle risorse, la manutenzione del software, l’applicazione di patch ecc.
• Software as a Service (SaaS) che offre infine una piattaforma completa gestita dal provider di servizi e permette agli utenti di concentrarsi sul livello applicativo.

Negli ultimi anni si è assistito all’evoluzione dei modelli appena descritti. Sono dunque nati ulteriori paradigmi di gestione ed utilizzo delle risorse: uno di questi è il cosiddetto Function as a Service (Faas), detto anche serverless computing.

Il serverless computing  è un paradigma di elaborazione cloud che permette l’esecuzione di applicazioni senza preoccuparsi dei problemi legati all’’infrastruttura sottostante. Il termine “serverless” potrebbe essere fuorviante: si potrebbe infatti pensare che questo modello non preveda l’utilizzo di server per l’elaborazione. In realtà sta ad indicare che il provisioning, la scalabilità e la gestione dei server su cui le applicazioni sono eseguite sono amministrati in automatico, in maniera completamente trasparente per lo sviluppatore. Il tutto è possibile grazie a un nuovo modello di architettura, detta appunto serverless.

Il primo modello di FaaS risale, come detto, al rilascio del servizio AWS Lambda nel 2014, da parte di Amazon. Con il tempo alla soluzione di Amazon si sono aggiunte ulteriori alternative, sviluppate da altri grandi vendor, come Microsoft, con le sue Azure Functions, e da IBM e Google, con le proprie Cloud Functions.

Esistono inoltre valide soluzioni open-source: tra le più utilizzate, abbiamo Apache OpenWhisk, usata dalla stessa IBM su Bluemix per il proprio serverless offering, ma anche OpenLambda e IronFunctions, quest’ultima basata sulla tecnologia dei container di Docker.

Cos’è una Function?

Una function contiene del codice che uno sviluppatore vuole venga eseguito in risposta a determinati eventi. Lo sviluppatore si preoccupa di configurare tale codice e specificare i requisiti in termini di risorse, all’interno della console del fornitore di riferimento. Tutto il resto, compreso il dimensionamento delle risorse, è gestito in modo automatico dal provider, in base al carico di lavoro richiesto.

Quali sono i vantaggi di questo approccio rispetto al cloud computing tradizionale? Come mai si è sentita l’esigenza di optare per un nuovo modello di computazione?

I benefici derivanti dal serverless computing sono molteplici:

• Nessuna gestione dell’infrastruttura: gli sviluppatori possono concentrarsi sul prodotto da realizzare piuttosto che sul funzionamento e sulla gestione dei server a runtime.

• Scalabilità automatica: le risorse vengono ricalibrate in modo automatico per far fronte a ogni tipo di workload, senza richiedere una configurazione per lo scaling, ma reagendo agli eventi in real-time.
• Ottimizazione dell’uso delle risorse: dato che le risorse di elaborazione e di storage vengono allocate dinamicamente, non è più necessario investire in capacità in eccesso preventivamente.

• Riduzione dei costi: nel cloud computing tradizionale, è previsto il pagamento delle risorse in esecuzione anche quando queste non vengono effettivamente utilizzate. Nel caso serverless, le applicazioni sono event-driven, per cui quando il codice dell’applicazione non è in esecuzione, non viene addebitato nessun costo, quindi non è necessario pagare per risorse inutilizzate.

• Alta disponibilità: I servizi che gestiscono l’infrastruttura e l’applicazione garantiscono elevata disponibiità e tolleranza ai guasti.

• Miglioramento del Time-To-Market: L’eliminazione degli oneri di gestione dell’infrastruttura permette agli sviluppatori di concentrarsi sulla qualità del prodotto e di portare il codice in produzione più velocemente.

Possibili problemi e limiti

Come sempre, non è tutto oro quel che luccica. Ci sono dei contro da tenere in considerazione quando si valuta l’adozione di questo paradigma:

• Possibile perdita di performance: se il codice non viene utilizzato molto frequentemente, potrebbero verificarsi problemi di latenza nella sua esecuzione, rispetto al caso in cui risulta in continua esecuzione su un server, una virtual machine o un container. Ciò accade perché, contrariamente a quanto si verifica utilizzando politiche di autoscaling, con il modello serverless il cloud provider spesso dealloca completamente le risorse se il codice non è utilizzato. Questo implica che se il runtime richiede un certo tempo per l’avvio (si prenda per esempio JRE), si crea inevitabilmente latenza aggiuntiva nella fase iniziale di start.
• Assenza di stato: le funzioni serverless operano in modalità stateless. Questo significa che se si vuole aggiungere una logica di salvataggio di alcuni elementi, ad esempio dei parametri da passare come argomenti a una funzione differente, occorre aggiungere un componente di storage persistente al flusso dell’applicazione, e legare gli eventi tra loro. In questo caso, Amazon mette a disposizione un ulteriore strumento, chiamato AWS Step Functions, atto a coordinare e gestire lo stato di tutti i microservizi e componenti distribuiti delle applicazioni serverless.
  
• Limite alle risorse: il serverless computing non è adatto ad alcuni tipi di workload o casi d’uso, in particolare a quelli ad elevate prestazioni, sia per i limiti sull’uso delle risorse che vengono imposti dal cloud provider (per esempio AWS limita il numero di esecuzioni concorrenti delle Lambda functions), sia per la difficoltà nel provisioning del numero di server desiderati in un arco temporale limitato e fissato.
• Debugging e monitoring: se ci si affida a soluzioni non open-source, gli sviluppatori dipenderanno dai vendor per quanto riguarda il debugging e il monitoring delle applicazioni, e non riusciranno pertanto a diagnosticare nel dettaglio eventuali problemi tramite l’utilizzo di ulteriori profilers o debuggers, dovendo affidarsi agli strumenti messi a disposizione dai rispettivi provider.

Casi di studio

Attualmente sono diverse le aziende che si affidano all’elaborazione serverless.

AWS Lambda viene utilizzato ad esempio da Localytics per elaborare miliardi di punti dati in tempo reale, e per processare dati storici e memorizzati in S3 o in streaming da Kinesis.

Il quotidiano Seattle Times usa AWS Lambda per ridimensionare le immagini della sua edizione online, in modo che vengano visualizzate correttamente su più dispositivi, che siano desktop, tablet o smartphone.

Shazam, The New York Times e Alibaba.com utilizzano il servizio Firebase di Google, mentre Fujifilm si affida alle Azure Functions.

Spindox in ambito serverless

Spindox utilizza AWS Lambda per diversi scopi: automatizzare i processi di backup delle AMI, avviare script di Cloud Formation per generare ad esempio virtual machines che eseguano il backup di cartelle condivise e le pubblichino su S3. Integra inoltre le Lambda con progetti IoT, per l’elaborazione e il logging delle richieste provenienti da Chatbot sviluppati internamente.

Tirando le somme…

Appare dunque evidente che l’utilizzo del serverless computing è strettamente legato alla tipologia di prodotto che si vuole sviluppare e che non tutte le applicazioni sono adatte a questo paradigma. Le limitazioni diventano evidenti soprattutto quando si ha a che fare con sistemi legacy, non sempre facilmente adattabili alle nuove tecnologie, o sistemi troppo complessi, che rischierebbero di far aumentare i costi in maniera non controllabile.

Se usato con la dovuta attenzione, i vantaggi per le nuove applicazioni risultano evidenti, sia a livello di sviluppo che di qualità del prodotto realizzato. Il fatto di utilizzare le risorse solo nel momento dell’effettivo bisogno, lo rende un modello molto flessibile e appetibile per le aziende, ma cosa comporta dal lato dei team di sviluppo e di operation? La mancata pianificazione delle risorse non potrebbe portare allo sviluppo di applicazioni non sufficientemente ingegnerizzate, povere dei giusti accorgimenti sia a livello di performance che di utilizzo delle risorse stesse?