Il Function as a Service (FaaS) ha contribuito ad arricchire il già farcito lessico del cloud computing, soprattutto quale modello alternativo rispetto al Platform as a Service (PaaS). Le piattaforme si collocano ad un livello di virtualizzazione intermedio tra l’infrastruttura e il software per l’utente finale. È il mondo degli sviluppatori, che devono scegliere come creare e gestire i microservizi su cui si basano le moderne applicazioni cloud native.
Vediamo dunque cosa si intende per Function as a Service, quali sono i suoi vantaggi, cosa lo differenzia appunto dal PaaS e perché il FaaS viene spesso e volentieri associato al crescente fenomeno del serverless, quando in realtà si tratta di argomenti IT ben distinti, che andremo ad esaminare nel dettaglio.
Cos’è il Function as a Service (Faas)?
Il Function as a Service, molto noto anche con il suo acronimo di FaaS, è un modello di cloud computing che consente di eseguire un’applicazione attivando una funzione quando si verifica un determinato evento, per cessarla immediatamente alla sua terminazione, in modo da non dover mantenere un’infrastruttura persistente.
La sua architettura di riferimento in cloud è costituita dal serverless computing, che consente il deploy dei microservizi in container stateless. Il FaaS è dunque un modello di esecuzione espressamente basato su eventi, ormai disponibile nel catalogo di offerta di tutti i principali cloud service provider, come alternativa al più diffuso PaaS (Platform-as-a-Service), che vede una presenza di servizi basati in prevalenza su applicazioni stateful, ossia in grado di mantenere una dipendenza dalle sessioni precedenti sulla base di una persistenza di dati.
Tra i Function as a Service attualmente più noti ritroviamo Amazon AWS Lambda, Microsoft Azure Functions (open source), Google Cloud Functions, IBM Cloud Functions, Oracle Cloud Fn e OpenFaaS (open source). L’interesse degli sviluppatori attorno a questa tecnologia è in continua crescita.
Oltre all’ampia disponibilità del cloud pubblico, il provisioning di un FaaS è possibile in un cloud privato oppure on-premise. Potrebbe apparire un po’ un controsenso ricorrere ad un’architettura serverless ed implementarla in locale, dovendo farsi carico del mantenimento di un intero data center. Qualcuno potrebbe chiedersi perché semplificare la vita ai dev complicandola agli admin di sistema? In realtà, anche nella condizione on-premise, il serverless offre numerosi vantaggi, in quanto consente di ottimizzare al massimo i consumi in termini di risorse, migliorando l’efficienza in termini di esecuzione di più carichi di lavoro.
Non ci stancheremo mai di ricordare come una strategia IT in grado di creare davvero valore aggiunto sia il risultato di un’ampia serie di considerazioni, in cui i cloud architect ed altre figure specialistiche in ambito cloud si occupano di analizzare ogni dettaglio dell’IT aziendale per individuare le soluzioni più consone al soddisfacimento degli obiettivi di business.
In questo contesto, il Function as a Service offre una validissima alternativa per applicazioni che prevedono carichi di lavoro con una frequenza relativa ridotta, breve nella durante, ma anche molto intensive per quanto concerne il volume di dati che entrano in gioco nel ciclo di vita di un determinato evento. È il caso della generazione di report e più in generale della data visualization, così come dei servizi IoT.
Come funziona il Function as a Service (FaaS)
Il modello Function as a Service permette agli sviluppatori di scrivere applicazioni in grado di essere eseguite come risposta ad un determinato evento, senza doversi preoccupare delle risorse hardware e software necessarie allo svolgimento di questa operazione, né alla conservazione dei dati di sessione, dal momento che la sua natura stateless non prevede questa eventualità. A meno che non rientri nel contesto di una pipeline ibrida in grado di combinare i punti di forza delle condizioni stateless e stateful. Ma questa è decisamente tutta un’altra storia.
Ma cosa si intende, come avremo sentito ormai centinaia di volte, quando si parla del FaaS come un modello di esecuzione basato su eventi? Focalizzare il concetto risulta piuttosto semplice se consideriamo la funzione come un’entità altamente scalabile ed effimera, capace di essere avviata e cessata in tempi brevi, senza dipendere da servizi in background, a differenza di quanto avviene nel caso del PaaS, dove gli sviluppatori o i sistemisti devono predisporre e allocare le risorse persistenti necessarie per eseguire correttamente i carichi di lavoro delle applicazioni.
Anche in questo caso, dobbiamo tenere in considerazione che le applicazioni basate su architettura a microservizi sono composte da molti elementi, che possono facilmente prevedere una condizione eterogenea di funzioni e servizi a lunga esecuzione.
L’applicazione può funzionare soltanto se i suoi componenti sono in grado di comunicare in maniera efficiente tra loro, nonostante la loro natura sia fortemente disaccoppiata. Ciò avviene grazie alle API (Application Programming Interface), un insieme di definizioni e protocolli per la creazione e l’integrazione di un software.
A scanso di equivoci, è necessario precisare che negli ultimi tempi i confini tra PaaS e FaaS sono assai meno marcati rispetto alla definizione originale, in quanto le soluzioni PaaS stanno diventando sempre più complete, garantendo anche capacità elaborative tipicamente serverless. Vedremo più avanti di cosa si tratta.
Ancora una volta è opportuno sottolineare come il FaaS risulta un modello decisamente interessante quando si tratta di dover gestire transazioni con volumi di dati molto elevati nel contesto di eventi che potremmo definire brevi ma intensi.
Il funzionamento del Function as a Service si basa sulla scalabilità dinamica delle istanze in esecuzione. Le funzioni vengono avviate on demand dall’attivazione di un determinato evento e si avviano nell’ordine dei millesecondi, elaborando ogni singola richiesta. In presenza di più richieste on demand, il provider avvia più istanze funzionali per soddisfarle. La scalabilità interviene proprio nella capacità di gestire dinamicamente l’aumento e la diminuzione della domanda. Quando i carichi di lavoro da eseguire calano, il sistema automaticamente cessa le istanze non necessarie e consente pertanto di ottimizzare l’impiego di risorse.
Pur con modalità differenti rispetto al PaaS, il FaaS consente di realizzare applicazioni ibride, caratterizzate da componenti serverless e microservizi tradizionali, rispettivamente eseguiti su container stateless e stateful, avvalendosi di tecnologie di orchestrazione come Kubernetes, ivi compresa la sua variante per serverless: Knative.
Quali sono i vantaggi del Function as a Service
I principali vantaggi del modello Function as a Service possono essere sintetizzati come segue.
Pagare soltanto le risorse hardware e software che vengono utilizzate
Il FaaS consente un pricing model pay-per-use davvero tale, eliminando del tutto i tempi morti e l’inutilizzo delle risorse che sono invece richieste dalle applicazioni stateful, per cui i server vanno tenuti attivi anche quando i carichi di lavoro impegnano soltanto una parte delle risorse allocate.
Nel caso del Function as a Service questo non succede, in quanto le funzioni non richiedono risorse IT persistenti. Il gestore di risorse del cloud service provider è in grado di scalare automaticamente la disponibilità di hardware e software necessario, cessando del tutto tale allocazione una volta che la funzione viene cessata. In termini pratici, l’utente paga soltanto la disponibilità di risorse nel periodo in cui le funzioni sono attive. Quando non ci sono carichi di lavoro in esecuzione, non si spende nulla.
Il FaaS è dunque a tutti gli effetti “cost effective” e risulta perfetto in almeno due circostanze: nel caso di carichi di lavoro dinamici e task programmati, oppure quando si tratta di avere il maggior controllo dei costi possibile nel caso di scenari che prevedono carichi di lavoro molto intensi.
Semplificazione gestione IT: automazione nella gestione dei carichi di lavoro
I provider FaaS sono in grado di scalare automaticamente le risorse necessarie per l’esecuzione delle applicazioni stateless, aumentandole o diminuendole in funzione della domanda proveniente dai carichi di lavoro. Per l’utente finale questo processo è assolutamente trasparente, in quanto non deve configurare o gestire assolutamente nulla.
A questi aspetti specifici, si aggiungono ovviamente i vantaggi generici del cloud computing in fatto di semplificazione nella gestione degli aspetti IT.
Appare evidente come i team di sviluppo non debbano preoccuparsi troppo della continuità di business per quanto riguarda i servizi erogati dall’azienda, in quanto ciò che occorre per soddisfarla rientra negli oneri in capo alle attività del cloud service provider, opportunamente precisati nelle SLA (service level agreement) dei contratti di fornitura.
Attenzione sul codice, non sull’infrastruttura IT
Nel caso del Function as a Service, gli sviluppatori possono letteralmente dimenticarsi di dover gestire o configurare le risorse IT necessarie per eseguire le loro applicazioni e concentrarsi esclusivamente su ciò che sanno e devono fare meglio: programmare il software.
Tale logica agevola soprattutto l’attività dei full stack developer, che possono gestire end-to-end lo sviluppo di un’applicazione riducendo, se non annullando del tutto, la dipendenza dai sistemisti. Il fatto di concentrarsi soltanto sulla programmazione migliora la qualità del lavoro dei team di sviluppo, il che si traduce molto spesso nella sensibile riduzione del time to market delle applicazioni.
Le possibili criticità del Function as a Service
Sarebbe forse eccessivo parlare di svantaggi, in quanto una consapevole gestione dei servizi in cloud consente proprio di evitare situazioni penalizzanti, ma non possiamo ovviamente non considerare le possibili criticità a cui si va incontro nell’ambito del Function as a Service. In alcuni casi specifici, i tradizionali punti di forza del FaaS potrebbero rivelarsi un potenziale boomerang.
Un possibile limite è dato dalla scarsa visibilità nei confronti dell’infrastruttura di back-end, dal momento che questa viene interamente gestita in remoto da parte del cloud service provider. E qui ritorniamo, per certi versi, anche al discorso intrapreso quando parlavamo dell’opportunità di gestire un serverless on-premise.
Appare evidente come nella maggior parte dei casi, il problema non sussista. Tuttavia, certe condizioni specifiche, che richiedono il massimo controllo sull’infrastruttura, faticherebbero ad usufruire di un FaaS in cloud pubblico, mentre potrebbero rilevare dei vantaggi nella configurazione di un modello ibrido.
Allo stesso modo, il modello pay-per-use duro e puro del FaaS potrebbe complicare la vita a chi deve prevedere i budget. Anche se tendenzialmente si tratta di un modello conveniente, nel senso che ottimizza al massimo il costo in funzione delle risorse effettivamente utilizzate, il Function as a Service potrebbe apparire ostico quando si tratta di stimare un budget complessivo.
Mentre un PaaS, anche a rischio di sovrastimare, consente di derivare facilmente un budget dalle condizioni previste a listino, il FaaS rende complessa la determinazione di un ammontare di spesa, soprattutto quando si affronta tale eventualità per la prima volta, non avendo dunque dati precedenti su cui basarsi.
FaaS vs Serverless
Function as a Service e serverless sono stati a lungo considerati dei sinonimi. Essendovi molte analogie concettuali, gergalmente potremmo tranquillamente accettare questa situazione, ma in realtà ciò non è in alcun modo corretto.
Il FaaS rappresenta infatti una condizione più ristretta rispetto al serverless, che si riferisce praticamente a tutte le categorie di servizi disponibili in ambito IT: elaborazione, memoria, storage, database, messaggistica, applicazioni, API gateway e molti altri aspetti aventi quale denominatore comune la user experience. A prescindere dal servizio, l’utente finale viene del tutto esonerato dalla configurazione, dalla gestione e dalla contabilizzazione delle risorse IT.
Il Function as a Service non si si focalizza soprattutto sulla metodologia, fondata sul paradigma funzionale dell’event-driven computing, che a livello IT si basa soprattutto sugli aspetti serverless legati alle applicazioni. Di qui l’inequivocabile punto di contatto tra FaaS e serverless, che ha portato ad accomunarli ben oltre le loro caratteristiche distintive.
Il FaaS rimane una modalità di implementazione dell’elaborazione serverless, con ogni probabilità la più nota e diffusa, e come tale andrebbe sempre considerata. Ad onor del vero, va comunque precisato che tale sovrapposizione è in un certo senso giustificata dal fatto che soltanto di recente il serverless ha assunto un significato più ampio nei confronti dell’intero immaginario di servizi IT, mentre in origine era più vicino alla condizione esplicitata dal Function as a Service.
Come già precisato, il termine serverless viene oggi impiegato anche quando si tratta di descrivere alcuni servizi gestiti, come i database o i sistemi di messaggistica, che non prevedono nello specifico l’intervento di uno sviluppatore o di un sistemista, in quanto le loro operazioni sono assolte a monte dal provider. Ma ciò non ha niente a che vedere con il Function as a Service.
FaaS vs PaaS
Abbiamo rilevato in più circostanze come FaaS e PaaS costituiscano modelli a servizi alternativi nell’ambito dello sviluppo delle applicazioni. Il titolo del presente paragrafo non è orientato a capire quale sia la soluzione migliore. Non esiste una soluzione migliore a priori. Occorre conoscere le caratteristiche di ognuna per saperle sfruttare a proprio vantaggio nel soddisfare gli obiettivi di business nel rispetto dei tempi e dei costi previsti dai vari progetti di sviluppo.
In altri termini, FaaS, PaaS, container, macchine virtuali e tutte le tecnologie deputate alla loro gestione e orchestrazione rientrano sotto un unico cappello, fatto di opportunità tecnologiche da sfruttare per soddisfare gli obiettivi IT. L’aspetto più interessante è che se ci mettessimo nei panni dell’utente finale, proprio grazie al concetto serverless, tutti questi aspetti non dovrebbero nemmeno interessarci. Noi dovremmo essere in grado di pensare soltanto al codice e alle applicazioni che dobbiamo sviluppare.
Se il nostro obiettivo fosse invece quello di garantire agli sviluppatori le condizioni che consentano loro di essere a tutti gli effetti serverless, potremmo fare riferimento al Function as a Service attraverso queste caratteristiche distintive.
Tempo di provisioning del Function as a Service
Nel caso del FaaS, parliamo di millisecondi, nel caso del PaaS occorre configurare container e VM, per cui si parla di diversi minuti, se non addirittura di ore.
Amministrazione di sistema
Nel caso del Function as a Service l’amministrazione di sistema risulta praticamente irrilevante, come se non ci fosse. Nel caso del PaaS le risorse IT vanno preventivamente allocate e gestite in corso d’opera per soddisfare le richieste dei carichi di lavoro. Anche se la condizione viene semplificata rispetto al contesto on-premise, occorre comunque un certo lavoro da parte dei sistemisti e degli amministratori di sistema.
Flessibilità e scalabilità del Function as a Service
Nel caso del FaaS, ogni azione viene automaticamente e immediatamente scalata dal provider, senza che sia necessario alcun intervento da parte dell’utilizzatore finale. Nel caso del PaaS sussiste ovviamente un maggior controllo, ma anche una maggior complessità ed il conseguente impegno nella configurazione le condizioni che rendono scalabile un servizio in funzione della domanda proveniente dai carichi di lavoro. Il livello di automatizzazione e self-provisioning dei moderni PaaS è senza dubbio eccellente, ma rimane distante dall’auto-provisioning del Function as a Service.
Pianificazione e programmazione
Tali aspetti riflettono esattamente quanto espresso in funzione della scalabilità. Nel caso del FaaS, non è necessaria una pianificazione di risorse IT a monte dell’avvio dei carichi di lavoro. Nel caso del PaaS è invece essenziale definire almeno dei parametri di massima, che possono essere successivamente gestiti a scalati di conseguenza. Occorre quindi un certo impegno nella pianificazione delle risorse da allocare, anche in previsione della possibile evoluzione del business, che può prevedere momenti di maggior successo alternati a momenti di particolare recessione.
Stato e persistenza delle risorse
Nel caso del Function as a Service, la natura stateless delle funzioni non prevede l’esigenza di dati persistenti, in quanto una sessione non dipende da una sessione precedente. Logicamente opposta la natura stateful che caratteristica la maggior parte dei servizi del PaaS, per cui va prevista una disponibilità di risorse, in particolare per quanto concerne i dati che consentono la conservazione dello stato attraverso l’esecuzione di più sessioni.
High availability (HA) e disaster recovery (DR)
La continuità di business ha assunto una rilevanza fondamentale nelle attività IT di un’azienda, in quanto da essa dipende la corretta erogazione dei servizi ai propri clienti. Nel caso del FaaS, non ci sono particolari considerazioni da fare, nemmeno in termini di effort e costi necessari per garantire livelli di tolleranza compatibili con le applicazioni. Tutti questi aspetti sono gestiti in automatico dal provider Function as a Service secondo le condizioni previste dal contratto di fornitura (SLA).
Nel caso del PaaS il discorso diventa più vario nel senso che la gestione di alcuni aspetti tecnologici, come i container e le macchine virtuali, rimane in capo all’utente finale. Ciò potrebbe comportare un dispendio extra di tempi e costi, relativi alla configurazione di tutte le impostazioni necessarie, ad esempio per quanto concerne le attività di riavvio automatico delle istanze e dei processi in caso di failure dell’applicazione eseguita.
Utilizzo delle risorse IT nel Function as a Service
Nel caso del FaaS non ci sono mai risorse inutilizzate, in quanto al cessare di una funzione, vengono disallocate anche le relative condizioni hardware e software necessarie per eseguirla. Nel caso del PaaS, si assiste ad una allocazione di risorse IT che non scala in automatico per soddisfare la variazione dei carichi di lavoro. Occorre quindi un maggior impegno nel monitoraggio e nella gestione, per evitare di sprecare o rimanere a corto di risorse.
Nel caso del Function as a Service occorre invece fare attenzione ad altri aspetti, relativi alla natura stessa dell’applicazione, che deve risultare funzionale ad un contesto event-driven. Non avrebbe alcun senso sviluppare un’applicazione con tempi di esecuzione lunghi con un approccio di tipo stateless. Comporterebbe un elevato dispendio di risorse, molto probabilmente penalizzante rispetto ad un’alternativa in PaaS.
Mantenimento delle risorse IT
Il mantenimento delle risorse IT è generalmente in capo al cloud service provider sia che si tratti di un FaaS che un PaaS. Non si tratta di un aspetto di poco conto, dal momento che container e VM richiedono moltissima manutenzione affinché tutte le applicazioni possano essere stabili e sicure nel loro impiego. La differenza fondamentale, in questo caso, è nella scelta tra un servizio in cloud computing oppure una tradizionale implementazione on-premise. Nel secondo caso, tutti gli oneri di gestione e manutenzione IT rimangono in capo all’azienda. Tale condizione risulta preferibile nei contesti in cui è necessario il maggior controllo possibile sui back-end delle risorse impiegate.
Quando optare per soluzioni Function as a Service
L’ambito privilegiato del FaaS coincide con l’esecuzione di applicazioni event-driven, caratterizzate da breve durata e grande intensità per quanto concerne il volume di dati coinvolto. Il FaaS risulta quindi poco consigliabile quando si tratta di applicazioni costantemente operative, in cui non c’è dinamismo di eventi.
A titolo esemplificativo, il Function as a Service potrebbe dunque costituire una scelta riuscita quando si tratta di creare sistemi di backend per attività di data processing, conversione di formati, encoding, data aggregation, data visualization e in generale quelle applicazioni che prevedono carichi di lavoro intensi ma condizionati da un evento specifico. Una volta cassata un’esigenza di codifica, non avrebbe senso mantenere attiva l’applicazione, che andrebbe cessata per non sprecare inutilmente risorse allocabili per eseguire altre funzioni.
La natura event-driven di una funzione rende il FaaS particolarmente indicato anche per l’esecuzione di web app, applicazioni di streaming, chatbot e back-end di sistemi IoT. Un impiego frequente è inoltre costituito dalla gestione dei servizi di terze parti, come la connessione di una web app da remoto ad un servizio in cloud. Rispetto ad una connessione permanente, l’approccio event-driven, che consente alla app di connettersi solo quando strettamente necessario, potrebbe tradursi in un significativo risparmio di risorse.
A prescindere da ciò, risulta essenziale comprendere alcuni principi chiave dello sviluppo di un’applicazione da eseguire in FaaS. Un errore concettuale potrebbe vanificare qualsiasi sforzo di ottimizzazione o risultare persino controproducente.
Il Function as a Service prevede alcune best practice che possono facilitare in maniera sostanziale la sua implementazione e il suo impiego di lungo corso. Tali aspetti non sono rivolti nello specifico all’infrastruttura, ma soprattutto al modo con cui si sviluppa una determinata applicazione.
Un criterio universalmente valido ed eternamente consigliato equivale a prevedere, per ogni funzione, una sola e specifica azione. Le funzioni dovrebbero essere infatti progettate per rispondere ad un determinato evento. Quindi codice leggero e snello quanto basta per caricare ed eseguire le applicazioni nel modo più veloce possibile, ai fini di ottimizzare l’impiego delle risorse.
Un altro aspetto consigliabile quando si sviluppano applicazioni event-driven è quello di cercare di evitare che una funzione richiami un’altra funzione. Il FaaS si distingue proprio per il fatto che le sue funzioni sono fortemente isolate. Tale condizione corrisponde alla maggior efficienza del servizio. Non avrebbe quindi senso snaturare questo aspetto, in quanto verrebbe certamente meno la convenienza del FaaS rispetto ad altri modelli, che sono invece concepiti proprio per connettere stabilmente più funzioni dello stesso applicativo.
I possibili consigli in merito allo sviluppo software per il Function as a Service sono moltissimi, per cui ci limitiamo ad aggiungere ancora uno ed uno soltanto, a nostro avviso essenziale, sosia il fatto di cercare di utilizzare meno librerie possibili, in quanto abusare di tale condizione potrebbe rallentare l’esecuzione delle funzioni e renderle più difficili da scalare, aumentando genericamente il dispendio di risorse. Anche in questo caso, qualora si rendesse necessario utilizzare molte librerie, sarebbe preferibile utilizzare altri modelli anziché il FaaS.
