Bene e benvenuti su GIT BAR, 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 è appena arrivato del mio pranzo, questo vi fa un po' capire in che condizioni sono.Cioè è 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? No no è il pranzo.L'ultima volta che hai preso un taco in puntata hai detto che non era andato troppo bene.Eh sì la digestione è un po' lenta è per quello che è.È parcheggiato.Perché in post produzione poi leviamo tutti i suoni molesti che ci sono.Sì io adoro i taco ma hanno una digestione waterfall e che è 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, Fak 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? Sì, tutto.Anche la data è coperta.Tu Luca? Vabbè ok.Tutto l'indiegno è serio e 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.Non c'è bene.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.Info@gitbar.it o @brainrepo sono i modi canonici.per contattarci e poi ovviamente c'è il gruppo telegramma basta cercare aprire telegramma 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 membri Membrè, membrè.Come si dice membrae? Membrè.Membrè, 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 gaff dopo l'altra.ma parentesi a parte presentiamo l'ospite che abbiamo di nuovo qua un amico di Gitbar abbiamo...allora proviamo a fare il serio benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer i mezzo artigiani 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 alla fantastica intro adesso mi sento proprio l'impostor syndrome a mille in realtà sarebbe Luciano che dovrebbe presentare il podcast Feedback direi 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 è da noi ci siamo sentiti un anno e mezzo fa più o meno qua su GateWarp, poi ci siamo visto 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 ci siamo sentiti, nel senso che lavora 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 linea è 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 antitesi no? Bella domanda non so se mi sono mai posto il problema da questo punto di vista forse c'è una personalità che è molto...cioè a me piace molto spaziare andare a vedere il problema a 360 gradi piuttosto che concentrarmi in particolar modo su un aspetto specifico poi come esperienza personale c'ho più di dieci 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 e 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.LM: 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 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 sei un prestatore d'opera alla consulenza più beccera, 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 diciamo 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'è una situazione assolutamente aperta di un team che vuole abbracciare l'innovazione e è disposto a fare la qualsiasi cosa per innovare, se viene fatto il passo più lungo della gamba è 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, diciamo, un po' classica, da on-premise a cloud, semplicemente non perché la volevano fare così per sport, ma perché proprio 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.e 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, 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 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 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 da soli.E questo ne dimostra anche il fatto dell'approccio che hai col cliente, cioè l'evitare 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 Nel senso che quando è stata rilasciata l'AMDA, credo fosse proprio 2014, aveva un po' questa promessa di dire, "Finalmente abbiamo trovato un'astrazione 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'erano abbastanza vicine a questo tipo di concetto.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 Ficio parlo proprio di configurabilità, dimensioni in cui si può configurare una lambda, e all'atto tra di 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 Diamo un servizio quanto più manage possibile, in modo che tu scrivi con un'astrazione 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, non è più una strazione 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é dice 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 da dove si può portare questa opinione un po' conflittuale che la promessa di serverless sono andato 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 Gitbar 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, lo andiamo a recuperare.Però è interessante quello che ha detto Leo, perché comunque noi non abbiamo solo un problema di configurabilità in 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ò configurabilità in italiano? Talvolta mi vengono queste...male che vada è un neologismo.Volevo chiederti, hai degli esempi, dei casi d'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 di 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 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'è dai JSON in entrata e in uscita, quindi banalmente già questo ti ha precluso tutta una serie di casi d'uso che magari al lato pratico ne potresti aver bisogno.Banalmente devo fare un upload di un file, non lo so, un video, non 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 all'atto pratico questa è una leaky abstraction, nel senso che una decisione tecnica di AWS può influire sull'esperienza che l'utente ha e limita, diciamo, 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.Poi potresti incorrere in un problema nel quale se c'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 superscalabile 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é all'atto pratico se non si arriva a una certa scala questi problemi non sono neanche dei problemi 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.Lei 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 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 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.Già delle cose un po' tricky.Si, 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.LM: chiaro.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? AC: no, certo, stavo pensando alla difficoltà di non inserire più olitondi in buchi quadrati, quadrati, come mi piace dire.Però anche questo vuol dire dover 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 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 e le troverò in questa puntata, credo, anche per questo.Io, Leo volevi dire qualcosa? Allora, no, volevo, non so, provare a introdurre un argomento o dire una cosa che mi passa per la testa.Allora, il serverless, insomma l'architettura serverless funziona molto bene nel momento 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, i grandi, i big moloc, 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 a 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 è qualcosa di cui discutiamo anche con i nostri clienti e non è mai una decisione binaria, ovvia, o usi serverless sì o no.Perché secondo me bisogna un po' chiarire quali sono i vantaggi di serverless.Nel senso che non sempre è un vantaggio di costo, come magari si è fatta molta enfasi, soprattutto all'inizio di questo fenomeno serverless, si diceva "eh, 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 è un effetto necessario dell'utilizzare serverless, quello dipende molto dal caso d'uso, e per assurdo serverless potrebbe anche costarti di più se vai a vedere il puro costo del compute.C'è tra l'altro un articolo del sito di Fortiorem, che magari poi cerco il link e ve lo passo qui, che fa proprio un'analisi molto dettagliata su un caso d'uso in cui la necessità di compute è ben nota, e lui confronta a parità di compute, se faccio una cosa su EC2, quindi virtual machine pure, rispetto Fargate, quindi dockerizzazione, rispetto Lambda, ogni volta che tu vai a aumentare il livello di astrazione, quindi in ordine EC2, Fargate e Lambda, c'è un aumento di costo di 20 per.Quindi sostanzialmente Lambda ti va a costare 400 volte di più di Easy2, quindi di Virtual Machine, a parità di capacità di computer.Quindi se tu riuscissi ad ottimizzare assolutamente l'utilizzo di Easy2, 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 mantenernela nel tempo.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 che 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 pure lì ci 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 un'analisi più completa e dire ok ma se devo 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 stai spendendo così e non ti rendi conto che lei sta spendendo perché è una virtual machine rispetto ad una lambda.Forse sto un po' esagerando, ma voglio anche approfondire questo tipo di discorso.No, no, era proprio il punto che tendevo io, cioè avere qualcosa da gestire ci devi mettere anche il costo della persona che lo gestisce.E magari per la persona deve trovare...Morale, 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? o il caro vecchio sistemista.C'è credo che per qualcosa per qualcosa anche solo per gestire le cose di ufficio o alla fine un cavolo di servizio ti serve su una virtual machine, forse forse alla fine qualcuno ti serve che faccia quel lavoro e a quel momento già che la RAL è molto elevata, quindi già che lo paghi, puoi "sfruttarlo" al 100% dandogli più lavoro, quindi più virtual machine da aggiornare e quant'altro.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 mi serve.Allora dovrei chiedere una consulenza e comunque quei soldi lo stesso in un modo o nell'altro vanno via.LM: Posso dire una cosa? Io adesso mi trovo a lavorare in un progetto che potremmo definire Enterprise, quindi con una grande azienda con decine di DevOps engineer 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.È una cosa, un pattern che ho trovato non solo in questa grande multinazionale ma anche in altre società piuttosto grandi e nonostante i costi una virata verso i servizi managed e questo è un po' in in controtendenza a quello che ha scritto DDD qualche qualche giorno fa parlando dei costi di AWS e del suo flame.Però pur con una forte presenza di, utilizziamo il termine old school, di sistemisti o di...e cavolo si opta per una serie di servizi managed per capirci.Le app sono deploiate con, se siamo in ambito azure 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 auso, ottenere in auso 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.Sì concordo assolutamente, secondo me andiamo con questo tipo di osservazione ad avvicinarci di più a quello che secondo me è 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 iniziale di serverless nel senso che serverless ci porta molto di più ad essere agili quando si parla di mettere in piedi una cosa nuova.E' 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 sono una webbook 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 condominio, queste e queste altre passavano 2, 3, 4 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 e 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 mette 0,5 minuti a far partire un'istanza RDS che già appunto c'è tanto manage e 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 di questi servizi manage 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? 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 ho 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 scrivevamo il codice erano due cose.La nostra applicazione aveva due importanti funzioni.Forse sto riducendo un po', secondo me 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 "runnare 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 solvono problemi diversi e c'è tutto il mondo dell'orchestrazione, parliamo di AWS in ambiente AWS, con CloudFormation 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.ed ecco 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 sistemistiche 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, 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 che 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 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 stella capacità, o che non riesci 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 di step function una delle cose che hanno introdotto anche abbastanza recente credo sia 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 "va beh i dati che sono venuti fuori da qui mettili 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, era più funzionale l'infrastruttura, però l'ha scrietta sotto forma 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 sul repository, va mantenuto, vanno fatte le ICD 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 cosa 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 insieme? come fai a testare tutto il giro, tutto il workflow che che bisogna seguire? che strategia si può adottare o si deve adottare con il AWS o in generale? sì tra l'altro mi sono appena ricordato che non ho risposto alla domanda riguardo la cloud ad 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 me non c'è una pratica che è quella su cui tutti sono d'accordo che sia il modo migliore di fare i test.E di test parla in un 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.Banalmente questo è un tema su cui ci sono 50 anni di storia, nel senso da quando esiste l'informatica si scrivono cose in locale, le esegui, vedi se funzionano, poi puoi anche scrivere dei test automatizzati, ma è sempre stata quasi una cosa ovvia il fatto di poter eseguire le cose in locale, a meno che magari facciamo un mega passo indietro quando c'erano i mainframe dovevi mandare il job, però vabbè, dimentichiamoci magari quella fase iniziale della storia degli informati e pensiamo magari anni un po' più recenti, da sistemi operativi un po' più moderni.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 combaciare 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 provider, però comunque dice "vabbè, una prima astrazione mi permette di vedere se il mio codice più o meno fa quello che deve fare".Dopodiché sopvenendo che c'è una tendenza a cercare di ridurre quanto più possibili 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 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 portarla in produzione non hai sorprese particolari.Giusto per inserirmi nel discorso di Cloud Abstraction, tutto questo è molto Cloud specific ad oggi, nel senso che noi andiamo a utilizzare Step Functions, piuttosto che Lambda, piuttosto che DynamoDB, piuttosto che SQS o SNS, questi servizi che sono tra l'altro da quelli più base, che un po' tutti utilizzano AWS, sono fondamentalmente diversi se vai a utilizzare gli equivalenti su Azure o su Google, proprio a livello di API.Quindi banalmente voler utilizzare una strazione, e sì, magari ne esistono, ma praticamente ti vai a portare il tuo problema a un minimo comune denominatore di funzionalità che tutti supportano e ti stai perdendo i vantaggi specifici di ogni cloud provider.Quindi forse è un discorso che da una parte sconsiglierei, dall'altra possiamo pure andare a parlare di Kubernetes e di tutto quel tipo di attrazione 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...Hai risposto benissimo, che secondo me quello che è evidenziato è importante, cioè per diventare cloud agnostica andiamo a costruire un ulteriore livello di astrazione sopra una serie di livelli di astrazione che alla fine diventa astrareal astratto, per cui si può con tool come Kubernetes in modo molto più pragmatico eliminiamo una serie di livelli creandone uno unico, comunque un quasi layer unico da strazione.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 deployarlo 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 NearForm, sono passato a fare il DevOps, avevo sentito di questa terra, mi sono detto "ah, posso deployare tutto dove mi pare".E no! Sei su WS, fai la Lambda, fai API Gateway, 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' impari.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 JAMSTACK, quindi CD-Static, Sheet 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 back end monolitici a build time.Quindi da un'altra parte il trend della computazione serverless ci ha portato e anche ci ha portato in modo positivo anche a ottimizzare energia diciamola anche qua.Però nel contempo più creiamo nuovi livelli di astrazione più ci ci allontaniamo da quello che in realtà è fisicamente quello che facciamo e questo ha un certo effetto anche se ci connettiamo a un ragionamento, 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 il consumo energetico e il gratis.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 Ozzo su Continuous Delivery che salutiamo, che ChatGPT 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.Una bella domanda, non so se è una cosa che potrebbe essere facita a calcolare, io poi ho un'opinione molto pro free tier, anzi vorrei che AWS rendesse più semplice per chi è uno studente, un 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, potrebbero fare meglio.Capisco il tuo punto di vista, nel senso che è vero che c'è molta logica del free, molta logica del "butta 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 e 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 o on-premise che sia, devi sempre dargli molto più buffer di quello che ti serve, perché non riesci a scalare in modo così dinamico.quindi all'atto pratico magari tu hai una macchina che consuma teoricamente 100 quando ti serve 2 e quel 100 magari lo raggiungi 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ù ecosostenibile Ora, tutti i cloud provider, quando si parla di ecosostenibilità, 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'ecosostenibilità 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 e 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 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 architetture 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 "cazzo, è 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 ottenere un approccio più tradizionale?" E ovviamente non è che c'era una risposta binaria sì o no, c'è il fantastico "Dipends" cui risponde a tutte le domande da consulente.[Musica] Però l'irragionamento 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 deve andare a osservare tutto questo tipo di cose e cercare di capire quali sono le leve che ha a disposizione alla 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, loro si sentono che se non hanno fatto un po' di serverless magari stanno facendo roba obsoleta e non gli piace.Uno dei casi che secondo me è ideale è quello di quando devi andare a fare background processing e quindi sostanzialmente c'hai 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 e risponde.Se però c'è tutta una serie di roba che deve essere fatta 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 a 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 a 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ù adeguato.Altri casi molto comuni sono quelli 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 dicevamo all'inizio della puntata, se banalmente devi fare l'upload di un file, non è la soluzione migliore farlo con API Gateway Lambda.Molto probabilmente non è una buona soluzione per niente.Quindi...- Partiamo con S3 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 ti arriva da qualche altro servizio vuoi avere un endpoint 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ì, sì, si parla comunque di endpoint HTTP, però dipende il caso d'uso, può essere ideale farlo con lambda, piuttosto che magari non sempre così ideale.E un altro caso d'uso che se non è uno molto interessante e 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'è 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 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.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 il concetto sempre di serverless function e riguarda, sta nel fatto che proprio nella parola, quando si parla di computazione serverless, si ragiona in termini di funzione, 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 abbastanza contrario, magari l'Aravel è 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é la strazione 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 Ci sono degli adapter che trovi per Laravel, per Express, che ti permettono di far sì che questi eventi vengono convertiti in richieste e risposte finte dal punto di vista del framework, però quello fa sì che tutta una serie di cose magari non funzionino come tu ti aspetteresti.Banalmente, torniamo sempre al discorso dell'upload o del download, quindi casi d'uso un po' più streaming, non funzioneranno quando tu li utilizzi nel contesto di 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% dei casi d'uso, non vedi la differenza, però ci sono un 10% dei 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% 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 ho questo codice in express già scritto, è una cosa piccola, la prendo e la tiro in una lambda perché comunque voglia andare a fare delle lambda nel breve medio periodo può essere un trade off accettabile se sai esattamente a cosa vuoi andare incontro ma non lo farei insomma come best practice, come scorciatoia diciamo.Anche perché i tempi di boot della lambda e i dta 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 che in realtà, anzi abbiamo detto, che in realtà c'è 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 è AppSync, che è GraphQL as a service, che mettiamola così.Quando, Luciano, quali sono le condizioni per le quali tu saresti tentato di andare verso una soluzione gestita come AppSync e quando invece preferiresti tirarti sul tuo buon appollo che ti chiami 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 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 dà molta più flessibilità rispetto ad AppSync.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 a qualcosa che dico "Vabbè, quando arriva sta chiamata parte sta lambda che già ho scritto e basta, 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 se vale la pena andare a pagare quel costo aggiuntivo di manutenzione dell'infrastruttura piuttosto che andare a utilizzare un servizio managed come AppSync.Ma, ripeto, non conoscendo benissimo i dettagli della tecnologia specifica, quello che ho adesso 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 micro servizio ma ti può anche chiamare l'open search della situazione che è l'omologo di elastic search as a service o può andare a scrivere roba su dynamo o su aurora anche questi magari serverless e qua io dico vabbè a questo punto c'è 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 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 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 in 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 2 che è una query che ci mette 2 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 i record quindi 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 ricordo 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 è schivelli dice va bene gli utenti li mettono nella tabella utenti i prodotti nella tabella prodotti invece metti tutto insieme e fai dei finti per tirare fuori dallo stesso bucket.Questa cosa che è un po' difficile da intuire.No, concordo assolutamente.C'è un libro intero di Alex Debris, 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 di andare a impostare un database in questo modo.E questo tipo di approccio, a mia opinione, ma forse mi riservo proprio 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 devi 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 con il modello NoSQL 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 NoSQL è 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 secondo me 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 una piega, sono d'accordo al 200%, però nella zona B del mio cervello mi è ritornato in mente un mantra, che era il mantra di tutto il movimento NoSQL, cioè tutto ciò che riguarda SQL possiamo vederlo, SQL e NoSQL 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 NoSQL.Però è una cosa che conflige in qualche modo con quello che hai appena detto e su quale sono d'accordo tra l'altro, cioè se io voglio accedere ai dati in modo anche efficiente devo aver già pensato al motivo per cui voglio accedere.Questa cosa nella mia testa si sta prendendo a schiaffi col concetto di schema on read perché in realtà nella definizione implicita di schema on read sto dicendo esattamente il contrario cioè definisco lo schema di dati quando vado 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.Cosa ne dite? Secondo me c'è pure un'altra dimensione di esplorare che forse viene sempre un po' messo in secondo piano, che è quella proprio dell'architettura di questi due diversi tipologi 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 è 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 reaggregare i risultati.Quindi quella secondo me è una cosa che viene sempre messa 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 da un punto di vista di gestione 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 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, 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? Riconducono il paese dei balocchi! Allora faccio un velocissimo recap innanzitutto dei link che abbiamo promesso di dare e che poi spero verranno inserite in questa sezione.Uno era il post di Owen Shanaghi, il CTO di Fortiorem riguardo al prezzo, il 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, e 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 AWS Bytes, 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 AWS Bytes.E tra l'altro anche la puntata, anche il link di AWS Bytes 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.Uno è 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, pare 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 viste nell'ordine in cui uno vuole.Cioè, sono ordinati dall'uno all'otto, 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, diciamo, diverse angolazioni.Ho visto due episodi, il pilot, cioè 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 e condivido queste due cose, vi 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 spiega, ti fa fare proprio un percorso, ti dice "guarda in questa partita scoprirò il mio re, vedi se riesci a farmi scaccomatto in questo modo oppure farò un un errore nel mezzo che ti consentirà di fare un fork, prova a fare 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.Anche se poi una partita fatto ed effettivamente ha funzionato parecchio, ho fatto alcune mosse che erano… ero veramente orgoglioso di quelle 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" e 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 propinare 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? 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 ne hanno aperte.Allora proprio così introduco il mio balocco.Allora vi devo dire una cosa, in una settimana e mezzo questo è il quinto episodio che registriamo, 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 e utilizzatelo perché aiuta tantissimo.La cosa veramente figa di Grammarly è che hanno rilasciato da poco l'API, quindi se avete, se fate una 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 dà 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, no? 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, 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 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 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 Maandelbrot 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 e li vedevo come delle robe astruse e Odi Freddi, 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 l'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 e funzionalità che triggerano, attivano delle AWS Lambda, 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 un buffer overflow e non riesco a capire se è una roba fighissima o schifosissima per cui ditemelo vuoi 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 a 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 cripto uscite da mezz'ora.[musica] è 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, 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 - Non so che cosa è successo.- Io voglio di solo, però con te.Luciano, grazie, grazie mille per essere venuto 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, L-O-I-G-E o mi trovate su github come lmammino, quelli che scrivo qui, 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, in realtà poi mi scontro col compilatore e finiamo a litigare.Mi trovate su Twitch sempre come Lojge.E niente, questi penso siano un po' tutti i miei contatti.in libreria con Node.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 Node 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 dimenticavo mi raccomando questa parte la taglio perché tipo sono andato davvero in buffero del flusso ho un annulpo intera...ah no è il bello della diretta...ho un annulpo intera...panic...ah ok giusto prima di chiudere una piccola cosa mi raccomando se avete un device apple andate su iTunes, stellinateci, metteteci in coricino, 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@gitbar.it @brainrepo e il gruppo Telegram che trovate cercando Gitbar su Telegram e cliccando sul primo risultato a occhi riusi perché saremo noti.Detto questo io ringrazio nuovamente Luciano per essere venuto a trovarci ormai tu lo sai no? Gitbar è 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 Gitbar è 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.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! GitBar, il circolo dei fullstack 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 Dead.
