AWS Lambda: Caso d’uso
aws lambda logo e caso d'uso

SERVIZI SERVERLESS

AWS Lambda è un servizio “serverless” proposto da Amazon. Per comprenderne funzionamento e potenzialità è necessario, prima di tutto, capire che il “serverless” è un nuovo paradigma nello sviluppo e nell’erogazione dei servizi.

Il nome stesso è, di per sé, significativo: un contesto serverless non può, evidentemente, prescindere dall’esistenza di sistemi su cui eseguire le applicazioni, tuttavia rappresenta una svolta rispetto ad un modello DevOps. L’obiettivo dell’ambiente operativo è infatti garantire un contesto di esecuzione standard alle applicazioni, lasciando in capo agli sviluppatori unicamente il codice. Tutti gli altri aspetti infrastrutturali, quali provisioning, amministrazione e scaling, vengono gestiti in modo automatizzato e trasparente.

Un approccio serverless, inoltre, prevede che le applicazioni o, più correttamente, le funzioni vengano attivate solo a fronte di eventi specifici, raggiungendo l’obiettivo della scalabilità a zero: in assenza di chiamate, non esistono processi attivi o demoni in ascolto, oltre a quelli infrastrutturali, e pertanto non viene impiegata alcuna risorsa di calcolo.

Questa caratteristica consente di ottimizzare l’allocazione delle risorse di realizzare un modello di costi realmente pay per use, basato unicamente sul numero di chiamate verso il servizio.

  • allocazione delle risorse ottimale e crescita lineare;
  • separazione della funzione dai dati e dall’infrastruttura;
  • definizione dei costi su una reale base pay per use.

Le uniche configurazioni che vengono demandate agli sviluppatori riguardano alcuni aspetti del dimensionamento dell’ambiente run time, quali la memoria disponibile ed il tempo massimo di esecuzione.

AWS Lambda

AWS Lambda è il servizio serverless di Amazon che permette l’esecuzione di codice applicativo in seguito al verificarsi di determinati eventi, quali, ad esempio:

  • chiamate API
  • caricamento di file in un bucket S3
  • aggiornamento di tabelle DynamoDB

L’avvio e l’esecuzione del codice sono completamente demandati all’infrastruttura di Amazon, che garantisce il provisioning delle risorse, l’autoscaling e le funzionalità di monitoraggio e log.

Le funzioni sono stateless e non offrono, per la loro stessa natura, persistenza dei dati, che deve quindi essere demandata a strumenti esterni.

Una volta caricato il codice e definito il contesto applicativo, l’infrastruttura si occupa di attivare, eseguire e scalare le funzioni.

Esempio d’uso di AWS Lambda

Per approfondire il funzionamento di AWS Lambda, ricorreremo ad un semplice esempio: a questo link è presente il codice Java per una funzione che effettua il ridimensionamento di un’immagine inserita in un bucket S3. L’obiettivo non è analizzare o modificare il codice ma introdurre il funzionamento di AWS Lambda e i passaggi necessari per l’attivazione di una funzione.

esempio d'uso AWS Lambda

Preparazione

Sono necessarie alcune operazioni per la preparazione dell’ambiente:

  • creazione di un bucket S3 che contiene due cartelle (origin e dest)
  • preparazione di ruolo IAM con i permessi necessari per agire s S3 e su Lambda (per semplicità, a solo titolo dimostrativo, è possibile assegnare a questo il permesso FullAccess)

Creazione della funzione Lambda

La funzione viene creata dalla console di gestione del servizio, con “Create function” e vengono inizializzati alcuni parametri:

  • il nome (MyLambdaTest)
  • il linguaggio utilizzato (Java 8)
  • il ruolo precedentemente creato
creazione della funzione lambda

I passaggi successivi consistono nella definizione del trigger (l’evento che innesca la funzione) e nel caricamento del codice da eseguire:

  • dopo “Add Trigger” è necessario selezionare il servizio S3 ed indicare il bucket ed il permesso
  • ed effettuare l’upload del pacchetto JAR indicandone l’handler di riferimento.
aggiunta trigger in aws lambda

L’handler è nella forma package.classname::method, quindi, nel nostro caso, è com.codeploy.academy.awslambda.CodeployLambdaFunctionHandler::handleRequest.

AWS Lambda offre la possibilità di configurare variabili d’ambiente che vengono rese disponibili alla funzione e sono quindi utilizzabili nell’applicazione:

  • DEST_BUCKET (indicare 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).

Nella sezione Basic Settings, oltre alla possibilità di inserire una breve descrizione, rivestono particolare importanza altri due parametri:

  • timeout (tempo massimo di esecuzione della funzione) e
  • memoria (che può essere utilizzata dalla funzione).

Proprio questi parametri determineranno il dimensionamento dell’ambiente runtime e quindi anche il costo della nostra funzione Lambda.

Una volta salvata la configurazione, la funzione è pronta per essere utilizzata: l’inserimento di un’immagine in formato PNG nella cartella “origin” del bucket S3 costituisce l’evento che attiva la funzione e dopo alcuni istanti verrà salvato il file ridimensionato nella cartella di destinazione.

Il pannello “CloudWatch Logs”, accessibile dal link “Monitoring” della funzione AWS Lambda, permette di visualizzare l’esecuzione ed accedere alle funzioni di monitoraggio e log.

Quando usare una funzione Lambda

Approcci di tipo serverless e, nello specifico, AWS Lambda sono utilizzabili nei casi in cui:

  • non si voglia gestire la componente infrastrutturale,
  • si preferisca un modello di costi in modalità unicamente pay per use,
  • non si voglia (o non sia possibile) procedere ad un corretto dimensionamento a priori delle risorse di calcolo necessarie.

Strumenti quali le funzioni AWS Lambda possono essere utilizzati:

  • per la realizzazione di un software completamente serverless, con le difficoltà progettuali ed implementative che questo comporta,
  • per la realizzazione di microservizi che implementano specifiche funzionalità in un contesto software più tradizionale.

Software completamente serverless

Sebbene, come detto, sia possibile sviluppare un applicativo completamente serverless sfruttando (anche) le potenzialità di AWS Lambda, è necessario prestare particolare attenzione agli aspetti progettuali.

Progettazione infrastrutturale ed applicativa

In primo luogo l’applicazione dovrà essere costituita esclusivamente da funzioni, che, in quanto tali, non presuppongono la presenza di servizi sempre attivi o di un livello di persistenza. Di conseguenza sono fondamentali, oltre all’implementazione delle singole funzionalità, anche l’identificazione degli eventi che innescano le funzioni, la definizione dei canali di comunicazione e l’interazione con i database e con gli strumenti che garantiscono la persistenza dei dati.

Le applicazioni full serverless devono essere implementate in un contesto che prevede l’utilizzo di strumenti funzionali a questo paradigma quali, ad esempio, AWS API Gateway , un servizio completamente gestito da Amazon che semplifica la creazione, la pubblicazione, la manutenzione, il monitoraggio e la protezione delle API consentendo la creazione di API REST e Web Socket che costituiscono il punto d’accesso delle applicazioni.

Amazon ha inoltre recentemente pubblicato AWS Serverless Application Repository,  un servizio che permette di gestire, condividere e pubblicare librerie che possono essere utilizzate nelle funzioni AWS Lambda.

Un altro aspetto critico, già anticipato, riguarda la persistenza dei dati e l’interfacciamento con i database: una funzione AWS Lambda deve essere eseguita rapidamente e con un limitato impiego di risorse, quindi, anche se è presente una cache che velocizza l’operazione, non può presupporre l’avvio di un’istanza di un database transazionale.

Amazon DynamoDB é, per esempio, un database altamente scalabile NoSql key-value che permette una facile integrazione con le funzioni lambda.

Competenze aziendali

In tutti i progetti è necessario che nel team di sviluppo siano presenti figure preparate, in grado di approcciare questo paradigma nel modo più competente possibile: non solo gli sviluppatori per gli aspetti tecnici, ma anche coloro i quali rivestono ruoli funzionali e decisionali devono essere in grado di comprendere vantaggi ed implicazioni di questa nuova tecnologia.

Scelta di linguaggi appropriati

Sebbene AWS Lambda, ed i servizi serverless in genere, consentano l’implementazione delle funzioni in molteplici linguaggi, alcuni si prestano maggiormente a questi specifici contesti d’uso.

Dal momento che ogni chiamata alla funzione determina l’avvio e l’esecuzione del codice, alcuni linguaggi, quali NodeJS, risultano più rapidi e consentono un minore impiego di risorse. L’utilizzo di applicazione Lambda in Java, per contro, è possibile, ma occorre valutare con attenzione sia il tempo di avvio sia la richiesta in termini di memoria. Il tempo di esecuzione e la memoria utilizzata non influenzano unicamente le prestazioni del software, ma determinano anche il costo per ogni singola chiamata alla funzione.

Gestione del lavoro e DevOps

La transizione verso un approccio serverless causa profondi cambiamenti che coinvolgono a diversi livelli l’organizzazione stessa del lavoro.

Un’applicazione costituita unicamente da funzioni serverless è caratterizzata da un lifecycle differente rispetto ad un software monolitico. Ad esempio, un applicativo costituito da dieci API esposte da un unico rest controller nel mondo AWS Lambda risulterebbe costituito da dieci funzioni Lambda distinte. Ognuna di queste sarebbe indipendente, avrebbe la propria linea di versionamento e il proprio flusso di deploy: da un lato questo può aumentare la complessità, ma, d’altro canto, la modifica di una funzione non implicherebbe il deploy di tutta l’applicazione, limitando i tempi e la possibilità di errore. In questo contesto, AWS Serverless Application Repository ha come obiettivo la riduzione della complessità e dei tempi di rilascio, garantendo allo stesso tempo coerenza nello sviluppo.

Valutazione degli effettivi vantaggi

La progettazione di un applicativo totalmente serverless richiede un’attenta valutazione ed un’accurata progettazione finalizzate agli effettivi vantaggi che si possono ottenere.

La scelta di una tecnologia o di un paradigma deve sempre essere relazionata sia alle competenze sia alla visione aziendale. Innovare non significa gettarsi alla cieca su una tecnologia perché nuova o particolarmente alla moda: innovare vuol dire essere aperti a qualsiasi cambiamento, con un approccio graduale e ponderato, scegliendo le soluzioni migliori in funzione dei benefici e degli obiettivi che si vogliono perseguire.

AWS lambda per contesti specifici

Fino ad ora si è ipotizzato di utilizzare funzioni AWS Lambda per realizzare progetti completamente serverless, con la complessità ed i benefici che questo comporta. Tuttavia non è l’unico scenario possibile.

In maniera meno dirompente, applicazioni realizzate in modo più tradizionale, possono, a fronte di determinati eventi, invocare funzioni esterne che non necessitano di un processo sempre attivo e che all’occorrenza devono poter essere attivate e scalare rapidamente.

I contesti sono molteplici e possono andare dal semplice esempio proposto per il ridimensionamento di un’immagine, a casi molto più complessi che coinvolgono IoT o Intelligenza Artificiale.

Prezzi

Prima di scendere nel dettaglio dei prezzi, è giusto citare il piano gratuito di Amazon che, per il servizio AWS Lambda, mette a disposizione un milione di richieste e 400.000 GB/secondo di tempo di elaborazione al mese.

Il prezzo della funzione dipende dal numero di invocazioni e dal tempo di esecuzione in base alla memoria allocata (impostabile dalla console di gestione).

Superato il primo milione, il prezzo è 0,0000002 USD per richiesta, a cui va aggiunto il prezzo per il tempo di esecuzione e quello per gli altri servizi Amazon utilizzati, quali, ad esempio, S3.

Amazon mette a disposizione svariati strumenti che permettono di calcolare il costo dell’infrastruttura:

Conclusioni

In sintesi, quindi, AWS Lambda è un servizio utilizzabile sia per la realizzazione di progetti full serverless, sia per implementare funzionalità specifiche integrabili in altri progetti.

La realizzazione di un progetto completamente serverless porta notevoli benefici sia in termini di gestione, sia di controllo dei costi. L’infrastruttura e l’ambiente operativo sono completamente esternalizzati e, trattandosi di un modello strettamente pay per use, è possibile ottimizzare i costi soprattutto nei casi in cui non si possa procedere ad un dimensionamento a priori o prevedere il carico di lavoro. D’altro canto la complessità progettuale e l’impatto sull’organizzazione aziendale e sui processi impongono un’attenta valutazione dei benefici in funzione degli obiettivi che si vogliono perseguire.

Meno complessa è invece l’introduzione di AWS Lambda come supporto ad integrazione di altri progetti. Questo consente un’introduzione più graduale della tecnologia e di sfruttarne i vantaggi mentre si acquisisce dimestichezza e consapevolezza dei nuovi strumenti.

AWS Lambda viene trattato in modo introduttivo nel corso AWS – Imparare per crescere, tenuto da Codeploy per Kinetikon. Codeploy è un’azienda che sviluppa soluzioni software innovative usando tecnologie all’avanguardia.