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.Bene e benvenuti, questa è la quattordicesima puntata di GITBAR, il podcast dei full stack developer italiani e oggi ho tante novità da raccontarvi.In primis il nuovo sito è online www.gitbar.it e avrete modo di accedere alle informazioni di tutti gli episodi.Ci sto ancora lavorando però intanto è già online e sta iniziando a prendere forma.È un'applicazione progressiva quindi potete aggiungerla alla home del vostro dispositivo e rimanere sempre aggiornati per ora è attiva solo la funzione offline quindi anche se perdete la connessione avete aperto un articolo all'interno del sito beh potrete continuare a leggerlo per ora insomma ho implementato questa funzionalità e poi avete le varie puntate dove potrete ascoltarle andare a un capitolo specifico per quello sto usando il plugin di speaker per ora finché non ne svilupperò uno tutto mio e sto continuando a lavorare per inserire delle nuove funzionalità.L'app l'ho sviluppata come vi avevo detto con Gatsby e devo dire che l'utilizzo di quel framework per lo sviluppo di siti statici mi ha entusiasmato.In realtà i dati li vado a prendere dall'API di Spreaker per ora e vengono generate tutta una serie di pagine che sono la pagina per episodio.Sto però questo periodo lavorando a una nuova funzionalità che è quella dei transcript.Per farla ho dovuto mettere le mani su una nuova tecnologia, anzi più che una tecnologia su un nuovo approccio allo sviluppo delle applicazioni, ma ve ne voglio a parlare subito dopo avervi salutato e ricordate i nostri contati.entrare in contatto con me e quindi con Gitbar scrivendomi @brainrepo oppure a info@gitbar.it mi raccomando fateci sapere le vostre opinioni e se avete anche qualche tecnologia in particolare che volete approfondire siamo sempre disponibili a nuovi stimoli dall'esterno.Altra cosa importante mi raccomando iscrivetevi nel podcast con il vostro client podcast preferito, quindi cercate "Gitbar" e cliccate sul pulsantino "+" in modo da rimanere aggiornati sui nuovi episodi che settimanalmente escono.Comunque, detto questo, possiamo partire! Ormai sono davvero tanti anni che sviluppo e ricordo quando i primi anni pubblicavo.ricordo ancora le pagine ASP su Aruba, chi è che ne ha mai fatto uso? penso che siano ancora in tanti quelli che utilizzano i servizi hosting di Aruba.Poi però mi sono evoluto e ho iniziato ad acquistare servizi che mi permettessero di avere delle macchine virtuali dove ci andava installare la mia...il mio stack LAMP quindi Linux, Apache, MySQL e PHP e questo è durato per tanto tempo e piano piano che ho preso più confidenza con le tecnologie ho iniziato a utilizzare Vagrant che con dei file di configurazione in automatico mi faceva il provisioning della macchina.Da prima su macchine virtuali che giravano con VirtualBox nel mio computer e per poi arrivare a lanciare dei comandi direttamente da Vagrant, quindi lanciare il provisioning direttamente da Vagrant su macchine remote che ospitavo su Digital Ocean.Naturalmente la tecnologia si è evoluta, tirare su una macchina con Vagrant presupponeva di avere a disposizione tanto tempo libero perché il provisioning non era poi così veloce visto che andava installato il sistema operativo, allora da prima in ambiente di development e poi in ambiente di staging per poi arrivare in ambiente di produzione ho iniziato a utilizzare Docker.devo dire che l'esperienza con docker è stata bellissima perché molto tempo perso a scrivere i file di configurazione per esempio quelli di vagrant veniva completamente eliminato da un sacco di file disponibili dalla comunità che potevi riutilizzare i famosi docker file che potevi riutilizzare per fare appunto in modo molto rapido il setup dei container però quando ho iniziato a sviluppare delle applicazioni che insomma ci sono un po' complicate.L'esempio era appunto di Political Magnet, un servizio di media listening che ho lanciato qualche tempo fa.Mi sono reso conto che forse il deploy di servizi un pochino articolati con un'orchestrazione di tipo docker dapprima con un docker compose orribile però devo ammetterlo sono andato in produzione con docker compose poi con un docker swarm per arrivare a tirare su un cluster kubernetes mi portava via un sacco di tempo io non sono un grande appassionato di operations quindi si devops per esigenza ma non ne vado pazzo e sono andato a cercare per un nuovo servizio che voglio lanciare una soluzione cercando una soluzione mi sono avvicinato al mondo serverless Il nuovo servizio che vorrei lanciare è un servizio di trascrizione automatica per podcaster, quindi inserisci il tuo feed RSS e automaticamente hai un servizio che ti genera i transcript.Non è niente di speciale, voglio fare un esperimento col mio podcast per poi vedere se ha senso lanciare un prodotto commerciale.però mi rendo conto che tirare su un'infrastruttura con container, stare di nuovo a fare le battaglie con l'orchestratore è superfluo, tanto più che superfluo nella fase in cui mi trovo, cioè quella di realizzare uno script che lo fa per me, per il mio podcast, per Gitbar.Quindi mi sono avvicinato al mondo serverless e ho scoperto veramente una serie di cosettine molto interessanti che vi voglio condividere.Quando si parla di serverless si parla in realtà di cose diverse e per capirlo è necessario fare due passi indietro.Infatti il nome serverless risale a diversi anni fa attorno al 2010 quando ci fu la trasmigrazione dai servizi on-premise quindi installati all'interno dell'azienda a servizi che si trovavano sui server remoti di prestatori terzi un esempio è appunto il passaggio dei repository di codice dai propri repository on-premise a servizi come github oppure tutti i servizi di CI che attorno al 2010 hanno fatto appunto sono apparsi nel panorama della tecnologia per le aziende.In realtà però la parola serverless appare attorno al 2015 quando amazon lancia nei suoi servizi AWS la funzionalità il servizio lambda.Infatti questo servizio smuove le acque e inizia a dar vita a un movimento chiamato movimento serverless che fa la prima conferenza attorno al 2016.Però adesso abbiamo fatto un po' di storia ma addentriamoci in fondo e proviamo a capire che cos'è in realtà serverless.Quando si parla di serverless in realtà ci si può riferire a due elementi diversi.Il Il primo è il "Backend as a Service" (BaaS) Il secondo è il "Frontend as a Service" [SIGLA] Già nella puntata precedente, quindi nella tredicesima, quando vi ho parlato di GraphQL, vi ho detto anche che il 2015 è stato un anno che ha visto questa esplosione così potente delle app mobile.Bene, sempre il 2015 è stato anche l'anno che ha visto la nascita di questi servizi di Backend.in realtà qual era il concetto che stava alla base? si aveva la necessità di tirare su delle applicazioni da poter pubblicare negli store in modo molto rapido, degli MVP che potessero andare in produzione in tempi super contenuti per farlo bisognava concentrarsi sugli elementi che sono quelli di interattività all'interno del client, per cui si è sentita la necessità di delegare la gestione e lo sviluppo di tutta la parte infrastrutturale a servizi terzi ed ecco che nella scena sono apparsi servizi come Parse o come Google Firebase che mettevano a disposizione dei servizi di storage, di gestione degli utenti, di gestione delle funzioni quindi di logica di logica di processo e delle gestioni di notifiche direttamente in server terzi gestiti da terzi senza la necessità di fare provisioning o di gestirne la sicurezza.Beh, questa è stata senza dubbio una grande rivoluzione, una grande rivoluzione anche spinta dall'esigenza di queste piccole app di avere un back-end semplice, non complesso, perché tutta la complessità in realtà di tipo processo veniva spostata sul client, demandata sul client.Alleggerendo il server di tutta la parte di renderizzazione dell'applicazione di interattività, di mera interattività, si aveva a questo punto l'esigenza semplicemente di leggere e scrivere dei dati.Poco più di questo.In realtà in questo caso noi stiamo parlando di Backend as a Service, quindi società che mettono a disposizione tutta una serie di servizi facilmente accessibili spesso attraverso delle SDK che si possono includere nel codice sorgente delle applicazioni per avere un accesso ancora più semplificato a questi servizi è nulla e in pochissime righe di codice si può andare in produzione alcuni di questi esempi sono per esempio google firebase dove ci sono delle librerie javascript o in linguaggio nativo quindi swift o java per accedere direttamente ai servizi di google per fare lo storage o per gestire gli accessi.La stessa cosa ha fatto amazon lanciando il servizio AWS Amplify che fa la medesima cosa offrendo sempre queste librerie che ne semplificano l'accesso e l'utilizzo di queste funzionalità e di queste impalcature anche strutturali di questi servizi che il provider mette a disposizione.un altro era ormai il defunto pars, dico defunto ma non è poi così defunto perché nasce come servizio back-end as a service ed era un servizio molto potente molto seguito solo che è stato poi dismesso come servizio a pagamento e adesso però è sempre presente in una sua versione open source installabile con i vari moduli e gestito da una comunità che ho visto devo dire non lo guardavo da tempo ma per preparare questa puntata ci ho buttato un occhio visto abbastanza attiva.Questo è un approccio, un punto di vista del mondo serverless.L'altro punto di vista è appunto il concetto di function as a service.Con il termine FAS invece si identifica tutta una serie di servizi che permettono l'esecuzione del codice in server terzi provisionati da terzi, gestiti da terzi, dove noi semplicemente concentriamo tutti i nostri sforzi su un unico elemento che è la nostra logica applicativa.Quindi in realtà non dobbiamo più pensare all'infrastruttura.Per pensare all'infrastruttura ci sono tutta una serie di tecnici dedicati che il fornitore di servizi ci mette a disposizione, esperti di sicurezza, esperti sistemisti, ops super skillati, noi dobbiamo semplicemente mettere il focus sul nostro codice, sulla nostra logica di business, la nostra logica applicativa.Una cosa molto interessante che entra in gioco quando si realizzano dei prodotti e ve lo dico perché ne ha avuto esperienza è quella che almeno in una fase iniziale dove non si può monetizzare da subito ma si sta andando a tirar su un MVP il costo è uno dei constraint dei vincoli maggiori in fase di realizzazione e nell'esperienza che ha avuto con la platform di media listening che abbiamo lanciato political magnet è stata quella insomma di essere quasi stritolati da dei costi iniziali.L'abbiamo lanciata su Kubernetes, no? Quindi abbiamo fatto partire tutto su un piccolo cluster Kubernetes.Cluster che aveva già solo di startup dei costi, perché era necessario un nodo master che potesse gestire poi tutti i nodi dove andavano a girare i nostri container.Tra l'altro presupponeva un po' di conoscenza di Kubernetes, la cui curva d'apprendimento non è poi così morbida e soprattutto partiva da un concetto principale che è quello della capacità riservata.Quindi in realtà il concetto di Kubernetes è quello di avere tutta una serie di macchine che possono anche essere delle macchine virtuali dove girano appunto i tool che permettono al cluster di vivere e poi i diversi container che fanno girare la nostra applicazione vengono disposti direttamente da un orchestratore all'interno di questi nodi per cui c'è comunque una capacità riservata ci sono dei costi di startup anche importanti con kubernetes siamo riusciti a contenerli ma ricordo quando ho fatto un workshop su DCOS mi ricordo che il lancio di un cluster mi costava qualcosa tipo 60 euro al mese che in realtà per fare dei test è un prezzo spropositato oltre a questo per il lancio di questo cluster c'era bisogno anche di tutto un bel po di tempo da dedicare proprio per il setup quindi insomma tutto sembrava giocare contro di noi adesso il servizio sta girando e sta girando su un cluster kubernetes abbiamo anche fatto un po di esperienza però per il nuovo servizio che volevo lanciare che voglio lanciare che quella appunto della trascrizione dei podcast non mi va di rimettermi in mezzo e dentro a tutti questi problemi che abbiamo già vissuto per cui l'idea è quella di utilizzare queste lambda function, le lambda function dove il concetto cambia completamente e dal concetto di orchestrazione dei microservizi si passa appunto al concetto di coreografia quindi ormai non devi gestire tutti i microservizi e tutto il cluster che stai andando a tirar su ma devi invece più che altro immaginare la tua architettura, progettarla bene prima e immaginare un'architettura di tipo event-driven dove appunto tutte le comunicazioni e tutte le azioni sono degli eventi.A questo punto utilizzando quest'approccio è la possibilità di utilizzare appunto le tecnologie lambda che ti permettono intanto di pagare solo quello che usi quindi non scali da un'unità minima di n macchine per il cluster a y macchine ma parti da zero cioè se la tua lambda non va in esecuzione perché magari mancano gli eventi per andare in esecuzione un evento può essere anche una chiamata un endpoint di api a quel punto non paghi niente tra l'altro il tempo in realtà per tirar su questo servizio è semplicemente il tempo di partenza della tua funzione non devi settare il cluster fare mille casini no semplicemente carichi la funzione del provider e ce l'hai bella pronta insomma un approccio un po ready to go tra l'altro approccio anche garantito da dei framework che ti permettono di farlo come serverless che è il framework che sto utilizzando e di cui vi parlerò tra qualche minuto.Per cui appunto c'è il concetto portato all'inesima potenza di microservizi quindi ti eviti praticamente di pensare a tutta l'infrastruttura.Naturalmente l'utilizzo delle lambda function e quindi delle function as a service ha dei pro e dei contro.I pro sono che hai un'architettura architettura legata agli eventi che comunque permette la tua applicazione di essere super performante, hai un auto scaling senza pensarci nel senso che ci pensa poi il tuo provider e paghi solo il consumo.Questi sono i concetti principali pro principali dell'utilizzo di infrastrutture di approccio appunto a funzionalità lambda.C'è proprio il concetto che si passa da monolita a microservizio a funzioni quindi alla fine pensi e strutturi la tua applicazione anche in funzione di questo cercando di disaccoppiare al massimo i tuoi servizi e questo anche a livello di progettazione ti dà dei vantaggi esistono però dei contro quando tu sviluppi utilizzando queste architetture lambda che possono essere le lambda function di avs oppure le function di google cloud beh in qualche modo hai un problema di vendor lock-in quindi utilizzando appunto l'infrastruttura in modo così forte ti agganci in qualche modo al provider e diventa più difficile starti a svincolare naturalmente un altro problema è che se hai in mano un applicazione che è un monolita devi in qualche modo devi andartela riscrivere perché perché dovresti dividere il monolita in funzioni e quindi diciamo che questo presuppone un processo di hard refactoring.Un altro problema che ho riscontrato come esperienza personale con le lambda function di AWS è anche il problema dei quattro secondi di timeout nel senso che la tua lambda function ha 4 secondi per essere eseguita e poi viene killata e questo se hai delle delle applicazioni che presuppongono il calcolo intensivo beh qualche problema te lo te lo te lo generano e un'altra un'altra cosa importante è che queste funzioni vengono eseguite in ambienti effimeri quindi in realtà gestire lo stato diventa un pochino complesso.Beh detto questo vi voglio raccontare quello che sono riuscito a fare fino a oggi.Allora come vi dicevo il concetto era quello di creare un sistema automatico per i transcripti.Io ho il mio feed del podcast e avevo bisogno di qualcosa che girasse in completa autonomia autonomia che mi generasse queste trascrizioni pronte per essere poi messe pubblicate all'interno del sito in modo da avere un boost in termini di SEO.Allora come ho strutturato l'applicazione? Beh innanzitutto ho utilizzato un framework che mi semplificasse l'approccio ai provider.il framework che utilizzo si chiama serverless che con la sola configurazione di un file yaml mi permette con veramente pochissime righe di fare il provisioning di tutta una serie di servizi di amazon quindi basta che tutti i generi un utente con avsam che ha una serie di diritti a questo punto associ questo utente con un comando che lancia linea di comando alla tua stanza serverless, alla tua applicazione serverless che gira nella tua macchina da quel momento in poi tu con un solo file YAML ti configuri la tua infrastruttura che nel mio caso va a indicare a CloudFormation che è un servizio che si occupa di provisioning di vari servizi di Amazon quindi che ne so ti tira su i bucket S3 per salvare i dati, ti tira su il servizio di trascrizioni, si collega, ti imposta i diritti fa tutto quello che deve fare a quel punto ho generato diverse lambda, sono tre la prima che gira a un intervallo di tempo che è quello di un giorno e va a controllare sul feed se ci sono dei nuovi episodi, paragonandoli con gli episodi che ho già salvato nel booket S3 se ci sono dei nuovi episodi beh se li va a scaricare su S3 a questo punto un'altra lambda che va ad rimanere in ascolto sul bucket degli episodi quindi sullo spazio fisico quando un nuovo episodio, un nuovo file mp3 viene messo in quello spazio fisico si avvia e lancia un comando ai servizi di trascrizione di amazon servizi che una volta terminati vanno a salvare il file su un altro bucket quindi mi salvano un file, semplicemente un file JSON una volta che io ho salvato questo file ho un'altra lambda che rimane in ascolto di questo bucket e quando vede che c'è una nuova trascrizione disponibile non fa altro che chiamare un hook e rilanciare la compilazione statica del sito con Gatsby ve ne ho parlato nella puntata mi parlava appunto di CMS headless e di motori per la generazione di siti web statici quindi mi viene ricompilato completamente il sito, mi vengono generate le pagine statiche che includono la trascrizione è tutto automatizzato, un unico processo che in un solo colpo mi permette di mettere online la trascrizione utilizzando un'infrastruttura che è complessa ma per la quale io non ho avuto il minimo mal di testa, il minimo problema di setup e soprattutto dei costi base di struttura.Perché se io domani mattina fermo le lambda o se non pubblico nessun episodio io non pago proprio un bel niente.E questo è il vantaggio.Veramente in poche ore sono riuscito a tirar su un servizio per quanto artigianale che mi permettesse di raggiungere l'obiettivo senza tirare su cluster, avere macchine su Amazon o su Digital Ocean che hanno dei costi fissi, ma semplicemente pagando quello che consumo.Quello che consumo sono i servizi di trascrizione, queste Lambda e lo spazio fisico su S3 che mi costa a un inizio veramente pochissimi centesimi, tanto che sono ancora credo nel piano gratuito, sono ancora coperto dal piano gratuito e quindi nulla tutto funziona tra un po' tra qualche giorno tempo permettendo riuscirò a deploiarla in produzione con il minimo sforzo.Spero che questa puntata vi sia piaciuta oltre a essere una puntata tecnica era anche una puntata dove vi ho raccontato un po' di fatti miei.In realtà mi piaceva proprio partire dalla mia ed è una cosa che mi piacerebbe tirar dentro sempre di più all'interno del podcast.Se poi voi avete delle esperienze da condividere, beh, potete farlo inviandoci un'email a info@gitbar.it oppure scrivendomi a @brainrepo su Twitter.Perché no? Siamo sempre disponibili ad ascoltarvi e a condividere il nostro spazio all'interno del podcast anche con voi.Vi ricordo che per rimanere aggiornati su tutte le novità di Gitbar potete iscrivervi con il vostro client di podcast direttamente nel nostro feed in modo che ogni settimana riceviate la notifica e stiate al passo con gli episodi Anche per oggi da Lione è tutto, un saluto da Brain Repo e ci sentiamo la prossima settimana Ciao! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e degli strumenti immancabili nella cassetta delle attrezzi dei fullstack dev.[MUSICA]
