Il concetto di serverless computing e di Function-as-a-Service inaugurato da AWS Lambda e da servizi simili di altri cloud provider si sta diffondendo grazie alla sua promessa di semplicità. Gli sviluppatori non devono preoccuparsi della parte infrastrutturale ma solo di scrivere il codice necessario a svolgere una certa funzione. Questo viene attivato al verificarsi di determinati eventi, svolge il suo compito e poi si disattiva.
Sulla carta il concetto è convincente. Il dubbio che può avere uno sviluppatore è se poi la promessa di semplicità sia mantenuta anche nella pratica, cioè se gli strumenti per creare e gestire le funzioni e i loro eventi scatenanti siano anch’essi semplici. Qui lo vediamo velocemente per AWS Lambda, l’approccio di fondo è replicato anche nei servizi FaaS di Google (le Cloud Function), IBM (OpenWhisk) e Microsoft (le Azure Function).
Innanzitutto, lo sviluppo in sé. Ci sono vari modi per creare il codice delle funzioni che dovranno essere eseguite, dai plugin per i principali IDE a framework specifici aperti a vari cloud. Oppure si possono usare direttamente i tool di AWS Lambda usando alcuni template che vengono presentati direttamente nella console.
A seconda della nostra scelta il codice della funzione può essere quasi completamente definito oppure tutto da scrivere. Anche il linguaggio da usare dipende dal template, in generale le funzioni possono essere compilate con tutti i linguaggi principali (C#, Java, Node.js, Python…).
Trigger, container, debug
Oltre al codice, l’elemento principale collegato a una funzione è il suo trigger, ossia l’evento scatenante. In AWS Lambda la scelta spazia tra gli eventi previsti da alcuni servizi specifici del cloud di Amazon, da S3 per lo storage ad AWS IoT, e comprende poi l’opzione più generale di un gateway da/verso API esterne. Con quest’ultima opzione qualsiasi metodo Http può attivare la nostra funzione.
Non è del tutto vero che gli sviluppatori non devono occuparsi di alcun elemento infrastrutturale. Ci vuole un minimo di controllo anche per le funzioni serverless e AWS Lambda prevede alcune opzioni di configurazione legate ai permessi di accesso della funzione alle risorse che coinvolge, anche per un eventuale auditing successivo. Inoltre si può intervenire sulla configurazione delle risorse di computing che eseguono la funzione quando viene attivata.
Di per sé, infatti, una funzione di AWS Lambda è solo codice salvato da qualche parte sul cloud di Amazon. Quando si verifica l’evento trigger della funzione, nella pratica AWS lancia un container che ha precaricato il runtime specifico per il linguaggio della funzione e che carica il suo codice e lo esegue. Nel definire una funzione, gli sviluppatori possono impostare alcuni parametri legati a questo container, come la memoria a disposizione e il tempo massimo di attivazione (e quindi fatturazione).
I tool presenti nella console di AWS Lambda permettono anche di eseguire test e debug del codice, operazioni che ovviamente possono essere portate avanti in maniera diversa se si sviluppa al di fuori della console con framework mirati. Si tratta comunque di differenze di strumento, non di metodo.
Le applicazioni di AWS Lambda possono essere molto diverse fra loro. Il campo del serverless computing è relativamente nuovo ma stanno emergendo già alcuni modelli di sviluppo particolarmente indicati o comunque diffusi. C’è una presentazione di AWS stessa che mostra cosa viene realizzato più di frequente con AWS Lambda e dà alcune indicazioni sulle best practice da seguire.
Al momento la maggior parte delle applicazioni delle FaaS riguarda prevedibilmente l’automazione di alcune operazioni “atomiche”, l’elaborazione in batch, lo stream processing e il dietro le quinte delle applicazioni web.
