Torna a tutti gli episodi
Ep.62 - Serverless e non solo con Alex Casalboni (AWS)

Episodio 62

Ep.62 - Serverless e non solo con Alex Casalboni (AWS)

Serverless o non serverless, cosa è e come ottimizzarlo, ne abbiamo parlato con Alex Casalboni, developer advocate per AWS. Abbiamo anche parlato di Amplify e delle vicende che hanno coinvolto AWS e Elastic riguardo le licenze.## Ricordati di iscriverti al gruppo telegram:https://t.me/gitbar## Suppo...

25 febbraio 202101:33:11
AIMusic
62

In Riproduzione

Ep.62 - Serverless e non solo con Alex Casalboni (AWS)

0:000:00

Note dell'Episodio

Serverless o non serverless, cosa è e come ottimizzarlo, ne abbiamo parlato con Alex Casalboni, developer advocate per AWS. Abbiamo anche parlato di Amplify e delle vicende che hanno coinvolto AWS e Elastic riguardo le licenze.## Ricordati di iscriverti al gruppo telegram:https://t.me/gitbar## Supportaci suhttps://www.buymeacoffee.com/gitbarQuesta settimana anonimo ci ha offerto 3🍻 danny_spina ci ha offerto una 🍺GRAZIE!# Links- https://aws.amazon.com/it/podcasts/aws-podcast-in-italiano- https://aws.amazon.com/it/developer/community/evangelists/alex-casalboni/- https://www.linkedin.com/in/alexcasalboni?originalSubdomain=it- https://aws.amazon.com/it/- https://github.com/alexcasalboni/aws-lambda-power-tuning- https://aws.amazon.com/it/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/- https://www.elastic.co/blog/why-license-change-AWS- https://aws.amazon.com/blogs/apn/aws-lambda-custom-runtime-for-php-a-practical-example/- https://aws.amazon.com/blogs/compute/building-php-lambda-functions-with-docker-container-images/# Il paese dei balocchi - https://www.youtube.com/watch?v=6yqfmXiZTlM## Contatti@brainrepo su twitter o via mail a info@gitbar.it.## CreditiLe sigle sono state prodotte da MondoComputazionaleLe musiche da Blan Kytt - RSPNSweet Lullaby by Agnese ValmaggiaMonkeys Spinning Monkeys by Kevin MacLeod

Descrizione

Questa settimana abbiamo finalmente Alex Casalboni con noi, un ingegnere con la testa tra le nuvole (letteralmente, perché fa cloud computing). Da musicista a startup fino ad AWS, Alex ci racconta come si è trasformato da sviluppatore PHP/jQuery nostalgico a developer advocate che porta il verbo del cloud in giro per il mondo. Parliamo di come non reinventare la ruota, dell'importanza di pensare in modo architetturale e di come il serverless stia cambiando il nostro modo di sviluppare.

Takeaway

  • Investire sul pensiero architetturale: Non concentrarsi solo sul codice, ma capire come funzionano scalabilità, backup e integrazione dei servizi. Le competenze architetturali sono più riutilizzabili di un singolo framework
  • AWS come agglomerato di startup: Anche nelle grandi aziende si può mantenere lo spirito startup con il modello "two pizza team" e ownership totale sui problemi
  • Il ruolo del developer advocate: Più che marketing tecnico, è divulgazione scientifica applicata al cloud. Creare contenuti di valore per gli sviluppatori è fondamentale
  • Sapere cosa esiste vs sapere tutto: Nel 2018 è più importante conoscere quali strumenti esistono per non reinventare la ruota che padroneggiare a fondo un singolo framework
  • Formazione stratificata: YouTube va bene per il livello 1, ma per competenze profonde servono corsi strutturati e libri. Il dettaglio conta quando serve davvero

Bold Opinion

  • Il nostro scopo non è scrivere codice o scegliere framework, ma risolvere problemi di business. Se ti butti su 800 libri di un framework, quando alzi la testa il mondo è cambiato
  • Chi arriva da startup impara in 2-3 anni quello che in grandi aziende tradizionali richiede 5-6 anni. I ritmi sono tosti ma ne vale la pena
  • La differenza tra sviluppatori junior e senior non è quanto codice scrivi, ma quanto riesci a vedere il problema nel suo insieme

Trascrizione

Bene e benvenuti su Gitbar, un'altra settimana e un altro episodio anche se questa settimana ci stiamo avvicinando alla fine ma dopo un episodio dove Peccato per voi l'avete dovuto passare con me adesso è Ritornato il momento degli ospiti e anche oggi con me ho un super ospite ma prima di presentarlo, il mio ruolo, come sapete, è quello di ricordarvi i nostri contatti info@gitbar.it via email o @brenrepo su Twitter oppure nel gruppo Telegram cercando semplicemente Gitbar ma bando alle ciance, non perdiamo altro tempo e dopo una piccola pausa vi presento l'ospite 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.Dicono che i musicisti hanno la testa tra le nuvole.L'ospite che ho oggi con voi ha la testa sul cloud.pianista sassofonista, esperto architetto di cloud e developer advocate AWS.Abbiamo con noi Alex Casalboni.Ciao Alex! Ciao Mauro, grazie a te per l'invito, è un piacere.Ho scoperto che sei un musicista.Io sono musicista, ho un percorso abbastanza divertente da ingegnere informatico a sound and music engineering, è un'unica facoltà a Como e poi ho trovato una startup, ho lavorato con il cloud e alla fine sono finito in Amazon Web Services.È stato un bel viaggio.Raccontaci un po' del viaggio che ti ha portato da prima su questa startup fino ad arrivare in AWS.Molto volentieri.Guarda, io lavoravo per una startup che si chiamava Cloud Academy.com.Ho conosciuto i fondatori a Cuomo, studiavamo insieme, eravamo proprio i classici tre o quattro ragazzi che hanno una bella idea e quando li ho conosciuti cercavo uno sviluppatore web e io stavo lavorando proprio come sviluppatore web part time durante l'università, mi sono appassionato, parliamo di dieci anni fa ho iniziato ad usare il php insomma tutto tutto quel mondo del web, c'era jquery, mi è diventato nostalgico se ne parlo e insomma li ho incontrati, cercavo uno sviluppatore web, abbiamo iniziato a creare insomma la versione 2 dell'MVP, il minimo mobile product per la startup, i due co-founder e io, quindi tre persone davanti a una lavagna per creare idee, sviluppare funzionalità, è stato molto divertente.Se fai fast forward di lì a due anni, due anni e mezzo dopo, c'eravamo più di 50 persone.Dopo siete stati a Mountain View, a 500 startups, a tirare su quasi 3 milioni di dollari.È stata una bella, una bella corsa ostacoli, quindi tanti cappelli diversi, tante persone, tanti problemi belli da affrontare, tanto codice e tante assunzioni, tante esperienze diverse che sicuramente mi porto dietro.Ho conosciuto tante persone che lavorano nel mondo cloud, perché in quanto Cloud Academy facciamo formazione e learning per tutte le tecnologie intorno al cloud, quindi la virtualizzazione, un po' di Linux, un po' di microservizi, tutto ciò che si è evoluto intorno a quel mondo dei servizi cloud.Ho iniziato a scrivere articoli, ho iniziato a fare dei webinar, viaggiavo tantissimo, era una delle mie passioni e lo facevo anche per lavoro e quindi vedevo tanti clienti, facevo un mix di motivazione, formazione, evangelismo, come si chiama, no? Technical evangelism e quindi ho scoperto questo ruolo part time del technical evangelist o developer advocate e a un certo punto ho deciso perché non farlo direttamente in AWS, parlavo molto molto spesso di tecnologie legate a AWS, che fosse il serverless, magari poi ne parliamo un pochino, o che fosse il machine learning dato che ha un background da data science, o che fosse il web, insomma tante altre cose che poi si legano al mondo del cloud.Tu hai lavorato in startup e in grandi multinazionali come appunto AWS, quali sono gli elementi proprio del modello di lavoro che cambiano? Quali sono i lati positivi di uno e dell'altro e i rispettivi lati negativi? Guarda, io mi sono innamorato del mondo startup perché impari tantissime cose velocemente, devi sempre affrontare il problema del giorno senza budget e quindi devi un po' inventarti e noi italiani siamo molto bravi a fare questo, quindi per me è stato divertente.Mi piace comunque il mondo Amazon Web Services perché Amazon in generale, ma soprattutto AWS, lavora come una specie di agglomerato di tante start up.C'è questo concetto del "two pizza team", il team che può essere stomato con un paio di pizze e ognuno di quei team quasi opera in totale autonomia o con pochissime interazioni asincrone, soprattutto quella che fa parte della cultura aziendale.E quindi in realtà è molto facile riadattarsi a un ambiente come quello di la biblioteca arrivando alla startup perché c'è già l'idea del indossare più cappelli, del avere ownership totale, andare a risolvere i problemi, non dire questo non è il mio dipartimento, questo non è il mio lavoro, fatelo voi.E quindi mi piace a livello culturale, mi piace molto AWS e in due anni e mezzo ho imparato ciò che in allievi normali si impara in 5-6 anni, quindi assolutamente ne vale la pena.Ovviamente i ritmi sono tosti, quindi non mi nascondo il vera un dito, è una bella sfida, è divertente trovarsi nella stanza ed avere persone super intelligenti, sono tutti geni e ti viene un po' la sindrome dell'impostore ogni tanto però è una bellissima esperienza.Una domanda che ci chiediamo spesso e che spesso sento ripetere è quella qual è il percorso che da una startup ti permette di entrare in queste in queste aziende che sono per noi ingegneri sviluppatori sono una meta super ambita nel senso che tipo di percorso dobbiamo fare, che tipo di studi dobbiamo fare, dove dobbiamo specializzarci, esistono dei metodi per accedere più facilmente o meno facilmente? Beh ovviamente ci sono tantissimi ruoli diversi.Io da sviluppatore che sono partito da "ok imparo un linguaggio di programmazione, imparo un altro, cerco di mettere insieme le cose", a posteriori se avessi voluto prepararmi un po' meglio a entrare in un contesto di questo tipo, avrei investito un po' del mio tempo a imparare anche tutta quella parte che non è nello specifico un linguaggio di programmazione o un framework, ma è magari più a livello architetturale.Per esempio come si progetta un'applicazione, non solo come si scrive il codice, la business logic, ma come metti insieme l'etabase, come metti insieme i backup, come metti insieme la scalabilità quando antiché avere 100 utenti ne hai 100.000.sono tutte cose queste che tipicamente o storicamente, soprattutto nelle aziende un po' più piccole, non vanno per capo al singolo sviluppatore perché magari c'è un team infrastrutturale, ma sono le competenze più riutilizzabili che non dipendono dal singolo linguaggio o dal singolo framework e che spesso fanno la differenza perché da sviluppatori spesso ci dimentichiamo che la grossa parte di un'applicazione non è scrivere il codice, è manutenere quel codice per i prossimi cinque anni e quindi se hai sbagliato l'architettura devi rifare tutto da capo a volte.È facile dimenticarsene ma è abbastanza importante quindi se guardate tutto il mondo del cloud tanti dei servizi sono agnostici rispetto al linguaggio di programmazione, anche non so una AWS Lambda stesso ha supporto per tanti linguaggi ma poi l'atto architetturale, come connetti servizi, come integri le varie funzionalità, ad astrarre abbastanza bene rispetto al linguaggio di programmazione.Il mio consiglio per gli sviluppatori, per riassumere, magari investite un po' del vostro tempo, man mano che aumentate la seniority, che andate verso un ruolo un po' più senior, con visibilità ad alto livello su un'intera applicazione, su un intero stack applicativo, non concentratevi solo sul codice, ma provate a vedere il problema nel suo insieme perché alla fine della fiera quello che facciamo noi sviluppatori è risolvere problemi che lo fai col codice che lo fai con un servizio gestito che lo fai con un servizio cloud alla fine vince chi lo fa prima e chi lo fa meglio.Verissimo verissimo prima ancora di passare ai giocattoli che è la parte per cui sto fremendo ti dico la verità voglio ancora farti l'ultima domanda sul tuo ruolo di developer advocate fondamentalmente in cosa consiste? È una bella domanda e me la facevo anch'io prima di farlo full time, diciamo così, perché la mia percezione da fuori era, o comunque facendolo part time o nel tempo libero, era sì viaggi, vai alle conferenze, fai dei webinar, è un po' tutto quel mondo che storicamente veniva chiamato il technical marketing, cioè Io rappresento un'azienda che vende dei servizi, dei prodotti, che vende qualcosa.Quando lavoravo per Cloud Academy vendevamo formazione e quindi faceva parte di quel ruolo andare a portare il verbo."Vai a portare il Cloud, cosa puoi fare con il Cloud?" E quindi arrivavi in un contesto di formazione in cui il cliente aveva già deciso che poteva imparare il Cloud e gli aiutavamo.Tutto ciò che è creare materiale tecnico, la dimostrazione, la demo su GitHub, il video che ti fa vedere come usare il servizio, io ho iniziato così.Faccio un video su YouTube, ha 10.000 visualizzazioni, vabbè allora magari quell'argomento interessa qualcuno, magari l'ho fatto in inglese e la prossima volta lo posso fare in italiano per capire qual è la mia audience che mi segue, eccetera eccetera.C'è un discorso di personal branding, c'è un discorso di social media, devi avere comunque una presenza, devi avere qualcuno che ti ascolta, se no parli a un muro e quello insomma richiede un po' di tempo, un po' di investimento di tempo e di energie, però nella mia esperienza se crei contenuto che ha valore e che non è giusto per, che fa incontro alle esigenze dei sviluppatori, degli architetti o chi insomma deve utilizzare le cose di cui parli.Alla fine insomma quella audience si crea, quel feedback loop si crea per cui poi ti chiedono altri contenuti, quindi sai già di cosa parlare poi e ci sono tantissimi modi per farlo.Se penso a due o tre anni fa era principalmente viaggiare in giro per le conferenze, se penso oggi è tutto molto più virtuale, molto più digitale, può piacere o può non piacere e quindi sono più conferenze online, meetup, podcast, tutto ciò che è divulgativo in un certo senso, come se fossi Piero Angela o Alberto Angela del cloud.Quindi mi piace come immagini.Proprio l'altro giorno abbiamo condiviso nel gruppo un meme di Alberto Angela che dice "rimanete là che arrivo e vi divulgo".bellissimo.Volevo chiederti un'informazione sempre sul mondo dei developer advocate.Tu lavori comunque sia in Italia ma anche con un respiro più internazionale.Noti delle differenze tra l'ecosistema italiano e quello internazionale? Allora lo notavo un po' di più quando lavoravo in in un mondo in cui la formazione che offriamo magari era a pagamento e allora lì è un po' culturale nel senso che ci sono altre culture in cui investire il soldo sull'educazione è più naturale se vai negli Stati Uniti, se non hai 50 o 100 mila dollari di debito appena esci l'università vuol dire che non hai studiato e quindi guardando a mercati più europei anche scolo la Svezia o l'Italia o la Germania in cui io ho studiato gratis tutta la vita, praticamente, e non mi senso di avere un'educazione peggiore.C'è un po' un bias culturale per cui pagare per l'educazione è un po' fuori dal nostro schema.Quindi lì lo vedevo un po' la differenza di mercato.A livello di interesse per il cloud in realtà no, nel senso che soprattutto oggi se vuoi trovare informazioni tecnologiche è più facile quasi trovarla su youtube o su twitter o su linkedin che trovarla comprando un libro, sfogliandoselo.Insomma è più facile trovare esattamente l'informazione che cerchi in un giro di 5 minuti piuttosto che leggersi 300 pagine di un libro tecnico.Quindi è un po' cambiato il modo di fruire il contenuto.Anche in Italia, da quel punto di vista non vedo non vedo grosse differenze.Io proprio su quello ci faccio una riflessione qualche giorno fa perché sto studiando un po' di argomenti e ho avuto il problema sai di cercare un libro andare a studiare con metodo o guardare nella rete.Quando in realtà tu vuoi approcciare a qualcosa io mi sono reso conto che fino al livello 1 puoi salticchiare qua e là tra i video di youtube ma arrivi a un certo punto dove il tuo percorso d'apprendimento deve essere strutturato, hai bisogno, specie quando scendi o sali a livelli alti, quindi ti sposti dalla superficialità, hai bisogno proprio di qualcosa più concreto, più robusto, più pensato.E questo è da una parte, dal mio punto di vista, una critica verso molti youtuber, molti divulgatori che approcciano gli argomenti in modo molto superficiale."Just for likes" come direbbero molti.Dall'altra, secondo me, è quella cosa che dà ancora valore ai corsi a pagamento, quindi i master in qualcosa, non master solo universitari, ma dei focus di studio particolari su qualcosa e ai libri, per quanto diciamo le nostre tecnologie corrano a una velocità assurdamente veloce.No è vero e sono d'accordo.Il mio consiglio, o almeno il mio promemoria per chiunque in realtà, non solo sviluppatori, architetti o chiunque lavori nel mondo IT oggi, è che le cose si muovono talmente velocemente che è più importante sapere cosa esiste per non dover reinventare la ruota al prossimo progetto piuttosto che andare a fondo col singolo framework che per quanto possa essere bravo e veloce, supportato da una community, a un certo punto diventa obsoleto.Quindi il dettaglio non è troppo rilevante, cioè se uso React o Vue.js o qualcos'altro, o PHP piuttosto che Python o Java, quello alla fine della fiera è un dettaglio implementativo, vista ad alto livello.Secondo me quello che è importante e che io consiglio a tutti di investire tempo è fare ricerca su cosa è possibile, cosa c'è già "di pronto".Se devi costruire una casa, oggi non è che ti vai a comprare le viti e il martello, probabilmente li compri delle assi già pronte o addirittura un prefabbricato, se è esattamente ciò che vuoi.E nel software è lo stesso, come dicevo prima, la nostra missione come software developer o qualsiasi ruolo abbiate nel mondo IT è risolvere i problemi del business che al piano di sopra ci dice che problemi dobbiamo risolvere o se avete la vostra azienda poi siete voi la stessa persona comunque lo scopo non è scrivere codice lo scopo non è scegliere un framework lo scopo è risolvere il problema quindi sapere cosa esiste ti permette di risolverlo più velocemente se invece ti butta testa bassa a riprire 800 libri sul framework x quando alzi la testa il mondo è cambiato e il rischio che magari hai perso tempo.Ti sei perso.In realtà è proprio questa la ricetta che ci trasforma da ragazzini con la felpa col cappuccio a gente che in realtà produce.Io lo dico sempre una parte del mio percorso formativo è stata da imprenditore ed è la cosa che mi ha insegnato di più a sviluppare.Nel senso che nel momento in cui ti fermi a leggere qualcosa arrivi con un pragmatismo completamente diverso.Poi vero è che se lavori in AWS stai facendo una cosa esageratamente verticale ti puoi anche permettere di spaccare la vite ma se devi rilasciare un prodotto, hai un time frame molto molto ristretto a quel punto utilizzare