AWS Lambda Container Runtime — Pro e Contro

Qualche riflessione sul nuovo servizio Serverless lanciato da Amazon Web Services

Appena letto l’annuncio riguardante il servizio di Amazon Web Service che consente di lanciare Docker Container come Lambda, ho subito pensato: “Wow, finalmente qualcosa che permetta di rendere Serverless qualsiasi cosa. Devo assolutamente provarlo!". Conoscendo servizi come Google Cloud Run, la mia aspettativa era quella di trovare qualcosa di simile ma, dopo aver fatto qualche test, mi sono reso conto che il servizio di AWS è qualcosa di decisamente diverso rispetto a quello che si possa immaginare.

Innanzitutto voglio subito smorzare ogni falsa aspettativa: con AWS Lambda non è possibile eseguire qualsiasi container in modalità Serverless.

Faccio questa affermazione poiché il container da utilizzare deve essere pensato appositamente per AWS. È necessario infatti che esso esponga le Lambda Runtime API ed AWS per facilitare questa integrazione, ha rilasciato un Runtime Interface Client per i linguaggi più usati. L’integrazione però, non prevede una banale installazione di una libreria ma consiste nel predisporre il codice nello stile già noto a chi utilizza Lambda. In pratica bisogna esporre un metodo handler, che verrà utilizzato dal Runtime Interface Client. Ne consegue che, diversamente da Google Cloud Run, si è costretti a dover adattare le applicazioni già esistenti per essere integrate con il runtime del linguaggio scelto. Grazie a questo approccio però, contrariamente al servizio citato prima, non è necessario un server http all’interno del container.

Inoltre, i Lambda container sono completamente integrati nell’ecosistema AWS. È possibile infatti inserire un trigger per qualsiasi tipologia di evento già previsto per le Lambda “tradizionali”. Questo ne determina però, di fatto, un lock-in completo con AWS poiché non sarà possibile eseguire questo container su altri cloud provider senza re-work.

Riassumendo brevemente, di seguito ciò che ho apprezzato in quanto proposto da AWS:

• Integrazione completa con gli eventi e l’ecosistema AWS;
• Nessun server HTTP e/o boilerplate da implementare. Bisogna solo scrivere il codice dalla funzione;
• Cold start più veloce rispetto ai servizi simili;
• Estensione degli use case implementabili con Lambda;

e ciò che non mi è piaciuto:

• Rework necessario per i container esistenti;
• Lock-in con AWS;
• Effort elevato per l’utilizzo di linguaggi “non standard" poiché le Lambda Runtime API sono implementate per pochi linguaggi;
• Necessità di utilizzare il Lambda Runtime Interface Emulator per il Testing;
• Deploy ostico, in pieno stile Lambda;

Il nuovo servizio, in sostanza, indirizza definitivamente una problematica che si tentò di risolvere con il lancio del 2018 dei Lambda Layer e dei Custom Runtime: rendere potenzialmente possibile l’estensione dei runtime standard consentendo anche l’utilizzo di altri linguaggi di programmazione.

Se però con i Custom Runtime le difficoltà implementative erano abbastanza elevate, la situazione ora è decisamente migliore per via delle facility che introducono i container.

Un ulteriore problema annoso delle Lambda “tradizionali” è dato dalla dimensione massima della singola funzione. Adesso, con i container, il limite massimo si è spostato da 250 MB a 10 GB. Questo rende fattibile l’utilizzo di Container Lambda, ad esempio, per il Machine Learning. I modelli ML di consueto hanno dimensioni elevate e, per utilizzarli in delle Lambda, bisognava prevedere meccanismi contorti. Ad esempio, molti aggiravano il problema dello spazio limitato copiando il modello a runtime, da un bucket s3. Con i container, invece, il modello potrà far parte del pacchetto software, migliorando i tempi di bootstrap della Lambda.

Per concludere, il nuovo servizio di AWS è sicuramente molto interessante per chi abitualmente utilizza Lambda e ne estende le già enormi potenzialità dell’ecosistema.

Resto però in attesa di un servizio in stile Google Cloud Run. Con un solo comando, si avvia un container in modalità Serverless e si espone un endpoint HTTPS pronto ad essere interrogato. Sarebbe una fantastica possibilità, per me che sono sviluppatore Java, poter eseguire il mio servizio Spring Boot senza nessun rework, in modalità Serverless, con un solo comando.

Se dovessi fare un parallelo AWS Lambda Container Runtime sta a Apache Openwhisk come Google Cloud Run sta a Knative. Due approcci diversi di affrontare il “serverless”.

Nel prossimo articolo mostrerò in dettaglio cosa sia possibile fare con le “nuove” Lambda. Stay tuned!