Computing senza server

Completato

Agli inizi del cloud computing, i provider di servizi cloud come Amazon e Microsoft si sono concentrati sull'offerta di un'ampia gamma di servizi IaaS ai clienti. Questo ha favorito la crescita dei cloud pubblici, consentendo ai clienti di spostare facilmente i carichi di lavoro eseguiti in locale su server fisici o su macchine virtuali in macchine virtuali nel cloud. Ma il modello IaaS comporta responsabilità. Un'organizzazione che avvia una macchina virtuale nel cloud si assume anche la responsabilità di gestirne il contenuto, ovvero il sistema operativo, tutti i runtime necessari, le applicazioni che usano tali runtime e così via.

Il modello PaaS trasferisce parte di tale responsabilità sul provider di servizi cloud e ha favorito ulteriori investimenti nel cloud. Con servizi come AWS Elastic Beanstalk e il servizio app Azure di AWS, i clienti possono eseguire il provisioning di server Web virtuali dotati di runtime diffusi come Java, Node.js e Microsoft.NET e iniziare a eseguire software su di essi in pochi minuti. Anche se le macchine virtuali eseguono le operazioni più gravose dietro le quinte, la presenza di queste macchine virtuali è in gran parte astratta. Il modello PaaS consente ai clienti di concentrarsi sulla scrittura di applicazioni mirate a risolvere i problemi aziendali anziché dedicare cicli alla gestione delle macchine virtuali e al mantenere aggiornate le piattaforme.

L'elaborazione serverless è un'innovazione relativamente recente nel cloud computing, che incrementa ulteriormente il livello di astrazione. Si supponga che l'organizzazione scriva e gestisca codice che esegue backup notturni dei dati cruciali, esegue cicli settimanali di fatturazione o trasmette un pagamento elettronico ogni volta che viene caricata una fattura nell'archiviazione cloud. In questo caso, l'obiettivo principale è eseguire questo codice ed eseguirlo al momento giusto. Tutto il resto è secondario, inclusi la posizione di archiviazione del codice e dove e come debba essere eseguito.

Si potrebbe adottare un approccio IaaS creando una o più macchine virtuali per eseguire il codice e installando le piattaforme e le librerie necessarie. Si potrebbe effettuare il provisioning di un'istanza di Elastic Beanstalk o del servizio app per ospitare il codice. In alternativa, si potrebbe usare un runtime di funzioni, ad esempio AWS Lambda o Funzioni di Azure, per eseguire il codice ogni volta che si vuole indipendentemente da dove o come è ospitato. AWS Lambda e Funzioni di Azure sono entrambi esempi di elaborazione serverless (in particolare di funzioni serverless), come anche Google Cloud Functions. Tutti e tre rappresentano il passaggio successivo nell'evoluzione naturale del cloud computing dal modello IaaS, in cui si ha la responsabilità di tutto, al modello serverless, in cui è possibile concentrarsi sulle azioni che si vogliono eseguire (il codice da eseguire) nel cloud e lasciar gestire tutto il resto al provider di servizi cloud.

Le funzioni serverless eseguite dai runtime di funzioni nel cloud sono la forma più comune di elaborazione serverless, ma non l'unica. Amazon, Microsoft e Google offrono versioni serverless di alcuni dei loro altri servizi PaaS, inclusi database serverless. Alcuni provider offrono il supporto per flussi di lavoro serverless, ossia la possibilità di definire flussi di lavoro aziendali nel cloud ed eseguirli in risposta a eventi esterni, ad esempio il caricamento di fatture nell'archiviazione cloud, l'attivazione di timer a intervalli specificati o l'arrivo di messaggi in una casella di posta elettronica, spesso senza bisogno di scrivere una sola riga di codice. Infine, molti dei servizi contenitore offerti dai provider di servizi cloud, tra cui Istanze di Azure Container e AWS Elastic Container Service, rappresentano esempi di elaborazione serverless, perché consentono di eseguire contenitori nel cloud astraendo l'infrastruttura sottostante.

Vantaggi dell'elaborazione serverless

L'elaborazione serverless offre tre importanti vantaggi alle organizzazioni che usano il cloud computing.

Riduzione dei costi di elaborazione: in genere i clienti pagano un canone mensile per le macchine virtuali IaaS e i servizi PaaS come Elastic Beanstalk e il servizio app di Azure. La fatturazione continua anche se i servizi sono inattivi. La maggior parte dei servizi di elaborazione serverless, tuttavia, supporta un modello di tariffazione a consumo, in cui viene addebitato solo il tempo di esecuzione del codice. Si supponga di dedicare una macchina virtuale da 100 euro al mese all'esecuzione di codice per il backup notturno dei dati cruciali e che il codice venga eseguito per 30 minuti ogni notte. Si pagano 100 euro al mese per eseguire il codice per 1/48° del mese, che equivale a meno di un giorno. Distribuire lo stesso codice come funzione serverless potrebbe costare pochi euro al mese. Con la tariffazione a consumo, il tempo di inattività non si paga.

Scalabilità automatica: i provider di servizi cloud offrono meccanismi per il ridimensionamento dei servizi IaaS in prodotti come AWS Auto Scaling e i set di scalabilità di macchine virtuali in Azure. Forniscono anche opzioni di ridimensionamento manuale e automatico per i servizi PaaS. Tuttavia, anche se il ridimensionamento viene eseguito automaticamente, un amministratore cloud deve abilitare l'opzione corrispondente e configurarla in modo che il provider di servizi cloud sappia come e quando deve avvenire il ridimensionamento. Una delle considerazioni di base da cui gli amministratori devono partire è che, poiché si paga per le singole istanze dei servizi IaaS e PaaS, occorre configurare il servizio in modo da ridimensionarlo abbastanza, ma non troppo. L'elaborazione serverless offre la possibilità di aumentare in modo trasparente e automatico il numero di istanze quando la domanda cresce e ridurlo quando decresce. Un amministratore cloud non esegue in genere alcuna configurazione, se non l'abilitazione di questa opzione nel servizio. Se si ricevono contemporaneamente 100 richieste di esecuzione di una funzione serverless, il provider di servizi cloud garantisce che le richieste possano essere eseguite in parallelo (o prevalentemente in parallelo). Non vi è alcun effetto sui costi in quanto, con la tariffazione a consumo, eseguire una funzione 100 volte ha lo stesso costo, indipendentemente dal fatto che l'esecuzione sia seriale o parallela.

Riduzione dei costi amministrativi: il modello serverless consente di concentrarsi sull'esecuzione di codice e flussi di lavoro, trasferendo al provider di servizi cloud la responsabilità di tutti gli altri aspetti, inclusa la manutenzione della piattaforma sottostante.

L'elaborazione serverless ha anche degli svantaggi. Ecco alcune limitazioni da considerare:

• Alcuni runtime di funzioni impongono un limite sul tempo di esecuzione di una funzione.

• Alcuni runtime di funzioni non garantiscono l'esecuzione immediata di una funzione, a meno che non si sia disposti a pagare di più. Con Funzioni di Azure configurato per la fatturazione in base al consumo, ad esempio, una funzione potrebbe non essere eseguita per un massimo di 10 minuti dopo l'attivazione. Questo potrebbe non essere un problema per un backup notturno, perché è probabile che non sia rilevante se il backup viene eseguito alle 1:00 o 1:10, ma potrebbe essere un fattore cruciale per le funzioni per cui l'aspetto temporale è essenziale, ovvero funzioni che devono essere eseguite in tempo reale o in tempo quasi reale.

• Le funzioni serverless sono in genere senza stato, ovvero non possono archiviare dati internamente e aspettarsi che persistano da una chiamata di funzione alla successiva. Possono usare servizi di archiviazione cloud esterni, ad esempio Amazon S3 e Archiviazione di Azure, per rendere persistenti i dati tra le chiamate, ma in questo modo il codice della funzione diventa più complesso.

Alcuni provider di servizi cloud offrono il supporto per le funzioni con stato (in Azure sono denominate "Durable Functions"), ma le funzioni che mantengono lo stato sono un'aggiunta relativamente recente all'elaborazione serverless e non sono supportate a livello universale.

Funzioni senza server

L'esempio più comune di elaborazione serverless sono le funzioni serverless. Si carica il codice nel cloud e si indica quando va eseguito. Il codice può essere scritto in un'ampia varietà di linguaggi, tra cui Java e C#.

La Figura 11 contiene un elenco dei linguaggi di programmazione supportati dalle funzioni serverless in Azure, AWS e GCP al momento della stesura di questo articolo:

Lingua	Funzioni di Azure	AWS Lambda	Google Cloud Functions
C#	x	x
F#	x
Go		x	x
Java	x	x
JavaScript (Node.js)	x	x	x
PowerShell	x	x
Python	x	x	x
Ruby		x
TypeScript	x

Figura 11: Linguaggi di programmazione supportati dai runtime di funzioni serverless più diffusi.

Quando si crea una funzione e si specifica il codice che eseguirà, si identifica anche l'evento esterno che determina l'esecuzione della funzione. Le piattaforme cloud più diffuse supportano trigger di diversi tipi, tra cui timer, eventi che si verificano in altri servizi cloud, ad esempio il caricamento di un documento nell'archiviazione cloud, e chiamate HTTP. È semplice caricare un codice di fatturazione in un runtime di funzioni e configurarlo in modo che venga eseguito una volta al giorno, una volta alla settimana o una volta al mese. Altrettanto semplice è attivare una funzione ogni volta che viene caricata una fattura nell'archiviazione cloud, ad esempio in Amazon S3 o Archiviazione di Azure, oppure ogni volta che viene effettuata una chiamata a un endpoint REST associato alla funzione.

Le funzioni serverless vengono spesso usate per eseguire attività autonome, ad esempio backup notturni e fatturazione. Vengono usate anche per connettere altri servizi cloud e comporre soluzioni complete usando i servizi cloud come componenti. La Figura 12 illustra una soluzione di questo tipo, usata per combinare diversi servizi di Azure per monitorare l'attività degli orsi polari nell'Artico. Nell'architettura gioca un ruolo chiave una funzione di Azure, che riceve l'output da Analisi di flusso di Azure (attivato da una chiamata HTTP), recupera una foto da Archiviazione BLOB di Azure e invia la foto a un modello sottoposto a training con il servizio Visione personalizzata di Azure, che usa l'intelligenza artificiale (IA) per determinare se la foto contiene un orso polare. La funzione è il collante tra Analisi di flusso, Archiviazione BLOB e il servizio Visione personalizzata.

Figura 12: Uso di una funzione di Azure per connettere altri servizi di Azure.

Flussi di lavoro serverless

Alcuni servizi di elaborazione serverless permettono ai clienti di automatizzare i flussi di lavoro aziendali senza bisogno di scrivere codice. App per la logica di Azure, ad esempio, fornisce più di 100 connettori predefiniti per interfacciarsi con origini dati che spaziano dai database Oracle ai servizi social media, come X. Offrono attivazioni per definire quando i flussi di lavoro dovrebbero essere eseguiti, come quando un file viene caricato in Box.com o viene postato un tweet con un hashtag specifico. Forniscono inoltre centinaia di azioni predefinite, che definiscono cosa accade quando viene attivato un trigger e che è possibile concatenare per formare flussi di lavoro complessi e condizioni che consentono di eseguire le azioni in modo condizionale. Inoltre, sono estendibili all'infinito, perché una delle azioni supportate da App per la logica di Azure è quella che chiama una funzione di Azure. Se un flusso di lavoro include una logica personalizzata non incapsulata in un'azione, è possibile fornire il codice che implementa tale logica e includerlo nel flusso di lavoro come se si trattasse di un'azione predefinita.

La Figura 13 mostra un flusso di lavoro di questo tipo in Progettazione app per la logica di Azure¹. Quando arriva un messaggio di posta elettronica, l'app per la logica si attiva e verifica la presenza di una frase chiave nella riga dell'oggetto del messaggio di posta elettronica e la presenza di un allegato. Se vengono soddisfatte entrambe le condizioni, l'app per la logica richiama una funzione di Azure per rimuovere qualsiasi codice HTML dal corpo del messaggio. Deposita quindi il messaggio di posta elettronica purificato e tutti gli eventuali allegati in Archiviazione BLOB di Azure e invia alle parti interessate un messaggio di posta elettronica con collegamenti ai documenti pertinenti nell'archivio BLOB, che notifica che le informazioni sono disponibili e in attesa di revisione. Questo esempio combina due paradigmi serverless: un'app per la logica che esegue azioni senza codice (quantomeno non codice scritto dall'utente o da altri utenti dell'organizzazione) e una funzione di Azure che contiene il codice fornito dall'utente per personalizzare il flusso di lavoro. Questo aspetto è rappresentativo del cambiamento in atto nel cloud computing, dalle macchine virtuali fai da te ad astrazioni di livello superiore che consentono alle organizzazioni di concentrare le proprie energie sulla risoluzione di problemi aziendali invece che sulla gestione delle macchine virtuali nonché sull'installazione e sulla gestione di runtime.

Figura 13: Definizione di un flusso di lavoro in App per la logica di Azure.

Amazon offre un servizio analogo con AWS Step Functions. Con Step Functions è possibile comporre flussi di lavoro visivi che combinano altri servizi, ad esempio AWS ECS e AWS Lambda. I flussi di lavoro sono composti da una serie di fasi, in cui l'output di una fase funge da input per la successiva. Come App per la logica di Azure, AWS Step Functions fornisce primitive per la diramazione e l'esecuzione parallela, evitando la necessità di scrivere codice a questo scopo. In effetti, un flusso di lavoro aziendale diventa un diagramma di macchina a stati facile da comprendere, facile da spiegare e facile da modificare.

Database serverless

Agli inizi del cloud computing, ospitare un database nel cloud voleva dire effettuare il provisioning di una macchina virtuale e installare un prodotto di database, ad esempio MySQL, PostgreSQL o SQL Server. Il modello PaaS ha cambiato le carte in tavola, offrendo i database come servizio. Con il database SQL di Azure o Amazon Relational Database Service (RDS), ad esempio, è sufficiente eseguire il provisioning di un'istanza e in pochi minuti si ha a disposizione un database ospitato nel cloud, pronto per servire i client. Inoltre, il provider di servizi cloud mantiene aggiornata la piattaforma di database applicando aggiornamenti software e patch.

Un'innovazione ancora più recente nel cloud computing è rappresentata dai database serverless, che offrono un modello ottimizzato in termini di prezzo-prestazioni, ideale per i database singoli con modelli di utilizzo irregolare. Azure, ad esempio, offre una versione serverless del database SQL di Azure. Con la versione mainstream del database SQL di Azure è possibile scegliere un livello prezzo-prestazioni basato sul carico massimo che si prevede venga gestito dal database. Se i carichi sono intermittenti o presentano picchi, spesso si finisce per pagare come se il database avesse costantemente carichi elevati.

La versione serverless del database SQL di Azure attenua questo problema, ridimensionando il database in base alle esigenze dei carichi da gestire, con costi basati sulla somma dei costi di calcolo e dei costi di archiviazione. Come per le funzioni serverless che usano un modello a consumo, si paga solo per ciò che si usa. Amazon offre un servizio analogo con AWS Aurora Serverless, una versione serverless del servizio di database Aurora di Amazon, mentre Google offre ai clienti un servizio di database NoSQL serverless noto come Google Cloud Firestore.

Riferimenti

1. Microsoft (2019). Automatizzare la gestione di messaggi di posta elettronica e allegati con App per la logica di Azure. https://learn.microsoft.com/azure/logic-apps/tutorial-process-email-attachments-workflow.