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 su Gitbar.Un'altra settimana e un altro episodio del nostro podcast.anche oggi non sono solo diciamo che nonostante questa quarantena, visto che noi siamo in piena quarantena, la solitudine non mi viene a fare visita visto che in tutte queste ultime puntate ho sempre un ospite con me.Anche oggi con me c'è un professionista che ci aiuterà a esplorare un mondo molto interessante ma prima di introdurvi l'argomento come ben sapete vi devo ricordare i i nostri contatti e me lo farò tranquilli molto velocemente.Info che ho la github.it via email o @brainrepo su twitter sono i modi per entrare in contatto con me.Naturalmente il gruppo telegram gioca un ruolo molto importante per farci due chiacchiere e scambiarci altri contenuti visto che questo è lo scopo del nostro podcast.Ma non perdiamo tempo in chiacchiere prendiamo giusto una piccola pausa e poi vi presento l'ospite di oggi.Oggi con me c'è Leonardo Rossi che è un back-end developer, ahimè come tutti, deve confrontarsi con un'operatività un pochino più full stack.e di Firenze, una città bruttissima direi.Si, concordo.E lavora a Nearform.Ciao Leonardo, come va? Ciao, tutto bene, ciao a tutti, grazie dell'invito.Ti ascolto da sempre, da quando si chiamava Gitbar, se ricordi bene, nelle prime puntate.Ricordi anche i miei accenti e le mie lettere sbagliate, quindi.Ma il solito problema di...si dice "gif" o "gif", tutta una diatriba dietro, uno la dice come viene, però mi sembra si dica GIF, non vorrei sbagliare.Tranquilli, adesso parte il flame nel gruppo Telegram.No guarda, tranquillo, anche se si chiamasse GIF o GIF io sbaglierei comunque, quindi ormai...Così che l'altro.Come tutti sanno, io faccio sempre un gran miscuglio tra inglese, francese e italiano e sto iniziando ad avere qualche problema.Detto questo, di cosa parliamo oggi, Leo? Oggi parliamo di un argomento che deve far parte, secondo me, della famosa cintura, casetta degli attrezzi del Full Stack Dev, che è l'Infrastructure as a Code.Dato che il nostro codice, le nostre applicazioni, da qualche parte devono stare, qualche server ci deve essere che fa girare il nostro codice, sapere quello cosa succede nel background secondo me è una cosa interessante e mi faceva piacere condividere le pensieri con te assolutamente il piacere è tutto mio quando si parla di infrastructure as a code mi viene in mente un concetto che si ripete sempre quando si parla di marketing questo concetto dice che tu puoi creare il prodotto più figo del mondo con tutte le funzionate immagina di essere un artigiano no? Quindi crei la statua un artista, crei la statua più bella del mondo ma se non la sai vendere la tieni nel tuo laboratorio probabilmente quella statua non ha alcun valore esatto e tu non sei un artista perché nessuno vede per la statua bravissimo invece la stessa cosa anzi senza invece proprio la stessa cosa accade col nostro codice se noi creiamo la nostra applicazione può essere l'applicazione più figa del mondo se la lasciamo su un container o ancora meglio su una cartelletta nel nostro nel nostro desto o su una repo su github repo ripo giusto per ritornare sempre al solito discorso non la deploiamo da qualche parte Probabilmente abbiamo non potremo anche non essere degli sviluppatori oltre che insomma buttare sul cestino un prodotto tra l'altro noi usiamo spesso impropriamente "deployare" e per deployare noi tendiamo tutto e il contrario di tutto cioè rendere fruibile.Questo dal mio punto di vista e non solo dal mio potrebbe essere una generalizzazione alle volte non opportuna perché in quello che noi definiamo come "deployare impropriamente" ci sono tutta una serie di fasi.Una di questa è appunto il setting dell'infrastruttura e quello che noi usando la parola giusta diciamo chiamiamo provisioning dell'infrastruttura la preparazione delle macchine che ospiteranno al nostro codice esatto ma Leo dal tuo punto di vista come si è evoluto proprio questa fase nel tempo? Allora diciamo che dall'inizio della storia del web quindi dalle prime pagine html che si potevano vedere quindi si parla in Italia almeno di fine anni 90 esisteva un'infrastruttura che serviva le nostre le nostre pagine però il rapporto che c'era tra lo sviluppatore e questa infrastruttura è cambiato molto nel tempo.All'inizio diciamo che abbiamo abbiamo i data center.Ok? I data center cosa facevano? Affittavano un metro quadro, al metro quadro anzi, ti davano la connessione alla rete e l'elettricità.Su quel metro quadro te potevi fare quello che ti pareva.Di solito cosa facevi? Prendevi un rack e ci mettevi dentro i tuoi server che facevano girare la tua applicazione.Chiaramente si sta parlando di una soluzione molto overkill per chi aveva il sito web personale.Quindi esistevano dei provider che rivendevano, mettevano questi rack nei server e rivendevano il noleggio, cioè noleggiavano questi questi server.Quindi siamo passati da avere solamente lo spazio, il famoso column, da collocation si chiamasse, a avere il tuo server bare metal.Bare metal cosa voleva dire? Che il provider ti dava il server, ti dava l'indirizzo IP, l'accesso SSH, fine.Da lì dovevi, iniziava il tuo lavoro.Le uniche cose che venivano delegate era, mi si è rotto il cavo di rete e allora andava la persona del data center a riattaccarlo, va via la luce, va a fuoco il data center, ecco, nel caso si poteva fare poco, però tutto il developer se voleva usare questa soluzione doveva configurare tutto da zero, aveva una macchina completamente pulita.Da questo momento, quindi, uno sviluppatore cosa faceva? Non aveva più, non pagava più il server per 5 anni, ma magari lo pagava per un anno.Il provider riusciva così a affittare lo stesso server a più persone durante il contratto che aveva con il data center.I server sono molto potenti, solitamente.Quindi, avere un server intero per la tua pagina web anche questo era overkill quindi i provider cosa facevano? Usavano delle soluzioni di tipo shared server ossia invece di darti l'accesso al server ti davano accesso alla tua cartella, ti davano i dati ftp e ti dicevano guarda il tuo dominio gitbar.it ha questa cartella, mettici dentro il file html.Benissimo, comodo, però che succede se io uso una versione di php diversa da quella che c'è sul server? Chiama il provider, chiama il data center, Alla fiera dell'est.Esatto, c'era tutto questo passaggio.A un certo punto si sono evoluti anche i processori e un cambio, diciamo epocale, se si può passare il termine, è avvenuto quando i processori hanno iniziato a supportare delle tecniche di virtualizzazione, cioè a livello a livello hardware i processori potevano virtualizzare degli altri ambienti se avete mai usato VMware o VirtualBox per installare Linux su Windows o viceversa vi accorgete che se chiaramente il vostro processore, ormai da diversi lustri direi tutti i processori supportano la virtualizzazione ti rendi conto che stai dentro, quando apri VirtualBox e installi Windows all'interno di quel Windows, diciamo quindi nella macchina guest, siamo dentro un sistema operativo completo c'è una scheda di rete, c'è una scheda video, c'è una scheda audio e il tutto non è emulato via software viene virtualizzato dall'hardware del processore e dal kernel del sistema operativo in questo modo invece di poter, di dover dare una cartella allo sviluppatore si poteva dare un server che condivideva le risorse con altri server virtuali all'interno di questa macchina fisica e questi sono i VPS, Virtual Private Server, che sono soluzioni che tuttora sono in voga e i prezzi sono ridicoli perché se uno vuole iniziare a mettere un'applicazione web su un server si parla di 2, 3, 5 dollari come prezzo base, poi chiaramente a salire a seconda delle prestazioni che vogliamo Però, ecco, è cambiato molto il rapporto con cui possiamo pubblicare le nostre cose perché la barriera di ingresso è bassa a livello economico, ci vuole certo delle conoscenze di amministrazione di sistema, i famosi sysadmin, che ci sono tuttora, per poter creare la nostra infrastruttura, che banalmente può essere solo il server web o il server database, però vedremo più avanti che in realtà adesso le cose sono molto più complesse.Perché? perché dai virtual private server, cosa si è pensato? Si è pensato che in realtà noi potremmo affittare questi server non solo al mese, ma anche all'ora.Addirittura AWS fa dei prezzi al secondo.Quindi io apro 10 secondi un'istanza o uso 10 secondi un servizio, pago solo quei 10 secondi.Quindi è cambiata completamente il modo in cui si pubblica, ma il modo in cui anche si può aggiornare la nostra infrastruttura, che è un po' il topic principale della chiacchierata di oggi.Leo, credo che un ruolo importante l'abbiano giocato anche il fatto che alcuni linguaggi non strettamente legati al ciclo richiesta-risposta come può essere PHP, siano entrati a giocare un ruolo nel mondo del web, no? Cioè, detto tra me e te, nel momento in cui le persone hanno iniziato a sviluppare dei portali con javascript lato back-end, quello che in realtà veniva offerto da una parte con l'hosting condiviso e quindi era impossibile, è concettualmente impossibile far girare del javascript su un hosting condiviso, perché avresti dei problemi di sicurezza e quando questo tipo di linguaggi sono entrati nel mondo dei più si sono sviluppati delle esigenze che in qualche modo il mercato doveva andare a soddisfare quindi non solo legate ai grandi player che avevano anche le capacità economiche di andare là e mettere nei rack i loro server ma anche l'ultimo pirlozzo che poteva essere io dieci anni fa lo sono ancora, ma questo a parte però...Ora sei un pirlozzo con 10 anni di esperienza.Esatto, sono un pirlozzo alla decima.Aveva la necessità di avere qualcosa di un pelino più evoluto rispetto allo spazio web.Da lì poi sono proliferati concetti come Yass, Pass...Esattamente, perché poi queste strutture si sono evolute a tal punto che adesso non non si affittano più solo server, ma si affittano anche servizi, come dicevo prima, che possono essere scritti in diversi linguaggi.Poi è chiaro che sotto sotto c'è sempre un processore che esegue le istruzioni, anche se si utilizza, te lo utilizzi per gli fare lo speech to text per fare le cose.È chiaro, non è una...questo è un servizio che gira su un computer, ok? un computer su una macchina quindi da qualche parte c'è un software che fa il transcoding di questo e questo è un servizio che viene che è scritto magari non so in python o in ruby non lo sappiamo però è un servizio che viene viene venduto al minuto al secondo insomma in solo quando serve on demand non è più una cosa che dice ok ho questa macchina e fa il transcode per un anno l'ho affittata e sono a posto quindi è vero si è cambiato anche il modo in cui si approcciano la pubblicazione perché poi alla fine il testo che ti traduci, che viene transcodato, poi va a finire in una pagina web e quindi fa parte del tuo sito web.Però è un servizio esterno che prima dovevi magari fare girare in locale, adesso hai tutto in cloud.Cloud è un concetto che ancora non abbiamo nemmeno introdotto, però visto ci si arriva.Ecco, hai citato la parola cloud, una parola super controversa, c'è la guerra sul cloud, è diventato sì parte integrante delle nostre vite ma c'è sempre da discutere perché è un argomento molto interessante, diciamo è quel posto un po' volatile dove mettiamo una parte della nostra vita fondamentalmente.Quindi andiamo a introdurre proprio il concetto di Cloud.Allora io vorrei iniziare con un aneddoto, non mi ricordo dove l'ho sentito, probabilmente durante una conferenza a un evento di network, la classica birra post conferenza, avevo sentito quella cosa dell'orecchio, uno diceva "eh Cloud, Cloud è il computer denantro" perché fondamentalmente è questo, però il concetto di Cloud è dato dal fatto che non ci sono limiti fisici.Quando ti viene presentato un servizio in cloud non ti dice "guarda, non puoi fare più di questo".È cloud, è scalabile, è infinito.Quindi è sotto sotto in realtà non c'è solo un computer, ci sono più computer, oppure ci sono più risorse che vengono da macchine diverse.Quindi il concetto di cloud è semplicemente un insieme, una rete di macchine che hanno, che mettono a disposizione diversi servizi, dai più disparati servizi, che vengono venduti con un prezzo al consumo.Quindi questa è più o meno una delle tante definizioni che possiamo dare al cloud.E abbiamo tre player principali, che sono AWS, Amazon, Google Cloud Platform, e Microsoft Azure.L'ho detto in ordine cronologico da quando sono stati lanciati, perché AWS è del 2006, Google Cloud è del 2008, Azure è del 2010, anche se poi queste date sono un attimo...anche lì sono tipo in cloud, sono un po' aleatori, perché in realtà il primo servizio di AWS, che era solo il servizio di code, è già dal 2002 che c'è, però in realtà nel 2006 hanno fatto tutto un reprending e diciamo che è stata messa quella milestone.Sì, Leo, se permetti, aggiungerei anche Alibaba Cloud ai player, perché noi non ne parliamo perché facciamo parte del mondo occidentale, però se io dicessi che il 32, se ricordo bene, per cento del mercato asiatico gira su Alibaba Cloud noi abbiamo un numero che è assurdo.Tra l'altro questa è anche una piccola marchetta per anticipare uno degli incontri che faremo qua su Gitbar, uno degli episodi che faremo con Paolo Mainardi dove parleremo proprio di Alibaba Cloud, quindi nelle prossime puntate approfondiremo l'argomento.Scusa se sono entrato a gamba attesa, ma Per me è importante proprio come provare di ricordarlo in modo da avere anche una visione un pochino più globale rispetto alla visione occidentalo-centrica.Esatto, infatti ci sono anche altri player secondari come IBM, Oracle, c'è anche Tencent Cloud, infatti che immagino siano più orientati al mercato.Non sono filo cinese, citando...No, però è giusto, giusto conoscere perché chiaramente ci sono anche dei motivi politici per cui c'è questa grossa divisione, basta pensare che WeChat è molto più usato in Cina da noi, non ce l'ha nessuno se non chi ha per esempio contatti con la comunità cinese, non lo so perché fa business con i cinesi, deve usare WeChat perché non tutti usano Whatsapp, parlo per esperienza personale qui a Firenze.è una cosa che va conosciuta, cioè se dobbiamo, dato che non tutti i servizi per esempio di AWS sono disponibili in tutte le regioni, magari noi dobbiamo fare una cosa per il mercato asiatico scriviamo tutta la nostra infrastruttura per AWS e poi andiamo a vedere che l'anno lo possiamo usare per dei motivi politici invece dovevamo sviluppare per Alibaba Cloud, quindi è importante sapere ci sono diversi player infatti anche questi player di cui AWS è il più grosso rispetto agli altri due però hanno delle delle peculiarità anche google cloud platform e microsoft azure ad esempio microsoft azure ha un sacco di clienti dell'enterprise perché perché si intiga benissimo con la suite office con windows server con come si chiama active directory quindi è chiaro che chi ha un ufficio o un diversi uffici che usano tutti windows e quindi hanno già delle cose in rete e passare a azure è molto meno faticoso che passare a AWS.Quindi hanno delle nicchie, stessa cosa per Google.Chi usa Google Suite è più incentivato a usare anche Google Cloud Platform perché si integrano bene tutti i suoi sistemi di autenticazione, eccetera.Mentre AWS viene da un altro tipo di business che era la vendita dei libri e poi la vendita adesso di qualsiasi cosa.Però cos'è successo? A un certo punto loro hanno creato questa infrastruttura, hanno detto "aspetta, ma noi questa infrastruttura, visto che funziona bene, potremmo provare a venderla, potremmo provare e quindi sono nati i vari servizi che ad oggi mi sembrano siano più di 170 - Non li ho contatti, però sono...- L'ho visto in qualche...però anche lì non sai mai se poi quel numero va bene perché ogni anno c'è una nuova conferenza e ne presentano altri 10 che poi magari non tutti vanno in produzione quindi il numero è alto e quindi non si tratta più del hosting del server in SSH, si parla di machine learning, di code, database text to speech, riconoscimento delle immagini, VR, è molto ampio.Diciamola, cosa interessante proprio del cloud è stata anche in termini di ottimizzazione delle risorse, perché buona parte, adesso la butto un po' sul super basic ma giusto per intenderci buona parte del tempo che utilizziamo del tempo macchina dei nostri computer remoti la sto proprio buttando alla alla zuppa di fagioli però per dirci buona parte del tempo di elaborazione queste macchine non sono nel tempo di uso queste macchine non sono utilizzate quindi è un salto in avanti a livello di efficientamento quindi una grande rivoluzione naturalmente come dici tu il computer è degli altri quindi di lì ci sono tutta una serie di ragionamenti da fare specie dopo che la corte europea ha approvato lo shrems 2 e quindi tutto andrà rimesso in discussione quanto prima però oltre alla parte fisica dei server, un'altra cosa si è evoluta e sono i ruoli.In realtà prima di questa transizione si avevano due ruoli principali.Da una parte c'erano i dev, dall'altra c'erano gli ops.Queste due figure avevano responsabilità completamente diverse.La responsabilità del dev era far evolvere rapidamente l'applicazione perché noi sappiamo lavoriamo nel settore sappiamo bene quanto valga il concetto di time to market quindi avevamo i dev che lavoravano pesantemente per cercare di far crescere il più possibile l'applicazione di soddisfare il più velocemente possibile le risorse di business questo era il loro obiettivo dall'altra parte avevamo gli ops che invece lavoravano per un altro obiettivo che era quello...completamente diverso...quasi quasi agli antipodi no? che era quello di garantire la stabilità dei sistemi adesso se è chiaro capire che se tu stai garantendo devi garantire la stabilità devi in qualche modo mettere una sorta di freno alla velocità e alla rapidità che invece il mercato ti richiede.Per cui tra queste due figure si andava a creare un conflitto per cui i dev cazziavano gli ops per i ritardi nei deploy e gli ops cazziavano i dev per la qualità dei codici.Insomma una lotta.Esatto esatto infatti quando le cose non andavano uno dava la colpa a quell'altro perché diceva "no l'infrastruttura non regge, ma che è, è scritto male il codice?" e via e via.Poi mi piace immaginare esatto un momento in cui un dev e un ops che fanno la famosa pace pace diavoletto.Il giochino che facevamo da bambini è quello è il momento in cui si va a creare, si va a sviluppare la filosofia DevOps che senza tanti fronzoli e senza tante parole cosa fa? Va a creare un ponte tra il mondo degli Ops e del Dev facendo in modo che queste due fazioni Guelfi e Ghibellini si vadano a incontrare attraverso cosa? Ancora prima degli strumenti attraverso un obiettivo comune.Qual è l'obiettivo comune? Quello di generare valore per la company, quello del raggiungimento degli obiettivi aziendali.Per cui da lì nasce l'esigenza di avere degli strumenti che possano da una parte garantire della stabilità ai sistemi, ruolo degli Ops.Dall'altra garantire la rapidità nello sviluppo, il ruolo dei Dev.Tutto questo si raggiunge con lo sviluppo del concetto di consapevolezza.Il concetto di consapevolezza dei Dev verso gli Ops, quindi sai che si stai scrivendo il tuo codice ma cribbio un'idea di dove quel codice andrà a girare ce la devi avere.Dall'altra il concetto degli Ops che in qualche modo devono imparare a prendere il linguaggio tipico dei Dev e devono anche in qualche modo adattarsi alla velocità dei Dev.Questo ha dato anche vita delle figure mitologiche un po' strane che sono per meta Dev e per meta Ops.Insomma tutti noi alla fine quando facciamo dei saved project siamo questi mostri a due teste però diciamo che oggi il contesto ci aiuta, ci aiuta attraverso una serie di strumenti, due sono quelli che adesso vi butto sul tavolo e di cui parliamo con Leonardo, da una parte abbiamo tutto il concetto di CI/CD quindi di delle pipelines ma che per nascere e per funzionare ha bisogno che noi semplifichiamo tutti quei click che l'ops, quei click o quei comandi bash, che l'ops lanciava per andare a impostare, settare, costruire la nostra infrastruttura e questo si fa appunto col concetto di infrastructure as a code.Leo, che cos'è l'infrastructure as a code? L'infrastructure as a code è un nuovo modo di intendere il software, perché il software può creare dell'hardware.Adesso noi stiamo sempre parlando di hardware virtuale, quando si parla di cloud e creiamo una scheda di rete virtuale, non c'è nessuno che va a avvitare una vite.È tutta una cosa gestita tramite software e tramite virtualizzazione dei processori e servizi del kernel del sistema operativo.Però, quello che è interessante è che, a questo punto, i servizi di cui abbiamo parlato prima possono essere attivati, disattivati e configurati tramite software, ok? Banalmente tramite delle chiamate API, però al monte di queste chiamate API sono stati creati dei sistemi per velocizzare la scrittura e l'automatizzazione di questi software.Quindi, un sysadmin che magari prima scriveva solo gli script bash quando accedeva al server perché doveva configurare delle cose, immaginiamo solo la creazione degli utenti in un'azienda, gli utenti vanno e vengono, licenziamenti, assunzioni, è chiaramente una cosa che va automatizzata.il sysadmin aveva la sua, nella sua cassetta di attrezzi aveva gli script bash a questo punto non sono più sufficienti perché non abbiamo più solo una macchina abbiamo la stessa pipeline di cui ho parlato prima è un software che gira su una macchina chi è che fa il deploy della pipeline che a sua volta farebbe il deploy del software e ora qui si diventerebbe una specie di inception però questi sono gli argomenti che un sysadmin deve tenere in considerazione Se io voglio creare una pipeline su AWS, con il servizio CodePipeline e i vari servizi satellite, io posso andare nella console e con vari click e varie digitazioni sulla tastiera creare la pipeline e configurarla.E questo è quello che si poteva fare prima.Adesso non è più un approccio che si può fare nel 2020 perché è un approccio che porta sicuramente degli errori.ogni volta che clicchi puoi cliccare in un posto sbagliato soprattutto è un lavoro tedioso che porta anche a uno sfinimento morale del povero SysAdmin quindi cosa è successo? si sono cominciati a creare non tanto dei linguaggi di programmazione perché spesso si usano dei linguaggi di programmazione già utilizzati JavaScript per esempio oppure anche Python e quindi SysAdmin si trova a un certo punto a doversi spostare e diventare un po' dev perché se vuole automatizzare deve usare un linguaggio di programmazione e quindi abbiamo questo avvicinamento del Dev verso il SysAdmin perché ha la consapevolezza che comunque il suo software gira e d'altra parte il SysAdmin che si avvicina al Dev perché comunque un linguaggio di programmazione lo deve imparare per poter automatizzare questi processi.E nel mezzo più o meno sempre con il concetto di Cloud c'è questa figura, questo concetto del DevOps più che la figura perché comunque un SysAdmin avrà comunque le sue competenze devono rimanere quelle, cioè un sysadmin ha delle competenze di network, di database, di server, ma anche di costi, cioè prima un sysadmin gli dicevano "guarda, compra una macchina per fare il database" e lui doveva andare a vedere "ma quante utenti abbiamo? quante transazioni abbiamo? ok, compra questa macchina perché non voglio spendere di più e non voglio prendere una macchina sottoperformante" quindi un sysadmin ha tutte queste competenze che il dev non ha ed è giusto che cioè giusto diciamo e queste competenze con queste competenze rimangono perché io posso creare le mie migrazioni per il database quindi ho il database utenti so dei dati di cui ho bisogno poi magari il sysadmin dice ok aspetta ma la password è sempre lunga 60 allora ti fa un campo da 60 non te lo fa da 100 e sono tutte cose che piccoli pezzi di un puzzle che portano a un risparmio e un'efficienza migliore assolutamente sì come non essere contrario.Aggiungerei solo che secondo me uno dei turbo boost che ha spinto l'utilizzo degli script per la configurazione specie in ambiente cloud è stata la fantastica accessibilità delle interfacce dei sistemi cloud che usiamo tutti i giorni.Sono di una semplicità e di un'intuitività che è disarmante.Naturalmente sono fortemente ironico perché sembrano scritti da un bambino di seconda elementare quindi alle volte è più intuitivo davvero farti lo script per provisionare bruttissima parola provisionare per mettere in piedi l'architettura che farla da pannello naturalmente tu hai parlato della riduzione dei costi ma ci sono anche degli altri vantaggi giusto nel concetto di infrastruttura come codice esatto esatto perché noi Noi possiamo considerare...teniamo sempre in mente un esempio semplice, cioè abbiamo un database e un server web, quindi diciamo che noi abbiamo un database e un server web che è in produzione.Noi possiamo con...attraverso l'infrastructure as a code, possiamo avere degli ambienti, uno per ogni dev, quindi ogni dev ha il suo database e il suo server web sempre sul cloud, completamente separato dalla produzione.possiamo avere più ambienti, quindi questi ambienti sono replicabili, replicabili velocemente, cioè non replicabili che chiedi al C-Satwin "Guarda, ti ricordi tutti i click che hai fatto? Ecco, me li rifai, però stai attento ai nomi, stai attento agli IP, perché non si devono parlare".Ecco, avere una cosa replicabile, quindi configurabile, diciamo parametrizzabile, è sicuramente un vantaggio.Oltretutto, questo codice, dato che quello di cui parliamo è codice, sono file, noi li possiamo versionare, ok? Quindi noi possiamo utilizzare Git per avere il nostro codice dell'infrastruttura che è versionato, su cui si possono fare delle PR.Quindi il concetto di software e hardware, diciamo, e infrastruttura si mischiano.Inoltre, tutto questo è automatizzabile.cosa vuol dire automatizzabile? Che io posso usare la pipeline per deployare la mia infrastruttura.Ok? Quindi la pipeline, oltre a deployare che è un'altra parola bruttissima, però mi viene questa, deployare il software, quindi la nostra nuova applicazione web che adesso supporta anche la feature X, implementa anche adesso, l'infrastruttura implementa le code, perché adesso le mail vengono mandate tramite le code e non in sincrono.Ok? Quindi questo è un upgrade, una nuova versione dell'infrastruttura che non cambia nulla al dev che scrive il software, quindi sono due cose separate, però anche l'infrastruttura può essere deployata in maniera automatica al semplice commit su git.Quindi i vantaggi sono molteplici.Sì, io credo che sia anche evoluto il modo in cui noi scriviamo il codice, proprio a partire dall'evoluzione dell'infrastruttura.Oggi si parla tanto di Cloud First Application o Cloud Application.Cloud Native.Questo perché in realtà buona parte della nostra complessità viene spostata in alcuni servizi che sono molto vicini all'infrastruttura.Tu hai fatto l'esempio delle code per le mail.Prima cosa facevamo? Prima avevamo un processo che girava magari con una cron adesso sto banalizzando e faceva un bel send mail ogni quarto d'ora girava da parte perché è fantastico oggi naturalmente questo non è il modo migliore per poterlo fare perché perché tu semplicemente cosa puoi fare in modo più semplice puoi mandare un messaggio in una coda di AWS AWS prende in carico il messaggio lo distribuisce attraverso verso quali canali? Il canale email ma domani potrebbe essere il canale notifica push.Tutta quella complessità ha traslato da la parte relativa al nostro codice quindi il codice che scriviamo alla parte relativa all'infrastruttura che ci sta sotto.Immaginiamo hai nuovi io devo fare una nuova applicazione in un pelino enterprise bene ragionamento tipico micro servizi.I micro servizi non possono esistere se alla base non ho dei sistemi di gestione semplice dell'infrastruttura dove vanno a girare perché buona parte della complessità la delegano all'infrastruttura.Devo dire anche che col tempo il lavoro che sto facendo sull'infrastruttura sta diventando sempre più trasparente.Un esempio è quello delle lambda di amazon dove il lavoro che fai tu verso l'infrastruttura quindi questa credo sia una tendenza proprio per andare a iper semplificare l'approccio con l'infrastruttura.Il lavoro che tu fai verso l'infrastruttura si limita veramente a pochissime cose.Super basic.Naturalmente le nostre applicazioni non sempre possono girare serverless.Voi perché i contesti aziendali spesso ci mettono davanti a delle situazioni dove quella più comune è quella di avere un monolita davanti da dover mettere in produzione e in quel caso devi prendere consapevolezza appunto dell'infrastruttura.Mi era venuto un esempio riguardo a questo shift dal codice all'infrastruttura che mi è capitata su un progetto su cui ho lavorato da NearForm.Praticamente io stavo lavorando su un'infrastruttura di questa applicazione che aveva database relazionale.E quindi ho detto "ok, adesso devo configurare, insomma, i backup, che devo fare in modo che vengano fatti i backup".Prima cosa si faceva? Si scriveva un'applicazione, pensiamola anche in maniera 2020, scrive una lambda che le lambda possono essere anche triggerate, diciamo, come se fosse un cron.quindi anche qui, cron viene simulato però fa girare una lambda e dico prendo il database e scrivo il mio codice che mi prende tutte le tabelle mi fa lo zip, lo mette su S3 perfetto, mentre lo facevo sono capitato su una pagina che mi diceva che in realtà RDS di Amazon fa già i backup automatici basta un paio di flag e dice ogni quanto, ogni dove e salva già in S3 quindi l'infrastruttura che poi sotto non sappiamo se loro al suo interno utilizzano una lambda o Python, non ci interessa, però è una cosa che noi non dobbiamo più scrivere, un backup alla fine è un backup perché non è che c'è da fare tante cose, se ci fidiamo di quello che fa l'infrastruttura è un problema in meno a cui non dobbiamo pensare noi ma devono pensare gli ingegneri di AWS.Assolutamente sì, ma ti faccio un altro esempio proprio il concetto di utilizzo dell'infrastruttura, no? Anche per quanto riguarda il fatto che debba essere replicabile e automatizzabile, che sono due caratteristiche tipiche.Mi viene da tirare l'esempio che ho visto proprio ieri mentre, nel momento casavianello, mia moglie lavorava.Cosa deve fare? Deve trattare una mole di dati in batch.Quindi cosa fa? Per trattarle ha bisogno di tirare su un cluster Spark.Ci sono tante macchine che fanno girare Spark dentro ma queste tante macchine le servono per 10 minuti e poi non servono più per tutto il giorno allora cosa fa? Airflow immaginiamolo come un sistema per fare le cron adesso sto banalizzando oltre gli eccessi però è un sistema che serve appunto per attivare alcune procedure che lancia un bello scriptino che tira su tutto il cluster collega tutti i nodi del cluster ci fa avviare spark all'interno mandi in elaborazione i dati e poi ammassa tutto rimuove tutto immaginiamo che costi avrebbe avuto a livello di infrastruttura fare questo tipo di lavoro e dico di più magari il cluster a livello di infrastruttura te lo saresti fatto fisicamente ci avresti fatto girare anche altri task ma il passaggio di configurazione da un task all'altro l'avrebbe dovuto fare il famoso sysadmin con la palla al piede legato al serve che col cacciavite virtuale doveva andare a sistemare tutto o con lo script in OBS sarebbe dovuto andare a sistemare tutto.Io credo quasi impossibile.Esatto mi viene in mente un altro esempio che esula completamente dallo sviluppo web lo dico solo come citazione questi servizi sono utilizzati anche per fare ad esempio rendering 3d ora quanto costa una macchina per fare rendering 3d è molto carrozzata ok quindi noi abbiamo questo mega computer diverse unità di euro che utilizziamo pochissimo perché finché disegniamo ora poi parlo da profano diciamo parlo per sentito dire finché disegniamo ci può bastare una macchina più piccola quando facciamo il rendering mettiamo in pausa tiriamo sul generatore e aspettiamo che abbia finito e finalmente abbiamo utilizzato tutta la macchina per quel momento lì magari rendering lo fai quando devi consegnare al cliente la cosa invece cosa succede se ti tiene la macchina normale che costa il giusto e il rendering lo fai fare al cloud ma gli mandi il file originale fai fare il rendering utilizzando delle macchine specifiche per fare rendering perché non tutte le macchine su AWS per esempio sono uguali alcune sono ottimizzate più per la memoria.Alcune sono ottimizzate per i dischi, alcune sono ottimizzate per la grafica, per machine learning.Quindi io mando il file, faccio fare il rendering.Quanto ci vuole? Un'ora? Mi costa 15 dollari.Sono 15 dollari che non ho speso nella macchina, però ho fatto il rendering e se questa macchina si rompe oppure deve essere aggiornata, perché magari dopo due anni la mia macchina supercarrozzata non è più adatta al software che uso e ci Metto una notte a fare un rendering invece in questa maniera me la risolvo così velocemente quindi questo un altro vantaggio completamente fuori Dal si oppure quella macchina carrozzata potresti non potertela permettere anche a livello Con quello che costano le macchine quindi cosa hai più accesso Al persone che vorrebbero fare i rendering 3d possono permettersi di iniziare a lavorare perché non hanno bisogno di quella di quella barriera d'ingresso di non so 10.000 euro per una macchina carrozzata ma posso dire ok me ne prendo una da 2000 e e poi faccio i rendering su AWS e vediamo come va.Quindi è tutta una cosa che si possono creare professioni non nuove però una persona che è interessata può accedere quindi barriera d'ingresso più bassa per questo tipo di servizi.Sì quindi abbiamo detto con l'introduzione dell'infrastructure as a code quindi questi documenti che definiscono Abbiamo una serie di vantaggi.Leo hai detto intanto che l'infrastruttura può essere replicabile quando è parlato dei vari ambienti Hai detto che può essere salvabile.È importantissimo Sì è vero Non facciamo quando fai un click sulla console Quel click sparisce dopo, lo devi rifare.Invece se ce l'hai salvato su un file, lo puoi rifare quante volte ti pare Il fatto che sia versionabile, quindi il concetto di rollback a un'infrastruttura precedente è importantissimo condivisibile cioè ragazzi la nostra infrastruttura as a code sta su git questo vuol dire che possiamo fare pure quest alla nostra infrastruttura cioè quando io ci penso oppure commentare la vista no in line comment Di gitta di gitta tu puoi commentare una linea specifica cioè fighissimo Esatto.Ed è appunto distribuibile, cioè io voglio fare l'hosting, ho un'applicazione su WordPress, purtroppo, e voglio fare l'hosting su AWS, non so nulla, vado a cercare, mi trovo il file già fatto che mi crea tutta l'infrastruttura e mi dice ecco adesso fai l'upload qua e te hai il supporto online.E poi subito dopo dice forse WordPress devi cambiarlo quindi.Scherzo, naturalmente per tutti quelli che utilizzano...Quei 60% dell'internet che utilizza Wordpress.No, scherzi a parte, ci sono anche tutta una serie di vantaggi, no? Sì, i vantaggi appunto...I vantaggi sono sul fatto che c'è questo concetto molto interessante che stavo leggendo oggi su il Kettle vs Pet, cioè gabbia contro cucciolo.Cosa succede? Che il cucciolo è una cosa che dobbiamo proteggere, la gabbia è intercambiabile.Prima il sysadmin, la sua infrastruttura era un cucciolo, invece adesso l'infrastruttura è la gabbia, cioè la gabbia può essere cambiata.Mi va giù un server, rifaccio il deploy, perché lo faccio automaticamente, lo faccio con un click e io faccio il deploy di tutta l'infrastruttura.In realtà, poi, sul cloud, se va giù un server, viene tirato su da solo ed è trasparente.Però, diciamo, il concetto è che l'infrastruttura non è più un asset da proteggere, ma è un asset che però è replicabile.Quindi, potendolo fare automaticamente, io posso anche dire...io faccio dei minimi cambi nell'infrastruttura, come si fa sul software, si fa piccoli cambi con lo sviluppo sempre più veloce, questa cosa avviene anche per l'infrastruttura.Aneddoto, Amazon, l'e-commerce di Amazon, ha centinaia di deploy durante il giorno, tanto che, avevano detto a una conferenza qualche tempo fa, da quando ti metti un prodotto sul carrello a quando fai il checkout, stai usando almeno due versioni di Amazon diverse.Chiaramente cambia la tonalità di giallo oppure il numero di commenti che vengono messi di default.Però la stessa cosa può accadere per l'infrastruttura.Ok? Quindi invece di avere una coda per l'email ho una coda per l'email del carrello e una coda per l'email del...non so, dei pagamenti.Ok? Questa è una cosa che noi possiamo deployare e aumentando il numero di...di deploy che facciamo nel giorno ci viene anche più facile fare il deploy, cioè il deploy non è più quell'evento dove tutti si fermano e dice ok meno male non è venerdì, facciamo il deploy.No, il deploy è una cosa, ah ok si faccio il deploy e vengo a mangiare deve essere una cosa del genere perché se qualcosa se qualcosa va male la possiamo la possiamo riplegare e rifare un altro deploy.Ci sono realtà che fanno buttano giù produzione e la ritirano su tutte le notti Perché perché tanto lo fanno automaticamente perché magari hanno dei servizi a conto interno che la notte non usano E poi perché quando va giù produzione per qualche motivo per un bug nel software loro sono abituati e ne fanno uno al giorno per cui Hai questa questa rilassatezza nel fare deploy ora io sto parlando Del mondo fatato dove tutte queste cose avvengono in realtà fare il deploy Dovunque vai è sempre una cosa in cui bisogna fare però ecco l'obiettivo è quello bisogna pensare che fare il deploy è semplicemente un'altra fase come fare i test.Io faccio i test, non è che ho paura di se i test diventano osso.Se diventano osso vuol dire che devi sistemare un bug.E' uguale nell'infrastruttura.E oltre a questo hai, facendo questi cicli di aggiornamento più veloci, hai dei feedback più velocemente, quindi la tua reattività nel cambiare infrastruttura migliora.Quindi questi sono tanti vantaggi che si può avere automatizzando il deploy dell'infrastruttura.È arrivato la rovina! Assolutamente sì, hai fatto proprio un ragionamento interessantissimo sul fatto che oggi le nostre infrastrutture sono facilmente replicabili.Tu hai parlato di deploy, la cosa che mi è venuta in mente è che adesso sono il Canary o il Blue Green Deployment, quindi su questo voglio proprio collegarmi al concetto di infrastrutture di definizione di infrastructure as a code perché in realtà quando si parla di definizione dell'infrastruttura si parla di un qualcosa che lavora su un processo questo processo è fatto in di step molto diversi quando si parla di deployment questo noi spesso lo usiamo anche erroneamente come l'ho detto prima come parola onnicoprensiva però quando si parla di deployment si intende il prendere la nostra applicazione e metterla sul server.Ma non si entra nel merito di come questo server questi server questa nuvola debba essere settata definita e configurata insomma come debba essere tirata su tutto ciò che riguarda il tirarsi su questa nuvoletta di robe che fanno girare il nostro codice si chiama provisioning che può essere fatto o con dei computer reali o con degli host/servizi virtuali per fare questa fase abbiamo bisogno di una serie di strumenti che permettano l'automatizzazione di questi elementi queste chiamiamole con la parola giusta queste risorse ok? La creazione di queste risorse e dico creazione non a caso viene fatta attraverso degli strumenti che andremo a vedere tra pochissimo che possono essere Terraform, CloudFormation, OCDK, di cui Leonardo ci parlerà nel dettaglio portando con sé la sua esperienza nella materia.Però dico, quindi io ho dei computer, in realtà ho dei bilanciatori di carico, dei database, delle reti che devo in qualche modo gestire, tirare su e questa è la fase di provisioning.più diciamo precisini aggiungerebbero un'altra fase quindi separerebbero dalla fase di provisioning la fase della configurazione quindi tutto ciò che è collegare i cavetti tra load balancer al database tutto questo è definito dal concetto appunto di configurazione adesso noi quindi quando diciamo provisioning cerchiamo di essere un attimino più omnicomprensivi quindi parliamo di provisioning di configurazione di tutto quella che è l'infrastruttura che ci riguarda.Questo tipo di configurazione di provisioning può essere fatto in due modi con l'approccio imperativo o con l'approccio dichiarativo esattamente come tutti i software la differenza tra il codice imperativo e la programmazione funzionale, no? Qual è? Che se nel modo imperativo tu dici come devo essere fatto una cosa, nel modo dichiarativo tu dici semplicemente cosa ti serve, quindi cosa di quelle risorse ti serve in questo momento per far girare il tuo codice.Cambia completamente l'approccio è un po' come l'approccio esempio stupido tra guidare la macchina e chiamare uber.Quando guidi la macchina sai che alla prima curva devi andare a destra, poi devi metterla a seconda, poi devi andare a sinistra, fermarti al semaf...ok questo è l'approccio imperativo.L'approccio dichiarativo è uber.Io voglio arrivare qua.Poc.Fine.Ci pensa l'autista a guidarti.In realtà questo è molto interessante perché non dobbiamo dimenticare qual è il nostro compito.In qualità di sviluppatori siamo necessariamente pigri, quindi tutto ciò che può essere automatizzabile o nascomplicità che può essere nascosta ci piace nasconderla.Quindi è normale che tenderemo un po' di più verso un approccio di tipo dichiarativo.Diciamo cosa vogliamo e come per magia abbiamo a disposizione l'infrastruttura che ci interessa.Quindi ricapitolando, quando si parla di approccio imperativo si parla di un approccio dove viene definito step by step.Questo mi viene in mente con i bash script del nostro famoso sysadmin.Un docker file.Esatto, mi veniva in mente il create resource di Kubernetes.Però abbiamo un problema.Quando il nostro sistema deve scalare su o giù, che è uno dei vantaggi del cloud, devo fare degli altri script custom che mi dice "se io ho questo stato devo fare un +1, se ho uno stato inferiore devo fare un +2".Adesso sto banalizzando, ma per dirti che comunque tu devi prendere in considerazione lo stato che avevi prima il percorso per raggiungere lo stato successivo quindi se noi immaginiamo un concetto dove devo scalare rapidamente su e giù probabilmente questo non è il metodo migliore per farlo quindi tirar su utilizzare un approccio imperativo.Altra domanda e cosa succede se per sbaglio fallisce il nostro script e in questo caso io mi trovo in uno stato di limbo non sono né carne e né pesce e quindi diciamo che ho qualche problema, lo vediamo tra qualche istante come possiamo risolvere il problema invece con l'approccio dichiarativo è molto semplice io definisco lo stato finale il famoso destination point di uber e a quel punto una complessità che mi è nascosta, che si occupa di creare le risorse e orchestrarle, quindi farle lavorare insieme per me.Per cui tutto è molto semplice e la cosa importantissima è quella un po' il concetto di funzione pura, no? Ogni volta che io avvio il mio script ottengo sempre lo stesso risultato.Perché? Perché sto definendo, sto dichiarando lo stato che voglio raggiungere, non il percorso.Per cui necessariamente io otterrò sempre lo stesso risultato per lo stesso schema che sto dichiarando.E di qui entra in gioco un altro concetto che è quello della mutabilità o dell'immutabilità dell'architettura.Ragazzi oggi col cloud è fighissimo perché i computer non sono i nostri quindi possiamo tirare su la nostra architettura per quattro per qualche secondo e poi spegnere quello che non ci serve.Se si accavallano non dobbiamo installare altre 50 macchine nel nostro data center e quindi oggi c'è permesso di utilizzare delle infrastrutture di tipo immutabile.Le infrastrutture di tipo mutabile invece cosa sono? Prima vi ho parlato di questo stato di limbo, no? Quindi quando parlavo di un approccio di tipo imperativo c'è uno stato che non si può definire.Questo stato di limbo appare nel momento in cui uno script fallisce, una definizione di infrastruttura fallisce e quindi io mi ritrovo con un'infrastruttura che non so che cosa sia.A questo punto cosa dovrò fare? Dovrò riportare tutta l'infrastruttura alla versione precedente e siccome io non so a priori cosa è fallito avrò bisogno di un sysadmin con la palla al piede legato al computer sotto schiavitù che si occupa di verificare elemento per elemento, una volta che ho fatto il rollback manuale, necessariamente manuale, quindi sto perdendo uno dei vantaggi dell'infrastrutture RASA code, alla versione precedente, a questo punto potrò riprovare lo script per arrivare alla versione successiva.Insomma, immaginate quanto questo tipo di approccio non possa scalare.Invece un approccio di tipo immutabile è appunto quello di siccome Leonardo ci ha detto che le nostre infrastrutture possono essere replicabili, io cosa faccio? Faccio una modifica, lancio, creo un'infrastruttura a fianco che è l'infrastruttura che mi serve nella versione n+1, una volta che questa funziona io uccido la vecchia.Quindi ho in qualche modo una garanzia.Spesso l'infrastruttura immutabile si può costruire con un approccio dichiarativo.Quindi a questo punto io direi che visti questi vantaggi credo che il nostro verso l'infrastruttura si è cambiato e ci siano anche delle trappole giusto Leonardo? Eh sì sicuramente perché se no tutti userebbero cioè si parlerebbe solo di questo invece ci sono anche degli svantaggi nell'utilizzare questo approccio.Intanto partiamo dal fatto parlo per esperienza personale io sono uno sviluppatore e da diversi mesi mi sto occupando anche di scrivere infrastrutture per dei progetti per i clienti all'interno di Nirvore.Ci sono arrivato per gradi, però adesso, nell'ultimo progetto, ho scritto proprio tutta io l'infrastruttura, perché avevo già l'approccio del developer, quindi conoscevo già gli strumenti di programmazione per Thunder, un bel po' di training su AWS, qualcosa sapevo, qualcosa no, e ho cominciato a scrivere l'infrastruttura.Qual è il problema? Io sono un dev, non ho tutte quelle conoscenze di un sysadmin, di un network admin, di un server admin, cioè non ho quel tipo di competenze così nel dettaglio.Quindi il rischio è che l'infrastruttura che abbia fatto io possa essere fragile, oppure possa aver usato più risorse di quelle che servivano, meno risorse di quelle che serviranno se non ho impostato bene l'autoscaling, per esempio.Quindi il fatto che un dev possa approcciarsi in maniera più semplice alla scrittura di infrastrutture porta tutti quei vantaggi di cui abbiamo parlato ma bisogna stare attenti perché quello che creiamo poi può essere insicuro o fragile e chiaramente il nostro software il più bello del mondo su un'infrastruttura fragile si torna all'inizio della puntata in cui abbiamo fatto un super software che non sta su e nessuno lo utilizza.Inoltre quando è parlato del fatto che nel deploy fallisce.Lì stiamo in una situazione che dipende, non c'è una risposta che io posso dare o un DevOps o un SysAdmin può dare, perché dipende cosa fallisce, in che punto, per quale motivo.Fallisce perché sto inserendo nel database un carattere che non è previsto dal sistema di carattere di quella colonna o fallisce perché temporaneamente l'API di AWS ha fallito in quel momento, allora posso anche riprovare a farla dopo un secondo.Quindi, quella cosa non si sa, bisogna vedere caso per caso.Spesso bisogna fare un rollback alla versione precedente, che può non essere in dolore, nel senso può portare a dei problemi.Ho messo un tera di dati dentro il database, mi è fallito il passo successivo, devo levare questo tera e poi rimetterlo di nuovo.potrei evitare di farlo.Sono situazioni che possono diventare complesse.Inoltre, avendo il...riprendendo il discorso del fatto che il codice sia distribuibile, ci sono per i sistemi di cui poi parleremo, dei moduli.Ad esempio, voglio la famosa applicazione Wordpress, quindi ho già il mio script che mi crea, diciamo, in Terraform o CloudFormation o quello...o altro, mi crea il database, l'endpoint dell'API gateway, il server web e tutto funziona.Ok, chi mi garantisce che quell'infrastruttura sia esattamente quello di cui ho bisogno, che non ci siano backdoor perché magari una persona Vspa ha lasciato aperto al nostro server, mette una regola per cui il suo IP può entrare in SSH nel nostro server senza autenticazione, oppure che sta usando una macchina per fare il rendering di un ambiente in 3D per fare l'hosting di un Wordpress, quindi quello che succede è che a differenza di quello che facciamo magari come sviluppatori, dove noi facciamo npm install e utilizziamo il il software di Terzi e ci fidiamo, difficilmente andiamo a vedere cosa è scritto nel codice, se sappiamo che quel modulo fa quella determinata feature, lo utilizziamo tendenzialmente.l'infrastruttura invece è consigliato fare una review di quello dei moduli che installiamo spesso perché il codice dell'infrastruttura non è se fatto a moduli non è necessario ogni modulo non è necessariamente così lungo per cui è possibile fare una review e poi perché comunque i problemi di sicurezza che possono esserci l'infrastruttura sono più importanti del problema di dei problemi che può possono venire via software c'è anche da dire che a livello di software di pacchetti npm proprio per prendere l'esempio ci sono sia dei sistemi automatici che tutto una community probabilmente molto più grande in cui un pacchetto che ha un problema o un bug grosso o una backdoor viene beccato quasi subito viene fissato quasi subito oppure quel pacchetto non viene più utilizzato e viene lo so esistono sistemi tipo sneak o anche npm stesso adesso segnala che guarda c'è un problema, un codice rosso su questo - Si, fighissimo perché c'è l'integrazione con GitHub Esatto, esatto, ci sono i bot che automaticamente ti aprono le PR per fixare la dipendenza che te stai usando e sull'infrastructure as a code, essendo magari un un pochino più di nicchia, come lo pubblico, questi sistemi ancora non ci sono per cui mai fidarsi dei moduli, a meno che non siano i moduli certificati da AWS che ti mette per farti iniziare a utilizzare l'infrastruttura più velocemente, ecco, quelli possiamo fidare.Ma quando si usa codice di terzi bisogna fare una review più approfondita.Eh sì, è come quando devi accompagliare l'aspirina, se la compri al mercatino probabilmente...Si ritorna, esatto, si ritorna al concetto di consapevolezza che hai detto all'inizio.Cioè io adesso l'infrastruttura, non è che prendo "ok, questo è un database, lo metto".No, aspetta, andiamo a vedere cos'è il database, perché è importante.quindi devo sapere anche che cosa c'è sotto e questo mi porta anche poi a utilizzare un esempio prima del ho la password di 60 caratteri bene vado a modificare quel modulo lì per dirgli guarda sta colonna famela di 60 perché tanto ho bisogno di Ho bisogno solo di quello assolutamente sì e adesso però come sempre dobbiamo mettere le mani nel fango e iniziare a parlare di sferraglia o sferragliamento vario quindi andare a vedere un pelino gli strumenti che tutti i giorni usiamo per fare questo tipo di approcci.Devo dire che io non faccio infrastructure as a code da un bel po' e quando l'ho fatto l'ho fatto con Terraform.Sia Terraform che CloudFormation li abbiamo introdotti prima in realtà adesso cerchiamo di fare una rapida overview e andare a vedere un po' cosa sono come si comportano.Che cos'è Terraform? Terraform è un tool che come vi dicevo prende in ingresso la descrizione di un'infrastruttura, converte questa infrastruttura che appunto è stata definita in un piano quindi una serie di step da eseguire nel cloud che prendiamo in considerazione visto che Terraform non si lega uno a uno con un provider che può essere AWS ma permette di interagire con provider di diverso tipo attraverso i suoi moduli infatti possiamo parlare con dei provider di infrastructure as a code as a service scusatemi quindi come AWS, Google Cloud o Azure o altri 70 milioni ma può collegarsi anche con altri con sistemi di platform as a service e con tutta una serie di altri servizi che possiamo utilizzare e che dobbiamo necessariamente configurare e tirare su quindi cosa facciamo? noi definiamo lo stato finale di ciò che vogliamo, lo diamo in pasto a Terraform che crea una serie di step da eseguire per tirar su questi sistemi, queste risorse, chiamiamole col termine giusto.A questo punto cosa fa Terraform? Visto che è stato configurato per i vari provider che vogliamo utilizzare non farà altro che lanciare questi comandi nei vari provider restituendoci come risposta quelle che lui chiama le output vars quindi che questi questi valori che può essere possono essere molto semplicemente cosa ne so un url per la dashboard di Kubernetes perché Terraform ti ha tirato su tutto il cluster Kubernetes e via dicendo.Tutto questo quindi si riconduce a un unico file che descrive l'architettura, file che poi rispecchia tutti i vantaggi dell'infrastructure ASACode di cui abbiamo parlato prima.Esiste anche Cloud CloudFormation, giusto Leonardo? Sì, volevo un attimo collegarmi al discorso di Terraform.Uno per una precisazione, semplicemente perché ci sono cascato anch'io.È vero che Terraform si interfaccia con tutti, con vari sistemi, con i vari cloud provider e non solo, per esempio anche Heroku o DigitalOcean.Però la stessa infrastruttura non è deployabile, cioè non è, come si dice, vendor agnostic.Cioè io scrivo la mia infrastruttura per AWS, se voglio un'infrastruttura simile mi devo creare un altro piano, un altro progetto Terraform per Google Cloud semplicemente perché non tutti i servizi sono disponibili il server, sì, il server è disponibile in tutti, però hanno dei parametri diversi, hanno dei sistemi di configurazione diversi quindi io faccio l'infrastruttura per AWS, voglio fare la stessa su Google Cloud, scrivo un altro progetto Terraform - Perchè ragione ci sono passato su molto - No perchè anche io ho detto "ah guarda che figata posso scrivere e deploy dove mi pare" No ancora lì non ci siamo arrivati ma forse meglio così perchè poi le cose che ipersemplificano si portano dietro dei problemi o delle decisioni che noi deleghiamo a Terraform invece che scriverle noi - Sì devono essere necessariamente opinionati altrimenti non puoi...- Esatto E un'altra cosa, Terraform, gli step che fa, semplicemente, tra virgolette, sono chiamate API.Cioè, quando io gli dico a Terraform, allora mi fai una virtual private cloud che ha questo spazio di indirizzi, poi mi fai un bucket S3 e una lambda, per fare un esempio, e scrivo in Terraform, quello che fa lui, lui trasforma questo file in una serie di chiamate API che ovviamente sono collegate, sono collegate in un lato, perché posso dire questa lambda me la metti in questa VPC, lui farà la chiamata API mettendo l'indirizzo, l'ID della VPC che ha creato prima come parametro dell'opzione VPC della lambda, faccio un esempio, però sono tutte chiamate API.E per questo funziona bene ed è velocissimo, dalla mia esperienza.Tornando invece al discorso di altri sistemi che sono invece sviluppati dagli stessi cloud provider.Il principale è CloudFormation di Amazon, ma c'è la stessa versione, quindi lo stesso concetto di CloudFormation ce l'abbiamo anche in Google Cloud Deployer, mi sembra che si chiami, e in Azure Resource Manager.È lo stesso sistema.Come funziona? Funziona che noi scriviamo un file che può essere in JSON, o in YAML o anche in Python per...mi sembra per Google Cloud, dove noi scriviamo in un JSON come sono fatte le...come è stata fatta la nostra infrastruttura, quali sono le nostre risorse.Nell'esempio di prima posso dire, guarda, questa risorsa è di tipo lambda, ha queste opzioni, il codice della lambda è in questa directory, quindi io specifico tutte queste.Posso usare anche delle funzioni, esempio crea una vpc con questo spazio di indirizzi quando crea la lambda prendi dalla vpc l'id e me lo metti come come opzione vpc della della lambda quindi si possono collegare le varie le varie risorse per cui posso posso fare esattamente quello che posso fare tramite la console di AWS questo file poi viene si fa un upload di questo file in realtà un comando della non della console, della command line interface di AWS, e dico CloudFormation, prenditi questo file che descrive l'infrastruttura e eseguilo.Fatto questo, CloudFormation fa tutte le sue cose, che a questo punto, io immagino, sono sempre chiamate API che vengono in background.Io vedo CloudFormation ha questo concetto di stack, cioè la mia stack è un insieme di risorse che sono all'interno di questa infrastruttura.Io posso vedere come progredisce la stack e dire "ok è stata creata questa, è stata creata questa" quando è finito ti dice "guarda, la stack è stata creata" questi sono gli output perché per ogni risorsa te puoi definire un output come hai detto bene te creo un API gateway dammi l'indirizzo perché almeno io posso cliccare e vedere che funziona l'applicazione oppure dammi il nome del bucket che hai creato almeno posso andare a vedere e magari fare l'upload da console quindi questi output li decido io e in questa maniera se io poi vado a cambiare il json o yaml o comunque il file di configurazione CloudFormation prende, guarda le differenze e fa solo, esegue solo le differenze tra le due cose questo lo fa anche Terraform, però diciamo Terraform vedi proprio quello che fa, ti dice quando fai il plan ti dice "guarda prima avevi fatto API Gateway con...o avevi fatto una lambda ora ce n'è un'altra aggiungo solo la lambda, non è che sto a rideployare tutto quello che ho fatto" quindi questo concetto rimane.CDK invece è uno strumento piuttosto recente di pochi anni fa che sviluppa Amazon, quindi ha un progetto di Amazon che permette di scrivere TypeScript per definire la propria infrastruttura.Lo dici in che modo? allora cdk è un compilatore che da una serie di file typescript genera il file per cloud formation una volta generato il file si fa come prima venne fatto l'upload cloud formation si occupa di fare questo cdk con delle chiamate pi ti fa vedere in console L'avanzamento della tua infrastruttura quindi se fai cdk deploy aspetti vedi la tua barra che va avanti se tutto va bene poi vedi gli output Però questo cosa cosa fa? Immaginate anche un'infrastruttura medio piccola L'abbiamo visto insieme quel file 3000 righe di json generato da cdk chiaramente un file di 3000 righe non è gestibile La information è verbosissima Va bene così perché almeno uno vede esattamente quello che succede però non voglio scrivere 3000 righe allora cosa faccio io scrivo dei CDK ha anche una folta libreria sempre di moduli sviluppati da Amazon dove quasi ogni servizio, quasi, eh, non tutti, hanno la loro classe TypeScript per CDK.Quindi io voglio creare un'API Gateway, faccio l'import da...del pacchetto AWS-CDK/AWS-API-Gateway, importo il gateway e lo configuro con i miei dati, proprio come in TypeScript.ok quindi faccio una classe e gli do tutte le...Quindi usa l'eredità di età? Esatto, esatto, quindi sono tutti dei construct, ogni oggetto, ogni risorso è una construct, però cosa fa? Oltre a darti solamente i costrutti base, gli da anche dei costrutti un po' più elaborati, per esempio la lambda, c'è il costrutto lambda normale, ma c'è anche il costrutto singleton lambda, quindi è una lambda che già ha un minimo di configurazione che ti permette di creare una singleton lambda con una riga ovviamente si parla di typescript quindi io posso mandare al costruttore di un oggetto un altro oggetto per esempio io faccio una lambda gli passo nel costruttore una VPC che ho creato prima e quindi me lo trovo in questa VPC e dico guarda mettimela questa NANDA nella sottorete pubblica di questa VPC creami un database e utilizza questa macchina EC2 che ho creato prima quindi non più riferimenti diabolici come quelli o concatenazioni astruse come quelle dei file di configurazione di CloudFormation esattamente, esattamente, quindi diventa molto più piacevole scrivere l'infrastruttura struttura molto più gestibile perché ogni file ogni risorsa sono poche decine di righe e quindi per uno sviluppatore cominci a vedere, diciamo, ma questo, cioè scrivi le stesse cose che scrivi quando scrivi il software e quindi questo è un sistema che però ha solo Amazon, non so se onestamente se Google o Azure hanno lo stesso concetto, però ecco è molto potente, ha dei problemi, nel senso che diciamo che nell'ambiente si dice che CDK va bene finché funziona perché poi a volte certe cose non le può deployare se si incarta, prova a fare rollback e non funziona spesso devi cancellare la stack, quindi tutte le tue risorse cioè spesso ti dico quello che è capitato a me fortunatamente si era ancora in ambiente di test, quindi potevamo farlo Però ecco, il deploy con CDK mi lasciava sempre un po' di quella tensione per dire "speriamo funzioni".Non tutti i servizi hanno la loro classe CDK.Quello che succede quando devi creare un servizio che non ha il suo costrutto CDK esiste questa...questo costrutto si chiama custom resource.La custom resource è una risorsa CDK che però cosa fa? Invoca una lambda, quindi gli dice "guarda, questa è una custom resource che è gestita da questo codice" Questo codice viene messo in una lambda e viene eseguito questo codice.Cosa c'è nella lambda? Le chiamate API della SDK AWS.Quindi se non sono wrappate all'interno di un costrutto CDK, puoi sempre ricorrere a questo sistema.che però dalla mia esperienza è un po' macchinoso nel senso che questa lambda viene chiamata con un parametro che può essere create update o delete cioè sto creando la risorsa allora esegui alcune cose la sto aggiornando e allora ne esegui altre la sto tirando giù potresti non eseguire nulla perché magari hai salvato un file su s3 lo vuoi mantenere quindi gestisci queste cose il problema è che mentre il cdk si esegue se te hai la tua lambda per esempio fai un errore semplicemente un syntax error, è niente di particolare.Lui prova a triggerarla ancora.Prova ancora.Quindi se c'è il deploy fermo lì, per un quarto d'ora, nemmeno perché quando vai in timeout la devi bloccare e devi fare dell'operazione manuale per interromperla.È chiaro, è un bug che hai introdotto te, lo sai e cerchi di evitare, però ecco, non è che ti dici "Guarda, è fallita la lambda tre volte, faccio il rollback".Quindi ci sono ancora queste...Alcune cose che lo rendono un po' macchinoso.però il fatto di poter scrivere TypeScript per definire un'infrastruttura è una cosa che avvicina ancora di più gli sviluppatori per me è stato il primo approccio e fra l'altro vi consiglio di andare su cdkworkshop.com che è uno workshop gratuito fatto da Amazon che in un'oretta si fa questo workshop fa capire che cos'è CDK basta avere un account Amazon fa creare qualche risorsa che non costano nulla forse pochi centesimi poi tanto la potete tirare giù però capite come funziona in un'ora e vi può far entrare in questo mondo.Sì super super interessante io CDK ammetto la mia ignoranza non lo conoscevo mi perdevo spesso nei meandri delle configurazioni cloud formation.Io ho usato ho usato CDK prima, poi ora sono passato a Terraform, preferisco di granunca Terraform perché è troppo più veloce, cioè se fallisce fallisce subito, se funziona perché sono solo chiamate API, non c'è tutto questo concetto di stack e soprattutto è parallelo, cioè Terraform calcola cosa può costruire parallelamente, quindi se devo costruire un database una distanza di c2 e non sono in quel momento collegato, li posso fare insieme mentre si dichia uno dopo l'altro.Si fa un grafo aciclico.Esatto, esattamente.Sì, naturalmente non siamo entrati nel dettaglio.Sono pur sempre uno sviluppatore io, quindi tanto il dettaglio non ci possa andare.quindi no mi ha fatto super piacere affrontare questo discorso ma abbiamo ancora l'ultimo momentino che è il nostro paese dei balocchi.E conducono il paese dei balocchi.Ah il paese dei balocchi.Siamo un po' tutti bambini e quindi ci piacciono i giocattoli per cui Leo cosa ci ci porti per il momento paese dei balocchi.Allora io ho portato due cose, sono due strumenti di produttività molto molto semplici.Allora il primo si chiama pagemarker.io è un software alla pocket per intendersi che serve per organizzare i propri segnalibri o articoli.La cosa molto molto figa che mi ha fatto anche acquistare il premium che sono due dollari al mese quindi nulla è che l'ho scoperto su Product Hunt.Te puoi salvare i tuoi articoli, c'è anche l'estensione di Chrome e questi articoli sono già gestiti come letto o non letto, possono essere taggati, ma inoltre ci puoi mettere delle note in markdown.Quindi te ti leggi l'articolo, ti segni le note, lo metti come letto, ti rimani nella tua memoria quando vuoi andare a rivedere dei tag, puoi fare una full text search sulle note, quindi ho detto guarda ho visto un articolo che parlava di terraform e di cdk, se ti ricordi di aver scritto le note lo vai a cercare lì e ritrovi l'articolo.Io l'ho trovato molto comodo e quello che faccio io, come lo uso io, è varie mailing list, apro gli articoli, salvo tutto su page marker, pulisco chrome e poi quando ho tempo di leggere apro quello, vado tra i non letti, Ovviamente questo lo dico, cioè non è che lo fa semprissimo, però diciamo è l'approccio che prendo.E l'altra cosa è un'estensione per VS Code che si chiama Peacock, come Pavone.Fa una cosa semplicissima, che però per me può essere molto utile lavorando in un team remoto, o comunque molto adesso lavorando in remoto, visti i tempi.Praticamente dà un colore al contorno della finestra di VS Code, un colore random, oppure sceglite il colore.A cosa serve? A me quando si fa delle code review o devi comunque fare vedere più finestre di VS Code perché magari dai da una parte l'infrastruttura e dall'altra il codice, te apri la call, condividi lo schermo e per non far confusione dici "guarda, il blu è l'infrastruttura e il rosso è il codice" e ti permette, a me ne hanno avuto anche diversi feedback, di dire "ah, finalmente, cioè, si capisce bene quando passi da una finestra all'altra" immaginiamo la finestra anche a schermo intero, vederla rosso o vederla brutta ti fa già capire questo è il codice front-end e questo il back-end.Io lo trovo molto utile, è proprio una bischierata ma mi piaceva condividere.No, no, molto molto figo.Sapi che Peacock lo installo subito e PageMarker lo provo.In realtà io sono un grande appassionato di Notion, quindi mi copio il link.Per me invece perché è il primo episodio dove anch'io porto qualcosa e volevo portare qualcosa a tema infrastructure as a code e c'è un bellissimo libro scritto da Morris è rilasciato da O'Reilly, Keith Morris spero si dica così non me ne voglia se mai ci sta ascoltando.È un libro molto interessante che introduce, devo dire anche approfondisce l'argomento.Devo anche dire che è in uscita il mese prossimo la revisione di questo libro e quindi anche per questo motivo volevo portarla come balocco della situazione.Bene, mi ha fatto super piacere affrontare questo argomento con Leonardo.Vi anticipo che Leonardo sarà nuovamente qua a brevissimo perché stiamo preparando un altro episodio.Giusto, Leo? Giusto, giusto.Spero che siate contenti anche voi ascoltatori.Assolutamente.come ospite fisso e nulla quindi io ti ringrazio infinitamente a nome di mio personale a nome di tutti gli ascoltatori e la community di Gitbar di cui tra l'altro ho visto che sei entrato nel gruppo Telegram quindi ne fai parte tra l'altro ascoltatore dalle prime dei primi episodi quindi grazie la fiducia, visto i primi episodi era solo fiducia quella fiducia strameritata, grazie a te dell'invito, mi ha fatto molto piacere parlare di questa cosa mi farà piacere anche parlare di altre cose, volevo dire che se mi volete contattare voi cercate Leo Rossi, più o meno mi trovate da tutte le parti con quel nome anche su Clash Royale se giocate contro Leo Rossi, sono io Quindi mettiamo comunque nelle note dell'episodio tutti i tuoi riferimenti, quindi Facebook, Twitter, Github, indirizzo di casa, numero di telefono, gruppo sanguigno, status dell'app immune, eccetera.Esatto.Eccolo.Non so in Toscana, ma penso che in Lombardia è una informazione facilmente reperibile.Sì, l'ho sentito, l'ho sentito.Bastava il codice fiscale.detto questo noi ci salutiamo e ci diamo appuntamento alla prossima settimana sempre con Gitbar ma prima di lasciarvi vi ricordo rapidamente i contati info@gitbar.it via email o @brainrepo su twitter naturalmente tutti gli episodi con le relative note li trovate su www.gitbar.it.Spero di riuscire a trovare il tempo di fare un piccolo restyling anche perché la prima stagione di Gitbar si avvicina al termine.Infatti la prima puntata è stata il 2 gennaio, lo ricordo benissimo, ho registrato il primo gennaio.e quindi il 2 gennaio 2020 siamo partiti con questa idea, ecco chiamiamola così, e quindi ci avviciniamo appunto alla fine dell'anno e con la fine dell'anno terminerà anche la prima stagione quindi ci saranno tutta una serie di piccole cosine nuove per il 2021 che speriamo sia un po' meno nefasto del 2020.Detto questo ricordo rapidamente che se l'episodio vi è piaciuto è solo merito di Leonardo e naturalmente se vi è piaciuto aprite la vostra applicazione di podcast e iscrivetevi in modo da ricevere ogni settimana le notifiche dei nuovi episodi.Se poi vi è piaciuto davvero tanto, beh, aprite l'applicazione podcast di Apple e lasciate una recensione.Questa recensione servirà per farci crescere un pochino di più nelle charts.L'applicazione podcast è magari andare a contattare delle orecchiette fresche.Detto questo, da parte mia e da parte di Leonardo ci salutiamo e ci diamo appuntamento alla prossima, no, Leo? Certo! Da Lione e da Firenze è tutto, ciao! 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 di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica]
