Cos'è il serverless computing?

Il serverless computing è un modello di sviluppo cloud native che consente agli sviluppatori di creare ed eseguire applicazioni senza gestire i server.

Anche se in questo modello i server vengono utilizzati comunque, sono astratti dallo sviluppo delle app. Le attività di routine per il provisioning, la manutenzione e la scalabilità dell'infrastruttura server vengono gestite da un provider di servizi cloud. Gli sviluppatori devono semplicemente creare pacchetti di codice all'interno di container per il deployment.

Dopo il deployment le app serverless rispondono alle richieste e si adattano automaticamente in base alle diverse esigenze di scalabilità. L'utilizzo delle soluzioni serverless offerte dai provider di cloud pubblico viene solitamente misurato on demand tramite un modello di esecuzione basato su eventi, pertanto le funzioni serverless non costano nulla, quando non vengono utilizzate.

Il modello serverless è diverso dagli altri modelli di cloud computing, poiché il provider di servizi cloud è responsabile di gestire sia l'infrastruttura cloud che la scalabilità delle app. Le app serverless vengono distribuite in container che vengono avviati on demand al momento della chiamata.

In un modello di cloud computing Infrastructure-as-a-Service (IaaS) standard, gli utenti acquistano unità di capacità, ovvero pagano a un provider di cloud pubblico i componenti server che sono utilizzati per l'esecuzione delle proprie applicazioni e che sono sempre attivi. L'utente è responsabile di aumentare la capacità del server durante i picchi di domanda e ridurla quando non occorre più. L'infrastruttura cloud necessaria per l'esecuzione di un'applicazione rimane attiva anche quando quest'ultima non è in uso.

Con un'architettura serverless, invece, le applicazioni vengono avviate solo quando necessario. Quando un evento attiva l'esecuzione del codice, il provider di cloud pubblico assegna dinamicamente le risorse per tale codice e l'utente paga il servizio solo fino alla fine dell'esecuzione. Oltre ai vantaggi in termini di costo ed efficienza, il metodo serverless evita agli sviluppatori le attività di routine e manuali necessarie per garantire la scalabilità delle applicazioni e il provisioning del server.

Il modello serverless consente di affidare al provider di servizi cloud attività di routine quali gestione del sistema operativo e file system, applicazione delle patch di sicurezza, bilanciamento del carico, gestione della capacità, gestione della scalabilità, registrazione e monitoraggio.

È possibile realizzare un'applicazione completamente serverless oppure in parte serverless e in parte costituita da microservizi convenzionali.

In un modello serverless, un provider di servizi cloud esegue i server fisici e ne alloca dinamicamente le risorse per conto dell'utente, che può eseguire il deployment del codice direttamente nell'ambiente di produzione.

In genere i prodotti di serverless computing rientrano in due categorie, ovvero Backend-as-a-Service (BaaS) e Function-as-a-Service (FaaS).  

I servizi BaaS consentono agli sviluppatori di attingere a svariati servizi e applicazioni di terze parti. Un provider di servizi cloud può ad esempio offrire servizi di autenticazione, funzioni di crittografia aggiuntive, database accessibili dal cloud e dati di consumo altamente affidabili. Nel caso dei servizi BaaS, le funzioni serverless vengono solitamente chiamate tramite interfacce di programmazione delle applicazioni (API).

In genere, quando gli sviluppatori parlano di serverless, si riferiscono al modello FaaS. Anche con questo modello gli sviluppatori devono scrivere il codice lato server personalizzato, ma in questo caso tale codice viene eseguito in container completamente gestiti da un provider di servizi cloud. 

Tutti i principali provider di cloud pubblico offrono uno o più servizi FaaS, come nel caso di Amazon Web Services con AWS Lambda, Microsoft Azure con Azure Functions, Google Cloud con vari prodotti e IBM Cloud con IBM Cloud Functions, per citarne solo alcuni. 

Alcune aziende preferiscono gestire i propri ambienti FaaS utilizzando piattaforme serverless open source, come Red Hat® OpenShift® Serverless, che è basato sul progetto Knative per Kubernetes.

Il Function-as-a-Service (FaaS) è un modello di elaborazione cloud basato su eventi in cui gli sviluppatori scrivono codice che viene distribuito in container completamente gestiti tramite una piattaforma, e successivamente eseguito on demand.

Diversamente dal modello BaaS, la modalità Function-as-a-Service offre un maggior livello di controllo agli sviluppatori, che creano applicazioni personalizzate anziché sfruttare librerie di servizi preconfezionati. 

È il provider di servizi cloud a gestire i container in cui è distribuito il codice. I container, nello specifico, sono:

• Stateless: semplificano l'integrazione dei dati.
• Temporanei: possono essere eseguiti per un breve periodo di tempo.
• Attivati da eventi: vengono eseguiti automaticamente quando necessario.
• Totalmente gestiti da un provider di servizi cloud: l'utente paga solo quello che utilizza, e non per server e applicazioni sempre attivi.

Con il modello FaaS gli sviluppatori possono chiamare le applicazioni serverless tramite API, che vengono gestite dal provider FaaS tramite un gateway API.

L'architettura serverless è perfetta per le applicazioni stateless asincrone che possono essere avviate istantaneamente. Il modello serverless è ottimale anche per gli scenari di utilizzo che comportano picchi di domanda improvvisi e imprevedibili.

Alcuni esempi includono l'elaborazione batch dei file di immagine in arrivo, che può essere richiesta raramente ma deve essere disponibile quando arriva un grosso batch di immagini da elaborare contemporaneamente, oppure il monitoraggio delle modifiche a un database, che richiedono l'applicazione di una serie di funzioni, come i controlli per verificare che rispettino gli standard di qualità o la loro conversione automatica.

Le app serverless sono anche adatte agli scenari di utilizzo che prevedono flussi di dati in entrata, chatbot, attività pianificate o logica di business.

Gli altri scenari di utilizzo comuni del modello includono le API back end e le app web, l'automazione dei processi di business, i siti web severless e l'integrazione fra più sistemi.

Consentendo l'esecuzione di applicazioni containerizzate in un'infrastruttura automatizzata, la piattaforma di orchestrazione dei container Kubernetes viene spesso utilizzata per l'esecuzione degli ambienti serverless, ma di per sé Kubernetes non è predisposto per l'esecuzione nativa di applicazioni serverless.

Knative è un progetto della community open source che aggiunge componenti per il deployment, l'esecuzione e la gestione di applicazioni serverless su Kubernetes.

L'ambiente serverless Knative consente di eseguire il deployment del codice in una piattaforma Kubernetes come Red Hat OpenShift. Con Knative è possibile creare il pacchetto di codice di un servizio come immagine container e passarlo al sistema, che lo esegue solo quando necessario, poiché Knative avvia e arresta le istanze automaticamente.

Knative è formato da 3 componenti principali:

• Build è un approccio flessibile alla creazione del codice sorgente nei container.
• Serving, che offre deployment rapido e la scalabilità automatica dei container, tramite un modello basato su richiesta per fornire i carichi di lavoro on demand.
• Eventing, un'infrastruttura per l'utilizzo e la generazione di eventi in grado di attivare le applicazioni. Le applicazioni possono essere attivate in vari modi, ad esempio dagli eventi delle tue applicazioni personalizzate, dai servizi cloud di diversi provider, da sistemi Software-as-a-Service (SaaS) e da flussi Red Hat AMQ.

Diversamente dai framework serverless precedenti, Knative è stato progettato per il deployment di qualsiasi carico di lavoro applicativo moderno: dalle applicazioni monolitiche ai microservizi, fino alle microfunzioni.

Essendo un'alternativa a una soluzione FaaS controllata da un singolo provider di servizi, Knative può essere eseguito in qualsiasi piattaforma cloud che esegue Kubernetes, inclusi i data center on premise. Questo consente alle aziende di gestire i propri carichi di lavoro serverless in modo più agile e flessibile.

Vantaggi

• Il serverless computing può incrementare la produttività degli sviluppatori e ridurre i costi operativi. Delegando al provider di servizi cloud le attività di routine relative al deployment e alla gestione dei server, agli sviluppatori resta più tempo da dedicare alle proprie applicazioni. 
• Il modello serverless consente di adottare DevOps senza costringere gli sviluppatori a descrivere esplicitamente l'infrastruttura su cui effettuare il deployment delle operazioni.  
• È possibile semplificare ulteriormente lo sviluppo di applicazioni incorporando interi componenti da offerte BaaS di terzi.
• In un modello serverless i costi operativi risultano inferiori, perché viene addebitato solo il tempo di calcolo effettivamente impiegato nel cloud, e non quello utilizzato per l'esecuzione e la gestione continuativa dei server.

Svantaggi

• Il fatto di non eseguire i server internamente e di non controllare la logica sul lato server comporta tuttavia alcuni svantaggi.
• I provider di servizi cloud possono imporre vincoli severi all'interazione con i propri componenti, limitando la flessibilità e la personalizzazione dei tuoi sistemi. Nel caso degli ambienti BaaS, gli sviluppatori possono essere vincolati a servizi di cui non riescono a controllare il codice.
• Delegare il controllo di questi aspetti dell'ambiente IT può determinare il vendor lock in. Se decidi di cambiare provider, potresti essere costretto a eseguire l'upgrade dei tuoi sistemi per rispettare le specifiche del nuovo fornitore.

I concetti di architettura serverless e FaaS si sono sviluppati di pari passo con la diffusione dei container e delle offerte cloud on demand. In un report di 451 Research, redatto in collaborazione con Red Hat, l'evoluzione dell'architettura serverless è stata suddivisa in 3 fasi.

Nella fase "1.0" l'architettura serverless presentava limitazioni che la rendevano poco adatta all'elaborazione generica. Il modello Serverless 1.0 è caratterizzato da

• HTTP e poche altre origini
• Solo funzioni
• Tempo di esecuzione limitato (5-10 minuti)
• Assenza di orchestrazione
• Esperienza di sviluppo locale limitata

L'introduzione di Kubernetes ha dato inizio alla fase "Serverless 1.5", in cui i framework serverless hanno cominciato a offrire la scalabilità automatica dei container. Il modello Serverless 1.5 è caratterizzato da:

• Knative
• Scalabilità automatica basata su Kubernetes
• Microservizi e funzioni
• Semplicità di debug e test a livello locale
• Supporto di più lingue e portabilità

La fase "Serverless 2.0" è iniziata da poco, con l'aggiunta di integrazione e stato. I provider hanno iniziato ad aggiungere le parti che mancavano per adattare il modello serverless ai carichi di lavoro aziendali generici. Il modello Serverless 2.0 è caratterizzato da:

• Gestione dello stato di base
• Uso di modelli di integrazione aziendale
• Capacità di messaggistica avanzate
• Integrazione con i servizi PaaS enterprise
• Sorgenti di eventi enterprise ready
• Stato e integrazione