AWS Lambda: Caso d’uso

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:

• Calcolo dei costi per AWS Lambda
• Calcolo dei costi per altri servizi Amazon

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.