Serverless

“No server is easier to manage than no server”
“Nessun server è più facile da mantenere che nessun server”
Werner Vogels, CTO di Amazon, alla presentazione di AWS

Attualmente, chiunque lavori nel mondo dell’informatica avrà sicuramente sentito la parola “Serverless” almeno una volta (a meno che non viva rinchiuso in uno scantinato in solitudine, ma avrei qualche dubbio anche in quel caso).

Se inizialmente si può cedere alla tentazione di ignorare il termine, pensando sia l’ultima trovata di qualche gruppo studentesco americano lontano dai problemi reali dello sviluppo software, la presenza costante in articoli autorevoli (Martin Fowler gli ha dedicato un articolo che si fa fatica a “scrollare” fino in fondo data la mole) e le conferenze sul tema che fanno il giro del mondo, ci costringono a fare il contrario e considerare la vera portata della parola “Serverless”. E per fortuna, perchè in questo caso il mondo informatico, per l’ennesima volta, ha fatto quel fantomatico “passo in avanti” e ci sta dando la possibilità di salire sul treno dell’avanguardia informatica, che pare possedere la giusta forza trainante per sviluppi futuri.

Una volta appurato che ignorare questo tema non è un’opzione in gioco, a meno che non si desideri restare ancorati ad un passato ormai superato, dedichiamo le nostre energie alla conoscenza di Serverless.

Cosa significa Serverless?

ll primo scoglio nel quale ci imbattiamo è esattamente la definizione, dato che non si tratta di un nome proprio di un Framework, nè rappresenta una singola tecnologia.

Con l’obiettivo di raggiungere una definizione più accurata possibile, ricorriamo alla tricotomia della semiotica interpretativa per esplorare il significato che può assumere questa parola.

Intentio operis

Il significato letterale, ovvero “senza alcun server” (niente di sconvolgente).

Intentio auctoris

Diamo per comodità la paternità della parola a Mike Roberts (anche se non siamo certi che sia stato lui a coniarla), che ha dato per primo una definizione superpartes rispetto alle implementazioni specifiche, ed è alla base di sviluppi successivi. Le definizioni di Mike Roberts in realtà sono due, perchè la prima è stata mutata/smorzata con il tempo, e sono (in ordine temporale): 
– Nella mia applicazione non uso codice lato server, la mia applicazione si basa solo su codice di terze parti per il server.
– Ci può anche essere del codice fatto da me, l’importante è che questo codice non risieda su un server come tutti noi lo conosciamo, ma risieda su qualcosa dato da un qualsiasi vendor, che venga scatenato da eventi e che soprattutto sia effimero.

Queste definizioni (la seconda in special modo) ci offrono molte informazioni in più per capire, da un punto di vista pratico, il da farsi. Intanto abbiamo scongiurato il rischio di dover creare applicazioni web con “pacchettate” di JavaScript e, in secondo luogo, apprendiamo tra le righe che non è necessario che non esista un server; piuttosto nell’approccio tradizionale è sbagliata la sua “posizione” (questo punto sarà più chiaro andando avanti con la lettura). Per ultimo, ma non meno importante, introduciamo la parola chiave “effimero”, che avrà un ruolo centrale per capire come “il Serveless” si sia sviluppato fino ad oggi.

Intentio lectoris

Questa è l’accezione più significativa, in cui ricadono tutte le questioni pratiche sostenute dalla community e dalle elite informatiche nel tempo e che hanno donato gli strumenti veri e propri a disposizione degli sviluppatori. Secondo questa lettura, il serverless è l’utilizzo di uno o più strumenti rivolti ad esso. Più strumenti serverless utilizziamo, più si è serverless e di conseguenza essere serverless non è uno stato binario (non vale la dicotomia “essere serverless – non essere serverless”), ma una posizione locata su un continuum.

Nel concreto… cosa è stato fatto?

Osserviamo adesso quali sono le principali strade a disposizione degli sviluppatori, con i relativi vantaggi e svantaggi. Iniziamo con la suddivisione delle due maggiori aree di interesse:

Backend as a service (BAAS)

L’applicazione di qualcuno si basa sul backend di qualcun altro (cosa che si adatta molto bene alla prima definizione di Serverless data da Mike Roberts). Ne esistono moltissime implementazioni; due esempi, presumibilmente conosciuti da tutti, sono Google e Facebook, che mettono a disposizione degli sviluppatori la loro login social, che non è altro che un API che permette di gestire utenti senza possedere un’infrastruttura di accesso. Essa è gestita completamente da questi fornitori di servizi i quali offrono la garanzia che l’utente, qualora superi la login di accesso, sia effettivamente loggato nel modo corretto. Questi sono generalmente rich client applications come single page web application o applicazioni mobile.

Questo esempio non introduce niente di clamorosamente nuovo, già da anni esistono queste possibilità, ed il loro utilizzo è di uso comune sia nello sviluppo che lato consumer.

Function as a service (FAAS)

Qui troviamo il fulcro del tema “serverless”. La definizione può essere riassunta banalmente in “noi scriviamo codice e lo mettiamo in una funzione richiamabile tramite eventi, la cui infrastruttura (compresa inizializzazione, gestione memoria, allocamento di risorse, etc.) è definita da un ente terzo e non dobbiamo pensare ad altro che invocarla“.

Le principali implementazioni ci vengono fornite da Microsoft e Amazon, che hanno sviluppato, indipendentemente l’una dall’altra, due piattaforme proprietarie chiamate rispettivamente Azure Functions e Aws Lambda. Si preoccupano, appunto, di incapsulare la logica delle funzioni, farle risiedere sui loro server e dare la possibilità di richiamarla tramite un paradigma event-based. 

L’approccio ad eventi è particolarmente interessante ed efficace perché dà la possibilità di richiamare la funzione dal codice di un altro nostro programma, ma possiamo anche lanciare eventi in altre decine di modi, ad esempio dopo l’aggiornamento di una riga nel database, all’upload di un file su filesystem, all’arrivo di un messaggio in un enterprise service bus, etc. (per fare questo è però necessario sposare “in toto” anche le relative tecnologie possedute dai due colossi, con, ovviamente, i vantaggi e gli svantaggi derivati).

Considerazioni su Baas e Faas

“Non avremo mai informazioni su dove stiamo eseguendo il nostro codice, il nostro codice può essere eseguito in una server farm di cui però non conosciamo il sistema operativo, non conosciamo se è un server, un container, un cellulare.”

Di fronte alla definizione di Baas e Faas, conoscendo i primi in quanto di uso comune anche prima di saperne il nome, mi sono posto le più banali delle domande: Me ne faccio realmente qualcosa? Perché dovrei utilizzarle?

Paradossalmente la tecnologia più vecchia e che già conoscevo è quella che per prima mi ha fatto dire: “Sì! Col suo utilizzo scriverò meno codice, utilizzerò componenti già ben consolidati, facendo di conseguenza meno fatica“

Il concetto di Faas non ha suscitato in me la medesima reazione di approvazione, non vedendo una semplificazione e diminuzione drastica nei tempi di sviluppo. Faas infatti, per certi aspetti, complica lo sviluppo, rispetto ad esempio ad un approccio semplicemente “di buon senso”, derivato dall’utilizzo di design pattern o il rispetto dei principi SOLID.

Vantaggi e Svantaggi nell’utilizzo delle Faas

Iniziamo con la demolizione:

1. Le funzioni di FaaS possiedono, generalmente, un limitato tempo di esecuzione. Ciò significa che alcune classi di attività a lungo termine non sono adatte alle funzioni FaaS senza re-architettura: potrebbe essere necessario creare diverse funzioni coordinate tra di loro, mentre in un ambiente tradizionale è possibile avere un’attività di lunga durata che esegue sia il coordinamento che l’esecuzione.
2. Controllo del fornitore. Con qualsiasi strategia di outsourcing si rinuncia al controllo di alcuni dei propri sistemi a favore di un fornitore di terze parti.  Tale mancanza di controllo può manifestarsi come tempi di inattività del sistema, limiti imprevisti, variazioni dei costi, perdita di funzionalità, aggiornamenti forzati dell’API e altro.
3. Blocco del fornitore.  È molto probabile che qualsiasi caratteristica Serverless che sia utilizzata da un fornitore venga implementata in modo diverso da un altro fornitore.  Se si desidera cambiare fornitore è quasi certamente necessario aggiornare gli strumenti operativi (implementazione, monitoraggio, ecc.). Probabilmente sarà necessario modificare il codice (ad es. Per soddisfare una diversa interfaccia FaaS) e potrebbe persino rendersi indispensabili di progettazione o architettura se ci sono differenze nel modo in cui si comportano le implementazioni dei fornitori concorrenti.
4. Le funzioni FaaS hanno restrizioni significative quando si tratta di dati locali (machine / instance-bound), cioè dati archiviati in variabili in memoria o dati che si scrivono sul disco locale.  Si dispone di tale spazio di archiviazione disponibile, ma non si ha alcuna garanzia che tale stato sia mantenuto in più invocazioni e, a maggior ragione, non si dovrebbe presupporre che lo stato di una chiamata di una funzione sia disponibile per un’altra chiamata della stessa.  Qualsiasi stato di una funzione FaaS deve essere esternalizzato al di fuori dell’istanza della funzione. Le funzioni di questo tipo generalmente fanno utilizzo di una cache di applicazioni diverse (come Redis) o un archivio di file/oggetti di rete (come S3) per memorizzare lo stato tra le richieste o fornire ulteriori input necessari per gestire una richiesta.
5. Latenza di avvio: questo è un punto molto interessante. Ci vuole del tempo prima che una piattaforma FaaS inizializzi un’istanza di una funzione a seguito di un evento.  Questa latenza di avvio può variare in modo significativo, anche per una funzione specifica, in base a un gran numero di fattori e può variare da pochi millisecondi a diversi secondi. Nel caso specifico di Aws Lambda (ma lo stesso principio esiste anche nelle Azure Functions) l‘inizializzazione potrà essere o un “avvio a caldo” (warm start) oppure un “avvio a freddo” (cold start), il primo utilizza un’istanza di una funzione, la sua infrastruttura e tutta una serie di componenti, riciclata da una invocazione precedente, il secondo crea una nuova istanza del contenitore, avvia il processo host della funzione, etc.  Non sorprende che, quando si considera la latenza di avvio, sono questi avvii a freddo che destano maggiore preoccupazione.
   La durata dell’avvio freddo dipende da molte variabili e solo alcune sono sotto il controllo dello sviluppatore. Ad esempio fanno la differenza aspetti come: linguaggio utilizzato, numero di librerie usate, quantità di codice, eventuali collegamenti alle risorse VPC, etc.
   Altrettanto variabile, oltre allla durata di avvio a freddo, è la frequenza di avvio a freddo. Amazon ritira le istanze Lambda inattive dopo pochi minuti quindi se si hanno ad esempio 500 eventi al minuto vedremo molto raramente un avvio freddo. Se, d’altra parte, si elabora un evento una volta all’ora, probabilmente si noterà un avvio a freddo per ogni evento. Sapere questo ci aiuta a capire se gli avviamenti a freddo ci influenzeranno significativamente e se si potrebbe voler eseguire “keep alive” delle istanze di funzione per evitare che vengano “killate”. Detto questo, gli avvii a freddo rendono le applicazioni che necessitano di bassa latenza difficilmente conciliabili con questa limitazione che i sistemi Faas attualmente impongono.

Dopo questa importante lista di fattori negativi, sembra difficile proporre argomentazioni a favore del contrario, ed infatti la lista dei vantaggi maggiori e determinanti non è una vera e propria lista, anzi, è un unico, singolo punto:

Costa molto meno: molto perché un server noi lo paghiamo di giorno, di notte, durante le pause pranzo, durante le vacanze, lo paghiamo sempre. Avendo inoltre carichi di lavoro molto differenti in base a tantissimi fattori, siamo costretti a dimensionare i nostri server basandoci sui picchi di carico maggiori ed avere risorse inutilizzate il resto del tempo. Con queste tecnologie serverless invece paghiamo esattamente quello che usiamo, non un euro in più. Non dimentichiamoci che, come detto precedentemente, Serverless è, nella sua massima semplicità, una soluzione di outsourcing e questo ci consente di pagare qualcuno per gestire server, database e persino logiche applicative che altrimenti dovresti gestire da solo.

Inoltre, dato che stiamo utilizzando un servizio predefinito che verrà utilizzato anche da molte altre persone, vediamo un effetto di Economia di scala: paghiamo meno per il database, ad esempio, perché un fornitore sta eseguendo migliaia di database molto simili ed inoltre si ottiene una diminuzione del costo del lavoro, essendo in grado di dedicare meno tempo a un sistema Serverless esternalizzato rispetto a uno equivalente sviluppato e ospitato in proprio. Per rendere l’idea del tipo di risparmio osserviamo la tariffazione di Aws Lambda, che applica 3 piani fondamentali:

1. GRATUITO: fino ad un limite di 1.000.000 di richieste e 400.000 GB/secondo di elaborazione.
2. RICHIESTE: 1.000.000 di richieste gratuite e successivamente 0,2 USD per milione di richieste.
3. ELABORAZIONE: 400.000 GB/secondo di elaborazione gratuito e successivamente 0,0000166667 USD per ogni GB/secondo ulteriore.

È incredibile quanto adesso non risulti più una scelta folle passare a serverless vero? 🙂 Con questo fondamentale vantaggio sta infatti riuscendo ad imporsi sul mercato.

Anche se abbiamo magnificato la variabile correlata all’economicità, è comunque riduttivo parlare di singolo lato positivo. Infatti, riflettendoci, individuiamo almeno altri 3 vantaggi, più o meno diretti, che facilitano l’adesione a questo approccio:

1. L’ottimizzazione è la base di alcuni risparmi. C’è un aspetto molto interessante da menzionare sui costi FaaS: qualsiasi ottimizzazione delle prestazioni che apporti al tuo codice, non solo aumenterà la velocità del tuo software, ma avrà un collegamento diretto e immediato alla riduzione dei costi operativi derivato dall’utilizzo di minori risorse.
2. Aiuta a scrivere codice atomico e ad avere una organizzazione dell’infrastruttura a microservizi: scrivere funzioni a sé stanti, dove non puoi fare affidamento a variabili globali o di istanza, aiuta a mantenere il single responsability principle, a disaccoppiare componenti e a utilizzare tecnologie eterogenee.
3. Una delle gioie di Serverless FaaS è che il ridimensionamento orizzontale è completamente automatico, elastico e gestito dal fornitore. Nel migliore dei casi, se il nostro processo di ridimensionamento è stato fino ad oggi manuale (nel caso, ad esempio, di uno sviluppatore che accede al server con l’intento di aggiungere istanze della sua applicazione) con FaaS potremo dimenticarcene felicemente e lasciare che il fornitore FaaS ridimensioni l’applicazione per noi. Allo stesso modo, dal momento che il ridimensionamento viene eseguito dal provider su ogni richiesta/evento, non è più necessario pensare alla domanda su quante richieste simultanee è possibile gestire prima di esaurire la memoria o vedere un impatto eccessivo sulle prestazioni.

Conclusione

Serverless è uno stile di architettura in cui affidiamo l’esecuzione del nostro codice (o della nostra logica) lato server ad un vendor.

Questo nella pratica si attua attraverso due tecniche: BaaS, in cui integriamo i servizi di applicazioni remote di terze parti direttamente nel frontend dei nostri software, e FaaS, che sposta il codice dei nostri server incapsulandolo in infrastrutture esterne che hanno come caratteristica principale l’essere effimere.

Dobbiamo essere consci che Serverless, a causa di alcune sue forti limitazioni, non è l’approccio corretto per ogni problema e che quindi non potrà, almeno per adesso, sostituire la nostra architettura in toto.

La positività riscontrata nella community informatica riguardo a queste tecnologie sta facendo sì che si trovino in rapida espansione sia dal punto di vista dell’utilizzo, sia delle evoluzioni e migliorie continue che le case di sviluppo stanno apportando costantemente per superare le attuali limitazioni.

Si prospetta quindi un futuro roseo per le tecnologie Serverless con strumenti sempre più evoluti ed ottimizzati.
Vi ho incuriosito abbastanza da approfondire l’argomento e valutare l’utilizzo di queste tecnologie?