Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Ciao Luca! Ciao Mauro finalmente, è da un po' che mancavo, infatti...Sì, sì, sì.Ti sei data la macchia a questo periodo.Eh, lasciamo stare.E io te l'ho detto, questo vuol dire essere essere metà tecnico e metà management.Non me lo dire, non me lo dire, non me lo dire.Ma sono contento di star qua.Tutto a posto? Come va? Bene, bene, tutto a posto.Sono anche rientrato un po' a essere un po' più attivo nel gruppo Telegram, ma quello lo sponsorizziamo dopo.No niente, sono tornato e non vedo l'ora di ricominciare.Adesso li farò tutti i podcast.Tra l'altro noi due dovremmo essere in bisticcio credo, perché vista la nostra discussione su su xml sì xml no, io dovrei essere offeso con te lo stesso.Non toccarmi xml no no no.Eh lo so che sei innamorato ma ti giuro mi fa cagare tantissimo zio, cioè non puoi capire il sangue che sto sputtando.Tra l'altro piccola marchetta se al lato, se vi va di darmi una mano come stiamo facendo insieme a Flavio, contattatemi perché c'è un po' da fare nel progetto 4v, se vi fa piacere ecco siamo siamo qua.Passate il momento Marchetta, è arrivato il momento di ricordare i nostri contati, info@gitvar.it @brainrepo, i contatti ormai canonici sedimentati nel tempo e incisi sulla pietra e abbiamo anche il gruppo telegram dove si parla appunto di XML o JSON, discussioni proprio in fiamme, basta cercare Gitbar Podcast, il logo giallo, Gitbar, siamo attorno a più di 1530 membri e quindi se venite anche voi sarete sicuramente di più.Vi ricordo che c'è anche il nostro canale YouTube dove avete già visto la settimana scorsa la prima puntata che abbiamo registrato al FOSDEM dove parlavamo del progetto FOURVIER e di podcasting e dove state vedendo i nostri bei faccioni anche questa settimana, quindi se non l'avete ancora fatto cliccate su iscriviti e cliccate sulla campanella per rimanere aggiornati.A parte questo vi ricordo anche che c'è lo store di GITBAR dove potete comprare la fantastica maglietta Visio Terminalista Metal Meccanico è terminata questo momento alla mastrota.Io direi Luca se siete d'accordo con me che possiamo iniziare.Minchia non mi sta bene fare il televenditore.Guarda ci stanno anche le donazioni, ci sta anche mettere il mi piace sul video di youtube guarda potremmo andare avanti ancora per un po' ma possiamo cominciare va che forse Sì sì, altrimenti rischiamo di diventare il banchetto del pesce, quindi meglio partire e presentare i nostri ospiti subito dopo la sigla.Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.come spesso facciamo anche questa settimana abbiamo due amici qua nel nostro Gitbar.Abbiamo con noi uno dei nostri primi ospiti di Gitbar, probabilmente quando Gitbar davvero aveva ancora il ciuccio e camminava a Carponi.Abbiamo con noi Mitch Murabito.Ciao Mitch! Ciao! Per la cronaca episodio 47.Me lo sono studiato di recente.Cavolo, pensare che abbiamo superato i 180 adesso mi fa sentire vecchio.Ecco Mitch, abbiamo un altro amico, il grande Graziano, con lui abbiamo condiviso tante avventure, no Graziano? Il Fosdam dell'anno scorso, CodeMotion, insomma, ormai anche tu fai parte della grande famiglia di Gitbar.Ciao a tutti, grazie mille per l'accoglienza.Mitch e Graziano fanno parte del team di developer relations di Miatplatform, Miatplatform che devo dire in tutta sincerità in Italia si è ritagliata un ruolo di, mi vorrebbe da dire, polo tecnologico d'eccellenza, o comunque di azienda tecnologica ben riconosciuta a livello internazionale e quindi anche di orgoglio italiano.e con loro oggi volevamo parlare di un argomento abbastanza controverso o quanto meno, di una metodologia che sta catalizzando tanta tanta attenzione e alla fine anche abbastanza hating, no? Cioè il discorso di quando si catalizza così tanta attenzione poi alla fine ci si dice "eh ma perché tutta questa attenzione ma sono le solite quattro stronzate condite con un nome nuovo e tutto va bene.Allora oggi proviamo a demistificare questa questa visione, proviamo a dargli una definizione quanto più oggettiva possibile anche se come ben sappiamo l'oggettività assoluta non esiste perché siamo esseri umani però cerchiamo di approcciarci nel modo meno più libero da bias possibile, sapendo sempre amici miei che io dovrò rompere i coglioni in giro quindi probabilmente vi provocherò come vi ho detto in fuori onda.Oggi infatti parliamo di platform engineering.Luca ti voglio fare una domanda, tu da uomo che ha navigato per tanti anni nei mari dello sviluppo software.Quando senti la parola platform engineering cosa ti viene in mente? So che domanda difficile, me le dovevi dire così me le preparavo queste cose.Platform engineering seguendo la parola mi verrebbe da dire una piattaforma che fa tutto e che riduce gli sviluppatori a qualcosa di un po' meno.Sei già a dover fare il tuo cattivo! Con la Ford Opinion! Stavo dicendo "Poliziotto buono, poliziotto cattivo" e dovevo essere il poliziotto buono! Ma questo è l'episodio "Due poliziotti cattivi e unica botta" No, è stato bellissimo perché in realtà in modo molto sub-tile, molto così fluido e nascosto l'hai servita su un piatto d'argento, però adesso, a parte gli scherzi, proviamo a vedere un po' Lato definizione, quando noi parliamo di platform engineering, Mitch o Graziano, a cosa ci riferiamo precisamente? Quali sono i limiti che definiscono questo tipo di ruoli? Ok, buon detto, vai vai, grazie.Comincio io e riprendo un attimo quello che ha detto Luca.Luca ha detto, è una piattaforma che fa tutto e rende gli sviluppatori un qualcosa di meno.In realtà non fa tutto, ma fa quello che serve per fare in modo che gli sviluppatori facciano gli sviluppatori.Quindi non fa fare agli sviluppatori qualcosa di meno, ma fa in modo che essi si possono concentrare per fare quello per cui nascono, quindi sviluppare.Cosa vuol dire "fa quello che serve"? Fa quello che serve perché è un insieme di cose che possono andare da tool, servizi, script, banalmente conoscenza, quindi documentazione, wiki, che servono ad un unico obiettivo che è quello del garantire l'autonomia dello sviluppatore.È una metodologia che si occupa di questo, sostanzialmente come lo fa? Lo fa attraverso lo sviluppo di quella che viene chiamata Internet Developer Platform.questa è a grandi linee, in due parole non so Mitch se vuoi aggiungere qualcosa, una definizione semplice di platform engineering esatto, io aggiungerei solo che è una metodologia, quindi quando si parla di metodologia come tutte le altre metodologie che conosciamo non si parla mai di uno strumento o di un contesto specifico poi un pochettino per deformazione professionale, sia io che Graziano diciamo, applichiamo questa metodologia a lavoro per la parte di cloud, Kubernetes e tutto quel mondo lì però come tutte le metodologie poi sicuramente è estendibile in altri contesti, in altri settori, un po' fuori dal nostro scopo direi e poi su ciò che diceva Graziano relativo al fatto del rendere gli sviluppatori un po' più felici perché possono fare effettivamente quello per cui diciamo vengono pagati, ora passatemi il termine aggiungo anche che dall'altro lato permette a chi si occupa invece di struttura, diciamo chi fa operation, di fare la stessa cosa, che non è, se ci pensate, una cosa del tutto malvagia.Mi viene da fare una domanda, anche questa un po' provocatoria tra le righe.Io sono uno vecchio, ok? E quando ho lavorato in aziende anche di una certa dimensione, spesso c'era il cerchio magico dei vecchi che in qualche modo definiva le practices, qualche volta veniva chiamato il team di practices dove ci si sedeva a tavolino tra i vari lead, a qualunque livello mi immagino che ne so, i principal e gli staff, che si sedevano e dicevano ok Per fare questa cosa cerchiamo di definire una practice, questa è la linea, la cerchiamo di distribuire in tutti i team.Cosa cambia dall'approccio delle shared practices all'approccio del platform engineering? Allora vado un attimo io e faccio un piccolo passo indietro così attacchiamo la discussione.Allora, fondamentalmente quel concetto non è superato, è assolutamente ancora valido, eccetera.L'unica cosa che cambia è che quando abbiamo iniziato noi, direi, soprattutto io, te, Mauro, probabilmente anche Luca, Graziano, scusa, tu sei giovane, quindi, quando abbiamo iniziato noi la realizzazione di applicazioni è anche abbastanza complessa e passava poi sull'utilizzo di pochissimi tool.Cioè se hai pensato a questa cosa, dovevi un pochettino conoscere la sistemistica Linux probabilmente per altre applicazioni, dovevi conoscere un linguaggio backend, probabilmente neanche un linguaggio frontend era necessario e obbligatorio quando ho iniziato io almeno.Sì, un po' di HTML e CSS, però non c'erano dei framework Quindi con pochissime cose riuscivi ad arrivare al dunque.E lì era molto facile, perché quel circolo di cui parlavi tu dettava delle linee guida su sicurezza su PHP, diciamone uno, vent'anni fa andava tanto.E definiva delle regole su come ottimizzare build su...in strada struttura su Linux, perchè poi alla fine quello usavamo definiva una serie di linee guida, venivano condivise quelle linee guida tendenzialmente anche il nuovo arrivato, neolaureato, con pochissima esperienza imparava quelle poche cose che servivano ed era non dico autonomo perchè nessuno è mai autonomo al 100% nei primi 10 anni di carriera ma tendenzialmente sapeva dove metterle le mani Ora, valutate un'applicazione oggi Oggi per sviluppare un'applicazione complessa, la quantità di cose che una persona normale dovrebbe conoscere è così tanta che non basta una vita di studio.Questa è la mia opinione personale.Perché? Perché devi conoscere il linguaggio front-end, il framework front-end, il linguaggio back-end, il framework back-end, i database SQL, il NoSQL, i sistemi di build, i sistemi di logging, le dashboard, i servizi cloud, come funzionano i cloud provider una serie di cose così infinita che una singola persona, secondo me modestissima, difficilmente riesce a realizzare un qualsiasi tipo di applicazione quindi quel circolo non può lettare linee guida su tutto, ma probabilmente lettare linee guida solo su alcune di queste parti Quindi fondamentalmente la metodologia ti viene in aiuto perché alcune cose, magari che anche il circolo conosce un po' meno, può prenderle da esperienze comuni, da altri sistemi.Immaginate l'int, oggi quando uno decide di adottare l'int in genere prende set di regole di azienda X, la personalizza secondo le esigenze, probabilmente ne cambia il 10%, ma il 90% lascio quello che già c'è, perché è inutile riscriverlo da capo, nella maggior parte dei casi.Se c'è la necessità di cambiare qualcos'altro, perché nascono dei limiti, ci sono dei limiti delle cose, allora il circolo di cui parlava Vauro si riunisce, si mette lì e va a modificare le cose che effettivamente serve modificare.Quindi, alla fine mi dici, prima lo scopo del circolo era più limitato, del cerchio magico, era più limitato per cui si poteva gestire.Oggi che abbiamo un'ampiezza di tool, di strumenti, di linguaggi, di robe così grande è necessario un approccio diverso, quello del platform engineering.Però io in realtà non ho capito, cioè quando, dovendo riconoscere una differenza, la differenza qual è? Quella dell'operatività del team di platform engineering o perché il circhio magico decideva "ok andiamo in questa direzione" e poi lasciava liberi i team di implementare questa cosa al massimo, se volevano comunicavano tra loro e si scambiavano le robe.Ma alla fine il platform engineering come approccia? Cioè in cosa si distingue sulla pratica? Allora sulla pratica tendenzialmente oggi non andiamo molto sul dettaglio ma dividiamo in un paio di gruppi e sicuramente esiste un gruppo di developer in qualsiasi azienda genera prodotti questo gruppo di developer tendenzialmente è molto molto bravo nella scrittura di codici applicazioni insomma chi più ne ha più ne metta e poi tendenzialmente c'è sempre un team che si occupa di infrastruttura, operation devops, quel mondo lì no? questi due team per forza di cose per portare avanti il progetto devono collaborare.Questa collaborazione non è spesso semplice perché se esistono all'interno dell'organizzazione più team di developer e più team di operation questi devono comunicare, magari una volta il ticket non me lo risolve il team di operation A ma me lo risolve il team di operation B e questa cosa diventa estremamente complessa.Ora immaginate un cambio di paradigma dove il developer non deve più chiedere al team Operation di creare un ambiente nuovo per avviare un nuovo progetto per svolgere dei test, ma semplicemente entra in quello che Graziano prima chiamava IDP, clicca un bottone e dopo 20 secondi quello deve alloperare l'ambiente dove iniziare il nuovo progetto o dove eventualmente effettuare i test.Questa cosa ovviamente, diciamo questo nuovo ambiente non viene creato dal nulla magicamente, viene creato da delle pipeline scritte dal team di operation.Il team di operation, assieme magari anche ai developer, definiscono degli standard, delle regole per cui quest'ambiente deve essere creato, tutte le linee guida del mondo, e una volta che mettono sulla pipeline la rendono disponibile al developer in modalità self service.Quindi il grosso vantaggio per il developer, poi ovviamente questa cosa di vantaggio anche per chi fa hoax, il grosso vantaggio per il developer è non dover più dipendere, per iniziare il progetto, dal ticket, che in genere funziona così, aperto al team di ops.Ovviamente, qua aggiungo un apparente, faccio anche io il poliziotto cattivo per un pochettino, ovviamente questa cosa vale se tu hai dei team abbastanza grandi, perché se tu hai un team di due persone dove uno è il dev e l'altro è l'ops e sono seduti attorno alla stessa scrivania, nessuna cosa migliore è alzare il braccio e chiedere "mi fai l'ambiente?" però probabilmente nei team più strutturati e spesso le aziende oggi iniziano a essere molto molto strutturate, avere un approccio di questo tipo ti permette di disaccopiare le operazioni dei dev da quelle delle operation, che non è come dicevo prima una cosa del tutto banale.Poi sia dev che operation insieme definiscono quelle che sono le linee guida e possono tranquillamente inserirla all'interno delle pipeline, degli artefatti che vengono creati nel mondo lì, per applicare delle linee guida comuni, quello che prima faceva il circolo magico.Quindi dovendo fare una sintesi, fondamentalmente ci sono delle risorse che la società mette a disposizione per standardizzare processi attraverso l'uso di tool o di meccanismi automatici.Esatto.In modalità...scusa, questa è una cosa importante perché questo, se ci pensi, è più o meno DevOps.Io conosco i miei amici, sapevo dove andavano a parare.In modalità self service, quella è la cosa importante che cambia molto.Scusa, in modalità self service è centralizzata, quindi un developer trova tutto nello stesso luogo, è autonomo nell'avviarsi le pipeline, nel trattare gli ambienti, nel fare le cose che deve fare e soprattutto o lavoro dal progetto 1 o lavoro dal progetto 10 il posto dove lui esegue queste operazioni è tendenzialmente sempre lo stesso.Mi viene a questo punto una domanda parliamo di in qualche modo alleggerire il lavoro dei team di quei meccanismi che in qualche modo sarebbero sarebbero costosi e probabilmente non genererebbero del valore a prescindere in modo immediato quindi automatizzarli potrebbe rendere più snello il processo ma mi verrebbe da chiedere chiedere.Cazzo, io per anni ho spinto sul concetto del team multidisciplinare dove dentro c'hai un DevOps, uno sviluppatore, per anni io, per anni noi, per anni la comunità ha spinto verso quella direzione.Ci siamo tagliati le vene dicendo "You build it, you run it", se fossimo Obama a un comizio elettorale e adesso con questo nuovo approccio che poi è tanto nuovo, non è perché le grandi enterprise questo tipo d'approccio lo utilizzano da decenni, però stiamo di nuovo ricentralizzando una parte abbastanza importante e ci sta, fondamentalmente ci sta.Se non ci fosse però il rischio di quello che noi chiamiamo "one size fit all" cioè quello di centralizzare con un team o comunque delle risorse dedicate al platform engineering alcune soluzioni per standardizzarle, omologare, creare dei processi condivisi, in qualche modo rischia di spingerci a usare martello per stringere un bullone.Quindi dov'è la linea tale per cui, secondo voi, o almeno il modo per decidere dove mettere quella linea che dice "sopra questo livello possiamo condividere, possiamo delegare a una risorsa condivisa".Sotto a questo livello dobbiamo avere un ownership, dobbiamo gestirlo noi in casa.Parlo di team.ok vado io allora è un discorso molto complesso e super interessante allora partiamo un attimino dagli strumenti cioè gli strumenti per forza di cose lavoriamo abbastanza tutti abbastanza in questo settore da sapere che non esiste lo strumento per sempre quindi oggi uso kubernetes domani non lo so cosa cosa succederà oggi uso il framework specifico, la libreria specifica, domani...- Parli con uno che aveva fatto tutto il percorso di formazione su DCOS e poi arrivo a Kubernetes e Mauro butta nel cestino praticamente quell'anno e mezzo di studio.- Io il mio primo lavoro in assoluto ho iniziato con un linguaggio di formazione che non vi dico neanche qual è e il giorno in cui ho iniziato a lavorare è uscita una notizia per cui veniva deprecato da chi lo produceva.- Tranquilla abbiamo iniziato tutti con action script, non ti preoccupare.Esatto, nella specifica da lingua nel mio caso.Comunque, detto questo, cosa succede? Allora, partendo dai team multidisciplinari, ok, è una scelta tendenzialmente corretta come possono essere altre scelte, questo dipende un pochettino dall'organizzazione.Questa metodologia non sostituisce il team.Ora, vado sugli esempi pratici e concreti, così è anche più facile da capire.Un team dove all'interno un developer e un ops, semplifichiamo all'ennesima potenza.Il developer continuerà a scrivere il codice, l'ops continuerà a fare l'ops, quindi tutta la parte di automazione, aggiunta di nuovi tool, gestione di casi specifici, cioè tutta quella parte lì non è che magicamente viene risolta della metodologia, ma serviranno delle persone e delle figure chiave che vanno a risolvere problemi comuni all'interno dei team.Quindi quella è una cosa.Poi quando parliamo di progetti, semplifichiamo chiamandoli generalmente progetti, abbiamo sicuramente una parte di creazione di infrastruttura, una parte di creazione di codice da eseguire sull'infrastruttura e poi tutta una parte post dove ho l'infrastruttura, ho il codice che ci sta girando sopra, devo monitorare, si assicura che tutto va bene e quant'altro.In quel caso il team multidisciplinare è la scelta zecata, perché io non è che l'ops, ora chiunque faccia ops, vi voglio bene, non succederà, secondo me non è che gli ops li licenzi per quel platform engineering, anzi, io gli ops li prendo e li metto a fare tutta la parte di automazione, come abbiamo già detto, ma anche tutta la parte di gestione.Cioè l'infrastruttura non è che nasce dal nulla cresce sugli alberi, qualcuno dovrà gestirla.Quindi in un team multidisciplinare è quello che farebbero.L'unica piccola differenza è che io in mezzo a questi due tasselli posso aggiungere, se voglio, delle figure, diciamo professionali, potrebbero essere platform team, che prende le funzionalità comuni, non utili solo a quel progetto ma magari a tutto il resto dell'azienda, dei progetti in azienda e quant'altro, che possono prendere quelle singole funzionalità, quelle singole pipeline, quei singoli pacchetti, quei singoli microservizi magari creati per essere facilmente riutilizzabili e li staccano dal progetto specifico e li mettono in un bucket comune, se è possibile, e non sempre possibile, sia per questioni tecnologiche che per questioni magari legali, staccano la singola funzionalità, la singola cosa, la mettono in un bucket comune a disposizione la storia dell'azienda.Il nuovo team che ha necessità della pipeline specifica, del pacchetto specifico eccetera eccetera può attingere da quel bucket.Altra cosa importante è in generale quando si pensa a costruire una soluzione di questo tipo, quindi un IDP per soddisfare esigenze di platform engineering, è impossibile avere tutto al momento uno.Tutti i tool, le metode, diciamo, le librerie, le cose che ci sono online, fanno dei piccoli pezzi, ma alla fine non si adattano completamente, come qualsiasi altra cosa, a un'esigenza.Quindi, avere delle persone ad hoc che prendono le esigenze dall'azienda, quindi dicono "ok, qual è l'esigenza più grande che hanno i nostri developer oggi? La creazione di ambienti, perché ogni giorno dobbiamo creare mille ambienti a mano.Bene, automatizziamo quella, cioè partendo da queste fondamenta per poi renderci utili a tutto.Quindi non c'è una sostituzione di quello che esiste, è più che altro un ulteriore gradino che si va ad aggiungere a quello che oggi è DevOps, a quello che oggi è cercare di automatizzare ambienti di infrastruttura.Mi piace...no scusate, dai Graziana.Prima Mauro, il fatto di avere una piattaforma implica l'imposizione di qualcosa, secondo me è sbagliato vederla così, cioè non è il fatto di avere una piattaforma, allora è la gabbia dorata per cui gli sviluppatori o i team utilizzano solo quello che c'è all'interno di quella piattaforma Secondo me va vista più come un posto in cui tutto quello che è condivisibile è presente per essere riutilizzato e tutti gli edge case che i team incontrano è un buono spunto per evolvere la piattaforma, ma non sei obbligato ad utilizzare quello, hai comunque l'ownership del tuo lavoro, hai l'ownership della tua applicazione e puoi prendere delle strade diverse qualora sia oggettivamente utile prenderle.Una domanda, operativamente e proprio in pratica queste piattaforme che cosa offrono? In genere, cioè mi è chiaro che c'è un team che, insomma, come dicevo prima sono a digiuno della materia quindi c'è questo tassello che mi manca.Cos'è che offre operativamente parlando, proprio in pratica.Mi è chiaro che serve per automatizzare, ma offre qualche tool o qualche cosa specifica per AWS o Google Cloud, o è soltanto un posto dove tu metti le tue collection, le tue cose di Ansible, o non lo so, ci sono dei plugin, insomma come funziona proprio operativamente parlando.Mi è chiara questa parte.Ok, tu grazie.Allora è un'astrazione rispetto a tutti i tool di infrastruttura cloud provider che ci sono.Non è un tool specifico, ne esistono diversi e ogni azienda crea il suo.Ci sono anche diversi metodi di interazione.Tu potresti avere una piattaforma che ha un'interazione di tipo grafico, quindi un sito web dal quale tu accedi, sviluppatore, con i tuoi permessi, il tuo dominio applicativo e riesci a provisionare la tua infrastruttura che ti serve per l'ambiente di test, database XY, accedendo con la piattaforma lì.Poi se c'è sotto un Ansible, un Google Cloud, se puoi girare su Google Cloud, su AWS, su Azure potenzialmente potresti anche non saperlo.Ci sono altre piattaforme dove magari puoi accedere anche a livello di CLI piuttosto che script, piuttosto che avere permessi di accesso in maniera diversa.Dipende tutto da come è implementata la piattaforma, non c'è una soluzione comune o standard.vuoi aggiungere qualcosa? Sì, allora più che altro volevo razionalizzare un po' come hai detto e aggiungere dei piccoli tasselli perché secondo me la domanda di Luca era un pochettino più relativa a cosa offre una piattaforma di questo tipo poi immagino che la parte del cloud era un esempio cioè l'idea è questa qua cioè l'idea è tu hai una serie di attività da fare ok, dalla creazione di variabili d'ambiente, tutto quel mondo lì e la creazione di microservizi, la loro gestione, la decisione se esporli o no, tipo con un ingresso root, una API getter eccetera eccetera.Poi hai tutta la parte di deploy, tutta la parte di runtime, tutta la parte di visualizzazione di runtime, quindi diciamo tu hai il tuo ciclo di vita del software.La piattaforma dove si mette? La risposta ti direi è che dipende da quello che ti serve.ok quindi tendenzialmente tu potresti costruire una piattaforma che ti permette di creare delle variabili d'ambiente, inizializzare dei microservizi da template di codice e poi deployarli e li finisce.Potresti avere una parte dove deployato un microservizio taggato come "ready for production" lo puoi prendere, prendere quell'immagine di quel microservizio e metterla in un catalogo comune dove altri sviluppatori possono prendere le robe.Quindi cosa ci puoi fare? Tendenzialmente tutto quello che ha a che fare col ciclo di vita del software.Poi, chiaramente ogni organizzazione ha delle necessità diverse, quindi magari hai delle organizzazioni fortissime sulla parte di ops, ok? Quindi infrastrutture eccetera, magari un po' più carenti sulla parte del codice.Allora a quel punto cerchi di ottimizzare la piattaforma per aiutare i developer, ok? Oppure hai delle organizzazioni fortissime coi developer, secondo me è il caso anche più classico Però non così tanto forte, ad esempio su cloud E quindi che ne so, integrare un AWS piuttosto che un Google Cloud, Azure, e più ne ha più ne metta Può diventare una cosa complessa Allora, a quel punto cosa fai? standardizzi la connessione del tuo IDP con il cloud provider singolo e da quel momento in poi chiunque ha necessità di utilizzarlo può collegarsi al cloud provider e utilizzarlo.Poi se dobbiamo semplificare immaginarla come un sistema dove hai dei plug-in in termini di connettori che ti permettono poi di collegarti le tue cose.Ora siccome alcune volte può essere complicato se se mi date l'occasione faccio un esempio concreto, no? Una sviluppatore deve iniziare a creare il suo progetto ovviamente qualcuno ha già configurato delle cose quindi non parliamo del momento zero perché ovviamente poi diventa una discussione sull'analisi delle necessità e ve la dispermerai allora ipotizziamo che già c'è qualcosa una piattaforma tipo può funzionare in questo modo il sviluppatore ha necessità di avviare un nuovo progetto e quindi ho bisogno di un ambiente di development per iniziare a creare tutto ciò che mi serve la mettere online per poi verificare l'integrazione con il lavoro degli altri team Allora a quel punto entro sulla piattaforma, creo un nuovo ambiente, un nuovo progetto che chiamo X e in questo progetto aggiungo un ambiente che si chiama Development Cosa succede? Ovviamente io parlo anche di tecnologie specifiche, però dibattisco la tecnologia, prendiamola come una cosa a margine Ho bisogno di magari un cluster Kubernetes con un determinato namespace dentro poi una volta che io collego questa cosa lui mi gestisce un cluster che ho collegato e dentro questo cluster mi va a creare un namespace a quel punto ho il mio ambiente, ho una voce per aggiungere i nuovi microservizi quando clicco aggiungi microservizio in node.js, tipo una caso cosa succede? Lui magari mi genera già un template dove ho il mio index.js ma anche la mia pipeline già scritta, il Dockerfile, tutte quelle cose secondo gli standard di cui parlavamo prima con Mauro del circolo magico.A quel punto io scrivo il mio codice che è la parte per me sviluppatoria più importante, metto, creo le mie API, creo la mia business logic più generica eccetera eccetera, faccio commit e push del mio codice, quando faccio commit e push c'è il sistema di pipeline e i local files che erano già scritti quando ho creato il template che mi generano un'immagine.Quest'immagine nel momento in cui clicco deploy viene sostituita l'eventuale immagine con lo stesso nome già presente.Cosa succede? Tutti i log delle immagini vengono raccolti e messi da qualche parte, poi analizzati da un sistema comune eccetera eccetera.Quindi come flusso può immaginare questo qua.Dove mi vado ad attaccare io con questa metodologia? dove mi serve.Se non ho necessità di analizzare i log, perché ho il mio sistema proprietario, oppure io ho sempre fatto così, preferisco far così, non aggancio il sistema dei log.Se il mio obiettivo non è generare le immagini perché ce le ho già e io voglio semplicemente gestire gli ambienti e decidere quali immagini mettere all'interno degli ambienti, cosa faccio? Genero, crea un sistema o configura un sistema che mi permette di generare un nuovo ambiente e poi prendere le immagini e inserirle lì dove mi serve.Quindi è molto in base a quello che serve, oggi non esiste uno standard comune e spero di aver risposto alla domanda.Sì, mi è chiaro come metodologia e come, diciamo, punto d'arrivo.Mi riferivo anche alla parte pratica, a quello che deve costruire tutte queste automazioni, se ha qualche aiuto, delle mani piattaforme che si vendono, che si pubblicizzano come piattaforme di platform engineering, non so se si può dire così.Cioè capire, ok, dal punto di vista dello sviluppatore o dei team mi è chiarissimo, però a costruire tutte queste automazioni dove e in che modo magari alcuni servizi aiutano, se hanno dei plugin, se hanno delle connessioni, se hanno dei template già fatti? Non lo so, volevo sapere anche questa questa parte qui.Questo è più parte di Ops, ok? Il 90% di lei è Ops, quindi ad esempio tipo che ne so, dico sempre due a caso, poi ognuno avrà le sue preferite.Magari se usi GitHub Action, se usi GitLab con il suo run, tu hai già dei sistemi lì che ti permettono ad esempio, dato il push del codice, di creare la build e poi fare push dell'immagine su Nexus.Vado proprio su cose facili.Quindi cosa succede? Tu fai una collezione di queste cose e da un momento in poi tu, diciamo, ops, dici "ok, da oggi in poi tutte le pipeline che builderanno Node.js avranno questa definizione dell'immagine Docker, poi la posso cambiare e useranno tutti i GitLab Run per la build, Nexus ha questo indirizzo con questa convention per le cartelle per fare lo store degli artefatti e così via.Quindi tu cosa fai? Prendi in questo caso abbastanza facile un repository, ora la semplifichiamo all'inesia a potenza, prendi un repository Git o GitLab, una CI di GitLab, aggiungi che quando viene creato un nuovo repository deve sempre partire da un template specifico con alcuni file e alcune configurazioni già preimpostate, a questo aggiungi le variabili d'ambiente, secret, eccetera che ti possono servire per collegarti il tuo nexus, per collegare il sistema dove poi vai a fare lo store degli artefatti, e la semplificante andrà e hai creato un tuo primo sistema di platform engineering.Quindi da quel momento i tuoi sviluppatori, che dovranno creare un nuovo backend, un nuovo JS, clonano il template e avranno a disposizione la CI, il Dockerfile, la connessione già con Nexus, che magari già a sua volta è connesso col cluster dove fare girare le cose, eccetera.Quindi lato Ops il tuo scopo è configurare questa catena di tool che poi aggiorneranno le persone che lavorano la TOPS, quindi il tuo lavoro è più cercare di standardizzare quello che fai giorno per giorno.Se mi permettete io voglio fare questo tipo di puntualizzazione che dipende molto dal mio modo di vedere la platform engineering.Il platform engineering al di là dei tool come diceva Mitch.Io se dovessi pensare a un team di platform engineering penso a un team che ha una serie di responsabilità fondamentalmente quella di standardizzare ciò che è standardizzabile per cui e questo mi viene da altre esperienze pregresse mi è capitato di avere dei team di platform engineering con tre frontender che facevano lo UI kit che si occupavano dello UI kit condiviso tra tutti i prodotti e rilasciavano un pacchetto tutti potevano utilizzare e quello stando a quello che stiamo dicendo oggi è platform engineering perché perché fondamentalmente c'è l'automazione il fatto che comunque io non debba farlo manualmente e c'è il fatto di generare risorse condivise stessa cosa può capitare e capita e deve essere e deve capitare con lo scaffolding come diceva Mitch prima dei progetti che fondamentalmente può essere un template di github o di github non c'è bisogno di sto strumento lunare c'è un template per il micro servizi in node un template per l'applicazione in react adesso sto banalizzando no? dal quale fai nuovo prendi boom fatto ancora più figo è se buona parte di questo template sono pacchettini su npm che si aggiornano dove l'ownership di questa cosa va a finire nel team di platform engineering.Sto dicendo questo perché in realtà ci siamo fermati molto a parlare di operation, della parte riguardante poi tutto il processo di deploy, quando secondo me buona parte o una importante parte di complessità che tocca i developer e non gli ops.Buona parte di quella complessità sta ancora prima fondamentalmente di questo e devo dire che nei team dove questo succedeva era molto figo.C'era un problema, c'era un problema nel cercare di capire in quale punto della catena si va a posizionare l'orecchia, l'orecchio del platform team.Per esempio mi viene in mente per aggiungere un altro esempio su uno dei ruoli dei platform team molto figo è quello che faceva Anna Beltrami di Spotify che è venuta a trovarci, lei si occupava di ottimizzare Xcode.Si occupava di lavorare sulla configurazione di Xcode proprio per farlo andare più veloce e per fargli buildare nel modo migliore progetti di grandi dimensioni.Anche quello secondo me sta nel platform team che deve essere questa specie di team condiviso che risponde a queste esigenze condivise restituendo degli strumenti automatici.Qua però c'è una questione.Da una parte il platform team come diceva prima Amice Graziano in qualche modo lavora bottom up, quindi cerca da una parte di sintetizzare le esigenze comuni dei vari team trovando i punti di connessione e facendo sintesi con un elemento, un tool, strumento condiviso ok dall'altra però c'è anche un approccio bottom top down cioè famoso cerchio magico che abbiamo detto una volta che si decide di utilizzare SLint con una certa configurazione o si decide di deployare su un cluster configurato in un certo modo con un certo pattern nel namespace a quel punto quel modo si segue e quindi c'è una direttiva top down.Se tu non la segui mi devi fare gli ADR quindi gli architectural decision record o comunque dei decision record che dicano ok non sto seguendo questa linea perché ci sono queste esigenze specifiche questi sono i rischi.Altra cosa importante il risk management è fondamentale in questo.Però detto questo a questo punto, siccome voglio arrivarci dopo ai tool, perché mi sto divertendo con una serie di tool in questo periodo.Detto questo però, a questo punto penso ai costi.Mi è capitato di lavorare in contesti Enterprise con la E maiuscola col cravattino e la giacca, dove in realtà quello che succedeva è che ogni team aveva un certo budget, proprio come i coins, diciamo dei coins, ogni team aveva un certo budget per allocare risorse nel platform team.E alla fine quando succede questo in realtà il platform team, l'elemento centralizzato il quale vai a chiedere "bottom up" una certa cosa, diventa un ostacolo rispetto ad avere risorse nel team per fartelo.Allora la mia domanda è, dopo questa premessa di un quarto d'ora, dov'è che tiriamo la linea tale per cui diciamo che è proficuo avere un platform team e non è proficuo.Non so se mi sono spiegato.Allora è una domanda di quelle che meriterebbe tre episodi solo lei, però possiamo cercare di semplificarla.Semplificare non la domanda ma la risposta.Allora il discorso che cos'è? E' che dipende come approcci il problema.Cioè se tu il problema lo approcci per la serie il platform team è un'entità slegata dal resto del mondo la stiamo estremizzando volutamente.Per cui i developer chiedono il platform team e gli ops chiedono il platform team e loro hanno la loro coda di cose da fare e iniziano a farle e quando hanno capacity le fanno, quando non ce l'hanno rinviano.Ovviamente lì, secondo me, si sta mettendo già in un mare di guai, ma ancora prima a ripartire.L'idea dovrebbe essere che chiaramente hai un team centrale che coordina le attività di tutti, perché se no è complicato.Chiamiamo lo team centrale persone di riferimento, comunque qualcuno che centralmente gestisce e definisce un po' che cosa è comune e cosa non lo è.Ma la responsabilità di creare le cose non dovrebbe essere mai isolata a un solo gruppo, dovrebbe essere magari incentivata su quel gruppo ma condivisa da tutti.Quindi faccio l'esempio concreto.L'esempio concreto è io ho necessità della funzionalità, chiedo alla Platform Engineering Team e loro mi dicono due di picche perché purtroppo siamo pieni, abbiamo altre urgenze da quel lato, non possiamo supportarti.Ok? Poi si potrebbe fare il discorso "cos'è una priorità, lo è veramente...facciamo che tutto è coerente e corretto con quel momento specifico a quel punto cosa succede? succede che il team che richiede la funzionalità dovrebbe essere il primo a contribuire a rendere disponibile quella funzionalità quindi io ho necessità di aggiungere questa nuova funzionalità alla piattaforma piuttosto che gestire questo caso specifico cosa faccio? lo scrivo, magari non perfettamente come potrebbe fare il team di platform che avrà delle competenze diverse ma lo scrivo, lo utilizzo e poi lo rendo disponibile quindi è un pochettino di grande organizzazione open source se ci pensi dove tu hai un team centrale di maintainer che ovviamente ti forniscono delle cose se vuoi puoi forcare e contribuire tu, fare i tuoi esperimenti e utilizzare come meglio credi il codice che hai forcato e quando il contenuto è rilevante, rimandarlo indietro per contribuire al progetto più grande.Hai detto una cosa bellissima, verrei là a Milano per darti un bacio sulla fronte, amici, perché in realtà nelle tue parole si leggeva una parola importante che è la parola ownership e c'è questo shifting di ownership che è fondamentale.Ripeto, nei progetti che ho fatto in grandi aziende dove diciamo che la grande azienda orizzontale io non l'ho ancora vista, non so voi ma quando iniziano e iniziamo ad avere più di 300 sviluppatori, 400 sviluppatori, 500 sviluppatori, alla fine il meccanismo dei silo appare per forza volente o nolente.A questo punto però capita per esempio che immaginiamo un contesto dove abbiamo dei team che stavano lavorando su questi microservizi, microservizi in java o in java mettiamo in javascript che mi viene più facile, microservizi in javascript e uno vuole fare una cosa vuole fare il monolita diviso, uno vuole fare microservizi, uno vuole usare una libreria di validazione A, l'altro voglio usare la libreria di validazione B.Allora quello che capita se ci sono dei team intelligenti è tavolo, tavola rotonda e si dice ok andiamo in questa direzione.Perfetto andiamo in questa direzione prendiamo questa decisione ma chi è l'owner di questa linea? Pensiamo all'SLint della situazione.Chi è l'owner dell'SLint condiviso tra tutti questi team? Non esiste! Esiste se esiste un platform team che magari tu lo crei il progetto poi il platform team lo eredita e si occuperà di fare da let's say maintainer open source quindi a metà tra un team di prodotto con tanti prodottini ok che mantiene che sviluppa seguendo le esigenze vari stakeholder che sono gli sviluppatori no? e ne diventa owner quindi quella decisione condivisa che stava nell'aria fino a ieri o negli diario che nessuno legge che ognuno forca, brancia come meglio crede ok? a quel punto viene centralizzata e mantenuta centralizzata sempre lasciando come dicevate voi lo spazio al team specifico di decidere di prendere un'altra via magari non sviluppa in javascript sviluppa in rust perché ha bisogno di microservizi super performanti quindi si creerà il nuovo microservizio in rust se nasce l'esigenza n+1 di un altro microservizio in rust è capace che se abbiamo un platform team un product owner del platform team un sperdonatemi un product manager del platform team con le antenne parate allora il product manager dirà attenzione sto vedendo un adoption un po più alta di Rust.Che facciamo ragazzi? Lo mettiamo nel backlog di creare uno scaffolder per il progetto Rust.Poi a questo punto ci sono strumenti più o meno facili.Io cito i miei, so che anche voi ne avete qualcuno e mi piacerebbe anche citarlo.Io parlo della mia esperienza dai template di Gitlab/GitHub a il bottoncino su backstage per fare lo scaffolding di un nuovo progetto, cioè a quel punto il platform team gestisce anche queste cose, per cui davvero diventa molto figo, calco il pulsante e c'ho il progetto creato, come dicevamo.Però la cosa importante è che c'ho uno, un team, se c'è da mergiare, la dico banale, gli update di Dependabot lo fa e se c'è da fare il bump a una major che rischia di rompere qualcosa si prende l'ownership di dire ok io devo fare il bump alla major notifico tutti gli utenti tutti i team che stanno usando quel microservice gli faccio mettere l'update in backlog e a quel punto aggiorno, per esempio.E a quel punto è là che ha senso un platform team.Al di là poi della parte ops che è un po' più lontana da me.No, no, no.Però puoi immaginare la parte ops, puoi immaginarla uguale ma speculata.Ok, cambia la tecnologia, cambia il perché, cambia le cose, ma la metodologia è quella lì.Quindi un team di platform engineering me l'immagino idealmente metà dev e metà ops, ognuno che interagisce col suo lato, cioè con l'organization.Tra l'altro, scusami, voglio aggiungere questa cosa perché stavi parlando di composizione del team e per me è importante.Tra l'altro ho visto che alcuni contesti veramente produttivi, e io parlo di una mia esperienza in una startup americana come cliente molto interessante, periodicamente fanno tornare gli sviluppatori dei team all'interno del platform team e questa è una cosa bellissima perché? Perché tu non ti stai solo portando uno sviluppatore al quale stai dando consapevolezza di quella che è la platform e quindi sarà un utente migliore della platform stessa.Ma ti stai portando uno stakeholder, un "cliente" all'interno degli stand up, all'interno del grooming, all'interno delle fasi di priorizzazione del backlog, di decisione delle feature che è un cliente c'è una figata perché il valore che aggiunge è anche quello assolutamente se ti dirò che non è banale neanche il contrario cioè prendere di tanto in tanto qualcuno del team di platform e metterlo su team chiamiamoli di produzione ok perché si vanno a scontrare con una serie di problematiche e modi di vedere anche la loro creatura totalmente diversi da quelli che immaginavano.Infatti una cosa estremamente importante in tutto questo contesto è il fatto del...è vero che alcune decisioni vanno prese dall'alto al basso, ma la maggior parte delle decisioni devono essere prese dal basso, quindi devi ascoltare le esigenze chi utilizzerà la piattaforma e di tutte le cose che quella piattaforma farà, che siano veramente utili.Perché spesso, se le decisioni non vengono prese da chi le cose le fa, rischi di interpretarle male.Risolvere il problema sbagliato sostanzialmente.Esatto, magari risolvere un problema che non è un problema, capito? Cioè capita più di quanto posttroppo immaginiamo tutti.Quindi in generale avere cambi di questo tipo sia da un lato che dall'altro, fare in modo che non ci sia una chiusura.Non è perché stai dividendo le aree e quindi hai un team di sviluppo, un team di team di platform, allora stai mettendo delle muraglie cinesi per cui tra loro non devono cooperare per là, se anzi la cooperazione deve avvenire su più fronti e in più maniere.Potrebbe essere banalmente l'esempio che facevo prima di contributo al modello tipo come se fosse un modello open source, sono riunioni costanti, feedback loop e tutto quel mondo Quindi non è sicuramente un approccio semplice come non lo sono stati in bastato altri approcci, altre metodologie che sono arrivate nel corso del tempo.Ma la differenza tra metodologia DevOps, perché alla fine anche DevOps è una metodologia, e platform engineering, perché prima parlavi che hai nominato separatamente i dev e gli ops e le messe insieme, però appunto mi è riecheggiato alla mente il fatto che alla fine c'era tutta la metodologia dev ops insieme alla agile che alla fine fa sostanzialmente risolvere lo stesso problema.Qual è il tassello che manca? Non so se vuole andare a Graziano, io sto monopolizzando questa chiacchierata.Vai poi magari mi aggiungo.Ok allora tu devi immaginarla così, l'Ops, diciamo DevOps, ha come obiettivo principale quello di cercare di automatizzare i processi, ok? Automatizzarli tra piccoli step eccetera eccetera è agile, ok? Queste fondamentalmente diciamo sono le due cose che hai nominato.Il Plus del Plus One Engineering che non è un sostituto a DevOps, non è il DevOps è morto, platform engineering è una cosa nuova, ma è semplicemente un gradino in più.Aggiungi ulteriori tasselli.Gli ulteriori tasselli sono praticamente questi qua.Beh, automatizzare già lo facevamo.Feedback continuo di loop e di miglioramento delle singole cose, quindi lavorare a piccoli step agile.Può essere la metodologia agile o per cicli di rilasci più brevi, è un'altra cosa che c'è.Poi c'è il centralizzare le cose, quindi cercare di avere tutto nello stesso luogo, il cercare di rendere tutto self service, perché la metodologia DevOps non aveva un approccio per cui il developer era autonomo nel creare un nuovo progetto, ma un DevOps, chi faceva DevOps, creava un nuovo progetto, inseriva le logiche per cui da quel momento in poi il developer sarebbe stato autonomo nel crearsi il branch, farle modifiche, mergeare e avere la pipeline magari di rilascio, ma in maniera un po' subordinata al lavoro iniziale che dovrà fare l'office.Ok, invece il platform engineering fa sì che questa cosa, oltre a tutte le cose che abbiamo detto prima, sia automatica.Altre cose, ovviamente deve renderlo semplice, perché se abbiamo detto che una delle cose che vogliamo risolvere è non avere carico cognitivo aggiuntivo sugli sviluppatori che non vogliono, ora sto esagerando, sapere come funziona il DevOps.Allora questa cosa deve essere anche semplice da utilizzare, non deve essere complessa, quindi al più accedo al portale web come diceva Tiraziano prima oppure una Klee, ma io non voglio sapere come funzionano le pipeline se sono scritte su Jenkins o su Azure o su GitHub Action.Io voglio fare in modo che per lo sviluppatore questa cosa sia trasparente così come in parte vorrei che per lo sviluppatore fosse trasparente dove va a deployare perché ora la semplifico in un ambiente in un mondo di microservizi il fatto che tu oggi deploy su cloud provider 1 o cloud provider 2 cambia quello che vai a fare cambia non poco devi conoscere il pannello di quel cloud provider i prodotti che ti offre eccetera anche se poi il codice che ci vai a metà sopra è uguale ok diciamo 90 per cento è uguale 10 per cento cambia il cloud provider non sarebbe molto bello sul developer quel 10 per cento di differenza tra deployare su google azure ews o qualsiasi altro cloud provider sia trasparente cioè per me o lo deploy su AWS o su Google cambia zero perché i miei microservizi funzionano sia lì che lì ovviamente quel 10% non è che è magia e viene fatto in automatico ma serve qualcuno, in questo caso Ops, che metta 6 metà stelle e fa in modo che la soluzione funzioni più o meno ovunque.Non so se ho risposto Luca però parliamo eventualmente.Se no mi chiaro la promessa, ecco diciamo Io però mentre parlavi tu dipingevi questa metodologia, questo approccio come ottimo per gli sviluppatori, cazzo a me veneva la pelle d'oca.Ti spiego perché dal mio punto di vista.Mi sento più architect che developer oggi, quindi probabilmente non fitto bene nei vestiti di questa situazione, però pensare, adesso l'estremizzo volontariamente la cosa, di arrivare, entrare nel mio portale dell'IDP, internal developer platform e poi vorrei che ci fermassimo un attimo, provassimo a fare esempi anche di tool, di strumenti, di prodotti che possiamo utilizzare di idee di configurazione però entrare là cliccare un pulsante ok crea il mio microservizio in node io con un pulsante che nel micro servizio poi noi lo sappiamo tutti tutti i nostri servizi tutte le nostre applicazioni sono crude mascherato da applicazione complicata le righe di business logic sono sei adesso sto banalizzando però non è molto lontano non è una realtà sta cosa è sono 6 e il resto è scaffolding e cose varie quindi io clicco il pulsante o il microservizio scrivo le mie 6 rig di cose perché il crude è automatizzato perché c'è una libreria del crude fatta dal platform engineering team scrivo le mie due funzioni di business logic con un pulsante deploy per il business bellissimo perché quel microservizio è costato due noccioline e mezzo rispetto ai 15 giorni di lavoro e poi io a quel punto subito la mia application io voglio andare nel developer platform nel developer platform team perché almeno la mi diverto almeno la gioco con giocattoli nuovi almeno la faccio cose un pochino più complesse quindi in realtà a livello manageriale questa cosa funziona a bombazza proprio cioè ottimizzazione delle risorse vai rilasci rapido cool a livello dello sviluppatore però nel contempo mi dico e adesso io se voglio giocare con qualcosa interessante devo entrare necessariamente in quel team perché altrimenti io devo scrivere sette righe di business logic e poi mi sparo in bocca perché alla quindicesima riga di business logic voglio morire Allora, è chiaro il discorso, io qui anziché rispondere alla tua domanda la prendo un po' per la tangente.Quante volte nella tua vita ti è capitato di rifare mille volte la stessa roba noiosa come non mai, la diciamo pulita? Semplicemente perché il progetto era nuovo.Ora, l'esempio che faccio da un bando è "social login".Io ne avrò scritti almeno 50 nella mia vita.Ma almeno, ok? Perché ogni cliente lo voleva leggermente diverso, ogni cliente doveva ripartire da zero perché per accordi il codice...mille volte, ok? La prima volta è stata divertente, la seconda, ok, dai, l'abbiamo fatto meglio la terza.Dalla terza in poi è diventata una tortura, perché io prendevo un giorno, due giorni, all'inizio magari 5-6 giorni, poi piano piano più ne scrivevo e più diventavo veloce, fino ad uscire a farlo, a doverlo fare con le mani dietro la schiena in una giornata.Ogni volta che andavo col task io lo guardavo e pensavo "ma mannaggia a me che devo fare queste robe".Quindi è vero quello che dici, alcune cose le trovi fatte, però nelle organizzazioni serie, cioè nelle aziende serie, tu hai tenuntalmente due tipi di task.Il task che il developer conosce bene, ripetitivo eccetera eccetera, che banalmente potrebbe essere anche quello che dicevi tu, no? Creare un CRUD.Cioè dopo che hai creato il primo nella tua vita, il secondo, il terzo lo devi fare perché lo devi fare, ma tutti ce lo eviteremmo volentieri.Poi invece esistono un sacco di cose veramente fighe da fare, che sono poi la parte, non so come dirlo, la parte che differenzia un progetto dall'altro, perché se tutti i progetti fossero un social login e un crud, il mondo sarebbe finito lì.Ma tutti i progetti sono un crud mascherato da progetto dai sto scherzando Mitch no no ci sono sicuramente sicuramente sono due parti importanti però secondo me la parte differenziale non è scrivere il crud e scrivere quelle sette righe che tu scherzavi prima di business logic attorno no? quelle sette righe una cosa che tu devi scrivere ora la semplifico tu socialoghi in due giorni crud due giorni business logic un giorno.In cinque giorni hai fatto questo social login col crud e quelle sette righe di business logic.Se io mi risparmio i due giorni di crud, i due giorni di social login e io anziché avere un giorno, perché magari stiamo dicendo sette righe, quelle poche righe di business logic, facendole di fretta e attaccate con gli stuzzicadenti che non sai come funziona il servizio dei posti dedicaci il doppio del tempo ipotizzare il doppio per l'azienda già guadagnato 60 per cento ok facciamo 60 per cento guadagno l'azienda e il 20 per cento lo guadagno io in quel 20 per cento io posso scrivere test che io è una cosa che auguro di fare a tutti ma poi sappiamo purtroppo come finisce no cioè si parte con le migliaia di attenzioni per la scadenza viva e le migliori intenzioni vanno via.Scrivere la documentazione, commentare il codice, scrivere il codice esplicificativo anziché scrivere variabili come x, y, z, cose che abbiamo fatto tutti noi.Io sfido chiunque a dire che nella mia vita non ho mai...ho sempre scritto i test, tutti li abbiamo fatti.Però se tu hai la possibilità di rimuovere delle robe ripetitive che fai costantemente, probabilmente noiose, e sostituirele con delle parti più diversificate, questa cosa non è male.Scusate, aggiungo anche il fatto che non è che perché il social login l'hai scritto deve rimanere quello per la vita, ok? Magari se cambia la tecnologia con lo devi riscrivere e lo riscriverai, ma lo riscrivi una volta, la seconda volta ripassi e lo sistemi, la terza volta non lo riscrivi, usi quello che già hai fatto.Sì, il discorso è che in realtà io l'ho banalizzata forse un po' troppo, e hai ragione, però c'è anche tutta una parte di rendere trasparente meccanismi.Per come sono fatto io mi piace sapere tutto, cioè io quando deploio adesso pur trovandomi in un ambiente enterprise sono andata a vedermi cosa fa quell'ELM file che io compilo, per vedere in realtà cosa sto tirando su.Non sono un ops, scrivo del codice, però sono andato a vedermelo per avere quel livello di consapevolezza tale per cui dico ok allora succede questo per cui qualunque sviluppo una ownership di un certo tipo automatizzando e rendendo trasparenti tutti questi layer o tu fai tornare gli sviluppatori all'interno del platform team e quindi spredi knowledge, spredi conoscenza, distribuisci conoscenza altrimenti ti ritrovi in una condizione e ho visto succedere anche questo e questo è quello che succede in molti consultifici ti trovi della gente super specializzata in scrivere il controller di spring cioè gente che la mattina si alza non scrive business logic il suo compito è scrivere il controller nient'altro nient'altro perché tutto il resto è automatizzato importi qua importi lì loro devono solo scrivere quel pezzo e quindi non diventa più una cosa del let's say artigiano che utilizza i pezzi assemble i pezzi e compone la sua opera d'arte coi pezzi ma diventa più un operatore alla Charlie Chaplin in tempi moderni che rischia di essere frustrante e secondo me la responsabilità è di come il management vede il platform engineering e il platform engineering rischia di essere o uno strumento potenziatore, un moltiplicatore o rischia di essere uno di quei processi di industrializzazione definiti con la "i" minuscola, dell'industrializzazione, della iperspecializzazione più becerai, più schifosa, dei famosi tuta blu.Noi prima, ieri, eravamo dei colletti bianchi, rischiamo di diventare delle tute blu a scrivere il...lo so sto parlando troppo da sindacalista, mi taccio, perdonate.Però in realtà è una questione anche politica.Ecco, voglio arrivare qua.Il platform engineering è anche una questione politica.Sì, esatto.È un po' in questo caso un problema quando vedi la standardizzazione come lo fuscare le cose.rendo disponibile l'utilizzo di certe cose già fatte, ma non ti nascondo come vengono fatte.Come dicevi prima, anche il turning dei developer tra i team di produzione e i team di platform engineering aiuta allo sharing della conoscenza, ma anche come il platform team si approccia, ad esempio, alla raccolta dei feedback degli altri team, ad esempio per capire cosa fanno determinati team come lo fanno banalmente potrebbero organizzare degli hackathon insieme per capire come si approccia a quell'applicazione con quelle tecnologie ops piuttosto che infrastrutture e quant'altro.È chiaro che poi il bello di questa metodologia, che è anche il brutto, è che io ti metto a disposizione tutta una serie di astrazioni, tutto dipende da quanto le offuschi quanto no.E anche a livello di chi poi utilizza queste cose, puoi avere il developer che arriva lì e utilizza quello che gli viene dato senza fare il passo oltre, come puoi avere quello curioso che inizia a utilizzare quello che gli viene fornito, approfondisce quello che sta utilizzando e magari contribuisce anche alla piattaforma.questo sarà corretto e metto l'accento su una cosa super super importante che è quello del fatto del ora fatta uscire anche la mia parte sindacalista così andiamo a scioperare insieme.Compagni dei campi! Ricordiamo che vediamo le magliette video terminalista metal meccanico rossa con tutti i simboli del caso.Vai Mieci, scusa.Ma poi mettete la cosa pubblicità in questi momenti oppure è proprio occulta? - è occulta ovviamente - questa è una cosa estremamente importante, se ne potrebbe parlare tanto, però le persone sono al centro di questa roba e quindi se tu crei e astrai troppo hai sicuramente un vantaggio all'inizio ma le persone le cose che non capiscono poi non possono neanche sistemarle quando non funzionano non so come dire cioè se tu crei una black box e lo sviluppatore da fuori della black box invia un messaggio e dalla black box fare i fuochi d'artificio fin quando tutto funziona magari anche figo ma se lo sviluppatore clicca e i fuochi d'artificio non partono.Ci inizia a smartellare là fuori un bordello.Esatto, quindi l'idea non è vendere trasparente nel senso del black box, cioè lo sviluppatore deve vedere cosa succede, deve vedere i componenti, dove si trovano, l'infrastruttura, come viene creata, le pipeline con cui vengono create le cose.Quindi deve avere tutti gli strumenti che gli permettono di essere curioso e anche di poter poi fare del lavoro in più quando serve, quindi debuggare, trovare...ma nei momenti classici, standard, di creazione di un servizio, di un ambiente eccetera, può non preoccuparsene.Poi se succede il dramma ha la possibilità di aprire questa scatola, andare a vedere che cosa c'è dentro, come le cose vengono attaccate...e magari anche di fare una pure questo per sistemarla.Esatto, tu che era la cosa che dicevo prima cioè se io sviluppatore chiedo al team di platform engineering sai, allora semplifichiamo, quando creo l'ambiente non me ne serve uno, me ne serviranno sempre due, perché non ce l'ho il motivo in realtà, proprio un esempio del cavolo, me ne serviranno sempre due.Boh, tra il team di platform engineering c'è fra un anno avrai questa modifica, ma come? Devo cambiare una variabile probabilmente da qualche parte o eseguire due volte una funzione che faccio mi apro la black box mi guardo dove il punto che mi interessa e a quel punto applico la modifica magari nella black box la modifica la devo applicare su un pezzo di codice allora sarà il developer a fare questa cosa magari la devo applicare scusate devops semplifico a una pipeline e quindi magari è il devops che lo va a modificare magari è una variabile su un vault e quindi sarà il tizio che si occupa di infrastruttura, sicurezza, non lo so però tutti devono essere in grado di aprire la black box e soprattutto di richiuderla aggiungendo cose, ampliandoci ecc aggiungo che questo è un interessantissimo talk, secondo me c'è anche la registrazione da qualche parte altri due colleghi, si chiamano Nick Cambiaso e Francesca Carta, il talk si chiama "Platform Engineering is not about tech" e parlano proprio di tutti questi aspetti, cioè del fatto che il platform engineering è una metodologia a servizio delle persone e se non tieni conto delle persone quando anche solo pensi di metterlo su, il 99% sarà un gran bagno di sangue.Vedo che il tempo sta volando però voglio fare un passaggio rapido sull'Internal Developer Platform Facendo un paio di domande proprio a brucio a pelo, abbiamo grosso modo spiegato che cos'è un Internal Developer Platform chiamato anche IDP ma mi interessava provare a capire sulla pratica quali sono le componenti che vanno poi a costituire un idp? ok quindi non te le spiego vado solo rapido così se avete dubbi come dire la prossima, sicuramente prima di tutto ti serve qualcosa per gestire permessi quindi tu utenti diversi all'interno di un idp devono poter fare cose diverse perché se no il rischio di metterti davanti problemi enormi è grande ad esempio se tutti se tutti i developer possono deployare facilmente cliccando un bottone anche per sbaglio in produzione capisci bene che il rischio di fare danni enormi è altissimo quindi serve avere sistemi che ti permettono di gestire l'autenticazione potrebbe essere app, active directory e migliaia di altre robe e sistemi che ti permettono di gestire permesse e quindi autorizzazione.Potrebbero essere sistemi di RBAC, di ABAC eccetera eccetera.Se volete un progetto open source si chiama ROND, ok? Praticamente è un sidecar container basato su opa e che permette di gestire rmax fondamentalmente.Poi mi mandi i link di queste cose per favore? Assolutamente questo ad esempio può essere un componente base molto importante quindi la possibilità di abilitare o disabilitare i bottoni in base al permesso.Dai grazie facciamo uno l'uno.Ok successivamente poi dipende molto dal tipo di piattaforma tutta la parte di componentistica a livello di API per l'automatizzazione dell'infrastruttura che si va ad interfacciare con i vari servizi che possono essere di cloud provider, di storage, di networking, di messaging, di database, poi a seconda di qual è lo scopo che ne fai della piattaforma puoi avere la necessità di provisionare un run time ma non la necessità di creare self-service database, quindi dipende molto da quello.Tutta la parte di automazione di test, build, pipeline e quant'altro, observability, storage degli artefatti...Vai tu, Mitch.Sì, ok, più che altro voglio dare qualche nome ai Tecnogenials, in bianco, su tutta la parte di pipeline le conosciamo.C'è GitLab, c'è GitHub, c'è Azure, che offrono dei servizi a Jenkins, se preferite avere qualcosa di ancora un po' più esterno.Quindi con quello ad esempio puoi gestire tutta la parte di operation, cioè tutta la parte di conservazione di chiavi che può essere estremamente importante.Quindi se hai developer diversi che hanno necessità di deployare, magari avere accesso a informazioni riservate senza pubblicarle su pipeline pubblica eccetera ci sono sistemi tipo volt ma anche github ne ha uno suo si chiama github volt se non sbaglio e quindi anche lì fai scegliere lo strumento è molto complesso perché oggi ci sono tanti strumenti che permettono di fare le cose e ad esempio tutta la parte di interfaccia se parliamo di kubernetes e questo può valere o non valere se kubernetes hai bisogno di un ingress api, gateway eccetera eccetera se vai sul landscape della scienzia app ci mettono in minimo 40 che fanno sta roba se ti dovessi dirne due che secondo me può andarla pena valerla pena utilizzare è uno facile che tutti conosciamo che può fare questa cosa è nginx quindi scrivi le tue regole lì magari fai in modo di automatizzarle e poi puoi ridirigere le chiamate esterne al tuo cluster interno se ne vuoi uno un po' più avanzato, un po' più...come dire...infiocchettato, però che fa tante cose interessanti, ad esempio c'è Envoy anche qui, mille scelte poi Envoy in realtà permette di fare tante cose e permette di farne così tante che sono andati migliaia di progetti che sono un subset di Envoy, quindi vari grubo emissari ecc.Creazione di infrastruttura può essere un altro problema importante, e quindi ci sono i vari Terraform e compagnie belle, io vado tutte con la maglietta già così.Insomma, tutta la parte di raccolta metriche, log, ecc, c'è lo stack, loci, grafano, occhibano, in funzione di quello che si vuole utilizzare.Comunque, c'è tecnologia e ce ne sono tante, pezzi che possono comportare un portale ce ne sono tante.Sul discorso di catalog, quindi catalogo di servizi, ci sono tanti portali che già offrono sistemi simili, prendi backstage, parlavi prima del sistema di scaffolding, sono comunque alternative.La vera sfida oggi, infatti, secondo me non è tanto trovare il tool che ti risolve il problema, ma è riuscire a metterlo insieme nella catena con gli altri tool.cioè quella è la parte difficile ed è quello il motivo per cui molte aziende, per cui la nostra, spingono su alcune cose tipo parlare del problema, mettersi lì a analizzare quali sono i casi specifici eccetera eccetera.Sì è chiaro lo diciamo anche a sua volta un po' di episodi fa con Francesco Cordi che all'epoca era il product manager di backstage cioè prima di installare backstage cerca di capire cosa ti ti ti ti ti qual è la tua situazione qual è il tuo contesto no? Perché come come dicevi tu prima il platform engineering non è una roba strettamente tecnica e più organizzazionale si può dire, non so come si dice, organizzativa, e quindi serve un punto di vista un pochino più olistico che l'approccio del tech guy che dice "fa scemo così perché backstage salvo poi ti ritrovi a installare 70 plugin e usi 3 e quei 3 che stai usando li hai anche configurati male perché non fittano il tuo use case.Quali sono a questo punto, uno l'ho già detto, ma quali sono i rischi di utilizzare un IDP? Cioè i tranelli, i problemi che si possono manifestare nell'utilizzo di questi strumenti? Allora scusa prima di partire con questo lascio poi la risposta graziano ma io volevo nominare un altro tool che per me è straimportante che si chiama Cube Green.Se non lo conoscete è una cosa fighissima questo è sviluppato da un collega che si chiama Davide Bianchi e ultimamente se ne parla tantissimo in giro che spegne sostanzialmente i namespace quando non ti servono.Per una questione energetica e quindi di benessere ambientale visto che viva a Milano che è la terza città pinguinata al mondo come dire male non fa ma soprattutto ha anche una questione di costi quindi è un progetto estremamente bello scusa è un pezzo della domanda di prima ma ci tenevo a dirlo no no no assolutamente sì no parlavamo dei dei dei rischi che si nascondono rischi barra problemi che si nascondono nell'adozione di un IDP? Allora, in realtà ne abbiamo citati alcuni anche prima, vedi ad esempio il costruire quella gabbia dorata per cui la gente che utilizza solo la piattaforma poi alla fine non sa cosa c'è dietro quindi rischia di diventare un collo di bottiglia con la piattaforma nel caso in cui non dovesse funzionare.Altro problema che banalmente potrebbe venirsi a creare in questa fase di costruzione è andare ad astrarre troppo quello che si va ad automatizzare, quindi non dare più un contesto rispetto a quello che si sta andando ad utilizzare agli sviluppatori, piuttosto che non avere un rapporto con gli utilizzatori finali, il platform team non mantiene un rapporto con i sviluppatori finali che poi vanno ad utilizzare quello che alla fine è un prodotto vero e proprio interno e quindi andare a costruire qualcosa che non viene effettivamente utilizzato, quindi sprecare sostanzialmente delle risorse, sprecare delle tecnologie per costruire qualcosa che non ha un fine, perché nessuno lo utilizza.Come dicevamo prima, come diceva Mitch, è una metodologia che si basa sulle persone, quindi la comunicazione è importante è costruire qualcosa per il solo mero benefit di andare a automatizzare un certo tipo di tecnologia, perché la tecnologia del momento non ha senso se poi non si va a fare advocacy della platforma affinché venga utilizzata internamente nell'azienda.È un po' come, fammi fare una metafora un po' magari azzardata.Costruire una super cucina, super attrezzata con gli utensili di ultima generazione ma poi ti dimentichi di andare a invitare i cuochi a cucinare.Magari comincia con prendi i cuochi, capisci cosa li servono, magari loro serve solo il coltello, non li compri il bimbi che poi possono già fare e non li serve.Quindi Astraea automatizza quello che serve e non quello che potenzialmente potrebbe servire fra cinque anni, sei anni.Essere attuali su quello che serve in questo momento.Questi sono i primi che mi vengono in mente così pensandoci al volo.Tu Mitch, hai qualcosa da aggiungere? Una cosa bellissima, la metafora sarebbe stata fantastica se dicevi qualcosa tipo "comprare fornelli più buoni del mondo e poi invitare tipo sushi chef o cose così.Comunque le due cose secondo me più pericolose in generale sono l'aggiornamento tecnologico, perché noi oggi abbiamo parlato di alcuni tool che hanno delle vite proprie, quindi le pieghe ha una sua vita, ci sono team che ci lavorano e lo aggiornano con una frequenza.Kubernetes, ne abbiamo detto un altro, è aggiornato con una certa frequenza e tutti questi tool subiscono cambiamenti più o meno costanti, non passano due o tre mesi senza un cambiamento, quindi secondo me uno dei grossissimi rischi è costruire qualcosa, poi dimenticarsi di aggiornarlo e ritrovarsi dopo due annetti da aver costruito la cosa perfetta con tutte le integrazioni che si spaccano malissimo e pariendo a dover ricostruire tutto da zero.Queste le cose non dico vissute, ma ne ho viste di storie così non banali.La seconda cosa, che è un po' cattivo di rimarcare quello che avevi detto, è far le cose senza effettivamente passarle alle persone.Questa secondo me è forse la cosa più importante.Se poi ne dovessi dire altre, io è adottare metodologie di questo tipo in contesti in cui non ne hai bisogno, è un altro grosso grosso errore problema.Ribadisco, ho fatto l'esempio all'inizio, se siete due persone attorno a un tavolo, montarvi il vostro personale dp per il vostro singolo progetto probabilmente non ha senso, perché vi costa molto di più di prendere e realizzare il progetto a mano.Quindi, tendenzialmente, metterei sottovalutare la tecnologia, sottovalutare o sovravalutare la necessità e sottovalutare l'importanza delle persone.Anche perché sappiamo che, soprattutto da top persone, trovare delle persone di talento difficile oggi, molto molto difficile, farle andare via perché si prendono decisioni sbagliate su delle cose che li riguardano secondo me proprio da stupidi.A questo punto guardando l'orario mi viene da dire Luca hai qualche ultima domanda? No penso di averle fatte tutte.Sì no volevo soltanto aggiungere una piccola cosa oltre al fatto di, giusto per parlare di esperienza vissuta perché bene o male non si parlava di platform engineering, però qualche automazione, qualche cosa, l'automazione self-service si è fatta durante il corso della vita, quella di stare attenti a non risolvere il problema sbagliato e di avere, questo lo volevo dire prima ma poi non sono riuscito a inserirmi, un po' di disciplina nel contribuire, questo l'avevate detto, a migliorare la piattaforma senza cadere nella tentazione di dire "ok mi serve una cosa che fa abc di...c'ho l'automazione che mi fa solo abc me la faccio bastare e utilizzo quello e non faccio la d oppure oppure peggio mi serve abd c'ho l'automazione che fa abc mi costa meno farla e la utilizzo in questo modo utilizzo cose che non mi servono vado da appesantire non miglioro la parte di automazione di tutto quanto e col tempo anche questa si è vista, si utilizzano sempre strumenti sempre meno adeguati perché magari sono quelli che ci sono più facili da creare per poi avere altri tipi di esigenze, esigenze di pulizia, esigenze di scarsità di risorse eccetera.Beh questa è una roba molto saggia, io nel 2018/17 andavo in giro con un talk per spiegare di non sare l'Odash per fare il merge di due oggetti javascript, la gente lo importava totalmente, c'erano tipo mega di libreria per una roba che si scriveva in 5 righe di codice.Secondo me è un ottimo suggerimento, cioè evitare di fare troppo e quindi accontentarsi del "ormai funziona così e quindi tengo tutto" e dall'altro invece anche usare delle cose che fanno meno di quello che ti serve e aggiungere il resto un pochettino a caso.Questi sono due grossi grossi errori che...ma non è il platform engineering.E' questo in generale.Ma infatti la parola chiave qua è modularità e disaccoppiamento anche nel platform engineering.Esatto, esatto.Tra l'altro ho scritto...vabbè, niente, se no non finiamo mai più.Ho scritto proprio un articolo su microservizi e gestioni di ecosistemi componibili, che è stato pubblicato ieri, credo l'altro ieri su The New Stack, poi magari lascio tutti i link, che parla proprio di sta roba.Cioè sì, è bello fare micro servizi, ma se poi non li puoi riutilizzare, non li puoi aggregare fra loro, stai buttando un sacco di risorse che potresti riutilizzare meglio.Un'ultima domanda, e poi sul serio mi muto anch'io, non dopo aver dato qualche balocco.Allora abbiamo questo platform in team, avremo probabilmente anche le nostre metodologie agile, le nostre cose.Quali sono le KPI, come si misurano le performance di questo team? Risorse, tempo risparmiato? Allora vado io direi, grazie a voi ovviamente aggiungi senza problemi.Allora la maggior parte secondo me delle metriche che puoi veramente misurare sono quelle di developer experience perché la parte di platform engineering non serve a fare altro che ci sia un un po' più di efficienza ma soprattutto più soddisfazione generale e qualità di quello che vai a produrre.Quindi faccio degli esempi, sapere quanto velocemente è possibile rilasciare in caso di un bug, sapere quante volte la durata media del "ho scritto la funzionalità, testata e l'ho messa in produzione.Tutte queste metriche, che sono metriche abbastanza standard sulla parte di developer experience, secondo me sono già un buon indicatore.Altro indicatore potrebbe essere quantità di risorse spese, quindi effettivamente quanto cloud stiamo usando.Ovviamente questa non è una metrica assoluta, ma è solo per comparazione.Però, se tu hai un progetto su cui ogni sviluppatore ha bisogno di avere un suo ambiente, oppure un ambiente di platform engineering dove tutti gli sviluppatori possono usare qualcosa di centralizzato, qual è la differenza di...buttiamola proprio sul pratico, costo di queste due cose.Oppure quanto è facile per uno sviluppatore essere "onboardato", si può dire? Non lo so.cioè fare un boarding su un nuovo cliente o un nuovo progetto banalmente, qua la butto sempre al lancio al mio mulino nel caso del platform engineering è facilissimo perchè se tu hai un'unica piattaforma dove gestisci tutti i progetti abiliti l'autorizzazione a quel developer di vedere il nuovo progetto e lui se sa usare già l'ambiente trova tutto al suo posto, tutto nello stesso luogo ed è veloce se invece devo condividere la password di GitLab, abilitargli l'account, poi dirgli dove si trova il cluster, dirgli dove si trova il sistema di pipeline ogni volta da zero, chiaramente è molto più dispendioso.Quindi direi questi, un po' di obiettivi sulla piattaforma come costi, velocità di deploy, anche la velocità con cui si scovano problemi o incongruenza, una serie di cose sulle persone quindi quando sono soddisfatte dell'utilizzo e quando sono facilmente...quando possono facilmente adattarsi a un progetto nuovo a un nuovo cliente eccetera eccetera.Grazie, non so se volevo aggiungere qualcosa sei muto sei muto graz, non ti sentiamo Ok non so perché ho dimuto, ma va bene.A parte le classiche DoraMetrics, quindi Deployment Frequency e quant'altro, metriche relative all'utilizzo dell'infrastruttura e di soddisfazione degli utenti, degli sviluppatori, non mi viene null'altro in mente sinceramente.Direi che quelle che ha elencato Mitch sono tutte le...Proprio parlando delle Dora Matrix però, mi viene una riflessione e con questa veramente ci avviciniamo al paese dei balocchi perché se no dura tipo 16 ore queste episochi.A me fa piacere, lo dico, quando ci sono gli amici...Dai magari fra un paio di mesi faccio un secondo round.No, ma sempre parlando di Dora Matrix, quindi frequenza di deploy, tempo medio per le modifiche, tempo medio per il ripristino il tasso di fallimento mi viene da chiedermi ok noi abbiamo un platform team e abbiamo un development team il development team development x del prodotto x y rilascia e quindi io la posso misurare le metriche d'ora come posso attribuire una certa performance all'impatto, se posso perché penso sia quasi impossibile, all'impatto del platform team.Tu mi dici ok c'è un di mezza, un per due della frequenza di deployment.Sì, vero, ma quanto in realtà dipende dal platform team e quanto invece dipende da, non lo so, un aumento di produttività del team stesso, insito che sviluppa business logico, comunque logica relativa a un progetto stesso ecco, come esiste se esiste un modo per ragione in termini di attribuzione se si può, anche perché la cosa più difficile di quando si vuole avviare un percorso che spinga verso verso un platform team? Di queste cose bisogna parlare col management per mettere i soldini sul tavolo per poi avviare questo tipo di processo? Allora è difficile, nel senso che alcune cose sono misurabili, altre ovviamente no, e altre sono in una zona grigia difficile da individuare.Però, ad esempio il trovare degli errori.Il trovare degli errori con dei sistemi classici potrebbe essere far girere delle pipeline una volta al giorno con degli integration test e aspettare un risultato.Nel caso del platform engineer ad esempio potreste avere dei sistemi automatici che magari fanno il controllo statico del codice più altre cose su tutti i microservizi che scrivi dal giorno zero.Ok? Quindi è chiaro che se il team diventa più bravo avrai meno problemi, ma anche se il team non diventa più bravo, ovviamente la stiamo semplificando, se tu hai dei controlli più granulari, delle cose più granulari, ovviamente i problemi saltano un po' di prima.Quindi tendenzialmente non è che tutto puoi ricondurlo al platform team o al team di sviluppo ma devi iniziare a dividerle cose ad esempio quanto è necessario ora faccio un esempio quanta quant'è l'iterazione necessaria per un developer per faccio sempre il solito esempio creare un nuovo ambiente con e senza la platform ma senza la platform prima aprivi un ticket gira che ti richiedeva un'ora di lavorazione e così via.Bom, hai quello.Quanto hai necessità oggi con il platform team e il tuo IDP? Due minuti, no, sono cinque minuti.Ok, quello può essere una metrica di comparazione tra il prima e il dopo.Ok, la frequenza di rilascio, se prima lo facevi con la pipeline, oggi lo fai schiacciando il bottone, probabilmente rimane uguale.Ma, "Quanti errori avevi nella pipeline di relash prima rispetto oggi?" Ok, questo può essere una cosa diversa."Quanto tempo è necessario a un nuovo developer per capire come effettuare un relash in produzione, ieri versus oggi?" Quella è un'altra metrica.in realtà sull'Edora è un po' complesso dividere il merito, diciamo, del miglioramento delle metriche tra team di dev e team di platform.Però ci sono tante altre cose che si possono migliorare.Però possiamo anche dire che in un contesto di platform engineering io ho l'expectation che almeno ci siano più team di progetto/prodotto.Per cui comunque anche sull'Edora io il trend dovrei vederlo perché spalmate su un insieme di team grosso modo l'impatto emerge l'impatto globale di quello che stai facendo emerge anche su quelle maglie.Assolutamente però è difficile ricondurre da dove arriva il risultato capito? Cioè non so come dire cioè tu potresti avere un team che a un certo punto acquisisce un senior super bravo che inizia a fare delle cose in strettamente anche se non hai introdotto la piattaforma.Quello è lo spike, però se hai 10 team 15 team e io mi aspetto che almeno 4 o 5 team ci debbano essere per giustificare il senso di avere un platform engineering team.Non mi aspetto che con 10 ingegneri io mi tiro fuori un'ingegneria.Probabilmente non avrebbe neanche senso farlo in modo così strutturato se i team sono piccoli, se il numero complessivo delle persone in gioco è piccolo.Però sai, se io inizio ad avere 5, 6, 10 team, lo spike del principal che entra in un team vestito da superman e risolve tutti i problemi, lo ammortizzi con gli altri team, per cui vedi il trend e dici "e lo vendi al management" perché poi alla fine in questo tipo di ambienti, cioè anche all'interno, devi lavorare il tipo commerciale perché devi giustificare l'impatto di quello che stai facendo.Questa è una delle cose più complesse in assoluto, forse non l'abbiamo detta prima, ma è al momento zero quando crea un team di platform, il team di platform la sua credibilità è zero, cioè chiunque li guarderà male dal management all'ultimo dei colleghi perché non avendo mai prodotto risultati ed essendo una cosa nuova vengono un po' visti come alieni.La cosa sta nell'essere bravi e un po' umili nel ciottare di portare piccoli risultati costantemente e iniziare a far vedere che si è lì per aiutare tutti e non per quindi aiutare soprattutto i colleghi, che è la cosa che interessa di più a me, ma anche il management a ottimizzare e fare quelle cose lì.Quindi qual è un altro tasto molto molto dolente nel creare questa cosa da zero.Paraculata, il team di platform deve gioire dei successi degli altri team, rendendosi molto parzialmente il merito di questi successi, perché c'è anche una questione di politica interna poi da tenere.Cioè se il platform Dici "Oggi abbiamo rilasciato questa applicazione o questo servizio è andato in produzione, performato da Dio, l'abbiamo sviluppato in una settimana, che è stato bravo? Il platform team o il team di prodotto?" E' stato bravo...E' esattamente la stessa cosa che è successo quando arrivo a DevOps.Pensaci, è identica.Eh sì, là c'era la paraculata del dire "sono stati bravi tutti perché l'ownership è di tutti, bravi tutti, trombette, cappellini a cono e viva Gesù".In realtà però avendo un team centralizzato diventa un pochino più complicato da giustificare a livello proprio di equilibri.A quel punto io vedrei la gestione del merito in questo caso in un modo più legato alla leadership, cioè come valuti un leader del suo successo.Il successo del leader sta nel successo di chi lavora, il merito del leader è il merito di chi lavora, senso che il leader paradossalmente non dovrebbe avere meriti evidenti però il team di platform engineering ha il bisogno di doversi giustificare col management per cui serve proprio un equilibrio comunicativo nel tavolo degli stakeholder tale da passare questa informazione ma sempre celebrare la performance del team che poi lavora sul prodotto ed è una cosa quasi psicologica.Anche molto bella se ci pensi, cioè il mio successo è il successo di tutti, e quindi il successo degli altri in parte è anche mio, cioè è proprio psicologia secondo me, qua sta degenerando l'episodio.No no no, ma vi anticipo che ci sarà proprio un episodio sulla leadership, quindi su tutto il mondo del team lead e questa belle soft skill che poi diventano hard quando arrivano le mazzate in testa, quindi ne parleremo in modo più approfondito in quell'episodio.Io direi che a questo punto un'ora e 40 e passa di episodio possiamo, se siete tutti d'accordo, fare un salto al momento il Paese dei Balocchi."Riconducono il Paese dei Balocchi" "Ah, il Paese dei Balocchi" Il Paese dei Balocchi, il momento nel quale condividiamo un libro, un talk, un video, un film, qualunque cosa abbia catturato la nostra attenzione e in qualche modo possa essere utile per la nostra community.Per cui volevo chiedervi avete qualcosa da condividere con noi? Iniziamo chiedendo a Graziano.Ok allora io mi ero preparato due cose, anzi tre, due riguardanti il discorso che abbiamo fatto oggi quindi volevo consigliare di dare un occhio al CNCF platform white paper che trovate sul...scritto dal platform working group e trovate sul sito della CNCF che è, secondo me, un buon punto di partenza per iniziare a capire gli argomenti di cui abbiamo parlato oggi.E' sempre in merito a Platform Engineering e ai topic che ci girano intorno.Un'altra buona risorsa è il blog di Martin Fowler che ha tutta una sezione dedicata alle platform, spiega cosa sono, fa un approfondimento anche su Team Topologies e quant'altro, che è molto carino, mentre un po' off topic, un libro che sto leggendo ultimamente, non so se è già stato portato in altri episodi, è "Build a second brain" di Diago Forte, che sempre rimanendo nel giardino dell'organizzazione delle risorse e quant'altro, è una cosa che sto trovando molto interessante per l'organizzazione delle note, knowledge e quant'altro, sia dal punto di vista vista dell'organizzazione mera in cartelle note file quant'altro che in processo di cattura dell'informazione di gestione.Nota a margine, velocissimo.Alla fine di quello leggi qualcosa sullo zelkasten e...mindblowing.C'è anche tutto un plugin per quella roba lì su Obsidian che è fuori testo.Sì sì ma su questo probabilmente faremo...abbiamo già fatto un episodio con Emanuele ma presto ne faremo un altro perché c'è un progettino caldo di cui voglio parlare.Mitch? Allora io vado pure con tre cose.Allora la prima è...io scrivo ultimamente tanto di queste cose, trovate un po' di articoli in giro sia sul blog della CNCF che sul blog di mia platforma, quindi se volete lì potrete trovare degli articoli vendor neutral dove si parla di platform engineering.La seconda cosa ce l'ho qua, se non conoscete il mondo Kubernetes vi consiglio il libro di Serena Stensini, si chiama Kubernetes edito da Apogeo, di tantissime cose interessanti, è un buon libro per iniziare in questo mondo.La terza cosa, qua è un po' sponsor, se volete vi interessa tutto il tema cloud, io e tante altre persone organizziamo il Kubernetes Community Day Italy, parlando di una conferenza di una giornata organizzata da una community per la community, dove parliamo di tanti temi relativi a Kubernetes, cloud native e anche platform engineering.Quindi se volete trovate le informazioni giù, diciamo poi dove le metterò Mauro.Può essere un buon momento per incontrare una community che parla di cloud.Fantastico, tra l'altro colgo l'occasione per mandare un abbraccio a Serena che tra l'altro è stata ospite e un'amica di Gitbar, quindi ciao Serena! Luca? Il mio balocco è un libro, stupirà o forse no perché uno dice "chi se ne frega", però il libro che vorrei baloccare è "Rust in Action" perché io non ho mai scritto una riga di Rust, c'avevo questo libro e sono andato, ho fatto una piccola vacanza in Spagna, quindi nelle due ore di aereo andate al ritorno, l'ho cominciato, non so perché, ce l'avevo nel mio Remarkable, doppio balocco se volete, e ho cominciato a leggerlo senza scrivere una riga, non avevo il laptop con me, quindi l'ho fatto apposta perché così, siccome c'è questa fama un po' strana, no Rust, che prendi a cazzotti il compilatore, anzi il compilatore che ti prende a cazzotti che questo linguaggio un po' strano, ho detto "ma voglio vederlo".In realtà adesso non l'ho ancora finito, anche perché due ore è andato, due ore ritorno, più qualche sera, sono circa a metà, però cavolo, non lo so, mi piace.Mi piace come concetto, come approccio, poi sicuramente quando comincerò a scrivere le prime due righe di codice me le pentirò ma la filosofia che c'è dietro, sull'ownership delle variabili, tutto è eccezionale.Capisco adesso perché c'è tanto hype, anche se non è proprio hype, quindi c'è tanto entusiasmo.un sacco di fermento, è vero.Lo sto capendo perché a me personalmente, ripeto, sarà che non ci ho ancora provato a scriverlo, sono riuscito a leggerlo senza nemmeno, però il concetto che c'è dietro alla filosofia mi ha colpito.Guarda, voglio dire questa cosa, io ve lo sapete sono quello che tira fuori un'analogia per tutto.Ecco Rust è tipo quando ti metti insieme una donna no? All'inizio quando leggi Rust in action sei tutto cuori, sbaciucchiamenti, infatuazione, passione.Ok, poi diventa moglie e dopo i primi anni di matrimonio inizia a rompere i coglioni fondamentalmente dopo che ci lavori un po' diventa come invecchiaia no la pace dei sensi dopo che hai che ne so 10 15 anni di matrimonio dici vabbè questa è mia moglie e a quel punto inizi veramente ad amare di nuovo l'ast si chiama sindrome di stoccolma questa è un po' la mia visione è la campana tipica di tutte le cose che a me sono piaciuta nella vita, hai un momento di innamoramento, poi come dire disillusione, e poi a quel punto ritorni a essere super in focus.Quando hai iniziato con Angular è stato così, Angular JS 2013, c'è stato quel momento di hype incredibile, dove è pazzesco, fai delle cose incredibili, poi inizi a guardarlo bene e dici "non so se è proprio il massimo", poi capisci come padroneggiarlo bene, allora a quel punto ti ritorna la voglia di far bene.Se arrivi a quel punto, probabilmente è qualcosa per cui vale la pena.Aggiungo una cosa non da sottovalutare, che a differenza di tanti altri linguaggi, non tutti, la community è veramente forte.Le persone che iniziano a utilizzarlo, iniziano a parlarne, sono molto coese.E questo, secondo me, sul lungo periodo può essere un grosso vantaggio? In realtà sì, l'unica cosa che aggiungerei è che a differenza del fatto "mi piace" la fase di disinnamoramento, che non è tanto io mi disinnamoro al linguaggio ma è lui si disinnamora a me, nel senso che è uno di quei linguaggi che ti fa sentire una merda quando lo usi dopo un po' perché dici "cazzo allora sono veramente stupido io, perché il compilatore mi dice di no per la quarta ora di seguito.Adesso sto scherzando, in realtà mi sto divertendo un sacco nello sviluppo delle furvie, ma probabilmente perché con me c'è Flavio che un po' mi strada e mi aiuta ed ecco perché ci tengo a dire che quando si impara un nuovo linguaggio avere un Buddy a fianco, per me lo è stato Marco, Yenick che mi bastò una sua chiamata per capire un sacco di cose, tra l'altro lo saluto, ciao Marco, Flavio che mi fa da maestro di sostegno nell'ambito RAST perché altrimenti veramente non sarei in grado, però ecco avere delle persone accanto, credetemi, cambia tutto.Quindi questo è il mio suggerimento.Il mio invece è quello di leggere il libro come se fosse un romanzo intanto.A questo punto tocca a me, giusto? Ok, prima è una marchetta.Ho parlato spesso di "work in public" all'interno di Hitbar, però ho sempre pensato che scrivere degli articoli su quello che faccio sia una grande perdita di tempo e anche una grande notorietà di perché scrivere un articolo probabilmente in inglese a me prende un pochino, anche solo mezz'ora, è mezz'ora che sto dedicando a scriverlo.Adesso che siamo vicini alla release 0.1 di Furvie però ho pensato che sia il momento giusto per riprendere a fare working in public e quindi ho scritto un piccolo articolo che non è ancora uscito quando stiamo registrando l'episodio ma uscirà quando voi lo starete ascoltando, dove racconto una cosa molto banale in realtà, come fare una confirmation modal, una modale confermativa "sì/no" in React che funziona in modo imperativo.È una cosa un po' strana, nel senso che io ho un flow con un sacco di passaggi, immaginate questo flow chart che fa delle cose "sì/no" forse con tante biforcazioni e alcune delle quali hanno bisogno di un confirmation, per esempio l'eliminare, lo step per eliminare un episodio all'interno di un flow più complesso, ha bisogno di una conferma, se no.Farlo in React in modo come andrebbe scritto in React, vuol dire tirare su uno stato, fare delle cose e non diventa più imperativo.Per farlo ho scritto un hook simpatico che mi risolve il problema e mi dà una funzione imperativa per poterlo fare e ho scritto un articolo su come ho fatto, molto banale, con uno scope super contenuto, ma il vero balocco è quello del work in public, cioè fermarsi a scrivere qualcosa dopo averla fatta ti serve per fare un rubber ducking a posteriori ed è sempre importante per prendere consapevolezza più profondo di quello che stai scrivendo perché talvolta, specie quando si lavora in side project, non si ha la profonda consapevolezza di quello che cazzo si scrive nel codice, quindi fa sempre bene ecco fare questo questo step.Seconda cosa, abbiamo parlato di platform team, io volevo condividere, raramente parlo di progetti che si fanno dentro NIRFORM, però volevo condividere questo progetto open source molto figo che sta curando Luca, che tra l'altro inviterò prestissimo qua su Gitbar, il progetto si chiama Inisium ed è praticamente un, io lo dico volgarmente, un deploiatore di codice in un ambiente cloud native che ti permette di deploiare la tua applicazione in un ambiente cloud native con un solo comando e lui si occupa di tirare su una piccola infrastruttura usando K-Native dove c'è che ne so il deployment dei vari feature branch su domini separati, ti da Grafana, Loki, Timeteistio, OpenTelemetry, Prometheus, tutto out of the box.Come dice Luca questo tool non serve per andare in produzione ma è uno di quei tool molto utili se tu hai un team che deve deve velocemente mostrare quello che sta facendo e ha bisogno di un environment rapido e non ha un sistema strutturato capace di provisionare magari in modo automatico questa cosa quindi stai entrando da un cliente non gli hai ancora messo insieme tutta la parte di platform engineering ma vuoi mostrare che i team stanno facendo qualcosa e deployare qualcosa magari in staging ecco può essere veramente utile quindi in insieme così dai tutto il tempo al DevOps team del platform team di tirare su le sue pipeline le sue cose fatte bene a modino come devono essere tirati su.Questo è un po il balocco che volevo condividere con voi Ragazzi, com'è? È sempre bello essere qui.Onestamente, non dobbiamo fare prima di altri 180 episodi.Sì, dovremmo rifarlo nuovamente presto e lo andremo a rifare sicuramente.Molto figo come topic, noi lasciamo qualunque discussione, bold opinion, aperta a le chiacchiere nel gruppo Telegram.quindi se volete fare dei follow up all'episodio fatelo pure nel nostro gruppo Telegram e se volete mandarci un video o un vocale lo metteremo in coda all'episodio successivo solo come follow up.È un'idea nuova che volevamo portare qua su Gitbar vediamo se qualcuno di voi insomma mette da parte la...la...la...la...la...come si dice? ormai ho dimenticato a parlare, la timidezza ecco e insomma ci manda il vocale o ancora meglio il video.Detto questo io ringrazio nuovamente Mitch e Graziano per essere venuti, ricordo che Mitch e Graziano fanno parte del DevRel Team di mia platform che tra l'altro insomma si occupa proprio di queste cose, quindi c'è i suoi prodotti che trattano insomma queste tematiche, buttateci un occhio e quindi grazie, grazie davvero Mitch e Graziano, super felice di essere qua.Anche per noi è stato bello, grazie a voi.Luca, beh ti aspettavi una cosa del genere dal platform engineering? Tu sei partito con una bold opinion come Vrapil L'ho fatto per rompere il ghiaccio e poi sono scatturito con l'amore di un minuto.Con il macetto l'hai rotto.No, sì, mi sono confuso con il fatto di poliziotto buono o poliziotto cattivo, ma va bene, dai.La verità è che mi avevi preso in contropiede, non sapevo che cosa dire, allora ho detto quello che pensavo.No, no, ma tra l'altro è una riflessione, l'abbiamo ripetuta più volte di questo ci siamo entrati proprio a fondo, perché fondamentalmente il rischio più grande, la paura più grande quando si adottano questo tipo di metodologie vanno fatte con granosalice.Come si dice? Con granosalice e consaggezza.Esatto, vanno fatte con saggezza e con la consapevolezza che qualunque cosa tu faccia come ha detto Mitch ha un impatto nei team e oggi la retention dei team è il vero capitale che molte aziende hanno a disposizione.In realtà il mercato sta cambiando quindi non so per quanto ancora la retention sarà un problema però ancora oggi oggi insomma la retention è uno dei problemi principali dei team.Bella! Io dopo due ore che parlo in italiano veramente non...La ricerca con l'anglo-schilese se vuoi! Ancora peggio! No, adesso eravamo...quanto? Un paio di settimane che non registravamo un episodio realtà è sì quindi insomma.Detto questo è stata una super puntata ricordiamo rapidamente i nostri contatti prima di chiudere.Info che ho la github.it @brainrepo su twitter e il gruppo telegram lo potete cercare @githubpodcast e siamo noi siamo circa 1530 32 e ci trovate lì.Abbiamo anche il nostro canale youtube nel quale appunto potrete vederci in faccia quando parliamo e abbiamo, dimenticavo una cosa fondamentale, dobbiamo ringraziare chi ci supporta.Io me ne stavo dimenticando invece è fondamentale perché le settimane passate non ho ringraziato i i nostri donatori quindi ahia ahia mea culpa mea culpa abbiamo due donatori da ringraziare il primo è Fabio Marzotti che ci dona due birre e il secondo è Marco Damiani che ci dona tre birre quindi grazie perché grazie a voi Gitbar può parzialmente sostenere le sue spese che ripeto sono tante tra i vari abbonamenti cose varie insomma perché Gitbar è gratis ma non senza costi quindi se vi fa piacere supportarci trovate un pulsantino in alto a destra nel nostro sito che dice supportaci cliccate là e trovate tutto potete anche supportarci con le modalità del podcasting 2.0 se avete un'applicazione moderna che permette di streamare Satoshi come Castamatico, come Fontan, potete semplicemente dire all'applicazione "Ehi, invia un Satoshi, due Satoshi, cinque Satoshi" che sono veramente una frazione di centesimo, ma questo ci fa capire che ci ascoltate e ci fa capire il vostro amore nei nostri confronti.E' l'amore tutto.Fai delle cose con amore.Mi ricorda la pubblicità di uno yogurt famoso, però basta sprolucchiare, è il momento di chiudere.Quindi vi do appuntamento alla prossima settimana ringraziando anche Luca per essere stato qua.Grazie mille.Grazie a te.Ciao a tutti.siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo ma ahimè lo stronzo è me medesimo e lo scritto giusto ieri siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery, gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test e flake pure.Siamo noi quelli che il tuo linguaggio fa cagare ma il mio è peggio, quelli che la chiarezza nei commit message prima di tutto e dentro ce l'appella tutti i santi, quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto, quelli che non si può fare di default diventa velocemente un tutto è possibile sia le risorse, tempo e budget di limitato.Siamo noi quelli che l'AI va regolamentata, mai visto questo nuovo modello che disegna gatti di funambuli? Quelli che il dipende e unisce gratis la prigione e quelli che la RAL...no vabbè, fa già ridere così.Siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente, ormai rassegnati che la definition of ready è solo una pia illusione.quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come Instagram ma meglio siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al github e davanti a una birra tutto ci sembra un po' meno grave Lo strenuto faceva parte ...
