Talent Garden Milano – 22/09/2016 ore 15: inizia l’AWS Lambda Zombie Workshop.
Arrivo in tempo nella sede del TAG, la mia prima volta in uno startup hub. Atmosfera moderna ma spartana, essenziale. Quello che serve per una startup, nulla di più.

Confesso di essere un po’ timoroso perché non mi sento un guru del Cloud. Sto studiando per prendere la certificazione di AWS Certified Developer, so smanettare abbastanza bene nella console, mettere in piedi istanze EC2, S3, RDS e altre cosucce ma di certo non mi sento un esperto e spero di essere all’altezza di un workshop sulle Lambda su AWS. Soprattutto… di capirci qualcosa. 😉

Conosco però bene cosa può fare una AWS Lambda. In breve, può far girare codice più o meno complesso senza dover badare/pensare all’infrastruttura che c’è dietro. Detta così, se ne intuisce le potenzialità ma potrebbe sembrare poca cosa, o quantomeno far pensare che il problema risolto sia soltanto quello di non dover pensare a gestire un server. So far from the truth…

Speaker principale dell’evento Danilo Poccia, che scopro presto essere uno “tosto” in AWS, precisamente Technical Evangelist, precedentemente Solutions Architect ed autore di un recente libro dal titolo “AWS Lambda in Action – Event-Driven Serverless Applications“, titolo che riassume abbastanza bene cosa fa una lambda.

Mi spiace ma lo devo dire…Unico neo nell’organizzazione dell’evento l’insufficiente numero di ciabatte elettriche per consentire a tutti di collegare il proprio pc. Io sono fra quelli sfigati… troppo lontano dalle poche prese che sono, ovviamente, tutte full… cosa che pagherò verso la fine dell’evento, costringendomi ad un prematuro ritiro causa morte della batteria…

All’inizio Danilo fa un discorso introduttivo e una panoramica sui vari servizi presenti nella console Amazon Web Services. In Italia, si sa, il cloud lo masticano ancora in pochi e la platea potrebbe non conoscere i vari servizi, anche se, dato l’approccio tipicamente smanettone di un workshop, ci si può aspettare di avere a che fare con persone che quantomeno sanno di cosa si sta per parlare.

E’ tempo di una pausa per un piccolo ristoro, generosamente concesso dall’organizzazione, e finalmente si passa alle cose “serie”.

Alla base dell’esigenza di un prodotto/servizio come Lambda c’è un nuovo trend nella concezione architetturale del software, quello dei servizi e, ancor più recente, dei microservizi. Anche se avvalorata da esigenze concrete è pur sempre lecita la domanda:

perché usare i microservizi? Risposta semplice…

le vecchie architetture 3tier, pur se solide e rispondenti alla necessità di maggiore produttività, ottenuta con la riusabilità e la separazione delle competenze, tendono ad esplodere abbastanza facilmente in termini di complessità e sono comunque strettamente dipendenti dalle tecnologie impiegate. Un’architettura a microservizi, invece, non deve seguire le tecnologie, ma seguire una logica di business (Business domain); deve essere scarsamente accoppiata (loosely coupled) ed è conveniente adottarla in presenza di contesti indipendenti (bounded context), questi ultimi corrispondenti alle aree di business/servizi aziendali.

Vantaggi? tanti… fra questi:

• I microservizi  adottano il principio della singola responsabilità e sono indipendent deployment
• Può essere scelto lo strumento più indicato e quindi stack applicativi differenti
• Adottare nuove tecnologie e altro ancora…

Certo, se non si sta attenti un singolo microservizio potrebbe presto diventare troppo complesso. E’ quindi importante riuscire, sia se si sta migrando da un’applicativo 3tier o se si sta concependo l’architettura di un nuovo software, a scomporre un workflow complesso in piccoli segmenti indipendenti e semplici, una sorta di unit of work, che poi sono alla base di uno sviluppo TDD/BDD.

Già, ma quanto piccoli? Una regola empirica è quella che un microservizio dovrebbe poter essere scritto/riscritto completamente in due settimane circa da un piccolo team dedicato di circa 5/10 persone, che devono seguire tutto il ciclo di vita.

Se il software è grande e complesso posso suddividere lo sviluppo con team dedicati a feature differenti (Feature Teams).

Va assolutamente definita la mappa delle funzionalità che possono usare la modalità Sync piuttosto che Async. Quando è possibile spostare un processo su async, lo si sta disacoppiando, e questa è cosa buona e giusta, ma vanno previsti gli impatti che comporta l’applicazione della programmazione asincrona.

Adottando un’architettura a microservices e piccoli team, in caso di bug o ritardi non ci sono momenti di stasi per gli altri sviluppatori fino alla risoluzione del bug, anche se bisogna usare una serie di accorgimenti. Alcuni di questi devono seguire il Postel’s law, meglio conosciuto come

Robustness Principle: sii conservativo in ciò che fai, ma libero in ciò che accetti dagli altri

In sostanza, bisogna far sì che il codice che invia comandi/parametri rispetti rigorosamente le specifiche, ma nello stesso tempo il codice che riceve in input questi comandi/parametri deve poterne accettare anche un numero maggiore di quello previsto, senza generare errori.

Inoltre, usare un set minimo di privilegi per l’esecuzione di un processo e adottare un sistema di autenticazione con Single Sign On, in quanto non è pensabile doversi autenticare ad ogni servizio, così come è assolutamente indispensabile prevedere un sistema di logging per ogni singolo step significativo interno al microservice, altrimenti il processo di debugging sarebbe davvero “a pain in the ass”…

Last but not least… Pensare sempre tenendo in mente i failures e a come far utilizzare il sistema con funzionalità degradate.

Danilo ha detto molte più cose e sicuramente meglio di me, facendo anche qualche esempio pratico di come si crea una Lambda, come si fa l’upload del codice su AWS,  come si attiva una lambda tramite triggers o http endpoint (Lambda esegue il codice solo all’attivazione del trigger e viene spesata per i millisecs utilizzati effettivamente; cioè in pratica se c’è idle non ci sono costi…), l’uso dell’AWS API Gateway, che funge da proxy e protegge da attacchi ddos, il tutto corredato anche da qualche use case, come quello del The Seattle Times in cui le fotografie sono salvate su S3, il servizio storage di Amazon, e poi viene lanciata la lambda che effettua il resizing dell’immagine nei formati stabiliti. E poi ancora altri use case, passati troppo in fretta per riuscire a prendere appunti coerenti…

In teoria adesso sarebbe dovuto venire il meglio, la parte pratica per noi. La formula scelta, una sorta di hackathon, invece a me è parsa piuttosto infelice. Non perché sia stata mal organizzata, ma semplicemente perché non consentiva, dato anche lo scarso tempo, un miglioramento delle proprie conoscenze e quindi un arricchimento in termini professionali. Avrei decisamente preferito un’esercitazione pratica per tutti di creazione di una Lambda e tutte le configurazioni necessarie, in modo da portare tutti i presenti ad un livello accettabile e poi successivamente passare all’hackathon.

Per non parlare del fatto che in questo momento il mio computer ha fatto “puff”… nero… batteria morta e non ho potuto far altro che dire “arrivederci e grazie”.

Alcuni links utili:

• https://github.com/awslabs/aws-lambda-zombie-workshop
• https://aws.amazon.com/it/training/intro-to-aws-labs-sm/
• https://aws.amazon.com/it/events/zombie-microservices-roadshow/
• https://aws.amazon.com/it/blogs/compute/surviving-the-zombie-apocalypse-with-serverless-microservices/
• http://www.slideshare.net/AmazonWebServices/workshop-aws-lamda-signal-corps-vs-zombies
• https://medium.com/aws-activate-startup-blog/surviving-the-zombie-apocalypse-by-building-serverless-microservices-bd115913d80f#.mfmew8kpq
• http://redfoxbook.com/18/1535309318

Dal sito XPEPPERS, organizzatore dell’evento, rubo due foto che mi immortalano… non potevo rinunciare a questo piccolo momento di ego… 😉

io, in primo piano di spalle, nell’ultima fila visibile

io, primo da sinistra in quarta fila