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.Benvenuti in un nuovo episodio di Gitbar.La Sveglia stamattina ha suonato molto presto per essere qua a parlare con Gianluca Arbezzano Questa volta il cognome è abbastanza facile e non dovrei averlo sbagliato Però prima di iniziare la nostra chiacchierata con Gianluca, come ben sapete, vi devo rompere le scatole Ricordandovi i contatti potete scrivermi a info@gitbar.it via email naturalmente oppure su twitter @brainrepo per quanto riguarda invece le puntate e gli audio con le note degli episodi e i transcript li trovate sul sito ricordate che nelle note dell'episodio vi metto il link al gruppo telegram il freschissimo gruppo telegram che parte proprio questa settimana ma bando alle ciance ci prendiamo giusto qualche secondo e poi passiamo a Gianluca è arrivato la rovina Abbiamo con noi Gianluca Arbezzano senior software staff Senior staff software engineer a packet host che è un cloud provider oltre che essere divulgatore conferenziere e anche streamer ciao Gianluca ciao grazie per l'invito come va Bene, molto bene, grazie.E mattino perché appunto lavorando un po' di più il pomeriggio e dopo pranzo al mattino è un po' più tranquillo, ho da riunioni varie, quindi sono più libero.Perché giusto tu lavori a Packet Host da maggio se ho visto bene, giusto? Sì, sì, sì, è un'azienda che in realtà è stata da poco acquisita da Equinix, che è un'azienda molto grande, però la sede originale di Packet era a New York, quindi abbiamo colleghi un po' dappertutto bisogna un po' adattarsi ai fusi orari.Ecco vedi questa è una domanda molto interessante, raramente parliamo di remote work e di smart working qua a Gitbar, però come vivi l'esperienza nel lavorare con dei team, dei colleghi che stanno a fusi orari differenti dal tuo? Io ho iniziato a lavorare da remoto 4 anni fa, più o meno, quando ho accettato di lavorare per un'azienda che si chiama Influx Data, che sviluppa InfluxDB, che è un database open source.Mi piaceva molto l'idea perché, avendo contribuito a progetti open source in precedenza, un minimo di esperienza e di confidenza per quanto riguarda il lavoro distribuito ce l'avevo già.un lavoro full time, però un'idea di cosa volesse dire lavorare in modo asincrono o di gestirsi il tempo l'avevo sviluppata.E mi piaceva molto, mi piace molto la libertà di poter dire "guarda, se oggi o se nella prossima mezz'ora so che non renderò, mi prendo una pausa da farmi un giro.Io faccio l'orto, quindi vado a zappare un po' la terra e per mezz'oretta poi recupero".E questo mi è piaciuto molto.Per quanto riguarda fuso orari è sicuramente una delle cose che quando tu dici alle persone "inizio lavoro da remoto" nessuno ti mette un campanello d'allarme.E quindi lo faccio io adesso, perché quando mi sono unito in FUSIB non mi sono reso conto che la sfida del lavoro da remoto sarebbe stata non quella più difficile, ma quella più difficile sarebbe stata gestire, diciamo, lavorare con la maggior parte dei miei colleghi, perché a quel tempo erano uno dei primi assunti in Europa che invece erano a San Francisco con nove ore di differenza.Quello è stato effettivamente alla lunga una delle criticità che poi è stata la sfida più grande.Come sei riuscito a gestirla in termini proprio di time sync? Ma diciamo che molte cose devono per forza venire in modo asincrono quindi bisogna creare un ambiente che permetta ai dipendenti di in qualche modo arrangiarsi quindi vuol dire avere chiaro cosa bisogna fare, lavorare anche su obiettivi e progetti che ti permettono di perderti del tuo tempo.Poi, fortunatamente, ci si trova a metà strada.Con i miei colleghi di San Francisco, veramente, avevamo, senza troppo sforzo, un'oretta di lavoro insieme, con un po' di sforzo in più, quindi io un po' più tardi, loro un po' presto, si poteva arrivare anche a due ore.E poi in realtà, creando questo ambiente, le ore insieme di cui avevo necessità erano minime.Poi non erano tutti di San Francisco, avevo un paio di colleghi che erano in time zone più vicine, magari in Minnesota, e quindi era più fattibile con loro, facevano un po' da ponte.Però è stata un'esperienza interessante che un po' ti svincolano dall'idea dell'ufficio, dell'ottore, di dover stare lì seduto per forza, sempre, perché sennò non stai lavorando.Ci sono dei momenti in cui effettivamente, non dico che tu non possa lavorare, però è facile dire "ok, magari vi faccio un'ora in più di pausa pranzo, perché tanto poi so che dalle 6 alle 7 è comodo che io sia qui".Il ruolo della documentazione all'interno dell'azienda, come è stato nell'ottica appunto di questo lavoro asincrono? Ha giocato un ruolo importante o è stato marginale? In realtà penso che quando in Influx eravamo un'azienda, quando sono arrivato, in forte crescita.Quindi a livello di documentazione interna si poteva fare meglio e negli anni poi è migliorata.È sicuramente cruciale condividere le informazioni, quindi utilizzare Github.Noi utilizziamo Github con le pull request e le issue, le usiamo sia per progetti, avendo un progetto per un source molto grande, con la community ovviamente si lavora così, Ma possiamo fare lo stesso criterio anche internamente, perché comunque la scrittura e la condivisione in modo scritto delle informazioni è fondamentale per lasciare alle persone la capacità di comprendere senza dover per forza fare dei meeting.Che è poi una cosa che tento di fare anche adesso.Nel senso che io, quando ho condiviso lavorare in packet, una delle prime cose che ho tentato di fare è quella di eliminare un po' i meeting ricorrenti, quindi i classici stand up, queste cose qui si possono fare, non bisogna per forza farle tutti i giorni, tutti uguali, magari si può fare qualcuna sincrona, qualcuno sincrono, in base un po' anche alla seniorità del team.Sicuramente quando hai tante persone junior bisogna seguirle un po' di più anche faccia a faccia.Insomma, secondo me bisogna un po' scardinare le regole che ci diamo in quanto… per semplificare un po' la vita, in cui queste cose vanno fatte così tutta la settimana, tutti i giorni, finché qualcuno non impazzisce.Bisogna un po' essere flessibili.L: Assolutamente sì.Ti faccio l'ultima domanda sul smart working e lavoro a sincrono.questo tipo di attività dalla tua esperienza è stata...aspetta, riformulo la domanda così mi viene un pochino più semplice dirla in una condizione come la tua, una situazione lavorativa come la tua si riesce a creare quella sensazione di appartenenza e di comunità all'interno della stessa azienda? oppure trovi degli ostacoli, degli attriti che in realtà rallentano lo sviluppo del concetto team azienda come famiglia? Diciamo che bisogna essere flessibili e anche un po' innovatori.Noi per esempio abbiamo un...lo facevamo sia in influx ma anche adesso in packet è molto sentito, organizziamo delle attività di team building che favoriscono il remoto, che richiede un po' di fantasia perché non è un argomento ben trattato.Ti posso portare qualche esempio.Qualche anno fa abbiamo fatto un'attività in cui l'azienda ha sponsorizzato dei biglietti per il cinema per due, per tutta l'azienda.Quindi è stata a cinema con la mia fidanzata.L'idea era quella appunto di mandare tutti a fare un'attività e condividere magari le foto, le condivisioni che abbiamo visto.Da lì si è creata un po' un'attività come poteva essere appunto "andiamo tutti al cinema insieme".Non si poteva fare perché viviamo in parti del mondo troppo distanti, però si è riuscito a creare un po' quell'ambiente lì.Ultimamente abbiamo fatto, non l'abbiamo ancora fatta, però so che c'è in programma un collega appassionato di caffè e quindi abbiamo organizzato un'attività di assaggio di caffè, che non so bene come funzionerà.Per cui ci sarà un esperto con il mio team, che non è questo ragazzo ma è proprio un esperto del settore, che ci aiuterà a capire cosa stiamo bevendo, le preferenze che abbiamo, che ovviamente è in sede è molto interessante, però è un'attività che si presta anche alle salate remoto.Quindi insomma ci vuole un po' di fantasia, probabilmente è un po' più difficile, però io a causa Covid purtroppo non sono potuto andare, però avevo un matrimonio di un mio collega americano in California quest'estate, quindi insomma si creano delle amicizie e comunque quindi si può farlo, di esperienza.Ottimo, quindi confermi quello che penso anch'io che con uno sforzo magari maggiore rispetto a "andiamo tutti a farci la birra il giovedì come usciamo dall'ufficio" però si può creare community e identità aziendale anche in questo modo.però passiamo ad un'altra domanda e qua invece voglio passare alla tua attività di divulgatore, conferenziere e anche streamer.Cosa ti spinge a condividere con gli altri quello che impari, quello su cui lavori? In realtà ci sono state fasi diverse, fortunatamente non è la mia carriera, la mia vita, però questa parte me la sono portata dietro.Le motivazioni sono un po' cambiate, ma inizialmente ho imparato a sviluppare, ho fatto le superiori a scuola, ho fatto l'operato informatico, ovviamente ho imparato e non ho imparato, poi la prima attività di apprendimento seria l'ho fatta con il mio primo lavoro.Ho sviluppato un CMS in PHP e lavoravo da solo, quindi in un laboratorio del Politecnico.Ho scritto questo CMS 3-4 volte.La prima volta in spaghetti, dopo un certo punto in cui io stesso non capivo più cosa avevo scritto e mi ho dovuto smettere.Allora poi mi sono dovuto passare oggetti, ho iniziato a usare Zenframe.Questo processo d'apprendimento l'ho fatto in questo modo, con questa efficacia, poi si parla di qualche mese, grazie alle community open source.Quindi io sono entrato, pochi anni fa, in chat di ERC e ho cominciato a bombardare le persone alle richieste.Fortunatamente ho trovato delle persone che mi hanno risposto, diciamo più o meno volentieri, più o meno costantemente ovviamente, perché è così che funziona.E niente, quindi io ho un… diciamo essere parte di una comunità è quello che mi ha diciamo fatto diventare lo sviluppatore che sono.E per me, da quando sono riuscito a rispondere a qualche domanda, da lì non sono più tornato indietro.Quindi per me è un po' questo che inizialmente guidava la mia voglia di condividere, di sapere che ci sarà un altro… che c'era un'altra persona che stava imparando che probabilmente aveva voglia di guardare cosa faccio.E la modalità con cui condivido è rimasta quella in realtà.Poi è un po' cambiata il punto di vista, nel senso che adesso faccio forse un po' meno domande, rispondo un po' di più o magari non rispondo più a modi di idee per cui creo contenuti in modo diverso.Però l'idea è sempre quella.Non so bene chi sarà ad ascoltarmi, so che probabilmente c'è qualcuno che sta facendo la stessa cosa che sto facendo io e magari può aiutarmi o trarre benefici da quello che faccio e quindi io comincio a condividerlo.E' quello che faccio un po' con lo streaming, una cosa instrutturata, completamente non strutturata, completamente senza scaretta.Quando sento che c'è qualcosa che o mi fa piacere avere persone intorno oppure che potrebbe essere utile accendo la live su Twitch e vado.infatti il contatto e il link al tuo canale Twitch lo mettiamo nelle note dell'episodio perché ho visto che ci sono già diversi video anche parecchio interessanti.Facciamo due passi indietro.Tu nasci come sviluppatore PHP.PHP che è stato diciamo il grande amore iniziale di tanti.Il primo amore non si scorda mai, lo è stato anche il mio quindi.E di molti amici passati qua a trovarci su github.Poi la tua carriera si è evoluta dal php, sei passato al go e fino ad approdare al mondo di kubernetes e dei devops giusto? Sì diciamo che io ho avuto la possibilità di lavorare, ho cambiato molte aziende quindi quindi quello mi ha aiutato un po' a vedere tante cose diverse.A un certo punto sono approdato in Corlay, che è l'azienda che organizza la Cloud Conf a Torino, quindi sono ben conosciuto nell'ambiente e lì ho imparato la potenzialità del cloud, quindi quante cose posso fare a livello di infrastruttura chiamando un API, che in quanto sviluppatore era una cosa che facevo quotidianamente.Quindi sono arrivato nel momento giusto ad apprendere come uno sviluppatore può fare infrastruttura, che è poi quello che DevOps o comunque la cultura DevOps cerca di impiantare nella testa delle persone da un paio d'anni.Quindi per me è stato più o meno un passaggio naturale.Io comprendo l'infrastruttura più o meno come comprendo il codice, perché è così che è quello il mio mezzo per imparare.imparare.Secondo me è stata una cosa che a quel tempo era interessante anche da vedere perché magari non eravamo in tantissime da avere quel tipo di punto di vista.Quindi sì, ho fatto un po' di tutto.Sono partito dal PHP per poi passare alle infrastrutture, lavorando in Cordula io ho fatto anche frontend al tempo con AngularJS, applicazioni PHP in Cordula, quindi insomma ho avuto quella possibilità lì.Poi a un certo punto mi sono detto "No, "Basta, non ho più voglia di fare JavaScript, non ho più voglia di fare PHP, voglio fare qualcosa di compilato" Java non era nelle mie corde, il Go stava nascendo, c'era Docker in giro che mi interessava, InfluxDB stesso che mi piaceva, che comunque è un tooling Go, e quindi mi sono detto "Adesso inizio a fare qualcosa in Go" e poi fortunatamente ho trovato che ovviamente serviva un lavoro per riuscire a portare avanti l'apprendimento in modo serio e quindi ho proseguito.E una domanda che ho fatto anche a Stefano in qualche puntata fa.Com'è stato il passaggio dal PHP al Go? Come l'hai vissuto questo attraversare proprio due modelli che apparentemente sembrano parecchio diversi? Sì, guarda, secondo me dipende anche molto da che tipo di persona sei.Io non sono una persona, vado molto, sono molto pratico nell'apprendimento, quindi la prima volta che vedevo progettingo li guardavo anche senza aver capito che fosse compilato o cosa fosse, li guardavo e dicevo "io questo linguaggio non lo comprenderò mai".Pur essendo poi un linguaggio di cui la sintassi tutti dicono essere diciamo comprensibile ed effettivamente comprensibile adesso.Però a quel tempo non troppo diciamo esperto in linguaggi, tutte ho imparato PHP perché facevo cose di Internet, cose di questo tipo.Quindi era un po' diverso.Poi adesso che ho delle conoscenze anche sulla modalità di apprendimento diverse, adesso posso, diciamo, valide la mia.Però a quel tempo per me era proprio un po' arabo.Passiamo da un arabo a un po' meno arabo o un po' più arabo e vediamo come si fa.E poi, ovviamente, è stato molto difficile leggerlo e cominciare a capirlo.Poi una volta che l'ho capito è stato molto facile fare qualcosa di interessante.Poi quando ho iniziato a fare cose un po' più serie, quindi progetti un po' più grandi, è ripartito tutto da zero praticamente.Ho rimparato il linguaggio, perché comunque cominci a capire come si usa un'interfaccia, cominci a capire come mai devi usare in un certo modo, come scrivere test, come fare performance e tutto.Quindi, in sostanzamento, ho imparato il Go due volte.Una volta a livello da ubista e poi dopo in modo più serio.Per fortuna poi, lavorando in Influx, ho avuto la possibilità di lavorare con gente che sviluppava database, quindi a livello di performance, di struttura del codice, ne conosceva molto anche a livello di internas e quindi poi è stato un… avevo le persone giuste intorno.Sì, e il boost di apprendimento in questo tipo di contesti diventa veramente grosso, un turbo boost.una motivazione doppia, tu lo vuoi imparare in più le persone intorno da cui puoi imparare benissimo e quindi dici "vai, ora prendo adesso o non prendo mai più".L: esatto e hai anche diciamo quello che noi chiamiamo il fuoco nel sederino perché comunque devi portarti la pagnotta a casa per cui anche la velocità dell'apprendimento è doppia rispetto a che ne sono le contribuzioni in un progetto open source.MZ: certo sì sì assolutamente che poi è quello di cui secondo me hai bisogno quando cominci a guardare un linguaggio in modo professionale, a un certo punto hai bisogno di un'azienda o comunque di un lavoro che ti dica "ok, adesso questo è il modo di fare e noi usiamo questo linguaggio e in qualche modo lo devi sfungare giustamente, in modo corretto, quindi ci sta".Adesso ti faccio una domanda/provocazione.Qualche tempo fa abbiamo avuto ospite del nostro podcast Michele Chabarra, che dal suo punto di vista lanciava una critica alla cultura DevOps e quello che diceva Michele è che quando si va a sviluppare un'applicazione si percepisce ancora troppo il livello di infrastruttura quindi si deve lavorare in specie con Kubernetes e Docker che poi andremo a vedere dopo però si percepisce ancora molto lavoro in quell'ambiente e quando invece, secondo naturalmente la sua opinione, ci si dovrebbe concentrare probabilmente più sulla logica di business rispetto appunto, se si è degli sviluppatori cloud, rispetto appunto all'infrastruttura.Come vedi questa provocazione? Perché anche Michele l'ha detto in modo provocatorio fondamentalmente.LM: "secondo me è interessante, io non so bene come… ci sono un paio di livelli, nel senso potenzialmente siamo noi che ci complichiamo la vita, secondo me, noi in quanto persone che vogliamo non solo fare qualcosa, quello che dobbiamo fare, vogliamo anche imparare di nuovo, è sfidarci in questo senso.Quindi facciamo qualcosa in più che probabilmente potremmo evitarci se proprio voressimo essere solidi su quello che va fatto.E quindi ovviamente magari un po' di complessità la potremmo rimuovere e ci semplificheremo la vita.Siamo così e quindi ci teniamo così.Bisogna avere nel team la possibilità di fare, di livellarsi vicenda.Non noto questa cosa.Io però, dal mio punto di vista, forse penso come lui, io tento di evitare l'infrastruttura più che posso perché penso che non sia poi così, diciamo, almeno quando facevo lo sviluppatore.Adesso in packet è diverso perché noi facciamo… [LM:] fate quello! [CM:] sì, infatti sono anche in una fase di di transizione personale.Quindi è un argomento che sento particolarmente.Nell'infrastruttura Bare Metal che faccio adesso, ovviamente io qua davanti a me ho dieci Nuke smontati e sotto i livelli, però abbiamo la possibilità di fare un lab e imparare a usare l'hardware, che è effettivamente una cosa che non ho mai fatto prima del cloud computing, perché per me un server non è chiamato Amazon, non è API.come molti di noi.Esatto, ed è molto interessante.Ci sono delle tecnologie che, diciamo, fanno in modo che tu possa fare di tutto su queste macchine senza toccarle, che è veramente interessante.Comunque, per togliere quella domanda lì, penso che ci piaccia.Ci sono delle categorie di persone di cui ho fatto parte per qualche anno, a cui piace complicarsi la vita e sono quelle che poi magari ti inventano Docker o te lo condividono in modo comprensibile e fanno partire un nuovo modo di sviluppare.Ci vogliono, diciamo.Però è effettivamente vero che tendiamo un po' a sperimentare.Secondo me va molto a categoria di personaggi, sono anche persone che invece non gli interessa.Per esempio, lavorando in Influx, avendo a che fare con persone che erano da anni nel settore database, oppure da anni nel settore linguaggi di sviluppo e quindi hanno scritto linguaggi e tutto a loro nel cloud di Kubernetes, era molto, diciamo, non era così interessante.Loro interessava scrivere un linguaggio che è un argomento molto complesso, diciamo, creare queste cose qui, quindi è molto diverso.Insomma, dipende un po' dalla categoria di persone che hai di fronte.Secondo me conviene magari smettere di, diciamo, usare il Twitter account che hai tu e entrare nel Twitter account di un'altra persona e vedere come si muove, perché spesso ovviamente creiamo un ciclo di persone intorno a noi che è quella che più ci assomiglia o che più vediamo.la famosa bolla no? Esatto la famosa bolla che esiste anche nel settore dello sviluppo Concordo guarda il discorso è che la mia bolla di twitter facendo questo podcast è talmente eterogenea che praticamente è una barra grossissima della t-shape, la barra orizzontale grossissima della t-shape, vedo e leggo qualunque cosa legata al mondo dello sviluppo, la tecnologia, da che ne so, da ASCAL, Scala, JavaScript e poi React e quindi dici ok, va bene, perfetto.No ma serve perché serve perché chiudersi diciamo in un solo ambiente ti porta poi a comprendere meno cose.Io ho lavorato con un collega che ha sviluppato la robot anni fa, quindi molte cose che vedo attualmente in kubernetes, in altre strutture cloud, arrivano da quel mondo lì paradossalmente, quindi feedback loop piuttosto che reconciliation, queste cose qua sono concetti che arrivano dalla robotica.Domanda, l'ho buttata là qualche secondo fa, ho parlato di t-shape, no? Siccome abbiamo parlato di esplorare altri linguaggi, altre tecnologie, come gestisci tu Gianluca il focus verso una tematica quando ti vai a documentare? cioè ti perdi mai nel mare magnum di informazioni tecnologiche? tanto da dire sia oggi voglio provare questo, domani voglio provare quello e poi alla fine dopo un mese dici ok cosa mi son portato a casa? ti è mai capitata questa situazione? LM: "Secondo me, assolutamente la risposta è sì.Mi è capitato così spesso, per un periodo della mia vita così intenso, che negli ultimi anni ho smesso di comprendere e di imparare.Mi sono detto che voglio imparare in modo diverso, quindi continuare a fare un boarding di tool diversi per sviluppare un po' meglio oppure sviluppare più velocemente queste cose qua, non sono più così interessato ecco perché preferisco forse avere la possibilità di imparare a mettermi su, cioè a imparare come si fa a mettere su un ambiente di sviluppo che ormai mi conosco, diciamo, e quindi posso concentrarmi su evolvere da quel punto di vista lì non ho più così necessità di dire ok adesso questo poco mi serve se no non posso andare avanti.Quindi un po' c'è una scrematura, prima non la facevo adesso c'è una scrematura all'ingresso abbastanza forte che poi ti porta a un certo punto, poi penso che a un certo punto ti porterà a dover diciamo essere un po' meno restrittivo.Poi in questa fase sono molto restrittivo su cosa posso, su cosa voglio guardare, cosa non voglio guardare.Almeno per quanto riguarda i tool di… in realtà ma è difficile perché cambia un po' il livello di tool, quindi magari prima guardavo molto al Docker per lo sviluppo piuttosto che essere veloce nello sviluppare, adesso forse queste cose qua me le sono portate dietro quindi non le guardo più, però adesso con tutta questa parte di Bare Metal ci sono da imparare, quindi non lo so, diciamo che fortunatamente forse in questo settore in cui sono adesso la tecnologia è un po' più stabile perché essendo vicino, diciamo, così vicino all'hardware bene o male, almeno a livello di nomi, si parla di DHCP, Pixyboot, Netbooting, quindi sono roba che se ne parla da tanti anni.Quindi un po' mi sta tranquillizzando, ecco.Però sì, come dicevo prima, bisogna cambiare un po' mentre… cioè bisogna essere flessibili, ecco.Quindi secondo me quella è un po' la chiave.Quando senti che stai parlando sempre delle stesse cose, bevendo sempre le stesse cose e ora di fare un passo indietro.Io mi sono preso una pausa anche dalle conferenze pre-covid, diciamo, perché appunto mi sentivo un po' tappare le ali dalla mia stessa bolla e quindi ho detto "boh, cambia un po' l'aria".L: capisco.Adesso però passiamo ai giocattoli e entriamo in quello che nel nostro podcast da qualche puntata, anzi dalla precedente puntata, si chiama "Il Paese dei Balocchi"."E conduco nel Paese dei Balocchi"."Ah, il Paese dei Balocchi".Ed eccoci qua nel Paese dei Balocchi.Gianluca ci ha introdotto Docker.Docker, molti di noi lo conoscono, però fa sempre bene mettere un attimino i puntini sulle "i" e ridare uno sguardo a questo mondo.Quindi Gianluca, dal punto di vista di Gianluca, che è stato sviluppatore, quindi dal punto di vista N-1, T-1 anzi per essere precisi, Gianluca, che cosa è Docker? Io andrei direttamente alla parte più interessante.Come ben tu mi hai fatto capire, la prendiamo dello sviluppatore.Quindi il fatto che come siano fatti, dove siano, dove girino, ci interessa relativamente.Noi siamo abituati a passarci dei file in qualche modo.Sviluppo un pezzo, lo do a te, lo dai a me, io me lo guardo e tutto.E questo gli chiedeva un po' di… finché sono file semplici, il problema è che non sai cosa tu hai nel sistema, cosa ho io.Quindi abbiamo dovuto un po' complicare questo tar file, questo tarball con delle informazioni in più.E intanto Docker ci ha dato direttamente un sistema operativo, quasi un sistema operativo, non è un sistema operativo per carità, però ci ha dato tutto quello che è, un po' di più di quello che ci serve per capire e per far girare un'applicazione, che è una figata.Cioè dal punto di vista dello sviluppo, tu mi dai un'immagine, io me la guardo, te la ridò, tu me la ridai e andiamo avanti così.Poi a un certo punto questa immagine magari la dai a un altro, cioè la dai a un altro sistema che la fa scalare, la porta su, che se la guarda e tutto funziona.Quindi far diventare questo Tarball magico è un po' più intelligente.Questo è come lo definirei.LM: Io ricordo che prima di utilizzare Docker in fase di sviluppo utilizzavo le immagini Vagrant.Se usavo Vagrant con le immagini.Cosa ha cambiato l'introduzione di Docker da questo punto di vista? Io da quando ho iniziato a lavorare packet sto usando Vagrant molto di più di Docker, te lo dico così, quindi è ancora lì, sopravvive, è utilissimo, puoi fare cose che non puoi fare con Docker, stupendo.Il problema che diciamo l'evoluzione a livello di, se vogliamo prenderlo da quel punto di vista è sulla parte di sicuramente API, il fatto che sia diciamo più facile da usare forse docker a livello di...con i background file dovevi scriverle, dovevi portatele dietro, non potevi tirarle su tante tutte insieme perché comunque dovevi dichiararle.LM: dovevi sbatterti col provisioning, fare facendo gli scritti con Puppets.LM: sono più pesanti, sono più complessi, sono più pesanti.A livello di già solo cosa scarichi e come lo scarichi è diverso.Il docker file secondo me ha fatto molto.Cioè il Dockerfile ha portato, tra le tante rivoluzioni, tra le tante cose che Docker ha sviluppato, il Dockerfile come lo conosciamo è molto interessante secondo me.Tu parti da un'immagine che più o meno conosci, che potrebbe essere Ubuntu, vedi qual è la differenza.È molto semplice vederla perché non ti chiedi di scrivere 900.000 righe di YAML che devi poi portare dietro, come fa Ansibolo, oppure scrivi il tuo modulo Terraform, che cos'è.lo scrivi run, cosa vuoi girare, workdir dove vuoi andare e poi condividi i volumi finita finita, abbastanza semplice da quel punto di vista io ho giocato paragonando lo script di provisioning fatto con ansible per la mia vecchia vagrant machine e docker e ho fatto il paragone in termini di numero di righe di codice e di tempo utilizzato per il provisioning è una cosa spaventosa.Se l'immagine di Vagrant, usando Vagrant ci metteva 6 minuti, 10 minuti a fare il tutto, forse anche di più, con Docker è quasi istantanea.Sì, poi appunto il concetto, oltre al Dockerfile, anche il concetto di livelli, quindi scarichi immagini a livelli… è diverso.Dal punto di vista dello sviluppatore io forse potrei vederla come un'evoluzione, perché comunque, come ci stiamo dicendo adesso, per lo sviluppatore non è così diversa l'esperienza.Nel senso, hai un file, in cui c'è scritto come vuoi fare le cose e ti permette di condividere ambienti interi, che è quello che già faceva la grant.Lo fa diversamente, lo fa forse in modo migliore, anzi secondo me lo fa in modo migliore, se no oggi non ci diteremo ancora la grant.Ti faccio una domanda, ma sotto il cofano, quindi adesso sveglio l'altro lato di Gianluca, come funziona Docker? Allora, sotto il cofano c'è un sacco di...cioè non è un cofano di una macchina, è più un buco nero che è un cofano.Non si sa quanto si può andare giù diciamo.E poi soprattutto negli anni si è un po'...si è molto evoluto, adesso i container girano un po' dappertutto, quindi in base a dove vai sono cose diverse.ti posso dire che ad alto livello l'infrastruttura è di per sé, anche ad alto livello, molto interessante perché è un demone che gira nel tuo computer quindi se tu sei su Linux hai un demon che si chiama Docker D che gira sul tuo computer che si occupa di prendere le richieste che tu fai attraverso la Docker CLI quindi quando tu fai girare "dock run" in realtà stai facendo una richiesta che è somigliato a una richiesta TCP che va a un socket che gira locale.Questo è già interessante, perché tu hai un socket che gira lì e ci comunichi.Quando vuoi azionare la macchina HTTP, tu attivi la funzionalità dell'API e il tuo socket TCP si trasforma e può essere utilizzato come un server HTTP.che questo è già molto interessante come livello di comunica, come diciamo architettura io lo trovo interessante arrivando da un'esperienza minima per quanto riguarda questo settore dei sistemi, quindi lo trovo interessante.Poi sotto, ancora sotto dockerd ci sono vari ecosistemi in cui uno di questi è containerd che è stato sviluppato qualche anno fa perché docker stava crescendo molto nella sua responsabilità e quindi si sentiva la necessità di avere un nuovo docker che facesse quello che faceva docker 5-6 anni fa che era permetterti di far girare i container e scaricare le immagini senza tutto il resto e quindi si è creato container D che è poi quello che adesso è molto famoso per kubernetes se kubernetes ha un'interfaccia, richiede un'interfaccia minima per quanto riguarda far girare un tuo pod, un tuo container perché non hai bisogno di niente più che sia un hook per il networking un hook per far girare i container, per passaggi d'immagine quindi questa interfaccia si sposa bene con un tool che sia più selettivo nel numero difficile che può sviluppare e questo in Kubernetes si chiama container runtime interface, la CRI puoi usare Docker come CRI, puoi usare container D che già c'hai nel tuo sistema perché Docker già lo usa quindi insomma, poi sotto container D c'è ancora un...No, no, no, fermiamoci qua! Fermiamoci qua! Quindi ricapitolando per tirare le fila, docker è la famosa scatolina magica dove c'è tutto l'ambiente che ti permette di far girare la tua applicazione.Chi decide che ambiente deve essere lo decidi tu attraverso le definizioni di un docker file, giusto? Perfetto.naturalmente la sua velocità è data anche dal fatto che poi tutti i dati vengono memorizzati a livelli per cui ti scarichi solo i livelli mancanti o generi i livelli mancanti in modo da ottimizzare anche la creazione della nostra immagine del nostro contenuto.Se vuoi pensare questi livelli sono più o meno le righe del docker file se vogliamo semplificare la cosa al minimo Io ti dico la verità, mentalmente li ho sempre immaginati voi perché comunque si avvicina un po' il concetto a dei commit sul git no? Sono assolutamente sì, però diciamo a livello se tu vuoi sapere quale layer sei, tu puoi puntare più o meno alla riga del local file.Esatto, questa è una cosa che proprio si percepisce.Ti faccio una domanda, anzi faccio una piccola introduzione Tu sviluppi la tua applicazione su docker, la metti in questa scatoletta magica che ti permette di farla girare praticamente ovunque E su questo mi viene una domanda rapida rapida Sai se per caso c'è la possibilità di far girare docker su raspberry pi? Sì sì, possiamo girare su raspberry pi perché mi sono fermato qualche anno fa e mi ricordo che c'erano dei problemi su ARM C'è stato un grande lavoro sul supporto di più architetture infatti adesso nell'ultima versione di docker in realtà il sistema di build quindi docker build è cambiato adesso si usa una libreria che si chiama buildkit che è open source lo trovi nel repositorio di docker che supporta diciamo molta architettura quindi ha fatto un gran lavoro su quello.Fantastico poi faccio due o tre prove perché ho una raspberry nel cassetto come buona parte di noi italiani, di noi sviluppatori.Bivania.Esatto ed è inutilizzata quindi ci invento qualcosa.Comunque dicevo, abbiamo sviluppato la nostra applicazione è un bel monolitta, quelli che ci piacciono tanto, decidiamo di passare a microservizi e decidiamo di creare tante scatolette magiche docker, ognuna con una responsabilità diversa.Però qua entriamo in un mondo che è quello di farle comunicare tra di loro e soprattutto fare un deploy comodo.All'inizio si prova magari con docker compose che ha proprio questa utilità forse in ambito più dev che che opto e poi però ci si rende conto che ci bisogna di qualcosa di serio ed è uno diciamo il motivo principale per cui ho portato Gianluca qua ed è Kubernetes o Kubernetes dimmi tu la pronuncia io le sbaglio tutte a prescindere.Anche io ho passato alcune mie prime meetup a Dublino con un ragazzo di Google che ha passato una buona mezz'ora a insegnarci come si pronunciasse, ma non è rimasto nella mia testa, diciamo.LM: Quindi che cos'è Kubernetes? GZ: Allora, è un orchestrator di container.Quindi come tu hai detto, in realtà anche a livello di monolite questo problema ce l'abbiamo.Nel senso, quando arriviamo a poter deployare, arriviamo a rilasciare il codice in produzione, come fai a farlo in modo che sia scalabile e che non sia, diciamo, vincolato alla presenza di un solo server lì che gira? devi trovare modo di orchestrare, in termini tecnici, la tua scatola.E quello che si fa è tentare di costruire un sistema che ti permette di vedere tanti server come se fossero uno.Questo è un po' il gioco, perché deployare su un server solo è abbastanza facile.Se riusciamo quindi a portare un sistema più complicato che è quello di avere cento, dieci, mille server che però sembrino uno, la cosa diventa forse più semplice a livello di interfaccia.Sotto l'interfaccia è molto più complicato.e questo è uno degli obiettivi di Kubernetes, permetterti di deployare e di sentire un sincronodo anche quando ne hai tanti.E lo fa come fanno tutte le applicazioni di questo secolo, diciamo.questo è uno dei programmi più utili ti fornisce un API che puoi utilizzare una command line interface un programma che puoi far girare dal tuo computer funziona in modo dichiarativo scrivi un file, che è un file YAML scrivi cosa vuoi e applica il tuo cambiamento si prende in carico questo cambiamento, si prende in carico questo tuo desiderio e cerca diciamo in tutti i modi di realizzarlo.È un tipo un babbo natale moderno, tu gli dici cosa vuoi e lui cerca continuamente di non solo darti quello che vuoi ma anche di fare in modo che rimanga lì, così com'è.Quando si parla di kubernetes entra in gioco una serie di componenti, i pods, i servizi, sono diverse, un eventuale load balancer e questo credo che sia uno degli elementi che spesso costituisce quel muro o quella salita ripida nell'approcciare a questo mondo.Una cosa che trovo spesso è il confondere il container con i pods, perché giustamente i pods sono un concetto nuovo per chi utilizzava docker, magari con docker compose.Dovendo spiegare il concetto dei pods, come potremmo riassumerli? Allora pensiamo al fatto che la nostra applicazione tendenzialmente ha bisogno di satelliti, di oggetti correlati per farla funzionare.Questo vuol dire che non possiamo, perché non è una buona pratica, far partire più processi all'interno del container, quindi questo non lo possiamo fare.Se noi volessimo però avere un esempio, un esempio molto molto diciamo forse che non si vede molto spesso ma che esiste dappertutto diciamo, è quello di avere un server HTTP di fronte alla nostra applicazione.Anche se la nostra applicazione magari ha un server HTTP, tendenzialmente si usa metterne uno davanti, un po' più famoso tipo Nginx o Hproxy che ci permetta di magari configurare il TLS, magari controllare meglio la parte di monitoring e osservabilità.Quindi c'è sempre un po' la tendenza di avere questo server davanti con le nostre applicazioni dietro e questo cosa vuol dire è che queste due applicazioni devono girare molto vicine l'una all'altra e col concetto di container questo non lo puoi fare perché il container come dicevamo prima fa girare un processo solo, ma per buona pratica.Quindi bisogna di un'architettura che ti permetta di dichiarare più container che devono girare molto molto vicini.Questo è quello che fa il pod.Il pod ti permette di dichiarare più di un container.Quello che fanno i container all'interno dello stesso pod è condividere molto di quello che hanno.Tendenzialmente condividono il network namespace.Il network namespace, se vogliamo pensare di modo semplice, sostanzialmente è come se potessero vedersi sulla network locale, quindi è come se potessero comunicare a livello di localhost, che è una cosa che non puoi fare quando deploy più pod perché ogni pod ha il suo network namespace.Perfetto, e invece i servizi cosa sono? I servizi vengono di conseguenza perché tu adesso devi pensare che non hai più un solo container che gira sul tuo computer, ma hai magari il concetto di pod, il concetto di pod è forse la minima astrazione che hai su Kubernetes, poi il pod viene riutilizzato in vari modi.Uno dei modi per utilizzarlo è il concetto di deployment o il concetto di 6+7, che sono due risorse, tutto quello di cui stiamo parlando adesso in Kubernetes viene chiamato risorsa, quindi servizi, pod, deployment, stateful set, magari parleremo di ingress dopo, comunque tutto quello che vediamo sono chiamate risorse e queste risorse sono spesso incapsulate uno dentro l'altro, il pod è quello che si incapsula un po' dappertutto, il deployment e lo stateful set ti permettono di deployare più pod con la stessa risorsa, quindi se se tu vuoi deployare 10 container della tua applicazione web, dichiari un deployment con replicas di 10.In questo modo lui ti deploya i 10 container, poi dà 10 pod, poi da lì in poi puoi complicare la situazione, puoi utilizzare dei label per decidere dove metterli, puoi configurare delle strategie per cui non possono stare nello stesso nodo questi pod, in modo che se un nodo vada via tu sei sicuro che gli altri non siano vicini, e via dicendo.i deployment vengono utilizzati tendenzialmente per quanto riguarda il deploy di applicazioni senza stato, quindi stateless gli statefulset invece, come dice il nome stesso, vengono utilizzati per applicazioni che hanno uno stato questo perché? Perché concettualmente sono molto simili, ma nella loro implementazione sono molto diversi lo stateful set è molto più pistino, lui cerca sempre di mettere i pod nello stesso posto in cui erano prima se può.In questo modo applicazioni stateful riescono a girare in modo più stabile, che sono poi magari database o cose così.A questo punto tu hai questi due concetti che ti permettono di deployare tanti container, tanti pod, però non hai un singolo entry point per la tua applicazione.Quindi tu magari deploy 10 pod web, però non hai un IP che puoi chiamare e risolvere uno di questi 10 pod, che è poi quello che vogliamo.Se noi stiamo deployando un database MySQL replicato, quindi abbiamo tre repliche di di MySQL.Noi vogliamo mettere all'interno della nostra applicazione web PHP che magari utilizza MySQL un solo end point per MySQL.Vogliamo essere sicuri che anche se uno dei nodi vada giù, possa comunque riceverne uno degli altri.Quindi cosa fai in questo caso? In questo caso configuri un service che sostanzialmente ti dà un IP fisso o un nuovo DNS fisso che maschera a tutti gli altri pod che hai deployato dietro di sé.Quindi diciamo che è una sorta di capoclasse che decide quale pod deve rispondere a quella chiamata giusto? Sì esattamente puoi vederlo come un load balancer.Per cui ricapitolando noi abbiamo i nostri pod che fanno girare i container vicini tra di loro quando c'è bisogno che questi container siano molto vicini un esempio può essere PHP, FPM con Nginx.Poi abbiamo un servizio che siccome questi pod li possiamo replicare deve decidere in quale replica deve rispondere a una certa chiamata.Ricapitolando quello che hai detto tu, correggimi se sbaglio.assolutamente, bisogna appunto ricordarsi che lo troviamo in tante forme, una delle forme è il deployment dello stateful set che ci permetterà di replicarli una delle cose che si nota utilizzando Kubernetes è che spesso la definizione di queste risorse diventa un po' verbosa Per ovviare a questo problema è apparso nell'ambiente Kubernetes Helm.Che cos'è Helm, cosa fa e quali sono i suoi limiti? Helm nasce per aiutarci a riutilizzare questi verbosi YAML file.Quindi è un repository in cui ci sono tutte le varie definizioni di applicazioni e tu puoi, diciamo, è un package manager sostanzialmente.Come fai l'apt-get di qualcosa per installarlo su Ubuntu, fai elm install e installi la tua applicazione su Kubernetes.Io non sono quel tipo di sviluppatore, quindi non lo conosco così bene, non sono un fan di questo tipo di soluzioni.Però questo è quello che fa, diciamo.La limitazione non lo conosco, quindi non posso ben aiutarti sulle limitazioni.Ho letto un po' di cose e io dalla mia esperienza ti posso dire che questi tipi di tool non sono mai abbastanza flessibili.Quindi una limitazione grande è quella.Comunque si parla di un template engine su cui vengono sostituite delle variabili, quindi a un certo punto il template engine diventa un po' complicato oppure è troppo semplice e non ti fa fare quello che vuoi.Quindi probabilmente una limitazione potrebbe essere quella lì, a meno quella che mi tiene lontano da questo tipo di soluzioni è quella.Sì, è perché ho visto che parecchio ha adottato nel mondo dei dev.Assolutamente, secondo me, come ho detto prima, non sono la categoria di persone che ha quei problemi da risolvere, però posso capire che sia grande.Ti faccio una domanda adesso rimetti i vestiti dello sviluppatore di qualche anno fa se tu fossi un solo dev di un progettino da deployare e sei da solo che devi farti il front end devi farti il back end, il modello dell'applicazione, devi anche farti magari anche il marketing suggeriresti in questo caso un deploy con kubernetes oppure opteresti per altre altre tecniche altre tecnologie? ma guardo ovviamente è una domanda un po un po complicata con le conoscenze attuali ovviamente andrei su kubernetes però andrei su un senso se avessi qualcosa da investire che dici "boh ovviamente devo tenere su un minimo di server quindi magari intorno a me" non lo farei per un server solo diciamo se voglio fare un singolo nodo di kubernetes faccio scp dell'applicazione da locale, da solo che se ne importa.Però se già ho in cantiere che questa cosa debba un minimo essere resiliente o comunque che voglio che si piloti da solo un minimo di diciamo automazione prenderei un servizio da service di kubernetes e andare di sopra.Perché lo conosco già è tutto.Se sono un sviluppatore da solo a cui non interessa particolarmente questo argomento ovviamente non lo farei.Se sei interessato all'argomento è un buon motivo per imparare.Secondo me da sviluppatore è quello che dobbiamo tenersi aperti come porta e comprendere come si utilizza.Quindi se posso decidere di utilizzare Kubernetes lo utilizzerei, ma non lo utilizzerei come "adesso me lo installo tutto, me lo tengo su, me lo faccio girare, me lo monitoro e tutto".Voglio utilizzarne le API, voglio conoscere come fare programmazione su Kubernetes, perché è facile da estendere, quindi ci puoi fare un sacco di cose abbastanza interessanti.quindi andare su quella su quella strada lì più che metterlo su un Kubernetes mio su più nodi perché quello è veramente una strada che ti porta come dicevamo prima a fare un altro lavoro ecco un'altra domandina questa app è più che altro una curiosità scusami, una cosa che mi volevo solo rafforzare lo farei perché Kubernetes al momento sta e o o sta diventando lo standard di fatto per quanto riguarda tutto.Nel senso, gira all'interno dei supermercati, all'interno delle casse dei supermercati, piuttosto che tutti i cloud providers hanno un servizio.Sta un po' diventando l'attore che democratizza l'interfacciarsi con dei sistemi.Perché comunque, con la possibilità di estenderlo e di fare entrare nel sistema Kubernetes delle risorse tue con le custom...ci puoi...sono a voglia di andare nel dettaglio, però tu puoi sviluppare delle estensioni per Kubernetes che ti permettono di utilizzare le Kubernetes API con oggetti tuoi.Quindi adesso faccio un esempio totalmente fuori fase, però se tu volessi fare di Kubernetes un CMS e salvarci dentro i nomi dei tuoi clienti, tu lo potresti fare e utilizzare il PI di e la sua SDK per lavorarci.Non è da fare, non va fatto, però ha quel tipo di assediabilità lì.Ed è per questo che tutti i cloud provider stanno arrivando lì.Ad esempio sia Amazon che GCP che altri cloud provider stanno creando, stanno integrando i loro servizi, quindi la possibilità di creare EC2, la possibilità di creare VPC e queste cose qui, all'interno di oggetti Kubernetes.quindi come tu crei un servizio arriverai a creare un EC2 per dire.Quindi a livello di sviluppatore o comunque a livello di conoscenza di utilizzo secondo me è fondamentale comprenderla.Quindi se si può fare ti tiri su un tuo servizio, su un servizio da service Kubernetes, ci deploy il tuo pod e impari come si usa.Sì io questo l'ho provato e mi sono reso conto che si arrivava a questo livello perché quando ho fatto un test di Kubernetes l'ho fatto su DigitalOcean che ha tra l'altro il servizio di Kubernetes e la particolarità infatti la cosa simpatica è che quando ci mettevo ingress quindi come come lo possiamo raccontare ingress? la porta d'accesso, insomma è un nginx che praticamente ti aiuta ad andare su un servizio piuttosto Ti espone verso fuori un servizio piuttosto che un altro e ti creava direttamente un load balancer di DigitalOcean.Sì, sì, sì, è quello, secondo me, è quella una delle motivazioni per cui conviene comprenderlo dal punto di vista dell'utilizzo della fruizione.Lasciamo stare se non sei del settore o se non ti interessa diventarlo come lo fa dietro, però dal davanti ci troveremo a interfacciarci con Kubernetes sempre di più.se poi vogliamo fare un'altra considerazione per quanto becera possa essere se noi installiamo docker desktop nella nostra macchina vediamo che in realtà c'è la possibilità di tirar su un minicube che poi ci spiegherai magari nella parte di gingilli ci spiegherai di cosa si tratta per tirare su il nostro class micro kubernetes locale no? quindi c'è se già che ti permette di far girare docker nella tua macchina da sviluppatore ti spinge e ti mette a disposizione kubernetes vuol dire che veramente ovunque qualche tempo fa ho fatto un workshop mi sa che era proprio un code motion ho fatto un workshop forse 2014 2015 adesso non ricordo sull'orchestrazione e si parlò di DCOS.Che fine ha fatto DCOS? Ha sentito i colpi di Kubernetes o sono cose diverse? In realtà è una distribuzione che arriva da Mesosphere che in realtà ha poi dichiarato poi ultimamente, qualche anno fa, ha detto "io adesso distribuisco Kubernetes" quindi è ancora lì ma ti trovi un Kubernetes dentro, se vogliamo semplificarlo.La stessa cosa è stata per Swarm no? Che adesso si interfaccia con Kubernetes.Sì, diciamo che è sì, come dicevi tu, Docker Desktop fornisce un'integrazione con Kubernetes e con Swarm, quindi è Swarm stesso poi, in realtà è stato Swarm ha avuto molti benefici a livello, secondo me, di community.Era un orchestratore e un orchestratore molto comprensibile.Ha portato concetti che con Kubernetes non puoi esplorare, perché non puoi esplorare da zero comunque se non sei una persona interessata all'argomento, perché sono un po' complicati.E poi in realtà anche a livello tecnologico ha portato molto anche a Kubernetes stesso perché tutta la parte di join e init, come la conosciamo in Kubernetes, arriva da Dockerswarm sia a livello di sicurezza che a livello di costrutti quindi è stato poi adottato anche da Kubernetes.Insomma è diventato lo standard, si è seduto sulla sedia e sarà difficile sprotestarlo adesso? È difficile, sicuramente difficile.Ti faccio una domandina.Guardavo il tempo, probabilmente è l'ultima di questo episodio, o la penultima.Una delle tue attività, immagino, e dei tuoi interessi è quello del monitoring dei cluster Kubernetes.Perché cosa è utile questo tipo di attività? Esistono degli strumenti per farlo? Esistono dei suggerimenti che puoi dare? Diciamo che più che del monitoring di Kubernetes stesso, sono interessato alla capacità di comprendere cosa sta facendo la tua applicazione, il tuo sistema, ovunque si trovi.Che è un un argomento che è cambiato con il cambiare del modo in cui scriviamo le applicazioni.Nel senso che adesso abbiamo molte più applicazioni di prima, molto più interconnesse, che hanno portato ad avere un approccio a come descriviamo molto diverso, perché adesso siamo in grado di riprovare, chiamando HTTP, abbiamo creato un sistema un po' più resiliente, diciamo fatto un tentativo, che però ha portato complessità più alte, quindi comprendere cosa fa un'applicazione o come una tua richiesta sta andando rispetto a quando eri un monolite in cui la tua applicazione picchiava sul endpoint e poi picchiava su un paio di classi, un paio di controller e poi andava nel DB, è molto diverso rispetto a quello che abbiamo adesso.In qualche modo no, ma è diverso.E quindi niente, sono molto concentrato su quella parte lì, perché da sviluppatore ho notato che è molto più difficile comprendere cosa fa un'applicazione, diciamo, e quindi bisogna essere in grado di...mi sono appassionato al tracing, mi sono appassionato a scrivere dei log che non siano più dei semplici punti nel tempo che non puoi correlare, ma che possano essere correlati insieme per raccontare una storia più grande.Quindi niente, questo è un un po' quello di cui mi interesso.Si sposa bene con Kubernetes perché ovviamente è dove la complessità trova posto e Kubernetes offre un sacco di dati e informazioni che puoi utilizzare.Molti arrivano dai suoi componenti, quindi Docker fornisce un sacco di...quando tu sei nel tuo computer e fai Docker System Events, vedi che comincia a stamparti a video delle linee JSON che contengono quello che Docker sta facendo.Tutte queste cose possono essere portate all'interno di un database come la Seek Search e Visionate, poi queste possono essere correlate con magari tutte le informazioni che Kubernetes stesso ti dà sullo stato del pod e varie, in modo da crearti una risposta alle domande che ti stai facendo diciamo.Quindi questo è un po' l'argomento che però appunto secondo me conviene trattare nel suo podcast.credo proprio di sì perché in realtà è enorme.Naturalmente noi aspettiamo che ne parli in uno dei tuoi Twitch show.In questa fase sono tutto concentrato sul Verme Teleprovisioning quindi è un po' diverso ma tornerò anche con il monitoraggio perché comunque fa parte, secondo me appunto il monitoraggio deve far parte delle skills che i sviluppatori devono avere e negli anni probabilmente non l'abbiamo avuto così forte, almeno io non l'ho preso così forte fino negli ultimi 4-5 anni.LM: guarda, da sviluppatore ho iniziato a capire l'importanza del monitoraggio quando ho provato, non so se lo conosci, Sentry.Sentry è un altro servizio che ormai non uso più perché in realtà non fa parte dello stack che era New Relic.Io da là riuscivo paradossalmente a intervenire molto più rapidamente sul bug in produzione con Sentry e a capire quanto stavano bruciando le mie macchine con processi stupidi con New Relic.Quindi in realtà poi una volta che lo provi dici "Ehi, aspetta, forse a questo punto non ne posso più fare a meno".LM: sì sì, ma poi aspetta, prova a entrare nel capitolo del tracing, di distributed tracing e vedere quella parte lì, è molto interessante.È un'altra di quelle cose che poi dici "ma prima che cosa stavo facendo, prima come facevo?" LM: perché se, mi ripeto perché secondo me è un concetto veramente interessante e fondamentale.In quanto sviluppatori noi creiamo applicazioni che possono essere monitorabili, comprensibili o assolutamente incomprensibili e impossibili da capire.Quindi questo è un punto di vista che secondo me dobbiamo tenere in mente quando scrivo un'applicazione.Io personalmente una delle cose che ho in mente quando disegno un'applicazione è come faccio a capire cosa sta facendo dall'esterno.Perché poi comunque non è che posso andare in produzione e mettere un break point oppure far girare la mia singola richiesta e cercare tranquillamente di produrre un problema.Sì anche perché per esempio dentro Kubernetes come fai a muoverti? È tutto un capitolo che come ti dicevo prima secondo me conviene se puoi riospitare persone e la gente interessa possiamo riparlare per un bel po'.L'unico limite penso sia il conduttore in quel caso, nel senso che non sarei in grado di reggere la conversazione, di tenere in testa la conversazione.aiuto sviluppatore, quindi hai un punto di vista, hai una grande esperienza su come fai a capire che cosa scriviamo.Faccio recito il ruolo dello sviluppatore ignorante.Non è questione di ignoranza, è proprio un argomento difficile, non sai mai come un utente utilizzare la tua applicazione, quindi tutti i concetti di essere self defensive e implementare le cose in modo difensivo, che quindi ti permettono di dire ok il mio utente può… so che il mio utente questo non lo può fare perché per design l'ho evitato, poi lo farà lo stesso però… L: sì, guarda, questo tipo d'approccio spesso è molto lontano dall'approccio comune nello sviluppo delle applicazioni, anche ora oggi siamo portati spesso a realizzare delle black box abbastanza opache anche con noi stessi e devo dire che questo tipo di meccanismo dovrà prima o poi cambiare.Quindi facciamo così, noi ci diamo appuntamento per un'altra occasione dove parleremo proprio di monitoring delle applicazioni.Quindi magari che ne dici possiamo coinvolgere qualcun altro insieme a te e facciamo adesso una puntata a tre.Io non saprei chi coinvolgere che parla italiano.qualcuno lo troviamo però ti scarico la patata bollente quindi ti porto qualcuno io porto le birre perfetto a posto già organizzato Gianluca prima di lasciarci però ci devi fare un regalino quindi ci devi raccontare perché non tutti gli ascoltatori di github hanno giocato con kubernetes quindi ci devi dare due dritte per iniziare ad approcciare a questo mondo? LM: Va bene, allora io mi sento di dirti che la documentazione ufficiale è molto buona.C'è un libro che si chiama "Kubernetes up and running" di Eurilli, che l'hanno scritto gli inventori o i maggiori attori intorno a Kubernetes.È un libro molto breve, molto facile da leggere e che ha la caratteristica di portarti nella documentazione.Quindi tu quando hai finito il libro sai anche leggere la documentazione, che è una bella cosa.Quindi io partirei da lì e poi se invece volete tirare sul vostro cluster ci sono due soluzioni, ci sono varie soluzioni.Quelle che mi sento di consigliare sono Docker for Mac, Docker for Windows, Hanno Kubernetes installato.Docker for Mac sicuramente che ce l'ho qua davanti alla faccia, docker for windows penso sia uguale, hanno kubernetes installato, quindi tu vai di attivi kubernetes e ce l'hai locale, facile.Se sei un po' più smanettone e vuoi provare minikube è una delle soluzioni che un po' ricorda docker machine se ce l'avete in mente, praticamente è una CLI che ti permette di tirare su un singolo nodo kubernetes con una macchina virtuale sul tuo computer, quindi questo è un altro modo.Il terzo modo che mi piace molto perché è molto facile, utilizza un tool che si chiama Kind che è stato sviluppato da Kubernetes stesso nell'app per il gruppo che si preoccupa del testing e ti permette di tirare su nodi Kubernetes utilizzando Docker.Quindi ogni tuo nodo è un, a posto di essere un server, una virtual machine, è un container che è interessante.Io andrei sui primi due, il third kind è molto semplice, io lo uso quello che su di più perché non ho bisogno di grandi cose, però penso abbia qualche limitazione in più, di cui però non mi viene in mente niente adesso.Quindi niente, Docker for Mac, Docker for Windows, Minikube.Il libro è molto comodo, la documentazione è buona, quindi io partirei da questo pacchetto.è detto questo io non posso far altro che ringraziare Gianluca al quale sono debitore di una birra che ci berremo nel prossimo episodio dove lo rivedrà protagonista quando parleremo di monitoring delle app.sappi che lo segno nella to do list quindi quella sono qui sei precettato e nulla io davvero Gianluca non posso far altro che ringraziarti a nome mio e a nome di tutta la community di Gitbar, sia per la tua presenza naturalmente in questo podcast che per tutta l'attività di divulgazione che poi negli anni hai fatto.Quindi grazie.LM: Grazie a te dell'invito, grazie a chi ascolterà.Una delle cose che aiuta il divulgatore e sapere che quello che fai è utile.Quindi mi fa molto piacere sentire che hai detto qualcosa che ti è piaciuto e appunto invito anche le altre persone a farmi sapere cosa ne pensano perché aiuta molto il morale delle truppe qui da questa parte dello schermo.LM: Prima di lasciarci ricordaci i tuoi contatti.Sì, allora il mio nickname è lo stesso un po' dappertutto che è Gian Arb.Quindi mi trovate gianarb.it è il mio blog, Gianarb su Twitch e su Twitter sono un po' i canali che in questo momento, sito, Twitch e Twitter sono i canali che uso di più.In molti slack c'è il mio nickname, alcuni li seguo più di altri e se mi trovate di voler salutarmi vi rispondo volentieri.Grazie mille Gianluca.Alla prossima allora.Ciao, grazie.Era Gianluca Arbezzano che ci ha introdotto nel mondo di Kubernetes e non solo, abbiamo parlato di diverse cose.I contatti li trovate anche nelle note dell'episodio, quindi potete rompere le scatole a Gianluca.Ci ha dato lui il permesso, quindi è possibile farlo.Detto questo, cosa rimane? Rimane ricordarvi i nostri contatti.Quindi, gruppo Telegram nelle note dell'episodio.mi raccomando iscrivetevi perché la pubblicherò naturalmente gli episodi nuove uscite e possiamo anche chiacchierare visto che la comunicazione via email e via twitter messaggi privati di twitter era un po' complicata io comunque vi ricordo anche i contatti quindi twitter @brainrepo email info@github.it vi ricordo anche che per tutte le puntate note degli episodi audio e quant'altro trovate tutto su www.gitbar.it se l'episodio vi è piaciuto e siccome c'era già Luca penso proprio di sì potete iscrivervi utilizzando il vostro client di podcast preferito in modo da ricevere ogni settimana la nuova puntata prima degli altri e se proprio vi è piaciuto tanto beh aprite l'app podcast di apple oppure itunes e lasciate una recensione.Noi ci sentiamo la prossima settimana sempre qua su GITBAR.Da Lione è tutto, alla prossima.Ciao! GITBAR, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta dell'attrezzi dei fullstack Dev.[Musica] [Musica] Ciao!
