In questo articolo daremo uno sguardo al mondo serverless per capire di cosa si tratta e quali sono i principali vantaggi /svantaggi, oltre l’hype.
Serverless assume diversi significati per diverse persone.
In ogni caso possiamo concordare che in un modello di questo tipo:
- paghiamo solo per quello che effettivamente utilizziamo (specialmente l’utente);
- la gestione della ridondanza e della multi AZ (zone di disponibilità) è built-in;
- la gestione dello scaling è gestita dal provider;
- auto-gestione e auto-provisioning dei server/containers.
In altre parole, non paghiamo per l’inattività e gli sviluppatori non devono più pensare all’infrastruttura sottostante (server/containers).
Ovviamente serverless continua ad avere server/container, ma il punto cruciale è che non ne abbiamo visibilità, quindi per noi utilizzatori e come se non esistessero.
Come Gojko Adzic ha scritto in un suo articolo “It is serverless the same way WiFi is wireless” ovvero “serverless è senza server come il WiFi è senza cavi”.
Serverless o FaaS?
Il termine serverless venne pubblicizzato da AWS intorno al 2014/2015 con il rilascio dei servizi AWS Lambda e API Gateway.
AWS Lambda è l’esempio perfetto di un modello FaaS (Function as a Service) serverless. Mentre API Gateway è un servizio puramente serverless.
In FaaS, lo sviluppatore si focalizza nel scrivere codice (funzioni) con lo scopo di risolvere i problemi di business senza la necessità di pensare a come questo codice verrà poi eseguito e scalato. In questo modello, la funzione è l’ultimo layer di astrazione, è come prendere un microservizio e spezzarlo in piccole unità logiche.
Sempre con questo modello possiamo continuare ad avere un’infrastruttura da gestire. Ad esempio possiamo usare un framework sopra ad un cluster Kubernetes come: OpenFaas (https://www.openfaas.com/), Kubeless (https://kubeless.io/), Knative (https://knative.dev/), etc.
Combinando i modelli serverless e FaaS, ottimizziamo i costi e la scalabilità e concentriamo lo sviluppo nell’implementare le logiche di business. Inoltre facciamo felici i clienti, i manager e gli sviluppatori.
Limiti e considerazioni
Anche serverless e FaaS hanno dei limiti e delle problematiche con cui confrontarsi. Purtroppo, ora come ora, non abbiamo ancora trovato la cosiddetta “silver bullet” che ci risolve tutti i problemi senza compromessi.
Sistemi distribuiti
Queste tipologie di modelli ereditano la maggior parte dei limiti di un qualsiasi sistema distribuito, ad esempio: la gestione della comunicazione sincrona/asincrona tra più servizi e la gestione degli stati di essi.
Da non sottovalutare l’applicazione di pattern e approcci architetturali appositi in base alla complessità del progetto in questione. Ad esempio approcci come Event Driven, CQRS, Saga sono riconosciuti come best practices, ed applicati correttamente risolvono grossi problemi.
Analisi dei costi in un contesto serverless
Sappiamo che un modello FaaS serverless ci permette di risparmiare molto sui costi, ma eseguire un’analisi preventiva su questi può risultare complesso. Come prima cosa abbiamo bisogno di pensare a quante funzioni verranno invocate durante l’arco di un mese. Successivamente dobbiamo stimarne la durata media di esecuzione e la memoria che verrà allocata. Infine possiamo affidarci ad uno dei calcolatori online del nostro Cloud Provider, inserire i dati e ricevere in output il prezzo stimato mensile. Un aspetto sicuramente da considerare è il free tier che viene messo a disposizione dai diversi provider che solitamente si aggira intorno al milione di invocazioni gratuite. Questo permette di creare un ambiente di sviluppo a costo zero.
Cold start
FaaS ci introduce il concetto di cold start, ovvero il tempo in cui il provider si occupa di preparare ed inizializzare il container nel quale verrà eseguita la nostra funzione. È un tempo che non è sotto il nostro controllo. Una volta che la funzione è stata invocata, quest’ultima non viene immediatamente terminata, ma rimane attiva per un breve periodo definito dal provider stesso, si dice quindi che la funzione è hot. Questo permette la re-invocazione della funzione in un momento successivo, senza la necessità di ri-eseguire il cold start. Ovviamente ad ogni esecuzione parallela, corrisponde una funzione nuova, in quanto una funzione può gestire una sola richiesta alla volta. Nel caso in cui vengano richieste cento invocazioni in uno stesso istante, cento funzioni diverse verranno eseguite di conseguenza.
Vendor lock-in
A questo punto, vista la presenza ricorrente del provider, vi starete chiedendo quali sono gli effetti del vendor lock-in che serverless ci sta provocando. Possiamo dire che il vendor lock-in è sempre stata una tematica molto discussa, ma siamo sicuri che sia veramente un problema?
La risposta è dipende dalle necessità di business: preferiamo avere un TTM (Time To Market) ridotto, o una soluzione vendor agnostic con un TTM di gran lunga più elevato?
I vendor lock-in sono ovunque: dal linguaggio di programmazione utilizzato ad uno specifico framework e/o libreria di terze parti.
Nell’ambito FaaS serverless possiamo applicare dei compromessi che ci consentono di agevolare l’eventuale migrazione a diversi provider. Ad esempio possiamo usare il framework “serverless” (https://serverless.com/). Questo ci consente di unificare la configurazione delle risorse e dei deploy, coprendo diversi provider.
Un’altra cosa che possiamo fare è scrivere del codice che ci consenta di agevolare l’eventuale cambio di provider e/o di servizi terzi. Per raggiungere tale scopo possiamo applicare i principi SOLID e seguire le buone pratiche di programmazione.
Conclusione
Serverless non è l’obiettivo finale.
Stiamo cercando di:
- testare nuove idee il prima possibile;
- applicare un continui miglioramenti;
- rilasciare velocemente;
- avere meno tecnologia da controllare;
- concentrarsi nel creare valore di business.
Serverless ora come ora è il migliore adattamento a queste richieste.
Le tecnologie serverless stanno continuando a maturare, e ogni mese nuove funzionalità vengono aggiunte dai diversi provider. Ad esempio da poco AWS Lambda ha introdotto un’opzione che consente di mantenere un numero prestabilito di funzioni hot. Ciò permette di ridurre al minimo i cold start. È un mondo in continua evoluzione.
