Bene e benvenuti, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Oggi il bar è gremitissimo e sono in un brodo di giugiole e per questo stappo questa bottiglia e me la bevo alla vostra salute.Chi abbiamo con noi oggi? Abbiamo Carmine, Leonardo, Luca e abbiamo anche Mattia.E Mattia oggi lo interroghiamo per Benino.No? Non ho studiato, non so niente, prof, mi giustifico.Il cane ti ha...dicevi Carmine? No, no, no, no, dicevo che era una vita che non sentivo mi giustifico, davvero, scusate.Il cane mi ha mangiato il comit.Sì, sì.Il flashback del Vietram, tipo...Allora dico un'altra frase.Dico un'altra frase.Ti sei già giustificato, vieni, vieni.Ma nonna mia adesso...No ma oggi doveva offrirsi volontario Leo Ok andiamo avanti, piccola introduzione sulla puntata di oggi che è un pochino diversa questa puntata è realizzata in collaborazione con Code Motion e grazie a questa puntata poi troverete una sorpresa durante Code Motion di quest'anno quindi rimanete con le antenne alzate perché potrete scovare qualche dettaglio.Detto questo il nostro compito adesso è quello di ricordarvi rapidamente i nostri contatti info@gateware.it @brainrepo su twitter che tra l'altro ha ripreso un po vita e il gruppo telegramma bellissimo gruppo telegramma il gruppo di anime più bello d'Italia non come quelli brutti dei diari.Va benissimo, va benissimissimo.Sento che si è staccato di tagliare con la parte.No, no, potete cercare Hitman su vostro telegram on client preferito.Siamo veramente tanti, siamo più di 1300 persone.Vi aspettiamo.Manchi solo tu! Così abbiamo chiuso.Detto questo io direi che possiamo iniziare.Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.La puntata di oggi è un'episodio che diciamo ha come topic principale o come parola d'ordine dipende ci spostiamo nel dominio delle architetture software dove non esiste una posizione assoluta ma tutto è un trade off.Tutto è una bilancia e a seconda della prospettiva cambia completamente la decisione e quello che è giusto è quello che è sbagliato.Detto questo possiamo introdurre il topic di oggi, i microservizi.Ma prima di introdurre il topic di oggi Luca ha scritto che non è...Fai come vuoi, ma io non ho scritto niente.Hai allucinazioni.Questa lo diciamo anche per gli ascoltatori, ho detto "tutto è un trade off" e ho visto la notifica di Luca su Telegram con la scritta "non mi pare" e quindi per un attimo ho detto vediamo vediamo cosa vuol dire invece si riferiva a qualcos'altro no la puntata di oggi parlerà di microservizi e la prima domanda che mi piacerebbe fare a Mattia e a fare a tutti è secondo voi quali sono gli elementi che fanno sì che un microservizio sia tale cioè quali sono le le caratteristiche che rendono un servizio un microservizio? Grazie per la domanda.Secondo me, prendi quello che ti dico con le pinze, nel senso che come tu sai ormai per esperienza, come sapete tutti e come sa anche il nostro pubblico io sono assolutamente un cazzaro e quindi potrei dire delle cose che non hanno alcun però secondo me un microservizio è un'applicazione che fa una cosa tipicamente all'interno di un ecosistema di altre applicazioni che fanno una cosa e lo fa magari esponendo un API mentre lo dico mi rendo conto che ok, allora che ne so CAT dei sistemi Unix è un microservizio perché è un'applicazione che fa una cosa e espone un API Less, more, tutti quei meravigliosi programmi costruiti secondo la UnixWay che fanno una cosa e li puoi concatenare e metterli assieme, sono dei microservizi.Probabilmente sì.- Io stavo pensando esattamente la stessa cosa.- Vai.Con i programmi Unix con i microservizi.Il Pipe è l'HTTP.- Sì, 100%.- Tranne che il Pipe funziona sempre.è tutto dentro Bash che sarebbe il nostro cloud, però è tutto molto semplice.Eh sì, però in realtà è molto simile e in effetti probabilmente nell'accezione che si dà al termine OG, appunto come dici tu, quello che fa la differenza è HTTP o gRPC, comunque un protocollo web based, network based, che mette assieme questi microservizi che probabilmente stanno su macchine diverse, differenza appunto dei programmi di Unix.Quindi c'è anche un tema architetturale per cui i microservizi hanno anche un'infrastruttura diversa, sono sono deployati in posti diversi, in modi diversi e indipendentemente l'uno dall'altro.Mattia ha detto una cosa interessante, è un modulo software che fa una cosa, è solo una cosa e qua è interessante provare a capire cosa vuol dire "fa una sola cosa" perché mi potete dire "sì Mauro fa una cosa vuol dire fa una cosa" ma io risponderei "dipende da quanto ampia è la rappresentazione che ne vogliamo dare a questa cosa" Il software è sempre un insieme di elementi complessi e possiamo immaginarli come gli atomi, le molecole, gli organismi.Ecco, secondo voi, dove il cut off, tale per cui si dice "sopra questa linea non si tratta più di microservizio", cioè come posso fare slicing del mio domenio applicativo per dire "ok questa è l'unità minima che compone il microservizio".Allora io adesso faccio la prima bold opinion della serata e soprattutto la cosa bella è che mentre lo faccio contraddico quello che ho detto un minuto fa, nel senso che secondo me il cut off che non è tanto questa cosa è un microservizio questa cosa no ma è "ho bisogno dei microservizi, non ho bisogno dei microservizi, è una questione, come la maggior parte delle questioni di cui parliamo noi in realtà, di persone più che tecnica.Nel senso che, nel mio punto di vista, un microservizio è una cosa che è gestita da un team, che quindi ha la sua indipendenza a livello di persone rispetto agli altri microservizi.Hai bisogno dell'architettura microservizi nel momento in cui hai un numero sufficiente di persone per cui puoi splittare le competenze in maniera, diciamo, molto netta.E quindi hai, per esempio, che ne so, il team che fa il microservizio dei pagamenti, il team che fa il microservizio del login, il team che fa il microservizio delle mappe, eccetera, eccetera.Nel momento in cui tu hai le stesse persone che lavorano su applicazioni diverse, in modo diverso e che cerchi di convincerti che sono microservizi, stai facendo una palla di fango, non stai facendo i microservizi, secondo me.Io stavo pensando una cosa...Scusami...No, no, no...Nel momento in cui diciamo che noi abbiamo un monolite, quindi un pezzo di software molto grosso, dove però c'è solo una parte, uno lo può vedere dalla storia dei Comet o dell'evoluzione, che cambia più spesso, potrebbe...potreste dire Questa parte la mettiamo in un microservizio, perché anche solo a livello di deploy ci risparmia il build time.Cioè una parte è sei mesi che non la stiamo cambiando, quindi quella rimane.Stacchiamo solo la parte che evolve, perché ci potrebbe risparmiare il build time, oppure necessita di maggior refactoring, quindi magari anche di competenze più specifiche.Mi è venuta in mente, potrebbe essere una domanda per voi altri, non per forza...Io ho un punto per fare challenge a questa cosa, che è tipo, che ne so, ho un monolite, e ho una parte in cui le performance sono critiche perché devo farci, che ne so, della roba grossa e decido che questa roba la estraggo e la metto in un'altra applicazione scritta in un linguaggio diverso che però scrivo su flight.Quella roba lì è un microservizio? Probabilmente sì.E allora, cioè, veramente io...mi avete presentato come quello che ne sa, ma io davvero non so dire che cosa sia un microservizio a questo punto.abbiamo dato tipo 5 definizioni diverse nei primi 5 minuti.Secondo me questa cosa qui è la cosa bella, di essere anche quanto più onesti con noi stessi e con chi ci sta ascoltando.Prima che nascesse la parola microservizio, non significa che non esistessero delle architetture in cui c'erano più servizi che comunicassero tra di loro, anzi, e si stevano e si sono nati proprio dei protocolli di comunicazione per fare questa cosa.Quindi se prima la chiamavano una SOA, una Service Oriented Architecture, ora si chiama Architettura a micro servizi.Diciamo il limite per il cui una cosa in micro, una cosa in macro, una cosa è un servizio normale, non so nemmeno come definirla, è da ricercare nel nostro dominio e da quello che è effettivamente più sensato.Come abbiamo detto prima, fai il micro servizio dei pagamenti, probabilmente se lo guardiamo in termini di numeri piccoli, dublio fortemente che sarà un microservizio.A quel punto possiamo dire "aspetta, c'è un microservizio che fa la transazione, c'è un microservizio che fa la callback sul client, c'è un microservizio che mi chiama Stripe".Nel senso che possiamo fare slicing, no sense, fino a che vogliamo.diciamo alla fine che lo chiamiamo microservizio, ma stiamo semplicemente parlando di una business unit del nostro dominio che può essere isolata e può vivere di vita semi-propria.L'unica cosa, ecco, un altro punto anche un po' bold che mi sento di dare, non partite che dovete fare più servizi, dovete fare il micro servizio per questo, per quello.Magari può essere un buon punto se vi dovete vendere a, non lo so, magari a qualche persona che sta cercando proprio quella cosa lì, ma partire a fare i micro servizi senza aver fatto prima anche un semplice POC, un MVP che sia un monolite per capire di che cosa stiamo parlando e quali sono le varie moving parts in gioco è un suicidio perché già a partire o siete estremamente esperti del mostro d'ominio e quindi avete già intuito fino da subito le varie boundary e la boundary che c'ha più carico, che c'ha meno carico, la più critica è quella...no, critica è quella che si infiana, non so, se siete i figli legittimi di Uncle Bob oppure effettivamente vi state sparando sui piedi.Quindi quello che vi dico è fate i microservizi partendo da un monolith che dividete in moduli e poi pensate se quel modulo debba avere effettivamente vita propria.Perché è possibile fare un'applicazione modulare, quindi un'applicazione che ha diversi servizi che sono modulati anche facendo un unico applicativo che possa chiamare monolitero.Infatti da quello che dicevate, scusate avete parlato tutti, adesso parlo io, la dico anch'io la mia, no scherzo, mentre parlavate stavo pensando al problema della definizione della S dei principi solido, visto che Carmina ha nominato anche il Bob, che è appunto il principio di singola responsabilità, che in un certo senso è sovrapponibile come problema.Cioè un microservizio inizialmente deve fare una cosa, ma una cosa sola, ma che cos'è questa cosa sola? E infatti la definizione quella brutta del principio di singola responsabilità è quello di dire una classe, un modulo, un'entità deve fare una sola cosa, mentre quella un più carina e una classe o un'entità e a questo punto ci metterei pure un microservizio deve avere un solo, non un solo motivo per cambiare, un solo attore gli deve dire perché deve cambiare.Sì, c'è anche un modo di dirla che dice che una classe dovrebbe avere solo un metodo pubblico, quindi di fatto sarebbe come dire che un microservizio dovrebbe avere un endpoint.Esatto, quindi ogni volta appunto pensavo a questa analogia che potrebbe anche essere un buono spunto per, come diceva Carmine, migrare o partire da un monolite e migrare verso il microservizio senza rompere alcun principio a cui ci siamo affezionati.Nel 99% dei casi un solo servizio vi basta, anche un solo servizio scala.Puoi scalarlo orizzontalmente, puoi scalarlo verticalmente.Se vi servono più servizi, significa che avete individuato delle parti che sono magari più critiche delle altre, che possono vivere vita propria e avere un ciclo di rilascio, di build, di consumo che è diverso dal vostro vecchio monolite.Ma se fate i microservizi perché va di moda, vi sparate sui piedi.Significa che non vi servono.Diciamo che se vi state chiedendo se vi servono i microservizi, non vi servono.io vorrei e vorrei per un attimo provare a fare questa questa specie di recap no? e provare a immaginare come dimensionamento del microservizio, dove per dimensione non parlo di chili ma parlo di superficie no? qual è il perimetro che posso tracciare per definire un microservizio? mi piace vederlo come un trade off tra il knowledge del team, quindi parte operativa dell'organizzazione e diciamo la parte più la parte di dominio che quel team tratta.Quando le applicazioni crescono specie nelle grandi organizzazioni il team non può essere onnisciente e la modularizzazione dell'applicazione può funzionare fino a pagina 100 nel senso che comunque in un modo o nell'altro un'applicazione per quanto modularizzata quindi suddivisa bene i moduli di dominio definito e ogni modulo assegnato a un team in qualche modo si integra più o meno strettamente col resto dell'applicazione dove la formalità di integrazione rischia di essere labile rischia di essere labile non vuol dire è labile e che diciamo è molto facile accopiare i moduli quando invece si parla di microservizi è molto facile anche accoppiare i microservizi anche questo è vero però la definizione dell'interface diventa un elemento rituale della realizzazione del microservizio.Per cui tu hai fisicamente diviso quel pezzo di dominio, quel pezzo di conoscenza da tutto il resto.Per cui mi viene da dire se io ho un'organizzazione dove la conoscenza da dividere è ampissima e i team possono avere velocità differenti a quel punto posso optare per l'utilizzo del microservizio e la divisione mi verrebbe da dire la faccio unendo quella che è la knowledge del team a quello che mi viene mi verrebbe da chiamare sottodominio no quindi porzione della logica applicativa che tratta un contesto specifico attorno al quale posso disegnare un perimetro è una porta d'ingresso.Quella porta d'ingresso sarà l'API del mio microservizio.Per cui quello che mi interessava evidenziare in questa parte è che alla fine la decisione se andare per microservizi, dal mio punto di vista, è una decisione di tipo organizzativo aziendale, come diceva Matteo.Stai per caso dicendo che il software a un certo punto rappresenta l'organizzazione aziendale? Bella questa! Non so se volevi arrivare lì però è esattamente poi dove le cose vanno.C'è anche la legge, non mi ricordo di chi l'aveva.L'aveva anche menzionata.Matteo.L'aveva menzionata proprio il nostro Mattia.Matteo, è anche Matteo.È anche Matteo.Un ricordo che ogni tanto viene fuori.Poi magari a fine episodio vi dico anche il numero delle puntate, quando l'ha menzionata Mattia e quando l'ha menzionata Matteo.E in realtà però ecco.Econway, ho googlato al volo.Sì, sì, Econway.La divisione quindi è data da come organizzi la tua azienda.Raga, l'altro giorno leggevo su un libro che i monolitti erano fighi e sono stati utilizzati perché in realtà rappresentavano quella che era quel tipo di organizzazione, quel contenitore grande.Oggi le organizzazioni hanno la necessità di correre in modo diverso, cicli iterativi, tutte queste belle cose.Per cui se io ho tutte queste esigenze potrebbe essere il caso di optare per l'utilizzo dei microservizi.Ma come dicevate prima i microservizi non sono gratis.Quindi secondo voi quali sono i costi dei microservizi? Beh, anche lì, secondo me, il costo dei microservizi riflette il costo organizzativo di com'è fatta l'azienda che li produce, nel senso che comunque nel momento in cui tu introduci dei punti di contatto, di comunicazione tra i team dei microservizi o i team in generale che lavorano su un monolite, sta introducendo dell'overhead comunicativo che è non solo quello, appunto, delle richieste HTTP piuttosto che gRPC o SOAP tra un microservizio e l'altro, ma anche l'overhead di comunicazione tra i team che li gestiscono.Per cui ogni team che fa...che espone un microservizio a dei client deve sapere, per esempio, che non può rompere le API in maniera breaking, appunto.o comunque se lo fa, deve farlo con criterio e come il signore comanda, o versionando l'API, o annunciandolo per tempo e deprecando le cose, ma, appunto, sai che siccome hai delle persone con cui devi interagire, non puoi rompere le cose a tuo piacimento, per cui c'è quello vero e del lì comunicativo di dover gestire la comunicazione e mettere, sincronizzare dei team diversi, degli attori diversi.E questo secondo me è il costo più grande.Poi c'è tutta la tematica di, per esempio, nelle aziende un po' grandi, di rischio di perdita di standardizzazione.Per cui se tu hai 100 team che fanno 100 microservizi che interagiscono tra loro e ognuno fa le cose a cazzi suoi, hai un bus factor molto basso, nel senso che se un team che gestisce un microservizio se ne va o a uno viene la diarrea o uno trova un lavoro migliore e devi farlo mantenere a qualcun altro e loro facevano le cose in maniera assolutamente cowboy e diversa dalle altre, sei in un lago di letame e questo è un rischio molto concreto.Per cui c'è appunto un rischio di esplosione del carico cognitivo legato alla diversità di tecnologie e di modi di fare le cose in gioco anche.Non è necessariamente un costo diretto ma è un rischio.Però non pensi che comunque questa cosa vada a inficciare l'ultimo punto che hai detto, il fatto della necessità di standardizzare i processi quando poi il numero di microservizi o dei servizi esplode.Non è però dall'altro lato il fatto di perdere velocity, perché stai dettando una linea quindi in qualche modo di sacrificare una parte dei benefici che i microservizi ti portano.È un trade off.Guarda come gestico la Carmine, dici? anche l'Uham erano molti.Perdi velocity tanto significa che hai splittato male.Se perdi tanta velocity nonostante tu hai diversi team dedicati significa che hai splittato male i microservizi.Sì, sono molto d'accordo nel senso che se tu hai splittato bene le competenze e e diciamo le ownership più che altro, riesci a lavorare in maniera indipendente e quindi ad andare veloce.Se perdi velocity per via della necessità di interagire con un altro team, hai splittato male.Sono a 110% d'accordo.Rispetto al discorso tecnologico, che credo dicessi tu Mauro invece, la necessità di standardizzare le cose contraddice un pochino il tema dei microservizi, nel senso che tu dici la figata dei microservizi è che puoi usare la tecnologia che ti viene più comoda per quel caso d'uso e se imponi un po' di standardizzazione, invece forzi magari delle cose a essere fatte nel modo non più veloce per quello specifico dominio e quindi rischi di perdere velocity, sì, verissimo.È un trade-off, nel senso che devi trovare tu, è estremamente difficile, l'equilibrio tra fare le cose tutti nello stesso modo oppure fare le cose ognuno come cazzo gli pare, che sono i due estremi, e probabilmente alcune cose le standardizzi e su alcune lasci libertà.Che ne so, usi lo stesso tool di deployment per tutti, usi lo stesso sistema DCI per tutti, ma lasci libero che database usare, perché magari ha senso usare database diversi per domini diversi.è la prima cosa che mi è venuta in mente.E tra l'altro hai toccato un punto che mi ero ripromesso di toccare perché proprio adesso sto lavorando sui microservizi e le sorgenti di dati sono un pain point, nel senso che tutta la parte di data management nei microservizi è un topic articolato e complesso, specie se si tocca per sbaglio il mondo delle transazioni.La best practice è la sua divisione logica di ownership in qualche modo ci spingono per dire ogni microservizio deve avere il suo repository di informazioni in modo che tutto sia completamente disaccoppiato e l'unico legame tra i microservizi sia il protocollo di comunicazione quindi l'interfaccia di comunicazione quella che noi chiameremo l'API che anche quella va documentata.Però cosa succede se per sbaglio il mio dominio generale ha una transazione che tocca più microservizi? Adesso viene il bello! Nel senso che immaginiamo una unicommerce dove ho il microservizio del pagamento, il microservizio dell'ordine, microservizio della spedizione.Sono tre team super cazzutissimi, bravissimi a fare quello che fanno, con dei pezzi di dominio che masterano molto bene.Non so se masterare è un termine italiano ma poco ci importa.Però l'acquisto è un'operazione che è orizzontale, che tocca tutti questi punti.E allora la prima domanda che mi faccio è "ma allora ho diviso male?" No, perché sono dei sottodomini fortemente incapsulati logicamente, non saprei come spiegarlo, però questa transazione li tocca tutti e tre.Come posso fare per gestire questi casi specifici? Grazie per la domanda perché è una roba di cui mi è capitato di parlare in passato perché ho esattamente sbattuto la testa contro questo problema in passato.Non era esattamente un e-commerce ma era molto simile nel senso che lavoravo in un'azienda, quella dove lavoravo prima di adesso, in cui avevamo un'architettura microservizi e di fatto delle transazioni che ne coinvolgevano più di uno per cui succedeva una cosa che triggerava un evento di un microservizio, che ne triggerava uno su un altro, che ne triggerava uno su un altro, che ne triggerava uno su un altro, che al mercato mio padre comprò.E cosa succede se durante questa catena di chiamate a n microservizi uno dopo l'altro, uno si rompe? Cosa succede alle richieste precedenti? Dipende.Il pacco grosso della situazione è che quando tu hai una cosa del genere per cui, appunto, succede una cosa che ne so, tornando all'esempio dell'e-commerce.Un tizio mette qualcosa nel carrello, fa check-out, chiama il microservizio del pagamento che ritorna all'hack del pagamento e allora devi svuotare il carrello e poi chiamare il servizio della spedizione per fare l'ordine, bla bla bla.Se una di queste cose non va a buon fine, devi rispondere in maniera sensata sugli altri microservizi.Il pacco della situazione è che fondamentalmente non hai quella cosa che ti insegnano all'esame di basi di dati quando parli delle transazioni, che sono le proprietà acide.Nel senso che la transazione, appunto, per come l'abbiamo detto, non è atomica, perché è divisa su più cose diverse, e quindi non è una e indivisibile, perché by design l'abbiamo divisa su servizi diversi.Non è isolata, perché succede su posti diversi, e quindi, appunto, By Design, di nuovo, non l'abbiamo più isolata.Si spera che almeno le altre due rimangano.Quindi dovrebbe essere isolata da quello che succede nel resto dell'applicazione e dovrebbe essere durabile perché i dati li salviamo comunque da qualche parte.Ci sono diversi modi di gestire questa cosa.Comunque, in generale, è un grosso pain point dell'architettura microservizi.Un pattern che si usa per risolvere questo problema si chiama saga e fondamentalmente è l'evoluzione di una transazione in un'architettura SOA o a microservizio, come la volete chiamare oggi con la buzzword del mese.Per cui, di fatto, una saga è una transazione distribuita e questa cosa richiede di usare alcuni concetti fondamentali per cui, per esempio, devi prevedere che ogni endpoint che tu hai per fare una cosa abbia anche l'endpoint per rollbackarla.Per cui tu hai un endpoint che ti dice "metti una roba nel carrello", ma se questa cosa scatena degli altri 20 e uno di questi si rompe, devi avere l'endpoint rollbacka l'aver messo questa cosa nel carrello.E se si rompe anche il rollback, che cazzo, a un certo punto.E questo però in qualche modo non ti spinge verso anche una architettura del microservizio, l'architettura interna del microservizio ai venti, non ti costringe quasi ad andare così per avere una gestione più pratica del rollback piuttosto che...Assolutamente sì.Io adesso sto lavorando su un booking.la disponibilità di...cosa ne so...un aereo è fatta con disponibilità totale meno 10 posti e faccio l'update se devo fare il rollback il rischio di danneggiare la sorgente di dati è molto alta per cui sono quasi spinto a dire ok i posti dell'aereo sono 150 poi al posto di sottrarre creo un nuovo evento che mi dice "sottrai 12" e faccio una proiezione di quello che mi rimane e questo in qualche modo può aiutare.Per quanto riguarda invece la comunicazione tra microservizi, secondo voi come si sceglie il protocollo giusto per far comunicare i microservizi? Secondo me dipende se ti serve una cosa sincrona o asincrona.Se ti serve una cosa sincrona non hai tantissime scelte, se no qualcosa appunto di sincrono, magari lo fai con HTTP, con gRPC, che è un cazzo che comunque però va su HTTP2, quindi alla fine non hai tantissime scelte.Ci sono anche altri modi di fare RPC con strumenti più legati proprio alla tecnologia, quindi magari non so se qualcosa legato anche più al linguaggio di programmazione, quindi ci si avvicina ad un RPC più tradizionale, nel senso che ci sono tante cose.Se invece bisogna una comunicazione asincrona, stai implicitamente parlando di un sistema di event.Quindi lì dipende se quel tipo di messaggi che si scambiano i vari attori devono essere persistiti o non devono essere persistiti, quindi magari puoi utilizzare una roba tipo Rabbit o AMCP in generale, oppure un broker tipo Kafka dove magari scegli anche la persistenza dei messaggi, effettivamente dipende.Però secondo me queste due categorie, o ti serve sincrono o ti serve asincrono, sono effettivamente fondamentali da scegliere fin dall'inizio.Quello che però mi preme dire fin da subito è che condividere la stessa base di dati con il meccanismo di comunicazione non è una cosa giusta, anche se l'ho visto fare la famosa tabella su Postgres tipo Jobs, Messages e c'hai l'advisory lock da una parte e poi c'è da quell'altra, adesso leggo, adesso scrivo, no, quello non è un meccanismo di comunicazione, quello è nel capitolato c'è scritto "microservizi", ma non li so fare, quindi c'è un certo post che è stato regolato.Nel senso ragazzi, si fa e tutti mangiamo dallo stesso piatto, indipendentemente dal gusto, però effettivamente non è una strada molto molto percorribile.Nella mia esperienza non sono mai andato fin da subito sulla comunicazione asincrona perché richiede un effort diverso.Cioè, ad esempio, come stava dicendo prima Mattia, se durante la comunicazione io devo gestire un tipo di errore, farlo con una comunicazione sincrona è molto più semplice.Basta pensare al vostro micro servizio, al vostro servizio, che fa una chiamata ad un altro servizio e hai la possibilità di sapere in maniera sincrona se quella cosa è andata a buon finomeno.Se invece stiamo parlando di un meccanismo di comunicazione a sincrono, fare delle operazioni compensative degli errori diventa effettivamente più difficile.Hai parlato di errori, no? E nella realizzazione di microservizi o nell'architettura, i microservizi diventano un elemento importante, possiamo dire centrale, no? Della dell'architettura.Perché? Perché se il monolita nella comunicazione tra moduli, se nel monolita, proprio attraverso la comunicazione tra moduli io ho un controllo sull'errore con l'utilizzo dei microservizi il controllo in qualche modo rischio di perderlo perché tra il microservizio A e il microservizio B c'è una comunicazione diretta e la comunicazione diretta di per sé deve essere interpretata come instabile e con rischio che fallisca.Secondo voi quale può essere il miglior pattern per la gestione dell'errore all'interno della architettura a microservizi? Vale dire non fare errori, è un pattern, ce l'abbiamo consentito.Dipende, dipende tantissimo, dipende dal tipo di errore, dipende da che cosa tu definisci come errore e quali sono le policy che tu definisci in base a ogni tipo di errore.Per cui per esempio ci sono degli errori su cui puoi mettere in piedi un meccanismo di retry, ci sono degli errori che devi gestire appropriatamente, ci sono degli errori in cui devi rollbackare le transazioni, dipende.Ed è una cosa che però decidi tu.Sì, la cosa la cosa importante era, dal mio punto di vista è quello di evidenziare che nella comunicazione tra moduli in un'applicazione in un monolita io do per assunto che la comunicazione tra moduli abbia l'errore legato al codice che sto scrivendo non degli errori che mi vengono magari dall'infrastruttura nel quale girano per cui un microservizio fallisce e l'altro si aspetta la risposta per cui l'attenzione a questo tipo di errori e nella comunicazione il dare per scontato che qualcosa può andare storto, credo che sia un'attenzione che è d'obbligo nella gestione dei microservizi.Cioè se io sto mandando un messaggio a un altro microservizio, mettiamo che lo mando attraverso HTTP, io ho il 100% di sicurezza che quella roba può fallire.100%, tant'è che c'è una branca del nostro mestiere, che credo paghi anche molto bene che si è inventata Netflix, che si chiama proprio Chaos Engineering.Loro hanno un tool, credo l'abbiano rilasciato open source, che si chiama Chaos Monkey, che è un attrezzo che a random, a caso, ogni tanto, in maniera del tutto imprevedibile, gli spegne dei microservizi a cazzo.Ed è fatto apposta per testare, adesso dico una bellissima buzzword, la resilienza del resto degli altri servizi rispetto al fallimento di uno di questi.Ho detto resilienza, quindi oggi sono il re.È una roba che comunque tante aziende grosse fanno.Scusa, Luca.No, no, credo ci sia anche il papà di questo scimmione che butta giù anche intere regioni, quindi non solo microservizi, ma proprio… Ecco che figlio ha fatto il molisse! Esatto, esatto.Era lì che nacque il modus erotico.Non è mai esistito.Stavo pensando su una cosa stupidissima.Quanta gente si è fatto il tatuaggio con scritto "resilienza"? Oltre a un savacchi? Perché loro spengono i microservizi.No, ma io ho pensato, mentre parlavi di resilienza, al concetto di antifragilità.perché volevo dire la stessa cosa, possiamo dire antifragilità invece di resilienza almeno usciamo dalla bolla? antifragilità è quando lo scimmione ti spegne i microservizi e c'è chat gpt che ti crea un servizio simile che risponde alle risposte creato direttamente on fly e funziona ma quale antifragilità? Beh, da questa cazzata possiamo andare avanti.Testability.Si parla un pacco di testabilità.Cosa cambia in un'otica di microservizi? Che vanno comunque fatti, anche se sono piccoli.E alzi ne vanno fatti di più, perché uno dei vantaggi di avere un'architettura microservizia che puoi mockare un microservizio quando testi le interazioni con esso.Però non vuol dire che basti fare quello.Devi fare contract testing, quindi devi testare che il microservizio con cui stai interagendo si comporti come ti aspetti che faccia e che tu faccia quello che ti aspetti di fare in risposta ai suoi comportamenti.Nel senso che gli input e gli output non devono cambiare? Esatto.Ma una cosa che spessissimo si trascura, secondo me, appunto è che ci siamo detti prima, va bene, microservizi, ognuno si smazza il suo e ognuno si testa il suo e poi nessuno fa i test end to end.E quello è una roba dove è capitato anche a me di farmi veramente molto male perché dici "eh, ok, questo microservizio è testato, fa quello che deve fare, il microservizio che interagisce con lui fa quello che deve fare e poi però il flusso end to end chi doveva testarlo?" lo stai dicendo alla persona che oggi si è scritto un cazzo di mock server perché in realtà non gli hanno dato l'accesso all'altro microservizio e quindi non poteva fare gli end to end e si ha fatto una cosa assurda io non la farei mai ma l'ho fatta il test end to end sul mock server è giusto, bisogna testare tu il dottore.Abbiamo parlato di testabilità ma abbiamo anche detto che a questo punto se la nostra organizzazione in qualche modo ci spinge a farlo perché è strutturata per farlo, se il nostro dominio è abbastanza vasto per essere diviso, decomposto ai microservizi più piccoli, abbiamo fatto tutto il bel sistema di comunicazione, ma quando si parla di deploy, come orchestra, come li faccio funzionare questi microservizi insieme, come li accendo insieme, come cavolo faccio? Io rido perché sto facendo quel lavoro lì adesso.Sì, sì, no, ma fatti.E sai che non c'è un cazzo da ridere.Li deploy, e quando li deploy, se uno si aggiorna e l'altro no, devono funzionare, non...Lo script deploy è più o meno lo stesso.Quando fai la promotion, dovrebbe andare tutto bene, perché se passi da un environment all'altro che sono uguali, non vedo perché dovrebbe fallire.Poi in realtà le cose falliscono.No, in realtà si tratta tutto del contract che diceva Mattia.Se le API non cambiano e se le cose sono versionate, va abbastanza liscio.però si sta parlando di una serie di...come si chiamano? Di piattaforme mobili che si spostano e aumentano la complessità.Aggiungerei anche, per aprire un altro topic, che tracciare le request che attraversano tutti i microservizi o avere un posto dove tutti i log vanno perché uno deve capire cosa sta succedendo e qual è quello che si è rotto perché capita, diciamo, nella...dove sto lavorando adesso, può capitare che un errore che viene propagato dal servizio B, cioè il servizio A chiama il servizio B, e il servizio A restituisce un errore, e allora ti vai a vedere il servizio A, dicendo "ah, c'è qualche problema, in realtà è stato propagato così, come era dal servizio B, e non c'è traccia di questa cosa".E su questo uno poi ci lavora.- Telemetry, open telemetry, quanto le amo.- Esatto.Però sul discorso del deploy, sono entità indipendenti di software che teledeploy come normalmente, dovrebbe essere un piccolo monolite, non dovrebbe dare problemi con l'altro.Vi racconto un'esperienza che ho fatto nelle settimane scorse.Abbiamo implementato MTLS, che sarebbe il TLS mutuale, cioè dove il certificato che ha il server...Cioè, anche il cliente deve fornire un certificato per autenticarsi.Questo perché, in questo modo, chi riceve la request viene ignorata, è come se il browser presentasse un certificato a lui e dire "io sono il browser di Leonardo Rossi", e lui dice "ok, Leonardo Rossi può accedere a questo servizio".Ecco, fare questa cosa, io mi sono dovuto creare prima una mappa dei microservizi e partire da uno, quello che veniva solo chiamato e non chiamava nessun altro, allora lui poteva fare da server e quindi poi cambiare gli altri client, ma quando poi siamo arrivati a quello un pochino più principale, che è ricevere request da tre e ne passo altri tre, quando devi far quello, hai dei disservizi.Cioè, quando passi da non avere quello, hai qualche minuto in cui si riavviano i microservizi e tutto funziona.e quello fa parte, si dice, per qualche minuto le cose saranno giù.A noi va benissimo, siamo una startup, abbiamo provato in development e quelli che sono in production, per qualche motivo hanno avuto qualche minuto di down.È fattibile? Sì, per noi sì.Per Google o per Amazon, dove questa cosa potrebbe essere qualche 100k di revenue in meno, magari no.Secondo me è interessante questa cosa, perché prima hai detto che tu fai un servizio diverso perché hai identificato il lato business unit che è indipendente e in più puoi anche poi deploiarlo in una maniera diversa e poi scalarlo in una maniera diversa.Sono contento conoscete la parola container, nel senso che ora che si è appena un po' più toccato con mano, non tutto può essere container, a noi tutti servono i container.Quindi alla fine la strategia di deploy credo ci siano delle linee guida che ci siamo già dette, ma nel caso pratico varia infinitamente dal modo di chi ha la porta su Queen6.Avere diciamo la possibilità di andare su container, di essere magari su Kubernetes o su un orchestratore simile e avere quindi tutto quel framework che fa rolling up per te, dove magari puoi fare anche canary, puoi fare blue wine, tante strategie di deployment che ti possono mitigare il fatto che un servizio possa andare giù è una fortuna, ma c'è anche chi questa fortuna non ce l'ha, quindi bisogna effettivamente trovare delle soluzioni che sono più in casa.Questa cosa qui la dico perché spesso nell'infinito mondo delle buzzword, quando si parla di microservice si parla anche di container, si parla anche di kubernetes, si parla anche tanto di queste cose qui, che sono cose che possono stare ben insieme, ma ci sono anche tanti casi in cui non ci sono.E vi posso garantire che anche i più brutti cluster SAP e più buti cluster ANA hanno questa cosa built in da anni e anni e lo fanno in una maniera molto meno frenzia rispetto a come possiamo pensarla oggi.Abbiamo detto che comunque abbiamo una serie di tool che ci permettono, il rilascio e di tirare in piedi tutti questi piccoli pezzi della nostra applicazione se così vogliamo rappresentarla anche se è un modo un po' innaturale per rappresentarla.E se io dovessi, ne abbiamo accennato, l'abbiamo accennato prima, ma se io dovessi voler avere una visione globale di quello che sta succedendo all'interno dei micro servizi quali sono gli strumenti che dovrei utilizzare? ditemeli per favore che poi li devo implementare io stavo googlando i palocchi quindi non ho ascoltato No, dicevo, parlo di observability.Da questo punto di vista quali sono gli strumenti che posso utilizzare per sapere quello che realmente sta succedendo all'interno della comunicazione dei micro servizi? Dipende da quanta voglia hai e da quanti soldi hai, nel senso che ci ci sono dei tool che costano non poco, che fanno APM totalmente.Ci sono diversi modi di farlo, però alla fine secondo me, almeno nella mia esperienza per quel poco di microservizi che ho visto io, con quel poco traffico, una scala relativamente piccola che ho visto io, di fatto il modo più semplice di farlo è equivalente a quello che fai quando debugghi un'applicazione locale e usi le printf per loggare tutto, ed è loggare tutto quello che succede tra tutti i microservizi, quindi loggare tutti i messaggi che si scambiano tra loro.E quindi, così facendo, ricostruisci le saghe, di fatto.Ed è un po' più low cost e anche low effort che mettere in piedi soluzioni di APM che costano molto, come, che ne so, Datadog o New Relic o quelle cose lì.O Sysdig, dove lavora un mio carissimo amico.Però, appunto, è una cosa che è quasi gratis.Nel senso che comunque, vabbè, ok, devi avere un coso che ti aggrega i log, tipo un Grafana o un Kibana della situazione, però...ho un log stash, una di quelle cose lì, però funziona bene.io una cosa che ho trovato molto utile è utilizzare OpenTelemetry per tenere le tracce perché è una cosa che quando si lavora con i microservizi ho visto è che alla fine devi ricostruire il percorso e ricostruire il percorso di una richiesta non è mai cosa semplice se la nostra architettura è composta da tanti microservizi OpenTelemetry io lavoro in Node quindi ha già un moduletto built-in direttamente per Node e quindi io in un modo o nell'altro attraverso l'uso di OpenTelemetry che per me ormai è out of the box quando lavoro con i microservizi ho la possibilità di andare a seguire punto per punto su un'interfaccia chiara e definita quali microservizi ha toccato la richiesta e dove ha fallito questa cosa mi ha fatto svoltare, mi ha letteralmente fatto svoltare perché a quel punto l'azione di debugging, l'azione di fix era naturalmente più incisiva e quindi ecco buttateci un occhio su OpenTelemetry che naturalmente non supporta solo le traces ma ci sono anche le metrics c'è un mondo enorme, prima o poi ne parleremo in uno di questi episodi.Vedo tutti sbracciarvi e a questo punto mi chiedo ci sono mosche, zanzari in giro o è perché volete intervenire? No, allora io diciamo che stiamo registrando questa puntata a giugno 2023, perché c'è scultura nel futuro e ci sono le zanzare, quindi almeno il mio gesto era una zanzare.Domanda, domanda.Ora la faccio io la domanda.Ma quanto è bello avere una CLI interna che ve li espone a tutti questi micro servizi, che ve li fa comunicare, avere gli strumenti per poter testare sulla vostra macchina differenti interazioni tra micro servizi.Ovviamente questa cosa della CLI è una provocazione, non tutti hanno gli strumenti per poter fare, gli strumenti, il tempo e le risorse per avere tutti questi strumenti di database, nonostante, come ho detto, se scegli di fare un pazzo di uzi, ad un certo livello hai una disponibilità di personale e di utili diversi.Ma comunque questa cosa può cominciare da The Docker Compose di ogni progetto che avvii a mano, che è la base e funziona nell'80% dei casi.Io personalmente lavoro così, ma sono solamente tra i servizi, a la gli dell'azienda, della team che vi spiega le cose eccetera eccetera.Voi come fate? Che fate? Ma soprattutto lo fate perché ho conosciuto anche persone che hanno detto no perché non serve, che hanno una visione un po' più holistica del software.No, che non serva, anche qui parlo per esperienza diretta, sarebbe molto utile perché noi non abbiamo per esempio un local environment che riproduce la nostra cloud in questo momento ed è un casino riprodurre un problema che hai anche solo nel nostro development environment senza dover fare un altro deploy con dei console log in più, per cui prima quando si stava parlando parlando all'inizio della suddivisione, uno pensa "ok, già voglio fare i microservizi", i microservizi si portano dietro anche a questa complessità, che sono tracciamento, raccolta dei logging e riproduzione in locale dell'ambiente che volete testare, senza dover per forza usare dei mocking.Quindi, che posso dire? Parti sempre dal monolith e poi dopo vedi.Però questo è un problema che con Docker, come dici te, si risolve quasi tutto, però a volte credo che ci siano delle...cioè, se uno dei microservizi si appoggia a qualcosa di esterno, che di esterno vuol dire un servizio che non gestisci te, fuori proprio dalla tua azienda, un Auth0, per esempio, devi...come dire...ok, non lo puoi moccare, magari, o lo mocki, se no non ci puoi lavorare in aereo ad esempio perché non c'hai la connessione.Questo è un problema che si porta dietro, in realtà a ripensarci anche un monolite che si autorizza con Out Zero ha questo problema.Però nei microservizi è ancora più difficile riprodurre questa cosa, almeno per noi che siamo un'azienda di 10 persone.Mock di Out Zero? E quante volte l'abbiamo vista, Leo? Sì, esatto.Mi rimandi sempre questo "c'è e sono".Poi nel frattempo le PID a zero cambiano, ma te ne accorgi sempre.In realtà è uno dei problemi più grossi quello.Io finora nelle mie esperienze c'erano dei Docker Compose con 24 container che venivano sollevati e facevano tutto il bordello, compreso mock server, i vari docker compose, uno per dev, uno per dev ma dove alcuni servizi non erano mockati oppure che si attivavano, si attivavano e si spegnevano con delle variabili d'ambiente, un bordello fondamentalmente.Ma scusami, no scusa, vai vai.No, una domanda a proposito, voi usate anche eventualmente alcuni servizi di produzione per lo sviluppo? Cioè state lavorando su un microservizio, uno dei cento microservizi, però non vi serve per testare, per fare l'end to end, non vi serve avere il locale, tutto quanto, magari siccome fate soltanto delle get o vi prendete soltanto i dati non andate a scrivere magari lasciate che puntino magari non in produzione ma in un ambiente di staging.In un ambiente di staging sì assolutamente se ci sono alcuni micro servizi in staging mi va bene contattare dal locale sì assolutamente.Produzione no ma per un fatto proprio di dati, cioè nel senso rischio di corrompere, rischio anche di far leggere al dev dei dati che non dovrebbe leggere.Però staging sì, sì, assolutamente, specialmente quando le architetture complesse.Anzi, la nuova frontiera del martello, il martello più così, non so chi di voi l'hanno utilizzato è Telepresence.Telepresence è quella cosa che ora che ve la descrivo è male, cioè è come se fosse un ambiente di sviluppo locale ma nel cluster.Nel senso che effettivamente fa questa cosa che ci stiamo dicendo noi.Voi immaginate di poter deployare il vostro ambiente locale, magari del vostro cluster di staging, in modo da poter interagire con altri servizi, con altri attori che ci sono nel vostro cluster.Quindi sì, effettivamente degli strumenti così esistono e li ho utilizzati.Però ecco anche qui la complessità aumenta esponenzialmente perché significa che metti un altro tool in mezzo, hai una cosa da debagliare in più e vi posso assicurare che quando tu contatti staging e ti si rompe giù poi cominci a dire "aspetta ma è staging che è che è rotto, è quello che c'è oggi che è effettivamente rotto.Quindi alla fine...In consistenza dei dati.In consistenza dei dati.In una mia precedente esperienza abbiamo un cluster Kubernetes locale che veniva tirato su con questo strumento che si chiama Tilt, che potrei immaginare come questo grande Docker Compose, ma in un cluster Kubernetes.Quindi effettivamente se c'è di quei 20, abbiamo anche più di tre tab servizi, però magari dove tu deve lavorare su 4-5 cose e poter dire anche su un cluster con queste 4-5 cose, alla versione di sviluppo build data con il codice che tu avevi sul tuo computer, quindi più o meno riuscivi.Però alla fine, insomma, soffismi, se c'è la possibilità di andare sul servizio che sta su stage, mi risparmio la AMMA, mi risparmio l'estreme.Ma guarda io vi dico per un grossissimo e Carmine ha tirato fuori il rocket science, roba super complessa, io molto più banalmente per un grandissimo e-commerce, veramente grande, grande, grande, ho sviluppato dei microservizi che andavano a querare il servizio in produzione, che era il servizio catalogo che era enorme cambiava ogni pochi secondi e soprattutto che la cui entropia andava ereditata anche nel servizio di staging e di development per cui noi semplicemente facevamo delle chiamate a questo catalogo e avevamo delle API key con lo scope ben indefinito di sola lettura e di alcune entità e basta la cosa ha funzionato e funziona ancora oggi molto molto bene.Ho una domanda, abbiamo detto che la questione dei microservizi è una questione più legata a come è strutturata l'organizzazione aziendale e allora mi chiedo come si distribuisce siccome con i microservizi la knowledge è frammentata come si distribuisce la knowledge riguardante il microservizio e parlo di interface e parlo di non lo so processi secondo voi qual è il modo migliore per farlo e se conoscete qualche strumento per farlo? Allora dipende ovviamente.Il primo strumento che mi viene in mente è usare quelle cose tipo swagger o quei cosi che ti generano la documentazione dell'api esposta via http in maniera automagica in modo che tu possa se non altro avere un un coso da dare a chi si deve integrare con il tuo microservizio per fargli capire come funziona.Però è comunque un tema molto complicato, nel senso che comunque abbiamo detto "ok, un microservizio è un coso che fa una cosa" e chi è che ti dice qual è la cosa che fa? Sta in un documento che nel momento in cui hai finito di scriverlo più aggiornato, sta appunto in una documentazione autogenerata che ti dice delle cose che però non sono esattamente fatte per essere lette e interpretate da un essere umano.C'è una source of truth unica nell'azienda che è un tizio che sa tutta l'architettura, che è l'architetto e che se un giorno lo morde un cane e rimane a casa, l'azienda chiude? Non lo so, è un bel casino, nel senso che comunque appunto il tema di fondo è che hai tante persone che devono condividere informazioni nel momento in cui sono tante, i collegamenti tra tante persone sono tante esponenziali e quindi condividere queste informazioni su tante esponenziali legami è un casino.È così by design.Però io mi sento anche di dire che non è un problema dei microservizi, nel senso che se tu hai un team da 100 persone che lavorano su un monolite, col monorepo e una col base unica, non credo che tutti sappiano tutto.No, ma poi è come utilizzare un'albiberia esterna qualsiasi documentata su GitHub.Uno tenta di utilizzare quella che è documentata meglio, meglio eccetera.Il fatto che sia all'interno dello stesso team della stessa azienda cambia poco.Le best practices sono quelle che si vede nei progetti di Swinsore, nelle libree più diffuse che vengono utilizzate.Quando l'azienda scala talmente tanto, veramente tanto, si ritrova a dover fare delving su centinaia di pagine di Confluence scritte a cazzo di cane e ognuno di noi l'ha fatto turandosi il naso.Una cosa che mi sento di suggerire, ne abbiamo anche parlato qua su Gitbar un po' di tempo fa, è l'utilizzo di software un po' più strutturati per fare questo.Uno di questi può essere backstage uno dei tanti no quindi che funziona o almeno la parte che funziona da software catalog la cosa figa di backstage sta nel fatto che non ti mappa o non ti mostra solo quelle che sono le API quindi quello che diceva Mattia prima il swagger della situazione o la struttura del graphql della situazione o la struttura dei dati che dovrebbero passare attraverso grpc ma ti permette di visualizzare e comprendere le dipendenze tra i microservizi che sono la cosa che l'informazione che 90 su 100 si perde e che è fondamentale quando devi mappare concettualmente quello che sta succedendo nella tua architettura.Quindi dice ok questo questo microservizio questa componente software espone delle API ma consuma queste altre API, dipende da questo servizio o a questi altri servizi che dipendono da loro, dipende da queste risorse per esempio da un database, da un'area di storage, mi viene in mente un S3 della situazione, non un bucket S3 della situazione.Avere questo tipo di software quando l'organizzazione scala diventa secondo me un must perché altrimenti ti perdi altrimenti c'è l'architetto che c'ha tutto su dei file o di disegnini a mano o dei documenti di confluence ma nessuno che riesce a trovare l'informazione e tra l'altro backstage può venire utile anche ne parliamo con francesco un po di tempo fa vi metto la puntata di backstage nelle note dell'episodio quando si devono creare dei microservizi.Data la dimensione, la creazione di un microservizio è una cosa abbastanza consueta all'interno di una grande organizzazione.Un microservizio lo fai spesso.In 15 giorni di lavoro io ne ho fatto 4 di microservizi.e tenere allineati tutti i microservizi diventava faticoso.Allora cosa si fa di solito quando è così? Si crea un bel template su github o su github o su dove siete voi, un pulsantino inizializza da questo repository.Backstage ti dà un modo più strutturato per poterlo fare, creandoti anche già le configurazioni deploy e altre belle cosine per cui è uno di quei tool che in un'ottica di microservizi in un'ottica di azienda grossa può fare la differenza a un costo però che dovremmo sommare al costo dei microservizi siete stanchissimi vedo ormai provati da all'ora e dieci minuti di...No, io non avevo da obiettare, ho nuito in silenzio.Io in realtà mi sono sempre riproposto di dedicarci più tempo a backstage perché secondo me lo trovo come uno strumento molto interessante, però è anche, come dicemmo all'interno della puntata, è anche uno strumento vastissimo che presuppone del carico cognitivo e tipo lo puoi utilizzare in un ecosistema, in un'azienda dove hai quel tipo di esigenze.Quindi è uno di quegli strumenti che difficilmente testi giocando a casa nel side project.No, infatti la mia esperienza con backstage era che proprio quando lavoravo con i microservizi ho detto "oh, ma che figata, sembra quello che serve a noi".Lavorato per un po', l'ho provato un po' e mi sembrava overkill persino per quello che stavo facendo io, che comunque era un'architettura a microservizi piccola.Poi adesso io non c'ero quando avete registrato la puntata su Backstage e magari ne avete parlato, però la sensazione che ho avuto io era appunto che fosse una roba che ti serve se sei Spotify.Se sei anche solo più piccolo magari è overkill.Sì, per esempio una cosa figa è avere chiare le go to person quando lavori in microservizi perché magari stai tirando su il microservizio di un certo coso che sta nel dipartimento Pippo, figlio del sottodipartimento Pluto del dipartimento Pippo dell'organizzazione della region EU e un tool come backstage semplifica quel tipo di comunicazione tra tra cioè non devi andare alla go to person a bussagli la porta e digli oh sei davvero tu o devo andare da qualcun altro.Perché in progetti precedenti mi è mi è capitato di fare 10 15 passaggi prima di trovare la persona giusta questa cosa se automatizzata vuol dire quattro giorni di lavoro di rompere le balle via Teams o via Slack a 70 persone.Però come dice Matteo Mattia può essere overkill io non ci ho dedicato troppo tempo da quello che ho sentito parlare in giro da amici che lo utilizzano hanno detto che ci hanno dovuto investire soldi e tempo per per ostarlo per fare configurarlo bene per la loro organizzazione ma magari può nascere una nuova professione come ci sono i configuratori di gira professionisti ci saranno anche i configuratori di backstage professionisti no? Ma una domanda scusate non l'ho avuto no non non ci ho mai guardato, immagino sia un tool che automatizza determinate cose, ma ci vuole comunque l'intervento umano, dobbiamo comunque tenere aggiornata una sorta di documentazione, magari nei singoli progetti che poi viene centralizzato in una documentazione più generale, no? A diversi moduli in realtà sì, ma si presuppone l'efforto umano.Però avere un punto centralizzato dove c'è tutta la knowledge dei microservizi è senza dubbio comodo e utile.Io ho visto un talk di Francesco Corti, che è stato anche ospite qua poche settimane fa qua a Firenze, dove faccia vedere il tool, e diceva fondamentalmente lo sviluppatore deve avere una tab aperta su Chrome che è l'interna developer portal, che sarebbe questo backstage.Quindi te continui a fare i commit su GitHub, continui a deplorare su AWS e continui ad avere la documentazione, però tutti i moduli ti fanno trovare i commit, lo stato del servizio, se è online o offline, la dipendenza del servizio, la documentazione, tutto nello stesso, come dire, nella stessa pagina.Ovviamente è stato sviluppato con milioni di ore uomo di lavoro, con tutti i moduli, però è un progetto open source e per implementarlo in un'azienda, ci vorrà una business unit che implementa backstage all'interno di questa.Se hai meno di 50 sviluppatori, faccio partire un numero, purtroppo non ti serve perché l'effort è troppo alto rispetto poi ai vantaggi che avresti.Eh sì, devi avere un team di dev-ex interno che ti tira su 'sta roba.questo è quello almeno che diciamo a suo tempo raga io guardavo l'orologio e tipo siamo a un'ora e un quarto tenendo presente che abbiamo iniziato a registrare 40 minuti dopo e tipo l'ora della scarpetta di cristallo e la mia carrozza diventa una zucca quindi secondo me è l'ora di appropinquarci verso la chiusura di questa puntata speciale che è la puntata 0 dove abbiamo parlato di microservizi in un episodio realizzato in collaborazione con Code Motion che darà vita poi a un card collezionabile a un insieme di card collezionabili perché ogni episodio in realtà verrà riassunto all'interno di queste card collezionabili, ognuna col topic appunto della puntata, che potrete collezionare e tenere con voi molto carine che in qualche modo descrivono in una serie di punti quello che ci siamo detti in questa oretta e un quarto di episodio.Ma non finisce qua perché è arrivato il momento tipico e topico di questo episodio e di tutti gli episodi di Gitbar ed è il momento del Paese dei Baloccoli è il momento del Paese dei Balocchi.Chi inizia? Allora ne ho due.Uno è estremamente facile e credo che sia tra l'altro poi uno dei dei motivi per cui abbiamo fatto questa puntata su questo tema con me di mezzo, nel senso che durante gli anni della pandemia Code Emotion ha fatto una conferenza online e hanno avuto la pessima idea di ospitare un mio talk sul Saga Pattern che attualmente è visibile, il video è visibile sul sito di Code Emotion e quindi questo è assolutamente un balocco baloccabile, ma l'altro balocco invece è il libro del Chaos Engineering che è stato scritto dalle due persone che hanno inventato questa cosa dentro Netflix, che si chiama Chaos Engineering ed è molto bello perché il sottotitolo è "System Resiliency in Practice", quindi è assolutamente Gianluca Vacchi approved.Ed è stato scritto dalle persone che hanno inventato il concetto di Chaos Engineering, che hanno scritto Chaos Monkey e racconta un po' tutta questa storia per cui non puoi rimuovere la complessità dei microservizi, non puoi evitare che qualcosa si rompa, che un microservizio sia giù quando ti serve e ti spiega come fare a gestire questa roba.Dai vado io.Ho scoperto un tool che ho utilizzato poco, però me lo sono segnato perché mi può che si chiama Dive, è su GitHub, che permette di poter analizzare un'immagine Docker layer per layer per vedere quali file ci sono e quali...diciamo il file system per ogni layer che viene aggiunto.E a me è servito qualche volta per controllare alcune versioni, controllare cosa succedeva, l'ho utilizzato soprattutto quando le cose non andavano.È un progetto open source su GitHub, funziona bene, molto veloce può servire una volta all'anno però ancora una volta l'anno vi salva diversi grattacapi Vado io allora visto che questa puntata è stata incentrata su architetture microservizi Tante cose belle di alto e altissimo livello vorrei anche fare un invito a non dimenticare il fatto che le più bei il Taj Mahal, i più belli edifici mai costruiti dall'uomo sono comunque fatti di mattoni o di qualsiasi altra cosa, comunque di piccoli tasselli che dobbiamo imparare a mettere insieme.Per cui mi invito a quello di ripartire dalle basi e per questo sto rileggendo in realtà un libro di Mario Cacciaro, Luciano Mammino, "Not the JS, a design pattern".Perché non JS, perché mi piace non JS e questa è una mia colpa, va bene, però il libro spiega anche molto bene le basi, come funzionano le cose e come poi con questa conoscenza costruire le cose belle, perché noi possiamo avere tutta l'architettura bellissima di questa terra, ma se poi usiamo male la libreria per fare le chiamate HTTP ci crolla tutto quanto.E poi Luciano è il nostro amico.No, tantissimi kudos a Luciano che io ho visto recentemente in diverse conferenze dove siamo andati e si ferma sempre a salutare, a fare colazione sempre, proprio bene.Ti interrompi per salutarti.Hai detto salutava sempre? Allora, io ho un balocco che in realtà è estremamente legato a quello che ci siamo stasera.Ho parlato di più servizi, di architettura distribuita, di transizioni distribuite e io vi consiglio The BIM Book.Vedrete che cos'è.È praticamente un estensivo libro che vi descrive come funziona la BIM, che è la Virtual Machine di Erlang.E voi direte "a me che me ne frega la Vittorio Masciniello, probabilmente niente se non tante delle cose che ci siamo detti questa sera, quindi la comunicazione tra nodi diversi, la residenza, la scalabilità, il distribuire il lavoro e le task in maniera distribuita, sono cose che la BIM fa out of Ovviamente è nata per uno scopo ben preciso, che era quello delle telecomunicazioni, quindi aveva necessità di avere tutto questo set di cose built in.Anche se non fate Erlang e se non fate Elixir, è sicuramente un bel primer che vi può far venire voglia di approfondire questi due linguaggi ma vi da anche una panoramica di come la virtual machine riesce a suorchestrare tutte queste cose complesse di cui abbiamo parlato stasera in una maniera assolutamente trasparente per lo sviluppatore.Se magari mi smuto forse potete anche sentirmi.Allora io ho un altro libro si intitola Fundamentals of Software Architecture, an Engineering Approach di Mark Richards e Neil Ford.Bello bello bel libro e tra l'altro acquistando questi libri su Amazon e partendo dal nostro link sponsorizzato ci aiutate ad andare avanti e tra l'altro c'è anche un altro link, anche se non volete comprare questo libro andate nella nota dell'episodio cliccate sul link e a quel punto con gli acquisti vostri di amazon potrete pagare parte delle nostre bollette.Detto questo ritorno rapidamente al libro, libro molto bello, ci permette di vestire i panni di dell'architetto del software e per persone come noi che hanno un imprinting più ingegneristico ci insegna a essere più consapevoli dei nostri dipende.[Musica] Raga siamo arrivati alla fine io scusate ma quando siamo in tanti non riesco più a trattenere le risate perché secondo me le chat di registrazione dovrebbero essere pubbliche a imperitura memoria in modo da giustificare le mie immotivate risate.Detto questo raga avete qualcosa da dire a vostra discolpa di questo episodio.Che se ancora gli ascoltatori non sanno che io dico un sacco di cazzate è un problema loro.Ma ormai credo che siano abituati alle nostre cazzate.Sta diventando un podcast di intrattenimento più che...Lo siamo sempre stati, siamo una betola quindi...No, che poi diciamo sempre quando c'è un ospite di guarda noi non sappiamo nulla siamo per imperare però oggi non ci sono ospiti quindi fate voi cosa può essere venuto fuori.Se volete il podcast che vi informa vi dovete ascoltare.Ha funzionato! Ha funzionato il pulsante di mutuo! Ha funzionato! No, dicevo aggiungo un'altra cosa allora la prossima puntata sarà i monoliti dove inviteremo di akk così chiudiamo il chat.No, avevamo riuscito a non dirlo.Ma in realtà nella chat non leggo altro quindi...no ragazzi dovete credermi le chat di registrazione sono qualcosa di eccezionale.Anzi facciamo così, facciamo un patreon dove mettiamo solo le chat di registrazione che sono un po' come l'only fan delle nostre chiaccherate registratori.Ormai stiamo delirando quindi io vi do appuntamento alla prossima settimana.Ciao ciao ciao ciao ciao Ciao! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica] [Musica] [Risata] [Musica]
