Il serverless computing è un pattern emergente di architettura software che promette di eliminare la necessità di provisioning e gestione dell'infrastruttura.
I responsabili I&O dovrebbero adottare un approccio “application-centric” per il serverless computing, mediante la gestione di API e SLA, piuttosto che di infrastrutture fisiche.
Il serverless non sostituisce i container o le macchine virtuali, quindi è fondamentale imparare come e dove usare al meglio tale tecnologia.

È bene chiarire 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 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.