Aws Lambda é un servizio serverless di Amazon Web Services.
Parlare di Aws Lambda vuol dire prima di tutto parlare di un nuovo paradigma di sviluppo: serverless.
Introduciamo brevemente questo concetto senza approfondirlo troppo.
Il nome, nella sua semplicità, é già molto esplicativo.
Si intende per serverless un codice eseguito solo ed esclusivamente al momento della sua richiesta.
In maniera schematica possiamo elencare i seguenti caratteri distintivi
- non c’é bisogno di avere un servizio sempre attivo e ‘fermo’ se non usato
- non serve gestire configurazioni server per l’esecuzione dell’applicativo
- il costo dell’applicativo é misurabile a livello di numero di invocazioni
Quest’ultimo punto, soprattutto per chi si trova a valutare anche costi e gestire eventuali budget, direi che é la caratteristica che rende il serverless una vera innovazione.
L’effettivo numero di invocazioni lambda determina il costo del software.
nessuna invocazione = nessun costo
Il vantaggio di questo paradigma direi che é quindi fondamentalmente economico (e non é poco!).
Aws Lambda é quindi un servizio serverless che esegue codice in funzione di un determinato evento scatenante. Un evento scatenante puó essere una qualsiasi azione. Per esempio:
- una chiamata Api
- caricamento di un file su un bucket S3
- aggiornamento tabelle DynamoDB
L’avvio del codice caricato é totalmente demandato ad Amazon che gestisce l’esecuzione su un’infrastruttura cloud scalabile determinandone il provisioning di capacitá ed eventuale autoscaling.
Log e monitoraggio sono presenti di default.
Quello che occorre fare é semplicemente caricare il codice applicativo.
L’esecuzione di una lambda é stateless; possono quindi essere avviate qualsiasi numero di funzioni in base al numero di eventi scatenanti.
Caso d’uso
Vediamo un semplice caso d’uso. In questo esempio realizzeremo una lambda in Java che effettua un semplice resize di un file immagine caricato in bucket s3. Per questo esempio usiamo il codice presente al seguente link [https://github.com/AndreaCiacciaCodeploy/CodeployAcademyAwsLambdaImage]. La riduzione dell’immagine é di per se banale e il codice utilizzato é sicuramente un hello world un po’ piú avanzato. L’obiettivo di questo articolo non é ovviamente quello di lavorare su tale codice, ma introdurre l’utilizzo di Aws Lambda per tali servizi.
Il flusso che andremo a implementare si puó cosí rappresentare:
Prerequisiti
Prima di tutto creiamo un bucket S3 con all’interno due cartelle (origin, dest). Successivamente prepariamo un ruolo su IAM che abbia i permessi di agire su S3 e su Lambda (per un primo test anche il permesso di FullAccess sui due servizi potrebbe andar bene)
Creazione lambda
Dalla console accediamo al servizio Aws Lambda. Clicchiamo su Create Function e inizializziamo la lambda indicando (usiamo pure Author from scratch)
- il nome [MyLambdaTest]
- il linguaggio utilizzato [java8]
- il ruolo precedentemente creato
Allo step successivo non ci resta altro da fare che indicare il trigger (l’evento scatenante) e caricare il codice da eseguire.
Selezionare Add Trigger e successivamente selezionare il servizio S3 indicando quindi il bucket e il permesso.
Tornati quindi sulla schermata della lambda effettuare l’upload dell’applicativo .jar e indicare l’handler di riferimento.
Nel nostro caso l’handler é cosí indicato: package.classname::method
com.codeploy.accademy.awslambda.CodeployLambdaFunctionHandler::handleRequest
Come spiegato su github, il codice qui sviluppato utilizza le variabili d’ambiente di aws lambda. Semplici variabili che possono essere utilizzate all’interno dell’applicativo. Carichiamo qui le seguenti variabili
DEST_BUCKET (indcare il nome del bucket di destinazione)
DEST_FOLDER (indicare eventuale folder di destinazione)
RESIZE_HEIGHT (l’altezza da impostare durante il resize)
RESIZE_WIDTH (la larghezza da impostare durante il resize)
PUBLIC (valorizzare con true o false. Se true il file caricato dopo la resize sará accessibile pubblicamente).
Le altre impostazioni possiamo lasciarle con valori di default. Unico appunto é la sezione Basic Settings dove é possibile inserire (oltre a una breve descrizione), il timeout e il valore della memoria da utilizzare.
Come introdotto piú avanti nel seguente articolo, questi due parametri determinano l’esecuzione stessa della nostra lambda e anche il costo economico.
Salviamo e siamo pronti a testare. Per farlo sará sufficiente caricare un file PNG dentro la cartella di origine per visualizzare dopo qualche istante il file ridotto nella cartella di destinazione.
È possibile visualizzare l’esecuzione, il monitoraggio e quindi i log dal pannello CloudWatch Logs accessibile anche dalla nostra lambda cliccando sulla voce Monitoring
Come e quando usare
Come si evince da quanto introdotto e dal caso d’uso indicato, l’utilizzo delle funzioni lambda sono utili quando non si vuole gestire la componente infrastrutturale e sopratutto quando si vuole ridurre i costi dell’infrastruttura.
Possiamo ad oggi dividere due casistiche di utilizzo:
- realizzazione di un software totalmente serverless
- introduzione di aws lambda per specifiche funzionalitá
Realizzazione di un software totalmente serverless
E’ possibile sviluppare un applicativo totalmente serverless sfruttando (anche) le potenzialitá di aws lambda. In questo caso é, peró, fondamentale una progettazione curata che tiene in considerazione svariati fattori:
Progettazione infrastrutturale/applicativa
La realizzazione di un software full serverless non passa solo dall’utilizzo di aws lambda, ma anche da servizi utili per questo paradigma.
Un esempio é l’utilizzo di Aws Api gateway. Un servizio serverless per la gestione e pubblicazione delle Api.
Di grande importanza é inoltre la gestione del database.
Una funzione lambda che effettua (anche) letture/scritture a db non puó basarsi su database transazionali il cui caricamento della logica di persistenza rende pesante l’applicativo.
Bisogna infatti considerare che il codice viene avviato ed eseguito quando viene chiamato. Aws Lambda deve quindi fare l’avvio del codice che non puó essere ‘pesante e lento’.
Le funzioni lambda devono essere avviate velocemente (viene comunque gestita una cache che velocizza le chiamate successive alla stessa funzione).
Serverless si sposa infatti molto bene con il paradigma microservices.
Competenze aziendali
Come in tutti i progetti é necessario avere all’interno del team di sviluppo figure preparate in grado di approcciarsi a questo paradigma nella maniera piú competente possibile senza considerare solo le implicazioni tecniche.
Occorre che anche le figure funzionali e decisionali abbiano afferrato le vere caratteristiche di questo paradigma.
Utilizzo di linguaggi approriati
Dovendo aws lambda avviare il codice e successivamente eseguirlo, esistono linguaggi piú ‘snelli’ e quindi piú consoni a queste infrastrutture.
Un esempio é javascript con nodejs.
L’utilizzo di applicazioni lambda in Java (per esempio) é possibile, ma occorre valutare con attezione i tempi di avvio del codice.
Attenzione! Valutare non solo i tempi, ma anche la quantitá di ram necessaria all’esecuzione. Questi due parametri determinano infatti il costo economico per l’esecuzione di una chiamata lambda.
Gestione del lavoro e devops
Anche l’approccio alle normali attivitá lavorative deve essere valutato.
Se pensiamo a un applicativo che gestisce una decina di chiamate api (esposte da un unico Rest Controller per esempio), nel mondo
serverless lambda, le dieci chiamate api dovrebbero essere 10 funzioni lambda. La gestione del codice a livello di versionamento e quindi di deploy deve quindi essere pensato molto bene.
Amazon ha pubblicato di recente Aws Serverless Application Repository.
Un servizio che permette la gestione di librerie applicative da utilizzare nelle lambda deployate. Rimando l’approfondimento a questo servizio a futuri articoli e alla documentazione ufficiale aws (https://aws.amazon.com/serverless/serverlessrepo/).
Un altro servizio utile é https://serverless.com/. Un framework per lo sviluppo di applicativi serverless.
Valutare gli effettivi vantaggi
Progettare un applicativo totalmente serverless ha quindi bisogno di giusti tempi di valutazione e progettazione che devono sempre avere come riferimento gli effettivi vantaggi che si possono ottenere.
La scelta di una tecnologia o di un paradigma devono sempre viaggiare di pari passo con quelle che sono le competenze e le visioni aziendali.
L’innovazione non é buttarsi alla cieca perché ‘c’é una nuova tecnologia fighissima’.
L’innovazione é essere aperti a qualsiasi cambiamento, ma con un approccio graduale e studiato.
Introdurre funzioni lambda per contesti specifici
L’utilizzo delle funzioni Aws Lambda non é da considerare esclusivamente per realizzazione di progetti totalmente serverless..anzi..
All’interno di una piattaforma o di un software é possibile introdurre funzioni lambda per piccoli e specifici casi d’uso. L’esempio citato in precedenza ne é un esempio. All’interno della nostra piattaforma per la gestione degli eventi sportivi é stata introdotta una funzione lambda per il resize delle immagini.
L’applicativo di per se non é full serverless, ma si avvantaggia di funzionalitá specifiche grazie alla presenza di aws lambda.
Costi
Prima di parlare di quanto effettivamente costa la nostra lambda é giusto citare il piano gratuito di amazon che, per il servizio aws lambda, mette a disposizione 1 milione di richieste al mese e 400.000 GB/secondo di tempo di elaborazione al mese.
Il costo della nostra lambda dipende dal numero di volte che viene eseguita. Non solo il numero di invocazioni, ma anche il tempo di esecuzione. Tempo che dipende dalla quantitá di memoria allocata per la lambda. Memoria che si puó impostare all’interno della console.
Dopo il primo milione di richieste il costo é di 0,0000002 USD per richiesta.
Il costo per il tempo é invece variabile in base alla memoria allocata. Esistono svariati servizi aws che permettono di calcolare al meglio i costi dell’infrastruttura. Al seguente indirizzo sono presenti i costi per aws lamda (https://aws.amazon.com/it/lambda/pricing/). Attenzione! Se la nostra lambda utilizza altri servizi AWS (per esempio S3), occorre fare una valutazione dei costi anche del servizio associato.
Il seguente link é invece una utile risorsa per una prima analisi dei costi su AWS https://calculator.s3.amazonaws.com/index.html
Conclusioni
Aws lambda é quindi un servizio utile non solo per la realizzazione in toto di un progetto serverless, ma per anche e sopratutto per la gestione di singoli casi d’uso. I vantaggi economici sono evidenti, ma l’approccio deve passare da una prima fase di studio e analisi (sebbene nel modo piú agile possibile).
In Codeploy utilizziamo aws lambda sia per progetti completamente serverless sia come integrazione in progetti dalla natura non serverless.
Non solo AWS. Anche Google e Microsoft nelle loro piattaforme cloud hanno servizi paragonabili (Google Cloud Functions, Azure Functions).
Ti ringrazio per la lettura. Scrivimi per ulteriori approfondimenti o dubbi.
