Che cos'è il serverless computing?

Quando si tratta di creare applicazioni, gli sviluppatori di solito devono svolgere una serie di attività di gestione dei server per poter eseguire il deployment del codice, come la definizione delle risorse per l'elaborazione e l'archiviazione, l'applicazione di patch, il bilanciamento del carico e altro ancora. Tutti questi elementi aggiuntivi portano a tempi di provisioning più lunghi e a costi operativi aggiuntivi, che in ultima analisi rallentano i team di sviluppo. 

Il serverless computing cerca di fornire agli sviluppatori un'esperienza "serverless" invisibile, che elimina la necessità di preoccuparsi dei server o di qualsiasi cosa possa essere necessaria per eseguire un'applicazione. Il fornitore di servizi svolge tutto il lavoro dietro le quinte per assicurarsi che tu abbia le risorse per eseguire il codice e soddisfare i requisiti senza che ti venga addebitata la capacità inuttilizzata. 

Pensa al serverless come alla fornitura di acqua potabile a casa tua. Potresti scavare un pozzo, testare la qualità dell'acqua, installare e mantenere tutti gli impianti idraulici esterni necessari per portare l'acqua dentro casa. In alternativa, puoi collegarti alla rete idrica del tuo comune. Ti basta aprire il rubinetto per avere accesso a tutta l'acqua che vuoi quando ne hai bisogno e il comune ti invia una fattura mensile per la quantità esatta di acqua che consumi.

Allo stesso modo, i cloud provider avviano automaticamente le risorse dell'infrastruttura e gli ambienti di runtime necessari per eseguire le tue app serverless e fanno lo scale down automatico a zero al termine dell'esecuzione. In genere, l'addebito avviene in base alle risorse durante il tempo di esecuzione. Tuttavia, questo può variare in base al servizio e al fornitore. 

Ma aspetta, non ci sono altri tipi di cloud computing che forniscono risorse on demand con pagamento a consumo? È vero, anche i modelli di servizi cloud come Infrastructure as a Service (IaaS) e Platform as a Service (PaaS) forniscono accesso on demand alle risorse di elaborazione. 

Tuttavia, l'infrastruttura cloud a te assegnata rimane attiva anche se non la utilizzi. È inoltre tua responsabilità scalare la capacità del server o configurare le tue applicazioni per fare lo scale up o scale down in risposta alla domanda degli utenti. 

Le architetture serverless, d'altra parte, sono basate su eventi. In questo modello, il fornitore fornisce risorse solo quando un evento attiva l'esecuzione del tuo codice e scala istantaneamente e automaticamente in base alle richieste.

Nell'ambito del cloud computing serverless, esistono generalmente due tipi di servizi: Function as a Service (FaaS) e Backend as a Service (BaaS). 

• FaaS fornisce le risorse di elaborazione necessarie per eseguire la logica delle applicazioni in risposta alle richieste. Questi elementi logici (o funzioni) vengono eseguiti in container completamente gestiti dal fornitore di servizi cloud. Le applicazioni serverless sono solitamente suddivise in singole funzioni che eseguono un'azione in risposta a un evento. 
• BaaS offre l'intera funzionalità di backend delle applicazioni web o per dispositivi mobili come servizio, ad esempio come servizi di autenticazione, gestione di database, archiviazione sul cloud, notifiche push e hosting. BaaS elimina anche la necessità di gestire server, container e macchine virtuali. 

Nello sviluppo, il termine "serverless" viene solitamente utilizzato per descrivere le offerte FaaS. Tuttavia, è importante notare che FaaS è tecnicamente un sottoinsieme della tecnologia serverless. Il serverless computing include qualsiasi tipo di servizio in cui la gestione, la configurazione, la scalabilità e la fatturazione del server sono astratte dall'utente finale. Ciò può includere database, spazio di archiviazione, flussi di eventi, messaggistica e gateway API. 

Alcuni degli esempi di serverless computing più comuni ed emergenti includono:

• Caso d'uso: sincronizzare senza problemi lead/clienti tra diverse applicazioni aziendali (ad esempio, da CRM ad automazione del marketing)
• Soluzione serverless: una funzione Cloud Run attivata da HTTP riceve webhook dal sistema di origine (ad esempio, Salesforce), trasforma i dati e chiama l'API del sistema di destinazione (ad esempio, HubSpot), spesso utilizzando Secret Manager per le credenziali
• Prodotti serverless di Google Cloud: Cloud Run Functions e Secret Manager

• Caso d'uso: automatizzare la generazione e la distribuzione di report di routine
• Soluzione serverless: un job Cloud Scheduler attiva quotidianamente una funzione Cloud Run tramite Pub/Sub; la funzione esegue una query su un data warehouse (ad esempio, BigQuery), elabora i dati in un report e lo invia tramite un'API di posta elettronica
• Prodotti serverless di Google Cloud: Cloud Scheduler, Pub/Sub, Cloud Run Functions e BigQuery

• Caso d'uso: ridurre i costi del cloud identificando e gestendo automaticamente le risorse di computing inattive
• Soluzione serverless: un job Cloud Scheduler notturno attiva una funzione Cloud Run tramite Pub/Sub; questa funzione utilizza l'API Compute Engine e Cloud Monitoring per identificare le istanze inattive e le arresta o le elimina automaticamente, registrando le azioni in Cloud Logging
• Prodotti serverless di Google Cloud: Cloud Scheduler, Pub/Sub, Cloud Run Functions, Cloud Monitoring e Cloud Logging

• Caso d'uso: elaborare e arricchire flussi di dati ad alto volume (ad esempio, attività degli utenti) per ottenere insight e azioni immediate
• Soluzione serverless: gli eventi clickstream dell'utente vengono trasmessi in modalità flusso a Pub/Sub; una funzione Cloud Run (o un servizio Cloud Run) consuma questi eventi, li arricchisce con i dati di Firestore e quindi pubblica i dati arricchiti in un altro argomento Pub/Sub per l'analisi in tempo reale in BigQuery o per consigli personalizzati
• Prodotti serverless di Google Cloud: Pub/Sub, Cloud Run Functions, Cloud Run, Firestore e BigQuery

• Caso d'uso: automatizzare la creazione, il test e il deployment di microservizi in caso di modifiche al codice
• Soluzione serverless: un trigger Cloud Build monitora un repository Git (ad esempio, Cloud Source Repositories); al momento del commit del codice, Cloud Build esegue i test, crea un'immagine container in Artifact Registry ed esegue automaticamente il deployment della nuova versione in Cloud Run
• Prodotti serverless di Google Cloud: Cloud Build, Cloud Run, Artifact Registry e Cloud Source Repositories

• Caso d'uso: genera automaticamente varianti di immagini ottimizzate (ad esempio, miniature, formati diversi) al momento del caricamento
• Soluzione serverless: una funzione Cloud Run viene attivata quando una nuova immagine viene caricata in un bucket Cloud Storage; questa funzione elabora l'immagine (ridimensionamento, conversione del formato), salva le nuove versioni in Cloud Storage e aggiorna i metadati in Firestore
• Prodotti serverless di Google Cloud: Cloud Storage, Cloud Run Functions e Firestore

• Caso d'uso: esegui inferenze AI in tempo reale utilizzando LLM come Llama 3.1, Gemma 2, Mistral e altri
• Soluzione serverless: Cloud Run si integra con modelli di AI come l'API Gemini, gli endpoint Vertex AI o i modelli ospitati su un servizio Cloud Run abilitato per GPU; può anche fungere da endpoint API scalabile e ospitare agenti di AI
• Prodotti serverless della piattaforma Google Cloud: Cloud Run, Cloud Storage, Firestore

Uno dei maggiori svantaggi del serverless computing è che si tratta di una tecnologia ancora relativamente nuova. Di conseguenza, non è ancora adatta a tutti i potenziali casi d'uso. 

È inoltre chiaro che alcuni degli attuali punti deboli verranno risolti nel tempo man mano che il serverless computing continuerà a evolversi. In particolare, è già stato fatto molto lavoro sulle implementazioni open source dei modelli serverless e sulla ricerca di modi per rendere i servizi cloud più aperti affinché le soluzioni siano trasferibili tra piattaforme e ambienti diversi. 

• Idoneità limitata per i casi d'uso: le architetture serverless non sono sempre adatte ad applicazioni con requisiti specifici, come processi a esecuzione prolungata o esigenze di latenza molto bassa
• Vincoli di prestazioni: le funzioni serverless possono subire avvii a freddo (esecuzione iniziale ritardata) e possono avere limitazioni sul tempo di esecuzione e sulla memoria
• Vincoli al fornitore: la migrazione di applicazioni serverless tra provider di servizi cloud può essere complessa a causa delle differenze nelle API e nelle configurazioni
• Visibilità del server ridotta: gli sviluppatori hanno una visibilità limitata sull'infrastruttura sottostante, il che rende difficile la risoluzione dei problemi di prestazioni o l'ottimizzazione dell'utilizzo delle risorse
• Avvio lento: le funzioni serverless a volte possono subire un "avvio a freddo" in cui si verifica un ritardo nella chiamata della funzione, che può influire sulla latenza