Menu
Menu
Contattaci
Il nostro settore richiede uno studio continuo e una forte attenzione all’innovazione. Incentiviamo quindi dei programmi formativi annuali per tutti i componenti del team, con ore dedicate (durante l’orario di lavoro) e serate formative sia online che in presenza. Sponsorizziamo eventi, sia come partner che semplicemente come partecipanti, e scriviamo articoli su quello che abbiamo imparato per essere, a nostra volta, dei divulgatori.
Vai alla sezione Team“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.
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.
Il significato letterale, ovvero “senza alcun server” (niente di sconvolgente).
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.
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.
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:
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.
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).
“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.
Iniziamo con la demolizione:
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:
È 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:
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?
Segui Giuneco sui social