Un’architettura di computing serverless permette agli sviluppatori di creare applicazioni senza pensare ai server sui quali gireranno. Si tratta, in altre parole, di uno strato di astrazione che consente di concentrarsi sullo sviluppo applicativo. Nel 2014, Amazon ha rilasciato AWS Lambda, un servizio che consente agli sviluppatori di creare funzioni cloud-based che girano su un parco preesistente di istanze gestite dal vendor. In seguito, AWS ha lanciato API Gateway, un servizio che permette anche a endpoint utilizzati dagli utenti finali (public endpoint) di richiamare funzioni Lambda via Http.
Il servizio AWS Lambda rientra fra le offerte di FaaS (Functions-as-a-Services) oggi disponibili, fra le quali si segnalano quelle di Microsoft, IBM e Google. Attualmente, AWS Lambda è la principale piattaforma per la creazione di architetture di serverless computing basate su microservizi. Tutte le architetture di elaborazione serverless presentano alcune caratteristiche chiave, che riassumiamo brevemente di seguito.
- Ridotta complessità. Con un’architettura di serverless computing diventa più semplice lanciare un gruppo di VM (Virtual machine) auto scaling (in grado di scalare da sole) dietro un load balancer (bilanciatore di carico). Si può più facilmente prolungare l’architettura applicativa in più regioni per permettere la ridondanza geografica. Gli sviluppatori possono concentrarsi completamente sulla scrittura del codice perché i server che invocano tali funzioni sono gestiti dai cloud provider.
- Scalabilità incorporata (built-in). Una delle maggiori difficoltà nella creazione di applicazioni web scale (che possono girare su tutto il web) è la configurazione dell’auto scaling per i server virtuali, in quanto va trovato l’equilibrio che permette all’architettura di espandersi, a fronte di picchi di traffico, e ridimensionarsi quando le richieste di accesso diminuiscono. Ma ciascuna applicazione tende a comportarsi in modo differente da un’altra. Scrivere le impostazioni che permettono di ottimizzare i costi e fornire le migliori prestazioni a ogni applicazione diventa così un compito tutt’altro che facile. Con l’elaborazione serverless anche questa attività viene delegata al provider. Il servizio Aws Lambda, ad esempio, viene eseguito su un parco gestito di istanze Elastic Compute Cloud (EC2).
- Eliminazione delle risorse inattive. Un altro vantaggio offerto dall’elaborazione serverless è che viene addebitato solo il tempo in cui le istanze eseguono il codice applicativo. Con i server tradizionali, invece, il cliente paga una tariffa oraria anche per l’esecuzione di istanze che sono lasciate inattive.
Le caratteristiche di un’architettura di serverless computing e il ruolo di Lambda
Esaminiamo una tipica applicazione web che utilizza l’architettura serverless di AWS.
- Livello front-end. Le risorse statiche che alimentano il front-end dell’applicazione web sono ospitate in Amazon Simple Storage Service (S3), il servizio di object storage di AWS. È possibile utilizzare S3 per trasformare un bucket (letteralmente: secchio; una risorsa in cui sono memorizzati oggetti), che è solo una cartella, in un sito web statico. In questa posizione è possibile memorizzare contenuti statici in Html, Javascript, file Css e immagini. In questa architettura abbiamo, in pratica, un sito web statico serverless con un framework Javascript che viene scaricato sul client dell’utente. Questo framework è in grado di chiedere a Lambda di fornire il back-end all’applicazione.
- Livello API. In questo scenario i motori di back-end dell’applicazione web sono AWS Lambda e API Gateway. Gli sviluppatori possono scrivere funzioni Lambda discrete e stateless per gestire operazioni di creazione, lettura, aggiornamento e cancellazione per una varietà di risorse supportate dall’applicazione. Tramite il gateway API, il codice front-end chiama le funzioni Lambda, che eseguono i workload dell’applicazione.
- Livello di database. I dati persistenti possono essere memorizzati in altri servizi gestiti come Amazon DynamoDb, un servizio di database NoSql, o Amazon Relational Database Service. Le funzioni AWS Lambda comunicano direttamente con questi servizi per la conservazione dei dati.
Amazon e Netflix utilizzano l’architettura dei microservizi da anni. L’idea di base è quella di suddividere una grande applicazione in una raccolta di servizi orientati ai task. Al contrario, le classiche applicazioni sono costruite come unità monolitiche, che spesso includono front-end e Html per interagire con gli utenti finali. Sebbene queste architetture abbiano funzionato per anni, oggi le applicazioni devono supportare un maggior numero di utenti e gli aggiornamenti diventano più difficili. Poiché i componenti di un’applicazione monolitica sono strettamente accoppiati, anche una leggera modifica al codice lato server può richiedere un update completo dell’app lato client.
Nell’approccio a microservizi un’applicazione è alimentata da tanti piccoli servizi, ciascuno con poche responsabilità. Ogni microservizio può guastarsi senza fermare l’intero sistema. Le piccole dimensioni dei microservizi permettono ai piccoli team responsabili di individuare e risolvere velocemente il problema.
Un’architettura basata su microservizi è caratterizzata da accoppiamenti laschi: ogni microservizio è indipendente e può gestire in autonomia uno stack di tecnologie; i team che si occupano di quel microservizi possono modificare la tecnologia sottostante senza fermare l’intera applicazione. La minore complessità dei microservizi (rispetto ad altre tecnologie) riduce infine la barriera di accesso allo sviluppo di nuove funzionalità applicative anche da parte di piccoli team di sviluppo.
