Bene e benvenuti su Geekbar, nuova settimana, nuova settimana e nuovo episodio qua sul nostro bar per gli sviluppatori.

Iniziamo già malissimo stasera, le energie sono al limite e a fianco a me ho un taco che è il mio pranzo ok? E appena arrivate del mio pranzo questo vi fa un po' capire in che condizioni sono, è stata una giornata di fuoco al lavoro ma per fortuna non sono solo, ho con me Leo e Luca, ciao ragazzi com'è? Ciao bene ma scusa una domanda il tuo pranzo o la cena? Il pranzo.

L'ultima volta che hai preso un taco in puntata hai detto che non era andata troppo bene.

Eh sì la digestione è un po' lenta, è per quello che è.

E' parcheggiato.

Un po' spostproduzione poi leviamo tutti i suoni molestici che ci sono.

Sì io adoro i taco ma hanno una digestione waterfall, è un po' insomma tutto dire.

Voi come state Luca e Leo? Vai Leo.

Io sto bene, stiamo lavorando molto e non posso dire molto però abbiamo delle release da fare nei prossimi mesi.

Tutto bene.

Io tutte le volte che chiedo qualcosa a Leo fa sempre riferimento all'NDA, allora quando è che venite in puntata e ci raccontate profondamente che cosa state facendo? Sono sotto NDA e non lo posso dire.

Anche la data non puoi dire.

Tu Luca? Va beh ok.

Non si può dire niente.

Tu Luca? Io pure sì sì tutto bene, tanto lavoro, ho cambiato lavoro da qualche mese quindi cose nuove, tanti strumenti nuove, tante cose da studiare, tante cose da gestire, quindi sono abbastanza in burnout.

Grazie.

Io sto fremendo in realtà, io sto fremendo ragazzi perché abbiamo un ospite super speciale, un amico di Gitbar, abbiamo già bevuto qualche birra insieme a Code Motion, ci prepariamo per farlo nei prossimi eventi dove andremo a incontrarci ma prima di presentarlo in realtà, e questo mi fa fremere sulla sedia, dobbiamo ricordare i nostri contatti.

Siamo la gitbar.it o etbrenrepo, sono i modi canonici per contattarci.

E poi ovviamente c'è il gruppo Telegram, basta cercare Gitbar Podcast e vedrete fuori un gruppo che ha conto attualmente 1181 membri, sottolineo membri e quindi niente, venite vi aspettiamo per la prima birra è gratis e la seconda...

membri e membre.

Come si dice membrae? Membr.

Membre, ok.

Io ragazzi non potete immaginare quanto faccio degli strafalcioni giganti, specie coi clienti americani che sono super presi da questa cosa dell'inclusività, forse anche in modo così plateale, e io faccio una gas dopo l'altra.

Ma parentesi a parte presentiamo l'ospite che abbiamo di nuovo qua un amico di Gitbar, abbiamo...

proviamo a fare il serio.

Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

Abbiamo un conferenziere internazionale, l'autore di uno dei libri se non il libro di riferimento per Node.js, abbiamo un amico di Gitbar nonché un serverless hero con noi, Luciano Mammino.

Ciao Luciano! Grazie per la fantastica intro, adesso mi sento proprio l'impostor syndrome a mille.

In realtà sarebbe Luciano che dovrebbe presentare il podcast Gitbar, è un piccolo podcast italiano dove parla di programmazione.

Che questo è vero.

Esatto, ciao Luciano come va? Tutto bene, tutto bene, è stata una lunga giornata quindi potrei dire cose strane però magari quella è la parte divertente.

Ma sei nel posto giusto, so che hai preso di corsa un treno, hai fatto di tutto per essere qua e per questo ti ringraziamo.

La prima domanda che voglio farti Luciano è, noi ci siamo sentiti un anno e mezzo fa più o meno qua su Gitbar, poi ci siamo visti un po' dopo, siamo visti a Code Emotion, abbiamo mangiato insieme, ma cosa bolle in pentola in quest'ultimo periodo? La stai combinando? Nella mia vita personale lavorativa o in generale? A livello code related, IT related.

Ma diciamo che non è cambiato tantissimo dall'ultima volta che ci siamo sentiti, nel senso che lavoro ancora per Fortiorem che è un'azienda di consulenza specializzata su AWS e continuo con questo ruolo che è una sorta di ibrido tra full stack web development e cloud architect e quindi diciamo che continuo un po' a imparare tutto quello che c'è da sapere sul cloud, AWS, migrazioni eccetera.

Non so se è un buon riassunto ma insomma questo è a grandi linee quello che ho fatto nell'ultimo anno e mezzo.

Mi ti faccio una domanda perché questa è una curiosità.

Trovi delle difficoltà a sposare la parte da sviluppatore con la parte di cloud architect? Cioè talvolta è come indossare due cappelli, due berretti no? Come fai a fare, se serve farlo, context switching e a gestire queste due personalità che talvolta sono anche in antitesi no? Bella domanda, non so se mi sono mai posto il problema da questo punto di vista.

Forse ho una personalità che è molto...

A me piace molto spaziare, andare a vedere il problema a 360 gradi piuttosto che a concentrarmi in particolar modo su un aspetto specifico.

Poi come esperienza personale ho più di 10 anni di sviluppo full stack quindi quella è una cosa su cui mi sento abbastanza tranquillo.

Tutta la parte cloud è un po' più in divenire, poi ci sono sempre tantissime innovazioni e in più c'è il fatto che il metodo con cui Fortiorem lavora forse è un po' particolare.

Nel senso che noi cerchiamo di, benché si parte sempre da un'analisi che è più da cloud architect, quindi di capire quali sono le esigenze, capire se l'architettura è quella corretta.

Fatto quello poi passiamo molto a una fase operativa in cui diventiamo una sorta di estensione del team del nostro cliente e quindi andiamo proprio a fare pairing col team dell'azienda con cui lavoriamo e in quel senso facciamo un po' di tutto.

Facciamo dalla parte di agile, scrum, eccetera, alla parte proprio di sviluppo pure per programming con gli sviluppatori dell'azienda.

Quindi è una sorta di secondo me inserimento molto naturale dal questo è l'obiettivo, definiamo insieme la strategia, una volta consolidata quella strategia cerchiamo proprio di metterla in pratica in modo operativo.

Quindi non vedo molto un conflitto tra queste due personalità come le definite tu, però forse dipende proprio molto dal modo in cui lavoriamo noi come azienda.

Proprio in funzione di questo immagino che il metodo con cui lavorate non è molto lontano dal metodo con il quale lavoriamo noi e quello che ti chiedo è quando, essendo comunque un'azienda di consulenza come hai detto, quando vieni integrato nel team del cliente e in qualche modo hai un ruolo anche da evangelist, da educatore, perché se sei un consulente o se un prestatore d'opera alla consulenza più bè c'era, oppure devi portare un improvement al team, devi portare metodologie, devi portare pragmatismo, devi portare una serie di competenze.

Quali sono, nella tua esperienza ormai lunga anche con Fortiorem, quali sono i modi che hai trovato funzionali per integrarti e trasferire la conoscenza pur rimanendo un consulente? Ok, non so se ho mai fatto una riflessione approfondita su questa cosa, diciamo che nella quotidianità di tutti i giorni ci sono varie cose che si fanno e forse non ci si dà troppo peso.

In generale credo che ci siano varie tecniche che valgono secondo me, a prescindere che nel caso in cui tu sia un consulente esterno se proprio sei una persona che lavora per quell'azienda, ovvero che se tu propone un cambiamento troppo drammatico dall'oggi al domani è difficile riuscire a ottenere consensi nel senso più lato, ma anche quando c'hai una situazione assolutamente aperta di un team che vuole abbracciare l'innovazione, è disposto a fare la qualsiasi cosa per innovare, se viene fatto il passo più lungo della gamma è sempre un po' difficile riuscire ad arrivare all'obiettivo.

Quindi preferisco un po' l'approccio incrementale in cui si parte un po' da quelle che sono le conoscenze attuali del team e si aggiungono degli elementi un po' alla volta e pian piano si arriva a fare innovazione.

Giusto per farti un esempio pratico, mi è capitato il caso di un cliente che doveva fare una migrazione un po' classica da on-premise a cloud, semplicemente non perché la volevano fare così per sport, ma perché avevano problemi di scalabilità abbastanza seri, avevano bisogno di quell'elasticità che potevano trovare solo sul cloud e nonostante il loro caso d'uso secondo me fosse stato un caso d'uso perfetto per utilizzare serverless, alla fine abbiamo preferito fare una migrazione becera proprio da virtual machine a virtual machine e mettere solo dei load balancer di fronte al loro deployment con degli autoscaling group perché quello era il modello mentale più vicino a quello che il team già conosceva ed il fatto di dover andare ad abbracciare il cloud e capire cosa fossero gli autoscaling group, come andare a creare delle AMI e tutta quella roba leggera, un overload cognitivo non banale e quindi abbiamo detto ok prendetevi questo, questo vi risolve il problema nel medio termine, nel lungo termine poi una volta che avete capito AWS, avete capito le basi del cloud potete cominciare a esplorare, magari spostate dei worker su delle lambda con SQS e pian in piano cominciate a integrare quel tipo di conoscenza, quindi se fossimo andati da 0 a 100 su serverless sarebbe stato figo però probabilmente sarebbe stato un passo più lungo della gamba per il team e magari ci sarebbero stati, cioè magari come consulente avremmo dovuto fare il 99% del lavoro noi e poi andare a dare in gestione al cliente una roba che magari loro non avevano del tutto capito e non sarebbero stati in grado di gestire la solita.

E questo ne dimostra anche il fatto dell'approccio che hai col cliente, cioè il levitare l'effetto lock-in a tutti i costi, cioè il essere un catalizzatore di successo piuttosto che essere una rondella della macchina, questa secondo me è una di quelle cose che quando si parla di consulenza è necessario mettere il focus, la puntata di oggi non è sulla consulenza anche perché non abbiamo Carmine con noi a sparare le bold opinion, ma è invece su un'altra tematica che hai citato che è il mondo serverless.

Il mondo serverless 2014, 2015, 2023, di anni ne sono passati parecchi.

Come si è evoluto lungo tutto questo quasi dieci anni? Allora parto subito con la opinione conflittuale che forse ti tirerà fuori gli argomenti di discussioni interessanti perché ultimamente sto avendo un po' una delusione da serverless, quindi vorrei portare questo tipo di opinione, nel senso che quando è stata rilasciata lambda, credo forse proprio 2014, aveva un po' questa promessa di dire finalmente abbiamo trovato una strazione che a livello di business vi fa concentrare quanto più possibile sui problemi di business, quindi scrivete la minor quantità di codice possibile per risolvere un problema di business, boom, produzione, non vi dovete preoccupare quasi di niente.

Che forse all'inizio c'era una abbastanza vicina a questo tipo di concetto e poi all'atto pratico quello che è successo passando dal quasi dieci anni dopo, sono passati nove anni, in realtà se prendiamo, io parlo in particolar modo di AWS lambda e di contesto AWS, quello che hanno fatto non è stato altro che aggiungere feature su feature su feature su, e per feature parlo proprio di configurabilità, dimensioni in cui si può configurare una lambda, e all'atto pratico oggi è forse più complesso andare a mettere in piedi una lambda di quanto lo era nove anni fa, perché c'è una matrice di configurazione infinita e bisogna veramente andare a capire cosa vuol dire ogni singolo parametro configurazione per mettere in piedi qualcosa di decente.

Quindi per assurdo è un po' un paradosso, nel senso che siamo partiti con quell'ideale di diamo un servizio quanto più manage possibile in modo che tu scrivi con una strazione semplicissima il codice, risolvi un problema, deploy, fine, tutto il resto se lo avete il cloud provider, e siamo arrivati al fatto che ovviamente gli utenti hanno avuto sempre delle richieste molto più specifiche, e AWS ha quella filosofia di customer first, quindi se abbastanza clienti chiedono una cosa AWS la fa, e all'atto pratico siamo arrivati a una sorta di astrazione che non è più un'astrazione perché puoi configurare lambda in mille modi diversi, e se tu ti stai approcciando a lambda oggi per la prima volta può essere un po' diciamo una cosa che fa un po' paura perché dici ok mi hanno promesso un'esperienza molto semplice, all'atto pratico non ho idea di dove iniziare perché c'è talmente tanta roba da configurare che effettivamente è difficile capire da dove iniziare, volevo portare questa opinione un po' conflittuale che la promessa di serverless secondo me è andata un po' a decadere negli anni.

Come il discorso del per esempio parlando di lambda, della quantità di memoria che allochi per ogni lambda che in realtà influisce anche sulla potenza di calcolo della lambda stessa, quindi te puoi decidere di dare più memoria e quindi più potenza per ridurre il tempo di esecuzione, dato che la lambda la paghi al millisecondo, quando vai a deploiare devi fare delle prove per capire se la tua applicazione, cioè se paghi meno aumentando la potenza e diminuendo il tempo di utilizzo, oppure tenendo un tempo di utilizzo più lungo, eppure come hai detto te all'inizio dicevano te metti la funzione e viene eseguita e non ti devi preoccupare della scalabilità.

Su questo voglio aggiungere una cosa perché qua su Github abbiamo un episodio proprio su questo topic che registrammo un po' di tempo fa con Alex Casalboni, proprio sul dimensionamento, aveva fatto dei lavori, era uscito con un tool che si occupava proprio del dimensionamento delle lambda, quindi ve lo metto nelle note dell'episodio e lo andiamo a recuperare.

Quello che però è interessante è quello che ha detto Leo, perché comunque noi non abbiamo solo un problema di configurabilità in termini di integrazione con servizi terzi, ma anche la stessa funzione serverless ha una certa complessità intrinseca, la stessa architettura anche solo del concetto serverless ha una certa complessità sua, naturale.

Hai parlato prima di configurabilità, si può dire configurabilità in italiano? Male che va di un neologismo.

Volevo chiederti, hai degli esempi, dei casi di uso particolari che evidenzino questo tipo di complessità che va a crescere proprio data dal fatto che possiamo utilizzarle anche per farci il caffè? Oddio, un esempio particolare non so se mi viene in mente così su due piedi, però in generale quando io parlo di configurabilità non parlo solo diciamo delle opzioni che hai in termini proprio di i parametri che puoi andare a configurare, ma anche di tutti i limiti quelli che sono imposti dal runtime che ti da la lambda.

Esempio banale, non puoi avere un payload credo più di 5 megabyte, né puoi restituire una risposta che sia più di 5 megabyte.

In più il modello non è streaming ma è semplicemente richiesta risposta e c'hai dei json in entrata e in uscita, quindi banalmente già questo ti ha precluso tutta una serie di casi d'uso che magari a latto pratico ne potresti aver bisogno.

Banalmente devo fare un upload di un video, non lo puoi fare direttamente con lambda ma devi utilizzare qualche strumento diverso proprio perché quello ti va a prendere un limite specifico delle lambda.

Poi come abbiamo detto, come ha detto Leonardo, ci sono questi problemi del tipo che il dimensionamento delle lambda è fatto in questo modo proporzionale in cui più aumenti la memoria più aumenta la CPU, questo probabilmente per un discorso interno di come vengono dimensionate le lambda e a lato pratico questa è una leaky abstraction, nel senso che una decisione tecnica di AWS può influire sull'esperienza che l'utente ha e limita le scelte dell'utente.

Altri esempi banali, ci sono dei limiti su quante lambda concorrenti possono esistere in una regione, in un account in un determinato momento, potresti incorrere in un problema nel quale se hai tantissime lambda, in un determinato momento una lambda non può partire perché non c'è abbastanza capacità in quell'account e quella regione e quello ti può portare a altre soluzioni anche un po' paradossali del tipo ok allora riservo questa lambda e la tengo sempre lì pronta a partire, il che significa che tu un oggetto che è stato pensato per essere super scalabile on demand e ti costa pure relativamente tanto se pensi che lo tieni sempre lì ad eseguire, ti ritrovi quasi costretto a doverlo tenere sempre lì attivo semplicemente per riservare quella concorrenza che sennò potrebbe essere rubata da altre lambda.

Quindi ci sono tutta una serie di dettagli tecnici che adesso sto pure un po' estremizzando perché a lato pratico se non si arriva a una certa scala questi problemi non sono neanche dei problemi così così forti però è vero pure che se vai a costruire un'architettura complessa quella promessa di serverless che ti dava meno rogne tecniche in realtà diventa sempre più debole.

Posso farti però una provocazione basata su un tuo blog post recentissimo dove spiegavi qualcosa relativo a S3, gli upload, le signature e quant'altro.

Nel tuo ragionamento, almeno quello che hai fatto adesso, forse non stiamo, ed è un problema che ho anch'io, forse non stiamo rischiando di perdere di vista quella che è la vera utilità, quello che è il motivo per cui dovremmo utilizzare le lambda.

Hai detto bene, se io riservo una lambda vuol dire che o non ho capito una cipa di come funzionano le lambda oppure ho pensato di utilizzare una chiave inglese anche per mettere i chiodi nel muro e questo ci sta quando c'è un team complesso, quando gli devi fare una formazione ed è difficile insegnargli o fare una certa pipeline per il deploy o per l'uso di Fargate o per l'uso di Kubernetes o per altre cose, quindi ci sta.

Però il problema non viene per esempio dal utilizzare uno strumento che non è pensato per quello in un contesto specifico e te lo dico perché vengo con l'esperienza che mi arriva da mia moglie dove in alcune pipeline di big data ho visto usare le lambda e ho detto no amico mio forse in questo caso non è lo strumento giusto delle lambda utilizzate e accese per un sacco di tempo che comunque venivano richiamate in modo che si riduce il cold start, delle cose un po' tricky.

Concordo assolutamente e da una parte secondo me va pure fatta la chiarezza su cosa noi intendiamo per serverless perché ci stiamo concentrando molto su lambda ma lambda è solo diciamo una parte di quello che viene definito serverless, però sono perfettamente d'accordo che lambda in sé come astrazione di compute non è adeguata per tutti i casi d'uso e spesso si fa quest'errore di andare a dire voglio essere serverless first o serverless 100% quindi qualsiasi caso d'uso lo devo risolvere con le lambda e lì poi ti ritrovi a dover fare tutta una serie di cose che magari riesci a risolvere il problema però ti ritrovi a fare qualcosa che non è assolutamente ottimale per quel tipo di applicazione.

Hai detto un'altra cosa interessante che andremo ad analizzare dopo che tutto l'ecosistema serverless quindi non solo lambda però ho visto un dittino muoversi da Luca volevi dire qualcosa? No certo stavo pensando alla difficoltà di non inserire pioli tondi in buchi quadrati come come mi piace dire però anche questo vuol dire dover comunque studiare molto approfonditamente quello che è l'ecosistema serverless quello che AWS offre o quello che google cloud platform offre e così via e quindi di nuovo viene un po' meno quella promessa che dice devi pensare soltanto al tuo domino, alla tua business logic.

Questo lo sto vivendo proprio nella mia pelle proprio perché io comunque c'ho anche un caso d'uso semplice però anche solo proprio perché voglio evitare di usare lo strumento sbagliato nel posto sbagliato io attualmente non sto pensando alla business logic sto pensando a dove infilare i pioli sostanzialmente e quindi no niente appunto speravo sto cercando risposte le troverò in questa puntata credo anche per questo.

Io, Leo volevi dire qualcosa? Volevo non so provare a introdurre un argomento o dire una cosa che mi passa per la testa allora il serverless, l'architettura serverless funziona molto bene nei momenti in cui uno non conosce la diciamo ha dei picchi non lo so di traffico e quindi non vuole stare a scalare manualmente e lascia fare tutto a AWS ma se un business conosce esattamente il traffico il numero di utenti non ha questi picchi tipo black friday eccetera serverless aiuta è funzionale o a quel punto perde la maggior parte del suo vantaggio perché una frase che ho sentito dire un po' di tempo fa in un podcast è enterprises don't use serverless cioè le enterprise le grandi big molloc che sanno esattamente qual è il loro traffico non usano il serverless perché conoscono esattamente le risorse di cui hanno bisogno in quel caso il fatto di non dover gestire i server che non vuol dire attaccare la spina o cambiare il disco andiamo qualche livello sotto ho perso la domanda nel senso come posso dire se uno conosce esattamente le capacità di cui ha bisogno ha bisogno di serverless o gli basta prendere un on-premise con quelle capacità di cui conosce le dimensioni no questa è un'ottima domanda che spesso è un qualcosa di cui discutiamo anche con i nostri clienti e non è mai diciamo una decisione binaria ovvia o si serve le siano perché secondo me bisogna un po chiarire quali sono i vantaggi di serverless nel senso che non sempre un vantaggio di costo come magari se fatta molta enfasi soprattutto all'inizio del di questo fenomeno serverless diceva è però se metti tutto su serverless paghi sempre pochi centesimi piuttosto che magari pagare centinaia o migliaia di dollari al mese che può essere vero ma secondo me non è una diciamo un effetto necessario dell'utilizzare serverless quello dipende molto al caso d'uso e per assurdo serverless potrebbe anche costarti di più se vai a vedere il puro costo del compute appunto c'è tra l'altro un articolo del del sito di Fortiorem che magari poi cerco il link ve lo passo qui che fa proprio un'analisi molto dettagliata su un caso d'uso in cui la necessità di compiut è ben nota e lui confronta a parità di compute se faccio una cosa su isi tu quindi virtual machine pure su rispetto fargate quindi dockerizzazione rispetto lambda ogni volta che tu vai a aumentare il livello d'astrazione quindi in ordine isi tu fargate e lambda c'è un aumento di costo di 20 per quindi sostanzialmente lambda ti va a costare 400 volte di più di isi tu quindi di virtual machine a parità proprio di capacità di compute quindi se tu riuscissi ad ottimare assolutamente l'utilizzo a ottimizzare assolutamente l'utilizzo di isi tu risparmi parecchio rispetto a lambda con un utilizzo costante chiaramente però secondo me quella è una visione parziale del costo perché in realtà va fatto una visione un po' più completa andando a includere quello che viene chiamato il total cost of ownership nel senso che una cosa è il costo proprio del compute in sé ovvero cpu che gira e paghi per quella cpu una cosa è il costo umano di andare a pensare come faccio a mettere in piedi una virtual machine e mantenerna nel tempo come faccio a mettere in piedi una lambda e mantenerna nel tempo e bisogna ricordarsi che quando metti in piedi una virtual machine devi pensare a tutta una serie di cose che con lambda non devi pensare nel senso devi pensare a non solo il dimensionamento ma anche che sistema operativo utilizzo come faccio a tenere l'aggiornato tutto lo stack software da andare a installare come tenere l'aggiornato patch di sicurezza eccetera e quindi diventa un lavoro molto più grande di quello di una lambda in cui benché abbiamo detto che non è al 100% vero in teoria pensa a scrivere una funzione e quella funzione gira poi può relici sono tutta una serie di parametri da configurare ma rispetto a una macchina virtuale la superficie di configurazione è molto più bassa e quindi il costo umano di dover andare a gestire una lambda è più basso di quello di dover andare a gestire una virtual machine quindi secondo me va fatto più questo tipo di analisi cioè non solo l'analisi di costo cpu chiamiamolo così ma non è più completa di ok ma se deve avere una persona dedicata che mi tiene in piedi questa virtual machine ed è una virtual machine critica magari sono 50.000 euro l'anno che sta spendendo così e non ti rendi conto che lei sta spendendo perché è una virtual machine rispetto a una lambda forse sto un po esagerando ma voglio anche approfondire questo tipo di discorso no no era proprio il punto che che tendevo io cioè avere qualcosa da gestire ci devi mettere anche il costo della persona che lo gestisce e magari per la persona che non è economica no? magari per la persona deve trovare quindi non è che uno deve prendere appunto la posizione binaria uno o l'altro però ci sono diciamo dei costi nascosti che uno non vede perché magari il devop ce l'ha già e non considera quel costo all'interno del costo 10.2.

Eh però questa anche era una mia domanda ma possiamo fare a meno veramente di un devop di un caro vecchio sistemista? Cioè credo che per qualcosa per qualcosa anche solo per per gestire le cose di ufficio boh alla fine un cavolo di servizio ti serve su una virtual machine forse forse alla fine qualcuno ti serve che fa che faccia quel lavoro e a quel momento già che la ralla è molto elevata quindi già che lo paghi poi tra virgolette sfruttarlo al 100% dandogli più lavoro quindi più virtual machine da aggiornare e quant'altro.

Cioè mi chiedevo questo perché a me un sistemista proprio mi manca attualmente non ce l'ho ma proprio mi manca perché non per tutto c'è un servizio e non per tutto e non sempre ho il tempo le capacità e le conoscenze per studiare qual è il servizio che che mi serve allora dovrei fare consiglio dovrei chiedere a dovrei fare chiedere una consulenza e comunque quei soldi lo stesso in un modo o nell'altro vanno via.

Posso dire una cosa io adesso mi trovo a lavorare in un progetto che potremmo definire enterprise no? Quindi con una grande azienda con decine di devops ingegner o sre chiamiamoli come ci pare insomma ormai i ruoli sono quasi più delle tipologie delle persone quindi diventa difficile però insomma con parecchia gente che scrive dalla mattina alla sera a terra forma e vive dentro cloud watch e sistemi di monitoring vari ed eventuali.

E' una cosa un pattern che ho trovato non solo in questa grande grande multinazionale ma anche in altre società piuttosto grandi e nonostante i costi una virata verso i servizi managed e questo un po' è in controtendenza a quello che ha scritto DDD qualche qualche giorno fa no? Parlando dei costi di AWS e insomma del suo flame.

Però pur con una forte presenza di utilizziamo il termine old school di sistemisti o di DDD e cavolo si opta per una serie di servizi managed per capirci le app sono deploiate con se siamo in ambito azur app service o se devo fare una qualche qualche feature qualche funzione qualche qualche azione automatizzare qualcosa si usano le serverless functions piuttosto che pur avendo le risorse in house piuttosto che insomma non si dice piuttosto che ma freghiamocene piuttosto che insomma tirare in house ottenere in house un'architettura che diventa ancora più complessa di quello che è.

Allora mi chiedo e lo chiedo a Luciano specialmente forse è cambiato anche il modo con con l'avvento di serverless in una visione un po' più ampia no? Quindi compresa la visione del database serverless e dei container serverless della storage dei file fondamentalmente serverless come S3 è cambiato proprio il modo che siccome tu sei anche un full stack developer il modo in cui pensiamo il software? Si concordo assolutamente secondo me andiamo con questo con questo tipo di osservazione ad avvicinarci di più a quello che sono il vantaggio di serverless nonostante abbiamo detto che la promessa di serverless non è che sia stata così mantenuta negli anni però secondo me continua un po' ad esserci della verità in quella promessa di serverless nel senso che serverless ci porta molto di più ad essere agili quando si parla di mettere in piedi una cosa nuova.

Esempio banale quando diciamo in un mondo tradizionale on premise bisognava mettere in piedi un qualsiasi nuovo servizio dalla cosa più banale immaginiamo che ne so una web book che deve rispondere ad un evento c'era veramente tanto lavoro di burocrazia da fare bisognava andare dall IT dal tizio dell'IT e dire sai dove è una macchina in cui posso mettere in piedi questa cosa mi crei il certificato mi serve un dominio queste queste altre passavano due tre quattro settimane prima di poter avere l'ambiente su cui andare a rilasciare magari 15 righe di codice.

Secondo me serverless è in generale tutto questo mondo di servizi più managed come possiamo pure pensare che ne so DynamoDB per quanto non è una strazione che mi faccia impazzire è vero pure se tu devi pensare a mettere in piedi un RDS che già RDS c'è tutta una serie di roba managed o piuttosto addirittura farti il tuo postgres da zero rispetto a creare una tabella su DynamoDB DynamoDB ci metti 0,5 minuti a far partire un'istanza RDS che già appunto c'è tanto managed ci vuole almeno mezz'ora quindi secondo me è più quello il tipo di ragionamento in un mondo che è sempre più agile sempre più dinamico in cui le aziende devono riuscire a sperimentare e mettere in piedi i servizi in modo quanto più veloce possibile lì secondo me la promessa di serverless e di questi servizi managed diventa un po' più importante benché secondo me la strazione perfetta ancora non si è raggiunta.

Però io sono uno stronzo e tu lo sai bene no? E adesso arriva la prima domanda cattiva alla quale io in realtà non so dare risposta è una domanda che mi pongo sempre ma sono bloccato là e dico sì vabbè abbiamo detto che in qualche modo il mondo serverless l'ecosistema serverless al di là del provider proprio in modo astratto più generale sta in qualche modo cambiando il modo che abbiamo di vedere il software perché fondamentalmente quello che noi facevamo quando scrivere scrivevamo il codice erano due cose la nostra applicazione aveva due importanti funzioni forse sto riducendo un po' ma secondo me i due le due grandi responsabilità di qualunque tipo di applicazione scritta sono eseguire business logic quindi logica specifica collegata al business di contesto e avere una sorta di glue code che metteva insieme una serie di elementi e lato codice si occupava dell'orchestrazione di queste componenti quindi la connessione al database piuttosto che la connessione al sistema di caching il redis della situazione.

L'ecosistema serverless ha un po' spostato purgato tutto il concetto di glue code fuori dal concetto di applicazione o perlomeno questa è la tendenza no? A questo punto il focus è sulla logica di business che ha come concetto principale rannare workflow se insieme al glue code purghiamo anche il crude della situazione rimangono veramente i workflow che sono delle funzioni e là il concetto fitta one to one proprio col concetto di computazione serverless.

Nel contesto però c'è tutta un'altra orchestra di servizi serverless che ha solvono problemi diversi e c'è tutto il mondo dell'orchestrazione parliamo di AWS in ambiente AWS con cloud formation o lo strumento della situazione che si occupa proprio di scriverti questo glue code spostando le responsabilità tutte sull'infrastruttura per cui a questo punto la vera ownership del team di sviluppo rimane la logica di business e dico la logica di business purgando anche il crude perché AWS ha tutta una serie di sistemi che semplificano anche le azioni di create, delete e quant'altro all'interno di una certa data source.

Per cui la mia domanda è posto che tutto questo è fighissimo perché ti riduce ai minimi termini il time to market riduce il numero di sistemi stiche tutti lì dentro.

A livello sviluppatore ha senso a questo punto preoccuparsi della ownership della propria applicazione? Quanta complessità vedi su tool o quanto vedi funzionare dei tool cloud agnostic che in qualche modo astragano questo tipo di dipendenza? Ok porti un bel argomento quindi cerco di risponderti un po' in ordine e sperando di darsi una risposta sensata.

Da una parte mi viene in mente ad esempio il discorso step functions basato su quello che hai detto ovvero che su AWS uno strumento ti permette di creare anche in modo visuale esiste pure un editor visuale tra l'altro l'ultima release pure fatta abbastanza bene per gli standard di AWS che ti permette proprio di dire quasi con logica no code o comunque low code voglio combinare tutta una serie di step fare degli if fare dei retry fare delle azioni in parallelo e poi effettivamente andare a creare dei workflow pure abbastanza complessi con una quantità di codice veramente minimale e soprattutto facendo rigirare su un ambiente che è totalmente managed in cui non ti devi preoccupare del fatto che non ci fosse se la capacità o che non riesce a scalare o altri problemi di natura puramente infrastrutturale.

Quindi assolutamente vero il fatto che c'è molto una tendenza a cercare di darti quanta più roba as a service possibile e tra l'altro proprio parlando step function una delle cose che hanno introdotto anche abbastanza recente credo sia a meno di un anno è il fatto che ad esempio l'SDK di AWS quindi tutte le chiamate che ti permettono di invocare tutti gli altri servizi di AWS adesso sono disponibili nelle step function come step nativi quindi in tutta una serie di circostanze non devi neanche andarti a scrivere una lambda per dire voglio chiamare quest'altro servizio ma semplicemente c'è il blocchettino che dice vabbè i dati che sono venuti fuori da qui metti direttamente su DynamoDB oppure leggi da DynamoDB fai questo filtro e poi manda i dati da un'altra parte e tutta questa cosa è estremamente managed nel senso che magari non è scritto una riga di codice per quello intendo codice business logic però d'altra parte c'è una tendenza che forse viene un po' sottovalutata che è forse pure una buona pratica ma forse ne viene sottovalutata l'importanza che tutto quello che fai in modo visuale o comunque manage o comunque generato con tutta una serie di tool alla fine se lo devi fare in modo enterprise è tutto infrastructure as code che da qualche parte devi scrivere quindi secondo me si sta shiftando molto il fatto che una volta scriviamo tutto un sacco di business logic che non era necessariamente business nel senso funzionale al business ma era più funzionale all'infrastruttura però la scrive sottoforma di codice adesso tutto quello lo stiamo delegando al cloud provider però in qualche modo al cloud provider dobbiamo dire come mettere insieme tutti questi pezzi e quello diventa tutta infrastructure as code che da una parte bisogna imparare tutti gli strumenti dall'altra è comunque codice benché non codice logico ma più codice di diciamo dichiarativo insomma più di configurazione che però va comunque messo su repository va mantenuto vanno fatte le CICD basate su quel codice vanno fatti i test eccetera eccetera quindi non so se sto andando per una tangente invece di rispondere alla tua domanda ma questo è quello che mi viene in mente ma scusate ti tiro in ballo un'altra un'altra cosa che di cui sto cercando una risposta in tutto questo i test come vengono fatti perché tralasciando i unit test quindi quando riesci a testare i singoli componenti le singole funzioni con tutte le best practice del caso però poi come fai a testare tutto tutto insieme come fai a testare il tutto il giro tutto il workflow che bisogna seguire che strategia ci si può adottare o si deve adottare con AWS o in generale sì tra l'altro mi sono appena ricordato che non ho risposto alla domanda riguardo la cloud abstraction quindi magari dei servizi che riescono a strarre il fatto che tu possa essere su AWS piuttosto che azure piuttosto che su google quindi cercherò di rispondere anche includendo questo o ne riparliamo dopo però in generale quello del testing è uno dei temi sui quali secondo me ad oggi cioè ci sono varie pratiche però secondo non c'è una pratica che è quella che su cui tutti diciamo sono d'accordo che sia il modo migliore di fare i test e di test parla in senso molto lato cioè banalmente non parliamo di test automatizzati ma del fatto che tu hai scritto una riga di codice aggiuntiva e prima di deploiarla a qualche parte ti chiedi ma funziona fa quello che deve fare come la testo anche manualmente cioè non voglio necessariamente scrivere un test automatizzato ma banalmente voglio eseguire questo codice che ho cambiato nella mia macchina locale per vedere se effettivamente fa quello che io penso che debba fare e banalmente questo è un tema che su cui ci sono 50 anni di storia nel senso da quando esiste l'informatica si scrivono cose locale le esegui vedi se funzionano poi puoi anche scrivere test automatizzati ma è sempre stata quasi una cosa ovvia il fatto di poter eseguire le cose locale a meno che magari facciamo un mega passi indietro quando c'erano i mainframe dovevi mandare il job però va beh dimentichiamoci magari quella fase iniziale della storia dell'informatica e pensiamo magari anni un po' più recenti da sistemi operativi un po' più moderni e secondo me con serverless si va un po' a perdere quel tipo di abilità di eseguire le cose localmente nel senso che più deleghiamo cose al cloud provider più ci troviamo ad avere meno roba che scriviamo noi che effettivamente possiamo eseguire nel nostro ambiente locale perché per quando il cloud provider o terzi ti possono dare degli strumenti per simulare quello che andrà a fare il cloud provider comunque spesso sono delle simulazioni e comunque chiaramente non puoi eseguire un intero cloud provider nella tua macchina quindi ti ritroverai ad avere delle astrazioni che non necessariamente vanno a compaciare al 100% con quello che poi ti troverai in produzione come ambiente di esecuzione quindi ci sono tutta una serie di approcci anche un po' ibridi che sto vedendo nel senso che c'è chi ancora apprezza il fatto di poter eseguire qualcosa localmente benché il livello di fidelità con l'ambiente finale è sempre più distante quindi magari accetti che l'ambiente locale non è perfetto rispetto a quello che avrai su AWS o su un altro cloud provider però comunque una prima astrazione mi permette di vedere se il mio codice più o meno fa quello che deve fare dopodiché sto vedendo che c'è una tendenza a cercare di ridurre quanto più possibile i tempi di deployment e far sì che l'ambiente cloud diventa il tuo ambiente di sviluppo chiaramente non stiamo parlando di rilasciare di continuo in produzione ma di avere un ambiente cloud di sviluppo che è molto più simile all'ambiente che avrai in produzione e il problema a quel punto dipende quanto riesci a aggiornare quel codice in cloud velocemente così da avere un feedback loop che più vicino possibile a quello di eseguire tutto localmente e ad oggi secondo me non c'è una soluzione perfetta benché se andiamo a vedere alcuni nuovi tool che hanno inserito all'interno di SAM o CDK cercano in qualche modo di farti rilasciare il codice o addirittura di sincronizzartelo quasi come se fosse un watch live in modo più veloce possibile in modo che riduci quel tipo di feedback loop e quello è un altro approccio l'altro approccio ancora è quello di creare appunto dei test automatizzati che prima di fare un rilascio in produzione effettivamente stanno testando tutto quello che tu hai fatto in un ambiente che è totalmente uguale a quello che avrai in produzione e ti danno un feedback sì tutti i test sono passati allora procedo con il rilascio in produzione oppure no e secondo me non c'è una pratica perfetta ribadisco questo l'insieme di tutte queste pratiche ti può dare un buon livello di fiducia nel fatto che se tu fai una modifica poi quando andrai a portare in produzione non hai sorprese particolari e giusto per inserirmi nel discorso di cloud abstraction tutto questo è molto cloud specifica ad oggi nel senso noi andiamo a utilizzare step function piuttosto che lambda piuttosto che dynamo db piuttosto che sqs oss e nesso questi servizi che diciamo sono tra l'altro da quelli più base che un po' tutti utilizzano sqs sono fondamentalmente diversi se vai a utilizzare gli equivalenti su azure o su google proprio a livello di api quindi banalmente voler utilizzare una abstrazione e sì magari ne esistono ma praticamente ti vai a a portare il tuo problema un minimo comune denominatore di funzionalità che tutti supportano e ti stai perdendo i vantaggi specifici ogni cloud provider quindi forse un discorso che da una parte sconsiglierei dall'altra possiamo pure andare a parlare di kubernetes di tutto quel tipo di abstrazione lì che un po' cerca di risolvere quel problema di un ambiente un po' più universale che è più semplice da emulare localmente ed è anche un po' più uniforme quando poi lo andiamo a portare in produzione sul cloud spero di aver risposto senza dire cosa no no no hai risposto benissimo che secondo me quello che evidenziate è importante cioè per diventare cloud agnostic andiamo a costruire una un ulteriore livello d'astrazione sopra una serie di livelli d'astrazione che alla fine diventa astrale all'astratto per cui si può con tool come kubernetes in modo più pragmatico eliminiamo una serie di livelli d'astrazione creandone uno unico o comunque un quasi layer unico d'astrazione.

La ricerca del cloud agnostic è più una cosa che i dev o i devops cercano perché dice io vorrei deployare questo su AWS e poi domani senza cambiare nulla voglio deploiarlo su google cloud però nel frattempo amazon e google fanno in modo che questa cosa non sia possibile perché loro vogliono il lock in quindi io quando avevo negli ultimi mesi in near form sono passato a fare il devops avevo sentito di questa terra fanno detto posso deployare tutto dove mi pare e no sei su AWS fai la lambda e fai la mia game, sei su google fai altre cose e ti perdi i vantaggi quindi devi scrivere sempre due volte il codice però è chiaro che amazon ha tutto l'interesse per marketizzare i propri vantaggi e fare in modo che siamo diversi da quelli di google perché poi dopo deve essere più difficile nella loro ottica per il cliente spostarsi su google perché se no non ci sarebbe business quindi è un po' una lotta un po' ibari.

Devo dire che spostando un po' il focus se dovessi fermarmi e pensare al serverless oggi credo che molto del boost è stato anche dato dall'apparire nel mercato di tutto ciò che riguarda il gem stack quindi city stati, ship building, ridurre al minimo la logica di business, non far girare tutto il sito ma solo quello che veramente serve quindi ridurre computazione da quel punto di vista, spostare molta computazione che andava prima nei nostri backend monolitici a build time quindi da un'altra parte il trend della computazione serverless ci ha portato in modo positivo anche a ottimizzare energia diciamola anche qua però nel contempo più creiamo nuovi livelli di astrazione più ci allontaniamo da quello che in realtà è fisicamente quello che facciamo e questo ha un certo effetto anche se ci connettiamo a un ragionamento o a un concetto di tipo ambientale cioè il fatto di essere così lontano dal ferro probabilmente ci fa perdere consapevolezza di quello che è il consumo energetico un altro elemento che ci fa perdere consapevolezza del consumo energetico è il gratis.

Adesso signori di AWS per favore chiudete le orecchie non sto parlando con voi quindi lasciate quello che c'è come vi prego ma quanto il free tier è stato trigger meccanismo di successo di questi servizi serverless e quanto in realtà lo stesso free tier ha triggerato ha stimolato il misuso l'uso sbagliato di questi strumenti.

Ah però scusa una parentesi che ho sentito oggi su continuous delivery che salutiamo che chat gpt spendono 3 milioni di dollari al giorno di data center.

Sì vabbè ma c'è microsoft che pagala quindi.

Quindi mi ripeti la domanda e me la so persa in quest'ultima osservazione.

No l'impatto che ha avuto il concetto di free tier nell'adozione dei servizi serverless è l'impatto che ha avuto lo stesso free tier nel misuso l'uso sbagliato di questi servizi.

E' una bella domanda non so se è una cosa che potrebbe essere facile da calcolare io poi ho un'opinione molto pro free tier nel senso che anzi vorrei che AWS facesse di più nel senso rendesse più semplice per chi magari uno studente universitario che non si può permettere di avere una carta di credito di essere in grado comunque di provare a utilizzare questi servizi e imparare e ad oggi secondo me AWS da questo punto di vista non fa un ottimo lavoro.

Capisco il tuo punto di vista nel senso che è vero che c'è molto la logica del free molto la logica di buttare online tanto costa poco e a volte ci ritroviamo a mettere in piedi roba che effettivamente o è fatta male nel senso che non è abbastanza ottimizzata o non è neanche necessaria tanto costa poco tanto è gratis quindi nessuno si preoccupa.

Però d'altro canto va pure osservato il fatto e questo l'hai detto pure tu che serverless come paradigma è un po' più eco friendly dei paradigmi un po' più tradizionali cloud o anche on premise nel senso che tipicamente quando vai a mettere in piedi una macchina virtuale o cloud on premise che sia devi sempre dargli molto più buffer di quello che ti serve perché non riesce a scalare in modo così dinamico quindi all'atto pratico magari tu c'hai una macchina che consuma teoricamente 100 quando ti serve due e quel 100 magari lo raggiunge una volta al mese in un picco ben preciso quindi stai pagando per un mese 100 tutti i giorni quando magari quel 100 ti serve un'ora al mese.

Con serverless riesce un po' quella curva di utilizzo a ottimizzarla e questo teoricamente dovrebbe dare un modello un po' più eco sostenibile ora tutti i cloud provider quando si parla di eco sostenibilità secondo noi fanno un po' di fuffa cioè è difficile avere delle metriche chiare perché poi magari dovrebbero tirare fuori tutta una serie di dettagli tecnici che non vogliono tirare fuori però per fortuna questo discorso dell'eco sostenibilità sta diventando un tema sempre più importante al punto che non so se sapete che AWS ha questi pillar del well architected framework di recente hanno proprio introdotto un pillar che è quello che cerca di capire qual è l'impatto da un punto di vista ambientale delle soluzioni cloud e come cercare di ottimizzare anche da quel punto di vista.

Discorso che secondo me andrebbe su cui andrebbe fatta più enfasi su cui andrebbero sviluppati più strumenti su cui andrebbe fatta più trasparenza però secondo me è già un buon passo avanti il fatto che se ne parli sempre di più e che diventi un argomento sempre più importante sia per aziende piccole tanto quanto per aziende più grandi.

Sei on mute.

Sì stavo cercando il pulsante ve l'ho detto ormai sono bollito tra l'altro hai citato la cosa interessante del well architected framework che devo dire che ho scoperto solo stamattina ed è una figata pazzesca e all'interno del well architected framework c'è ho trovato un documento o comunque un gruppo di documenti che era il serverless application lens che è un documento che in qualche modo tra le varie cose che fa evidenzia anche delle topologie di architettura serverless e delle best practice per la creazione di architetture specifiche.

Ad oggi secondo te quali sono se dovessi portare sul tavolo tre casi d'uso dove veramente il serverless in senso ampio e quindi non solo lambda dà il meglio di sé.

Quali sono i casi dove veramente dici sei fatto proprio per questo? Guarda ne parlavo proprio di recente con un amico che mi ha chiesto una serie di opinioni lui doveva sviluppare un nuovo progetto all'interno della propria azienda e si chiedeva mi conviene andare a provare un approccio serverless perché magari un qualcosa che andando avanti con la tecnologia e con l'adattazione cloud tutti si sposteranno su quel tipo di approccio e quindi naturalmente devo andare a finire lì o posso tenere un approccio più tradizionale e ovviamente non è che c'è una risposta binaria sì o no c'è il fantastico depends con cui risponde a tutte le domande da consulente.

Però l'irraggionamento secondo me che è poi interessante che è venuto fuori a quel tipo di conversazione è sempre il fatto di ma il tuo team che tipo di competenze ha e quanto vuole imparare roba nuova e ovviamente tutto ciò correlato al fatto quale sono le tue deadline che tipo di prodotto stai costruendo e che tempistiche hai per andare sul mercato con questo nuovo prodotto quindi di nuovo non c'è una risposta semplice ma devi andare a osservare tutto questo tipo di cose e cercare di capire quali sono le leve che ha a disposizione alla fine e tirare fuori una strategia pratica.

E in quel caso una delle osservazioni che abbiamo notato è se vuoi provare serverless perché è una cosa che i tuoi sviluppatori vogliono provare perché c'è anche un po' di hype e loro si sentono che se non hanno fatto un po' di serverless magari stanno vendo roba obsoleta e non non gli piace.

Uno dei casi che secondo me ideali è quello di quando devi andare a fare background processing e quindi sostanzialmente c'è magari un'applicazione fatta in modo tradizionale facciamo finto un web server ad esempio c'è il tuo container o virtual machine che sia gira un processo 24 ore su 24 arrivano richieste risponde se però c'è tutta una serie di roba che deve essere fatto in background non lo so mandare le mail mandare le notifiche ridimensionare immagini o quello che sia il fatto di andare a utilizzare strumenti come sqs e lambda per fare questo tipo di lavoro secondo me uno dei casi d'uso più ideali perché ti leva una marea di complessità infinita e effettivamente secondo me sqs e lambda sono proprio ottimizzati per quel tipo di caso d'uso quindi quello è forse uno dei primissimi casi d'uso che consiglierei a chi vuole iniziare a utilizzare lambda se c'è quel tipo di problema inizia a spostare quel tipo di computazione su sqs e lambda e lì comincia a esplorare che vuol dire scrivere una lambda che vuol dire collegarla sqs che vuol dire il fatto che le lambda scalano in modo dinamico in base a quanti dati stanno su sqs e così via quindi quello è un tipo di architettura chiamiamolo non lo so background processing processing asincrono non ti so dire se c'è un nome più più adeguato altri casi molto comuni sono quello di fare api con api gateway lambda lì secondo me può andare bene in tutta una serie di casi ma non va generalizzato lo uso sempre per tutto perché appunto come diciamo all'inizio della puntata se banalmente deve fare l'upload di un file non è la soluzione migliore farlo con api gateway lambda molto probabilmente non è una buona soluzione per niente quindi le piase con l'essere dopo aver letto il post di luciano ok anche quello lo metteremo nei link grazie della pubblicità però banalmente se ad esempio devi fare un webbook cioè c'è un evento che t'arriva da qualche altro servizio e vuoi avere un end point che riceve quell'evento e fa qualcosa fare una lambda è semplicissimo piuttosto che andare a mettere in piedi un web server tradizionale quindi anche lì si parla comunque di end point http però dipende il caso d'uso può essere ideale farlo con lambda piuttosto che magari non sempre così ideale è un altro caso d'uso che se non è uno molto interessante su cui c'è secondo me tanto che vedremo negli anni futuri è quello del big data e anche tu l'hai menzionato quasi come un caso in antitesi per il serverless ti dirò che ho lavorato con un cliente tra l'altro è uno dei casi d'uso secondo me più interessanti su cui ho lavorato in cui abbiamo costruito una pipeline che riesce a calcolare veramente terabyte di dati ed è quasi tutta costruita su serverless e lì il vantaggio è che ci sono tutta una serie di workflow che in base a come vengono configurati c'hai uno spike iniziale di computazione e quindi se dovessi far partire delle virtual machine o anche dei container il tempo iniziale di bootstrap è talmente alto che a far partire le lambda benché alla fine la computazione ti costa di più però il cliente riesce a avere una risposta nel minor tempo possibile per loro quella è la cosa più importante quindi pure lì ci sono dei trade off interessanti per cui benché anch'io sono abbastanza d'accordo nel dire che se devi fare big data e magari ti servono delle macchine belle grosse che girano sempre nel 99% dei casi quella è la soluzione corretta ci possono essere le variazioni di quel tipo di problema in cui magari serverless risulta essere la cosa più ideale proprio per quella caratteristica che ha di scalare molto velocemente da 0 a 100 non so se ho risposto sì sì tra l'altro aggiungo una piccola parentesi la mia critica particolare era verso lambda nel mondo big data tu hai tirato fuori un caso d'uso che funziona ma io ci tengo anche a evidenziare che AWS visto che stiamo parlando di AWS ha tutta un'altra serie di servizi serverless per il mondo dei big data uno dei quali è per esempio Athena che è già pensato strutturato e ragiona in un'ottica un po' più diversa quindi il mio esempio di serverless function era correlato al fatto di usare probabilmente uno strumento nel caso che avevo visto io era utilizzare uno strumento per il quale magari non fittava al 100% volevo chiederti anche un'altra cosa interessante in realtà che riguarda proprio al concetto sempre di serverless function e riguarda nel fatto che proprio nella parola no quando si parla di computazione serverless si ragiona in termini di funzione no però nel contempo ti trovi degli strumenti che ti buttano un Laravel dentro una serverless function come reagisci davanti a questo tipo di uso è un misuso o è un caso d'uso che ha anche senso? Io sono all'estate abbastanza contrario anche magari Laravel è un caso estremo ma anche Express che è molto più lightweight non lo metterei dentro una lambda per fare web server perché secondo me lì c'è proprio un problema di astrazioni che non matchano al 100% nel senso che se tu prendi questo tipo di web framework tradizionali sono pensati per girare con una socket TCP che ti gestisce questa connessione HTTP ti arriva una richiesta manda una risposta su questa connessione e il web framework è proprio in controllo di questa connessione può decidere di fare streaming di tagliare questa richiesta a metà fare tutta una serie di cose che nel paradigma lambda non esistono perché l'astrazione sta dopo cioè nel paradigma lambda c'è un evento e una risposta e entrambi sono dei json che vengono totalmente bufferizzati in entrate e uscite non c'è nessun tipo di connessione permanente quindi quello che ci sono degli adapter che trovi per l'arabel per express che ti permettono di far sì che questi eventi vengono convertiti in diciamo richieste risposte finte per dal punto di vista del framework però quello fa sì che tutta una serie di cose poi magari non funziona come tu ti aspetteresti banalmente torniamo sempre al discorso dell'app lodo del download quindi casi d'uso un po più streaming non non funzioneranno quando tu li utilizzi nel contesto di diciamo una un deployment di express dentro una lambda se tu vai a utilizzare quelle funzioni di streaming non possono mai funzionare come funzionerebbero normalmente in un web server quindi secondo me il rischio è sì magari per il 90 per cento dei casi d'uso non vedi la differenza però ci sono un 10 per cento di casi d'uso in cui non funziona proprio e alla fin della fiera ti ritrovi a dover pagare il costo di una strazione che non so che vantaggio ti dà magari l'unico vantaggio che puoi avere la familiarità con quello strumento ma lo stai andando a calare in un contesto che non segue al 100 per cento le regole per cui quello strumento è stato pensato quindi io continuo sempre a sconsigliare quel tipo di approccio poi è vero pure ci possono essere delle condizioni molto particolari in cui dici vabbè ma c'è questo codice in express già scritto è una cosa piccola la prendo e la tiro in una lambda perché comunque voglio andare a fare delle lambda nel breve medio periodo può essere un trade off accettabile se sai esattamente a cosa puoi andare incontro ma non lo farei insomma come best practice anche perché come scorciatoia diciamo anche perché i tempi di boot della lambda e dt express dentro la lambda vogliono dire soldi no? Esatto quindi stai andando a pagare quel tipo di astrazione per non credo avere un tipo di vantaggio pratico se non quello che si se magari già ce l'hai scritta così non devi riscriverla in un altro modo.

Certo ma hai detto prima no che in realtà anzi abbiamo detto che in realtà c'è tutto il mondo tutta la parte di glue code si è spostata talvolta si sposta verso l'architettura l'infrastruttura e tra i servizi di AWS c'è sempre un servizio serverless che ha catturato la mia attenzione e che è Upsync che è GraphQL as a service che mettiamola così.

Quando Luciano potrebbe scegliere cioè quali sono le condizioni per le quali tu saresti tentato di andare verso una soluzione gestita come Upsync e quando invece preferiresti tirarti su il tuo buon appollo che ti chiama i tuoi microservizi davanti magari a un API gateway della situazione? Allora su questo argomento sono piuttosto ignorante quindi ti do una risposta molto vaga nel senso che ho praticamente quasi mai fatto GraphQL in produzione ho solo fatto così dei giochini per per conto mio personale quindi non ti saprei dire quanto Upsync effettivamente a livello proprio di feature è in pari con un Apollo Server mi aspetto conoscendo AWS che non lo sia nel senso che un Apollo Server magari ti da molta più flessibilità rispetto ad Upsync e quindi forse il trade off è sempre un po' lo stesso quello di dire ma quanta voglia c'ho tempo risorse di andarmi a gestire io un container che sia o una macchina virtuale rispetto con qualcosa che dico vabbè quando arriva a sta chiamata parte sta lambda che già ho scritto e basta e non mi interessa pensare al sistema operativo alle librerie eccetera quindi forse fare questo tipo di ragionamento e dipende dalla complessità del tipo di applicazione che stiamo andando a scrivere e il tipo di feature che mi servono magari posso decidere vale la pena andare a pagare quel costo aggiuntivo di manutenzione dell'infrastruttura piuttosto che andare a utilizzare un servizio managed come Upsync ma ripeto non conoscendo benissimo i dettagli di della tecnologia specifica quello che ho detto potrebbe avere più o meno senso.

No io ritornando ad Upsync tipo ha catturato la mia attenzione perché è uno strumento che fa praticamente buona parte di quello che il nostro buon amico Carmine chiamerebbe il crudino della chiesa su GraphQL nel senso che si interfaccia e proprio come buona parte dei prodotti AWS pensato per interfacciarsi con gli altri servizi di AWS quindi si ti può chiamare una lambda che possiamo vedere in modo un po' con la zappa come un microservizio ma ti può anche chiamare l'open search della situazione che è l'omologo di Elasticsearch as a service o puoi andare a scrivere roba su Dynamo o su Aurora anche questi magari serverless e qua io dico vabbè a questo punto credimi il po' di lavoro scimmiesco di due sviluppatori te lo sei tirato via perché anche questo dobbiamo dire quindi cioè spostando una parte di responsabilità nell'infrastruttura stiamo anche andando verso un approccio un pelino più no code o siccome usiamo infrastructure as a code potremmo dire un po' codeless no? Nel senso scrivere un terraform è sicuramente più conciso poi insomma terraform è abbastanza verboso però scrivere un terraform è sicuramente più conciso che fare il servizio GraphQL e i crude a mano nel contempo però ho ne approfittato per introdurre tutto il concetto di database serverless su questi quindi Aurora serverless Dynamo hai già anticipato che hai qualche strong opinion su Dynamo qual è però la tua visione nel concetto generale no di data storage in termini di dati di questo tipo? Sì diciamo la mia strong opinion rispetto a Dynamo è il fatto che viene un po' venduto come database general purpose quando secondo me lo è relativamente nel senso che è un ottimo database quando già sai esattamente tutti gli access pattern ai dati e di conseguenza in quel caso puoi andare a ottimizzare proprio la struttura del database per quegli access pattern e c'hai tutta una serie di vantaggi cioè sicuramente un database molto efficiente già distribuito il livello di manutenzione minimo però non è un database molto dinamico nel senso che se l'indomani a livello di business ti rendi conto che hai sbagliato qualcosa o ti serve un campo in più o devi modificare un workflow buon divertimento a fare una migrazione dei dati perché non esiste neanche il concetto di migrazione dei dati cioè ti devi andare a fare tutto tu da solo e mi è capitato di dover fare questa cosa DynamoDB e la complessità è assurda cioè quello che tu faresti con un sequel che dici alter table aggiungi un nuovo campo e questo campo deve avere il valore del campo precedente moltiplicato per due che è una query che ci metti due secondi a scriverla a farla in DynamoDB ci perdi le settimane solo a capire come orchestrare un workflow che ti fa lo scan di tutto e ti aggiorna tutti tutti i record quindi cioè vanno vanno tenute in considerazione queste cose secondo me a livello di marketing non viene venduto DynamoDB con questo tipo di prospettiva ma viene venduto come vabbè se fai serverless usi DynamoDB di default e puoi fare tutto addirittura che non è necessariamente vero.

Mi ricordi io ho lavorato poco con DynamoDB ma mentre mi documentavo avevo letto che c'erano anche dei pattern di single table cioè te metti tutte le date nella singola tabella e poi lavori solo sui filtri sui dati che ci sono che per uno che viene da un database anche documentale ma se no è skew head dice va bene gli utenti li mettono nella tabella utenti i prodotti nella tabella prodotti invece lì metti tutto insieme e fai dei filtri per tirare fuori dallo stesso bucket questa cosa che è un po' difficile da intuire.

Non concordo assolutamente c'è un libro intero di Alex Debrie che tra l'altro consiglio perché è un ottimo libro solo per capire come applicare questo tipo di mentalità quindi non è una cosa così ovvia cioè non è una cosa che di default ti viene da andare a impostare un database in questo modo e questo tipo di approccio a mia opinione ma forse mi riservo pure il fatto di non aver capito al 100% quello che Alex voleva comunicare con questo suo libro sì magari ti dà un po' di libertà in più nel data modeling di evolvere quel data modeling man mano che scopri dei nuovi requisiti o deve implementare le nuove funzionalità ma comunque secondo me parte da un presupposto in cui hai già molto più chiaro di quello che avresti magari con un approccio SQL tradizionale quali sono gli access pattern rispetto a appunto confrontando il modello SQL col modello no SQL secondo me la differenza chiave è proprio quella che il modello SQL è pensato per dire tu mi dici quali sono i dati io mi vedo tutto il resto e se vuoi cambiare le cose hai tutti gli strumenti per farlo e ti cerco di diminuire al massimo la duplicazione dei dati il modello no SQL è proprio diametralmente opposto cioè io ti ottimizzo per degli access pattern specifici se ne vuoi altri duplica i dati e quelli sono ottimizzati pure e questa non è una cosa che viene comunicata bene a livello di marketing cioè viene più che altro detto se fai serverless devi usare DynamoDB se fai applicazioni tradizionali che girano su virtual machine puoi usare SQL quando secondo me questa cosa non è cioè l'uno non escude necessariamente l'altro.

Eppure sembra strano sai perché quello che dici non fa non fa una piega sono tipo d'accordo al 200 per cento però nella zona B del mio cervello mi è ritornato in mente un mantra che era il mantra ed è il mantra di tutto il movimento no SQL no? Cioè tutto ciò che riguarda SQL possiamo vederlo con SQL e no SQL sono delle parole di marketing noi potremmo dire schema on write per tutto il mondo di SQL e schema on read per tutto il mondo no SQL che però è una cosa che fa conflige in qualche modo con quello che hai appena detto e sul quale sono d'accordo tra l'altro cioè se io voglio accedere ai dati in modo in modo in modo anche efficiente non deve aver già pensato al motivo per cui voglio accedere questa cosa nella mia testa sta prendendo a schiaffi col concetto di schema on read perché in realtà nella definizione implicita no di schema on read sto dicendo esattamente il contrario cioè definisco lo schema dei dati quando vado a leggerli adesso io non chiedo a nessuno di dare una risposta a questa piccola pazzia però ecco vi chiedo e chiedo anche a tutti gli ascoltati di fermarsi un attimo a riflettere su questa contraddizione perché probabilmente c'è una contraddizione anche nel modo nel quale noi vediamo queste tecnologie no? Cosa ne dite? Secondo me c'è pure un'altra dimensione da esplorare che forse viene sempre un po' messa in secondo piano che è quella proprio dell'architettura di questi due diversi diciamo tipologie di database in genere quando prendi SQL si parla sempre o quasi sempre del database monolitico che ti dà tutta una serie di caratteristiche e proprio perché è monolitico tutto sta in un unico server può fare tutta una serie di cose quando si parla di NoSQL si pensa già a database distribuiti che quindi devono capire già come partizionare i dati e come conseguenza di ciò ci hanno pure tutta una serie di limitazioni aggiuntive e quindi magari si tente di più alla duplicazione dei dati perché quella è diciamo la soluzione più semplice al problema o a diminuire le capacità di query perché anche quello ti permette di fare tutta una serie di cose in più dal punto di vista della distribuzione dei dati e quando fai una query di andare a interrogare più nodi e riaggregare risultati quindi quella secondo me è una cosa che viene sempre messo un po' in secondo piano perché raramente si va a guardare l'architettura del database e si pensa più dal punto di vista utente qual è il linguaggio di query e quali sono le capacità che hai però secondo me se ci andiamo a leggere ad esempio il paper di DynamoDB che poi quello che ha pure ispirato Cassandra si capisce anche il perché DynamoDB o Cassandra che sia siano molto più limitate a un punto di vista di gestione dei dati di quanto sia il classico database SQL monolitico in cui non hai il problema di dover distribuire dati e aggregare le query.

Senza neanche aprire il capitolo transazioni perché a quel punto veramente la diversità si acuisce e questo dimostra un fatto importante che in buona parte delle nostre applicazioni noi utilizziamo un tool perché il contesto ci spinge, il marketing ci spinge, quando magari fermarci un attimo e leggere un libro che per me è quasi più importante della Bibbia tipo Data Intensive Applications che secondo me è veramente un viaggio, cioè a me ha aiutato proprio a sviluppare quel tipo di consapevolezza che spesso dimentico ma comunque mi ha aiutato a costruirla per capire che talvolta la scelta non è sul motore di query che utilizziamo solo su come andiamo a prendere i dati o a salvare i dati ma quello che ci sta sotto probabilmente potrà tornarci indietro come un boomerang in un secondo momento.

Io guardavo l'orologio, cioè sembra che abbiamo appena iniziato a registrare, ci stiamo giusto riscaldando ed è tipo passata un'ora e venti, quindi io chiedo rapidamente a Luca e a Leo se hanno qualche domanda per Luciano.

No, non adesso.

No, ma come al solito mi verranno sotto la doccia domani, poi sarà troppo tardi, pazienza lo troverò nel gruppo forse.

Io a questo punto vorrei chiedere a Luciano, anzi andare insieme a Luciano, Luca e Leo nel momento tipico e topico del nostro podcast, il momento il Paese dei Balocchi, il momento in cui i guest e gli host condividono con noi un tool, un libro, un video, una ricetta, qualcosa che abbia in qualche modo colpito particolarmente la loro attenzione.

Quindi la prima domanda va verso Luciano.

Luciano c'è qualcosa che vuoi condividere con la nostra community? E conducono il Paese dei Balocchi.

Ah, il Paese dei Balocchi.

Allora faccio un velocissimo recap innanzitutto dei link che abbiamo promesso di dare e che poi spero verranno inseriti in questa sezione.

Uno era il post di Owen Schanachy, il CTO di Fortiorem riguardo al prezzo, il confronto di prezzo tra EC2, Fargate e Lambda e quello secondo me è un post ottimo a qualche anno ma secondo me ad oggi è ancora molto rilevante.

L'altro è quel caso d'uso che avevo menzionato riguardo a fare big data con serverless ed è un caso d'uso con cui è stato fatto anche un articolo che è stato pubblicato proprio sul blog di AWS quindi spero che vogliate linkare anche quel blog post per far capire perché in quel caso particolare secondo me Lambda ha più senso di altre soluzioni nonostante stiamo parlando di big data.

E un'altra cosa che vorrei menzionare, questo forse è il mio link aggiuntivo, è il fatto che ultimamente mi sto un po' dilettando con Rust, ne avevamo parlato pure un po' prima della live e quindi ho provato anche un po' a esplorare il discorso di posso scrivere una Lambda in Rust e quali sono i vantaggi e gli svantaggi e la complessità del caso e da una parte ho trovato questo articolo che bilinco di una società che si chiama Scanner che è proprio un how to, cioè come fare a fare la prima Lambda, quali sono gli strumenti ed è fatto molto bene, dall'altro è un argomento che parleremo nella prossima puntata del podcast di AWSbytes che è un podcast che gestisco insieme a Owen Shanaghi di Fortiorem e appunto parleremo proprio di vantaggi e svantaggi e come fare a scrivere la prima Lambda in Rust quindi vi mando pure come riferimento a vedere questa puntata di AWSbytes.

E tra l'altro anche la puntata, anche il link di AWSbytes lo mettiamo nelle note dell'episodio.

Leo, Luca cosa avete da condividere con noi? Allora io ho due cose velocissime che non centrano nulla con l'argomento come al solito, la prima è un videogioco che ho sentito come balocco su digitalia che si chiama Vampire Survivors, è un survivor game, uno dei giochi con il più alto rilascio di endorfine che abbia mai trovato, c'è su Steam, c'è anche la versione mobile, è stato fatto da un italiano ed è il gioco su Steam fatto da un italiano con più successo, un successo improvviso, vi invito anche a leggere le interviste che sono state fatte, molto divertente, non vi dico nulla, andate a provarlo.

E l'altro è una serie TV che si chiama Kaleidoscope che si trova su Netflix che ha una cosa particolare perché in pratica gli episodi sono stati fatti per essere visti nell'ordine in cui uno vuole, sono ordinati dall'1 all'8 mi pare la prima stagione, però sono identificati con dei colori, in pratica parla di una grossa rapina che deve essere fatta, però a seconda di come uno vede l'ordine degli episodi, prende diverse angolazioni, ho visto due episodi, il pilot, il primo, il secondo è un flashback di 24 anni prima, quindi più o meno ho capito che viene preso lo stesso argomento da diversi punti del tempo e mi sembra interessante, condivido queste due cose, troverete i link nell'episodio.

Io balocco anche un'app, un'app per mobile, sapete che mi dedico agli scacchi ogni tanto, sto cercando di imparare a superare un livello quanto meno decente, a parte ovviamente il blasonato c'è il scom, c'è il Dr.

Wolf che è un vecchio che ti insegna a giocare a scacchi e ti spiega le mosse, ti fa fare proprio un percorso, ti dice guarda in questa partita scoprirò il mio re, vedi se riesci a farmi scaccomato in questo modo, oppure farò un errore nel mezzo che ti consentirà di fare un fork, prova a far quello, insomma ha un approccio divertente che sta, spero, credo, funzionando.

Io per adesso non ho ancora fatto partite perché ho l'ansia della prestazione e della sindrome dell'impostore, però sto aumentando il mio livello almeno virtuale contro il computer, perché se poi una partita ho fatto effettivamente ha funzionato parecchio, ho fatto alcune mosse che erano… ero veramente orgoglioso delle mosse che avevo fatto.

Il secondo balocco è un piccolo libricino che probabilmente ho già baloccato ma me lo trovavo davanti adesso, ho detto perché no, si chiama Mentire con le statistiche di Darrell Huff, lo si trova anche in italiano, appunto insegna come mentire con le statistiche in questo caso per difenderti da chi cerca di rifilarti statistiche vere ma false, quindi statistiche basate su dati veri ma presentati in modo che ti sembrano quello che in realtà non sono.

C'è quel famoso esempio che era il film di Nicolas Cage correlato alle morti per annegamento in piscina? Sì anche quello ma anche come proprio vengono banalmente disegnati i grafici prendendo come origine non lo zero ma il punto più alto oppure quando si gioca con le proporzioni sui volumi invece che sulle aree, insomma tante cose di questo tipo oppure anche quando ti presentano dati, i sondaggi omettendo la base campione e quindi ti spiega proprio su esempi reali, su esempi di giornali negli ultimi anni, in realtà negli ultimi decenni, ti apre gli occhi e ti fa leggere la realtà in modo diverso, la realtà che ti vogliono appropinare in modo diverso.

Comunque era carina l'introduzione che hai fatto quando hai detto serve per difendersi, sembrava un po' il disclaimer che c'è in buona parte degli scriptini, degli script kiddies che dice questo script è fatto solo a scopo educativo, non utilizzatelo! Quante volte l'abbiamo visto? Quante volte l'abbiamo scritto? Questo repository è fatto solo a scopo educativo e magari sono una roba per utilizzare le API di Grammarly che non sono pubbliche, però è solo a scopo educativo, cito Grammarly non a caso perché io tipo con le API sono un paio d'anni che le uso e finalmente ce le hanno aperte.

E allora proprio così introduco il mio balocco, vi devo dire una cosa, in una settimana e mezzo questo è il quinto episodio che registriamo, quindi potrei essere a corto di balocchi ma ne ho tre! Il primo è Grammarly, se non l'avete provato provatelo, se siete delle capre con l'inglese, amici miei siete come me, utilizzatelo perché aiuta tantissimo.

La cosa veramente figa di Grammarly è che hanno rilasciato da poco le API, quindi se fate un'iscrizione subscribe pagante che costa attorno ai centinaio di euro l'anno, quindi poco meno di 10 euro al mese, veramente poco per quello che ti da, cioè ti evita di fare figure di merda fondamentalmente, è molto utile e la cosa figa è che vi dà tipo c'è un SDK che vi dà anche il componente React che ha già la correzione grammaticale di Grammarly e la cosa è parecchio figa perché la potete potete fare il vostro text editor che è un po' quello che sto provando a fare io nel mio poco tempo libero, specifico per il vostro caso d'uso.

Questo è il primo balocco, il secondo balocco colgo l'occasione insomma dell'introduzione che ha fatto Luciano su Rust per dire che io sono abbastanza tonto e quindi sto leggendo per la seconda volta Rust in Action, lo sto rileggendo perché secondo me è uno di quei libri che se lo si legge tutto ad un fiatto va riletto una seconda volta con molta più calma e magari prendendo lo stimolo da là e andando al Rust book per andare poi più a fondo su alcuni concetti e sono ricapitato su un esempio, un blocco di codice sul quale ero andato molto veloce sopra che era la creazione di un grafico di Mandelbrot o Mandelbrot non so come si pronuncia però vedere quell'immagine mi ha riapperto un cassettino e sono andato nella libreria a cercare il libro in questione e il libro è Abbas e Euclide di Pier Giorgio Odifreddi che spiega proprio anche tra i vari concetti che spiega c'è proprio il concetto di Mandelbrot e di quant'altro quindi sono riandato a leggere il capitolino il paragraffetto di Abbas e Euclide di Odifreddi se non l'avete letto leggetelo giusto per fare una passeggiata in concetti che perlomeno io non avevo alcune idee di cosa potessero essere li vedevo come delle robe astruse e Odifreddi nonostante abbia tanti limiti non mi stia troppo simpatico in cui il libro veramente è riuscito a esprimere concetti abbastanza complessi in modo molto molto semplice e questo può essere un insegnamento anche in quello che facciamo all'interno del podcast.

Ultimo balocco è una roba strana dico strana non so ancora se figa o meno perché oggi nella chat aziendale un collega che cito per nome che penso ci stia sentendo Matteo Pietro ha condiviso un link a un nuovo linguaggio di programmazione o almeno così pare abbastanza nuovo visto che ne esce praticamente una settimana si chiama wing ed è un linguaggio di programmazione che in qualche modo si propone di essere un linguaggio pensato per il cloud si sposa abbastanza bene con l'episodio di oggi in realtà perché ci sono tutta una serie di metodi di funzionalità che triggerano attivano delle AWS lambda fanno fanno delle robe la cosa veramente particolare che ho visto nell'esempio non ci ho dedicato troppo tempo però c'è una cosa che ha catturato la mia attenzione è che in mezzo al codice di infrastruttura immaginiamolo come il codice cdk c'è una puntata registrata con leo qualche eone fa dove parlavamo di cdk per immaginatelo come del codice cdk che è una sorta di cloud formation in typescript ma dove dentro c'è anche della business logic questa cosa mi ha mandato tipo in buffer overflow e non riesco a capire se è una roba fighissima o schifosissima per cui ditemelo voi insomma nel gruppo telegram senza dubbio ha senso anche solo per farci questo tipo di domanda buttarci un occhio.

Come sempre ragazzi io non so perché vengo sempre messo in mezzo in questa cosa probabilmente perché sono l'unico che non si vergogna a parlare di soldi ma non vedo perché vergognarsi è una cosa così bella parlare di soldi perché i soldi sono veramente la cosa più bella del mondo quindi donate perché dobbiamo fare cena da massimo bottura con i vostri soldi quindi è una cosa molto importante e siamo molto poveri quindi donate copiosamente veramente in tantissimi mi raccomando dateci i vostri soldi e noi ne faremo l'uso più responsabile che se ne possa fare ovvero metterli su delle crypto uscite da mezz'ora.

è il momento di ringraziare i nostri donatori questa settimana abbiamo il primo donatore del 2023 che ringraziamo e tra l'altro è anche anonimo anche se noi sappiamo chi è quindi sappiamo chi sei scherzo grazie per gli interessanti contenuti che ci regalate grazie a te caro anonimo anche perché sei il primo donatore di questo nuovo anno che abbiamo aperto con una decisione anche abbastanza forte che è stata quella di rimuovere le pubblicità quindi adesso insomma è tutto sul nostro groppone vi ricordo che se volete sostenerci e non volete fare una donazione diretta che potete comunque fare andando nel sito www.gitbar.it potete tranquillamente cliccare su uno dei link che trovate all'interno delle note degli episodi o che puntano ad amazon in quel caso si setta una sessione che se non mi sbaglio dura per 30 giorni e pochi centesimi dei vostri acquisti andranno anche al nostro supporto grazie di cuore e grazie anonimo Eccoci qua sono le 10 le 22 e 43 e siamo ancora tutti in piedi belli arzilli Bell'arzillo sarebbe...

non so che cosa sta succedendo Io morire di sonno però vabbè Luciano grazie grazie mille per essere venuti a trovarci ricordiamo rapidamente i tuoi contatti Allora innanzitutto grazie a voi perché è sempre un piacere imparo sempre tantissimo quindi grazie i miei contatti mi trovate su twitter come loige o mi trovate su github come lmammino e mi trovate anche su linkedin poi ultimamente mi sto dilettando un po' su twitch a fare dei live stream ogni tanto quindi se vi piace rust e vi piace vedere come io faccio finta di capire rust ma in realtà poi mi scontro col compilatore e finiamo a litigare mi trovate su twitch sempre come loige e niente questi penso siano un po' tutti i miei contatti E in libreria con note.js design pattern dai che ti ci devi comprare la casa al mare quella sì sì grazie metti pure il link anzi mando pure quello che tra l'altro è una delle pietre miliari non so se l'ho già detto per la programmazione per chiunque abbia sviluppato un odd un'occhiata deve averla data a quel libro non piratato però compratelo bene leo luca luciano grazie davvero di questa serata super figa è stato veramente un piacere ecco riavervi tutti e tre qua sono senza parole cosa devo fare adesso ragazzi luca leo aiutatemi vi prego i contatti ecco ecco i contatti dimenticamo mi raccomando questa parte la taglio perché tipo sono andato davvero in buffero per flusso c'è un annulpo intera no è il bello della diretta giusto prima di chiudere una piccola cosa mi raccomando se avete un device apple andate su itunes stellinateci metteteci in cuoricino lasciateci una recensione questo fa in modo di in qualche modo continuare a preservare la nostra posizione all'interno delle classifiche di itunes e quindi riuscire a raggiungere nuove orecchie vi ricordiamo rapidamente i nostri contatti info che sono a github.it e il gruppo telegram che trovate cercando github telegram e cliccando sul primo risultato a occhi chiusi perché faremo noi detto questo io ringrazio nuovamente luciano per essere venuto a trovarci ormai tu lo sai no? github è un po' anche casa tua quindi quando hai qualcosa di nuovo quando il compilatore di rust ti dice qualcosa di interessante ecco vieni da noi a raccontarcelo perché insomma github è il circolo degli sviluppatori dove hai la tessera è tra l'altro una delle prime ms quindi ti aspettiamo per il momento il compilatore di rust mi dice solo vai a zappare quindi quando cambieremo questa storia magari arriverò a parlare di rust e devo dire ringraziamo che non ci sono le emoji se no la frustrazione salirebbe ancora di più detto questo io vi do appuntamento alla prossima settimana ciao ciao ciao ciao ciao git bar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con brain repo parliamo di linguaggi e tecniche di sviluppo web di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei full stack dev.