Microservices e Domain-Driven Design

Small Talk con Gianluca Padovani

Trascrizione dello Small Talk del 14 settembre 2022 con Gianluca Padovani per parlare di uno dei best seller del nostro catalogo corso: Microservices Practical Workshop.

L'intervista è stata leggermente modificata per adattarla al formato scritto.

Avanscoperta: Ciao Gianluca, ben trovato. Siamo a un mese dal tuo corso Microservices Practical Workshop, cosa ci puoi dire al riguardo?

Gianluca: È un argomento che mi appassiona molto perché in realtà mi accompagna dall'inizio, da quando iniziai lavorare nel mondo dell'informatica… è bello come alcune cose nascono e sono già così, anche senza dargli un nome. Poi dopo gli si dà un nome, come appunto nel caso dei microservizi, le cose si formalizzano e a volte diventano molto mainstream e super famose.

Ma io, e chi ha partecipato al mio corso lo sa, vedo le radici dei microservizi anche dentro a UNIX, e il modo in cui UNIX approccia alcune cose, ossia proprio nell’idea della decomposizione fatta da Parnas, quindi nelle radici stesse della buona programmazione.

Poi i microservizi hanno formalizzato tutto, chiaramente: quando vai in un mondo legato ai microservizi, ti entrano in campo tutta un'altra serie di problematiche. Però secondo me c’è questo nocciolo che rappresenta anche qualcosa di piuttosto antico.

Avanscoperta: Iniziano le chicche, che sono la parte più bella di Small Talk: rivelazioni, dietro le quinte, cose che non si leggono nella scheda corso.
Entriamo nel vivo: a chi è rivolto il tuo corso? Per com’è disegnato ora, è un corso da remoto di quattro mezze giornate più due ore di follow-up, che sono un’occasione, dopo esserci sporcati le mani e aver visto tanto codice, di ritrovarci dopo circa due settimane per vedere un po' cosa è successo e come va. Questo perché, come si suol dire, a volte va tutto bene durante il corso, poi si va a casa, si prova a mettere in pratica, si sbatte la testa e dopo due settimane si cerca un po' di fare il punto tutti insieme.

A chi è rivolto Microservices Practical Workshop?

Gianluca: Sicuramente è rivolto a chi ha un minimo, e più che un minimo direi, di esperienza nel mondo dello sviluppo. Quindi a chi si è scontrato contro i classici problemi di applicazioni enterprise enormi diventate ingestibili: chi ha il classico mega monolite a cui, io dico sempre, bisogna voler bene, perché non è il nostro nemico: il monolite è una persona che soffre e che noi dobbiamo aiutare a soffrire meno… parliamo quindi di persone che hanno questa montagna di codice che non si riesce mai a gestire e che vuole trovare un modo per incominciare a sciogliere qualche nodo all’interno del monolite.

Queste persone hanno un certo grado di esperienza nella programmazione e, preferibilmente, anche nel mondo del Domain-Driven Design, e su questo ci torneremo, oppure hanno già iniziato ad approcciare i microservizi, ne sono rimaste in qualche modo scottate perché hanno visto solo la parte dolorosa di questo mondo, quando i conti non tornano (classico problema dei microservizi), difficoltà nel fare le transazioni distribuite, ecc.

Chi li vuole approcciare? Chi è rimasto scottato o, e questo è l'ultimo caso, chi magari li sta già usando e vuole vedere un altro punto di vista nell’uso dei microservizi.

Questo perché quando si parla di microservizi si parla di tutto e il contrario di tutto, nel senso che quando si approccia un’architettura a microservizi ci sono molti modi per farla, ci sono vari drive che ti portano ad usarla, e varie necessità: vuoi perché alcune parti le vuoi isolare perché le devi certificare in maniera formale, vuoi perché alcune parti devono essere più scalabili o più efficienti di altre, o alcune parti sono troppo complesse e non le riesci a gestire… quindi ci sono vari modi, varie necessità e varie problematiche che un'architettura a microservizi può risolvere.

Ci sono anche vari modi di implementarla: dal classico modo completamente basato su http, o comunque su un’architettura più classica in cui microservizi si parlano in stile request-response, ad altri modi, che sono quelli che vediamo nel corso, con architetture basate sugli eventi, molto orientate al mondo del Domain-Driven Design, il che ti porta ad affrontare tutto il percorso verso i microservizi in una determinata maniera.

Tempo fa, su LinkedIn c’è stata una domanda che chiedeva: “è necessario fare DDD per fare microservizi?” La risposta formale è no: non è che se non fai DDD non puoi fare microservizi.
Tuttavia, un approccio che io consiglio è quello DDD-oriented, perché ti permette di analizzare il tuo business in una maniera olistica: in questo modo riesci a osservare il tuo problema in una maniera globale, e non solo dal punto di vista tecnico.

E questo secondo me è uno degli altri problemi relativi ai microservizi: si pensa che siano solo una questione tecnica, il che è un errore. Fare microservizi significa approcciarsi al business in modo diverso.

Provando a riassumere: a chi è rivolto il corso? A chi vuole iniziare, a chi ha iniziato ed è rimasto scottato, e a chi li sta usando e vuole provare a vederli sotto un'altra luce.

Avanscoperta: Quando si parla di microservizi, si tira in ballo una delle buzzwords più abusate degli ultimi tempi. La mia prossima domanda vuole provare a restringere un po’ il campo e andare a capire bene e per davvero: cosa sono i microservizi, volendo dare una definizione che vada bene un po’ in tutti i contesti?

Gianluca: Ne parleremo nel corso, ci sono varie definizioni formali dei microservizi, formalizzate da chi li ha inventati. Una definizione che a me piace molto, e che però è molto da consulente, ossia il classico “it depends”, è: qualcosa che ti deve stare in testa. Questo chiaramente è molto soggettivo, nel senso che è legato alle skill del team e del gruppo di dev che ci lavorano.

Se invece la guardi dal punto di vista del DDD, secondo me è quella più semplice perché ti dà dei naturali punti di taglio, che possono essere o un bounded context o un aggregato, ma diciamo che dal punto di vista più agnostico possibile…

un microservizio dovrebbe essere un servizio auto contenuto,

quindi qualcosa ha una serie di dati di cui solo lui è padrone, e solo lui ha la capacità di modificare quei dati, per cui è l’unico padrone del suo stato interno. In qualche modo poi questo microservizio parla con altri servizi in due modi: o utilizzando una tecnica più request-response, classico http che abbiamo menzionato anche prima, o reagendo a eventi che riceve su un classico broker, e fa cambiare il suo stato interno in quel modo.
Quindi tu lo puoi interrogare per sapere qual è un determinato stato, che mantiene solo lui.

Chiaramente, ed è questo il motivo per cui dico che i microservizi non sono solo una questione tecnica, il microservizio deve essere tagliato rispetto alle esigenze di business, perché

uno dei fattori principali per cui si sceglie un’architettura a microservizi è quello di voler accelerare lo sviluppo di feature legate a un determinato bounded context (termine del DDD) o settore di business, il che significa che deve esserci un certo grado di allineamento.

Per esempio, si può avere il microservizio che si occupa del mondo della finanza, o del marketing, all'interno del tuo business, o si occupa dell’onboarding di nuovi utenti, e dev'essere qualcosa che ha a che fare con quella parte, e quindi rimane contenuto a quella determinata parte.

Il team può crescere e può diventare esperto di dominio, perché uno dei fattori di accelerazione nello sviluppo è quello per cui gli sviluppatori riescono a parlare in maniera sempre più efficace con il business, e di conseguenza quando il business ha una determinata esigenza, i dev l’accolgono, senza doversi preoccupare di tutte le parti del sistema, ma solo della loro parte.

Avanscoperta: Partiamo con le domande dal pubblico: “spesso microservices significa scalabilità e flessibilità al costo di una maggiore complessità gestionale. Quando conviene iniziare a considerare la scalabilità come un fattore?”.

Gianluca: Domanda molto interessante perché dietro la parola scalabilità ci può essere tutto e niente. Quando si dice scalabilità, si pensa a una scalabilità tecnica, quindi il fatto che il tuo microservizio possa rispondere a un maggior numero di richieste esterne.
Ma io sotto al cappello della scalabilità metto anche la capacità di scalare dal punto di vista di sviluppo.

Per esempio, se tu hai il classico monolitone, con un mega repository con dentro tutto il tuo codice, e vuoi accelerare su una certa parte di business (reporting, finance, ecc.), perché sai che il tuo business in quella zona lì deve crescere nei prossimi mesi, e quindi vuoi aumentare i componenti del team, questo diventa complicato, perché se vuoi mettere le mani su quel codice devi conoscere tutto il monolite, e fai fatica a isolare alcune parti.
Di consegneuza non riesci neanche a scalare in termini di sviluppo.

Mentre se hai un team molto dedicato a una determinata zona, ed è allineato col business, questo team ne diventa padrone, cioè ha una conoscenza del dominio molto elevata e può aiutare da un lato il business a trovare soluzioni corrette, dall'altro conosce fortemente la sua codebase ed è sicuramente più efficace nello sviluppare nuove feature.

Quand’è che si deve iniziare a considerare la scalabilità come un fattore? Io dico sempre che la scalabilità nasce dal design che tu fai del tuo microservizio, quindi non è tanto una questione di andare a fare fine tuning, che va fatto ma in un secondo momento.

La scalabilità secondo me deve essere pensata dal punto di vista architetturale, e sicuramente un’architettura microservizi ti aiuta a decidere dove scalare, anche banalmente, perché ti permette di dire: “questo microservizio lo metto in replica 10”, e quindi hai 10 istanze dello stesso microservizio che ti rispondono, mentre un'altra parte del tuo sistema, che viene sollecitata molto meno, la puoi lasciare con un’istanza o due. Quindi già questa scelta ti porta nella direzione della scalabilità.

Poi è chiaro che se tutto dipende da come implementi il tuo microservizio: se non sei poi in grado di gestire in maniera concorrente le richieste, per esempio, il fatto di avere molte repliche non serve poi a tanto. E questa è più una questione di design, che però io ormai tengo in considerazione da subito, sennò stiamo parlando di niente.

E quando si parla di aumentare il numero di richieste in modo considerevole, mi chiedo sempre: “ma di cosa stiamo parlando?”. In ogni caso è sempre il business che guida. E mi chiedo, quindi: “hai effettivamente la necessità di servire 2 milioni di richieste al secondo?”, perché se hai quel tipo di esigenze di business, allora è il design, in primo luogo, che deve andare in quella direzione, e questo deve accadere dall’inizio.

Se per esempio hai una start up, e partiamo da subito dicendo che serve rispondere a 2 milioni di richieste, forse stiamo facendo il passo più lungo della gamba. Magari può anche andar bene partire con un’architettura a microservizi… ma meglio non spoilerare un’altra domanda a cui dobbiamo rispondere tra poco.

Avanscoperta: Infatti ce n'è una di Simone, che ringrazio, e che chiede: “il pattern che si vede spesso è che con la start up si parte semplici, con un bel monolite, poi si vede e in caso, se scali, si passa ai microservizi”. È vero?

Gianluca: In teoria, sì; in pratica, quello che succede, nella mia esperienza, è che si va troppo avanti. Quello che capita nelle startup è che si vuole ottenere un MVP immediatamente, e secondo me scegliere un monolite è la scelta giusta: avere a che fare con un business in continuo movimento, dove non solo hai richieste di nuove features su una determinata zona (e su quello i microservizi sono fantastici)... quando sei una startup, soprattutto in early stage, rischi che il business cambi completamente, cioè all'inizio pensi di vendere delle biciclette e poi scopri che in realtà stai noleggiando un servizio di consegne.
Quindi hai cambiato completamente il tuo business. Su questo fronte i microservizi ti frenano, mentre con un monolite, dove hai tutto sotto controllo, sei in grado di fare cambi di business più forti.

I microservizi dovrebbero entrare in una seconda fase. Quello che io dico sempre è che non c'è un momento x in cui passi dal monolite a 50 microservizi: dovresti essere in grado di vedere che a un certo punto di fianco al tuo primo monolite, che in realtà sarà comunque molto piccolo, puoi fare puoi far emergere un secondo monolite, e quindi muoverti verso un'architettura un po' più a microservizi, ma senza averne subito 50, ok?

Perché nel mondo dei microservizi ci sono alcuni step: da 0 a 10 microservizi hai una serie di problematiche, da 10 a 50 o 100 ne hai delle altre, e dopo ne hai delle altre ancora.
Quando rimani in una certa fase, più o meno hai un certo tipo di problematiche.

Quello che io consiglio di fare alle start up è di partire con un monolite, stando bene attenti che a un certo punto puoi introdurre magari un secondo servizio, o un terzo, senza dover andare a prendere per forza tutti i tool che ti servono quando sei a 200 microservizi.

Questo significa che ci sono varie fasi da tenere in conto a seconda della storia in cui si trova un progetto, che è un po' il punto complicato, e per questo spesso io dico: “fatevi aiutare”, perché è complicato per chi non ha esperienza capire quando è il momento di inserire un altro microservizio e posso ignorare tutte le problematiche che ho quando parlo di 200 microservizi.

Quando si parla di 3 o 10 microservizi, non ho problemi di goverance. Quando ne ho 200, invece, ho problemi di governance del tipo: “ma chi è che fa cosa? Cosa fa quel servizio in particolare?” Cioè ci sono 200 cose da capire ed è complicato ottenere informazioni e documentazione, mentre quando hai 5 o 6 microservizi.

Avanscoperta: Un’altra domanda dal pubblico: “banale ma non banale: meglio repository unico per progetto, o repository separati per ogni microservizio?”

Gianluca: Dipende cosa intendi per progetto, una risposta può essere: per me ogni microservizio ha il suo database, e nessun altro microservizio può farvi accesso, è blindato. Il suo stato è quello.
Se vuoi interrogare quel microservizio ci sono altre mille modi, come la chiamata http, mandare un messaggio e così via, ma ogni microservizio ha il suo database, inteso come database logico.

Quindi diciamo che ogni microservizio ha il suo stato interno e ha il suo database, tant'è che dovrebbe essere libero anche di scegliere il tipo di database: il microservizio A ha bisogno del database relazionale, il microservizio B quello documentale, e il C un grafo, perché deve fare relazioni di amicizia o fare determinate cose… e quindi dopo lì si entra nel mondo della governance, dove va stabilito che libertà dare a ciascun microservizio, però diciamo ogni microservizio dovrebbe avere il suo stato, e quindi più repository separate.

Avanscoperta: Ancora una domanda da parte di Simone, a cui forse hai già risposto: “avere sotto un database unico è una bad practice o è plausibile?”.

Gianluca: Dipende. Se creiamo da zero un'architettura a microservizi e quindi stiamo trovando una soluzione a un problema greenfield, avere un database condiviso secondo me è male, ma proprio male male, tra le cose che in assoluto non si fanno.

Discorso diverso se sei in una fase di migrazione, ossia: hai il monolite, sta tirando fuori microservizi, sei in una fase di immigrazione, allora può essere che un microservizio va ad accedere ai dati del database del monolite, o delle due anche viceversa: una parte del monolite va ad accedere ai dati dei microservizi.

Ma deve essere un momento transitorio che col passare del tempo va eliminato. A livello architetturale i database devono essere completamente separati, tranne rari casi particolari in cui un database in realtà è una cache… però come regola generale i database devono essere assolutamente separati.
Questo, ossia il voler condividere il database come scelta architetturale e non come fase transitoria, è uno dei motivi per cui vedo spesso fare del casino, e consiglio vivamente di non farlo.

Avanscoperta: Torniamo a parlare del tuo corso nello specifico. Quattro mezze giornate da remoto, un sacco di pratica ed esercitazioni, non sarà un corso in cui sedersi e guardare una carrellata di slide. Esercizi di gruppo, dicevamo, e da soli. Come bilanciamo teoria e pratica?

Gianluca: C'è un po' di teoria, anche perché col nome “microservizi”... non può mancare. Ma in realtà si poggiano su due grandi pilastri:

1) uno è il poter dividere il problema in sotto problemi, classico della programmazione UNIX, in cui l’esempio più lampante è quando hai cat, che lo metti in pipe (|) con un grep e il risultato lo metti ancora in pipe con un sort, ciò che ottieni è qualcosa dove il risultato è maggiore della semplice somma delle parti:

2) e l’altro è il fatto che un’architettura a microservizi non è altro che un sistema distribuito, e di nuovo ci sono caterve di teoria sui sistemi distribuiti. Chiaramente, in un corso come il nostro non si può fare tutta questa teoria, ma un po di basi su questi due aspetti c’è.

Ma c’è anche molta pratica: partiremo dal cercare questi microservizi, ed è uno degli aspetti più complicati di quando si crea un’architettura microservizi, partendo da una domanda come: “che microservizio devo creare? Come li trovo, questi microservizi? Come faccio a trovarli all’interno del mio business e del problema che devo risolvere?”, che è anche uno dei punti in cui sorgono problemi, perché si tende a riapplicare alcuni pattern mentali che abbiamo, come il classico three-tier architecture, in cui un microservizio si occupa della parte di salvataggio dati, un altro della business logic e un altro ancora si occupa della presentation.

In generale questo approccio è molto complicato secondo me, e anche pericoloso, e di nuovo entra in gioco il Domain-Driven Design, in cui tagliare il business seguendo i suoi naturali confini, che sono classicamente boundaries, bounded contexts e aggregati, dà grande valore.

Per cui uno dei primi esercizi che faremo è sul trovare questi microservizi. Poi incominceremo a fare un po' di esercizi di analisi su come questi microservizi si parlano: ci sono vari modi per far parlare questi servizi.
Se lavorate con me e un po' mi conoscete sapete che io odio il “giusto o sbagliato”, e cerco sempre pro e contro: ogni cosa che si fa ha i suoi pro e sui contro.

Ogni tipo di comunicazione tra microservizi ha i suoi pro e i suoi contro. C’è stata un’ondata di discussioni in cui si diceva che non fosse giusto far parlare i microservizi con http… non è vero: si può fare, e se lo fai ti esponi a determinate problematiche ma hai anche determinati vantaggi. Se scegli un approccio completamente basato sugli eventi, avrai altre problematiche.
Nel corso quindi ci saranno un po’ di esercizi su questa parte.

Proveremo anche a entrare e scrivere un piccolo microservizio, quindi una volta trovato proveremo a implementarlo. L’esempio durante il corso sarà fatto con TypeScript, ma siamo a un livello abbastanza generale, per cui quindi chiunque abbia un minimo di conoscenza dello sviluppo può metterci mano, e da lì proveremo a farlo evolvere rispetto tutte le problematiche che poi capitano nella realtà.

Per esempio: quando hai tutti i microservizi, come fai a ottenere uno stato globale del sistema? Come fare a rendere alcune parti più performanti (perché magari quella parte del sistema deve andare un po’ più forte)? Cosa succede una volta che ho trovato un numero crescente di microservizi? Come ne gestisco le problematiche?

Ci saranno varie parti sia di teoria che di pratica. Spero di aver trovato il giusto mix perché odio un po' le ricette e gli approcci prescrittivi, preferisco dare una ricetta in meno ma spiegare perché quella ricetta lì funziona, o meglio: quando quella ricetta funziona, e quindi presentare anche scenari e use case, in modo che dopo ognuno possa calarla nel proprio dominio e nella propria quotidianità.
È fondamentale capire le basi e perché si è fatta una certa scelta, e non solo “mi han detto di fare così”.

Avanscoperta: Nel corso di questa intervista abbiamo parlato di microservizi e Domain-Driven Design, un connubio di cui hai parlato anche in un capitolo del libro corale Cronache di DDD, pubblicato da Avanscoperta e uscito da qualche mese in digitale e cartaceo.
Oggi ho sentito spesso parlare di esigenze di business e codice che devono andare a braccetto e in questo sappiamo che DDD è fondamentale.
Ci puoi dire qualcosa di più sul rapporto tra DDD e microservizi?

Gianluca:

DDD offre tutta una serie di strumenti che facilitano l’entrata nel mondo dei microservizi per i neofiti: c’è tutta una serie di concetti che puoi prendere quasi così come sono, se li consideri in maniera astratta, e riportarli nel mondo dei microservices, ed è tutto molto naturale.

E questo è uno dei primi vantaggi che io vedo. Concetti come aggregati, entity, bounded context, e anche il DDD nella versione CQRS ed event sourcing, secondo me ti aiutano ad analizzare e a sviluppare i tuoi microservizi.

Una cosa non fondamentale ma secondo me di grande valore nel Domain-Driven Design è che ti dice dove potresti avere problemi, cioè: se il DDD ti dice che questo è un aggregato, significa che a livello di business quella parte lì deve cambiare in maniera atomica, transazionale. Se tu a livello di microservizi la vai a spezzare, ogni microservizio avrà il suo boundary transazionale.
Quindi tu stai dividendo una cosa che a livello di business dovrebbe stare insieme, e quindi questo è già un segnale di allarme molto importante.

DDD ti dà tutta una serie di indizi su come andare a trovare i tuoi microservizi e su dove ci potrebbero essere dei pain point, quindi le zone un po' più dolorose cui devi sempre fare molta attenzione.

E di nuovo, DDD allinea il business con la parte tecnica, che è uno dei suoi cavalli di battaglia, nonché una delle cose che spesso nel mondo dei microservizi si sottovaluta, ma che è assolutamente necessaria.

Se un'azienda vuole abbracciare i microservizi deve fare anche un minimo di riorganizzazione aziendale. Non puoi avere 50 microservizi e 10 team e tutti possono toccare tutti i microservizi: così stai facendo un mezzo monolite cammuffato.

Serve invece che conoscenza e ownership di determinati microservizi siano affidate a determinati team, e in questo DDD è fondamentale, perché allinea esigenze di business a esigenze tecniche.

Avanscoperta: Abbiamo accennato poco fa al nostro libro, pubblicato su Leanpub (digitale) e Amazon (cartaceo), chiamato Cronache di Domain-Driven Design, un libro corale nato anche dall'esperienza con le conferenze on-line organizzate da DDD Open, dove Gianluca ha contribuito con un capitolo intitolato “Microservizi e DDD”.
Ci vuoi raccontare qualcosa su questa esperienza di scrittura?

Gianluca: Volentieri. Avevo esperienza di scrittura di qualche blog, articoli, ma non ho mai affrontato la stesura del capitolo di un libro. È stato molto interessante, anche perché comunque è stata una scrittura corale, guidata da Avanscoperta, quindi ci avete messi tutti insieme, e il bello è stato sviluppare uno stesso argomento ma da diversi punti di vista.

Io ho portato quello dei microservizi perché c'ho lavorato e ci sto lavorando tanto e ci trovo un grande valore. Consiglio la lettura del libro o dall'inizio alla fine, perché veramente vedi tante storie, oppure anche semplicemente a spizzichi e bocconi, perché ogni storia e ogni capitolo rappresenta un punto di vista diverso su DDD, inizia e finisce, quindi potete trovare grande valore da ogni capitolo, a seconda delle esigenze e interessi.

Il capitolo iniziale di Alberto Brandolini è molto interessante, si parte dalle basi su terminologia e altri aspetti fondanti di DDD e di ciò che si parla nei capitoli successivi.

Nel mio capitolo parlo di come DDD può essere usato in vari modi nel mondo dei microservizi. C’è un esempio in cui DDD non è usato in modo consistente, ma come feedback per non aaver fatto troppi errori: c’erano forze che spingevano a separare alcune cose, e DDD è stato usato un po’ come cartina tornasole per fare emergere eventuali problemi…
Oltre al mio capitolo ci sono tante altre storie, per cui vale davvero la pena leggerlo!

Avanscoperta: Sono sette storie più una bonus track di Matteo Baglini su DDD e Functional Programming, oltre al già citato capitolo introduttivo di Alberto Brandolini… un libro corale con varie storie e punti di vista diversi su DDD.
Un grazie enorme da parte di Avanscoperta per aver contribuito a un libro che non contiene dogmi, ma piuttosto storie di vita, casi reali di come avete fatto a usare DDD nel vostro lavoro.

Due domande per chiudere: “microservizi può voler dire anche anche possibilità di eterogeneità dello stack, come dire: scelgo il linguaggio o il framework giusto nel posto giusto… ma spesso i CTO vedono in questa eterogeneità il male. È vero?”.

Gianluca: La risposta è “dipende”. O meglio: sì e no.
Io sono CTO di un’azienda, e avere all'interno della propria azienda 18 linguaggi diversi è chiaramente un problema, perché non puoi avere tutte le persone fluenti su tutti i linguaggi, quindi entrano in gioco tutta un'altra serie di problematiche molto forti.

Per esempio, capita che hai un microservizio scritto con un linguaggio X dove solo due persone possono metterci le mani. In questo modo stai perdendo tutto il valore di scalabilità in termini di feature di cui parlavamo prima, quindi ti chiedo: dov'è il valore di fare microservizi?

Secondo me il punto di eterogeneità sullo stack va visto in quest’ottica: all'interno di un'azienda sana, ci dovrebbero essere sempre tre linguaggi. Il linguaggio vecchio, che nessuno vuole più usare e che si sta dismettendo; poi c'è il linguaggio attuale, quello che usi per affrontare qualsiasi problema incontri; e poi c'è il linguaggio nuovo, che è quello che il team o l'azienda sta sperimentando, ed è quello che probabilmente in futuro diventerà il linguaggio dominante (il secondo, in questo esempio), e così via.

Questo dovrebbe essere sempre come una ruota che gira in un'azienda sana, o in un reparto sano, diciamo così, poi dipende dalle dimensioni di un'azienda.

Se tu hai un unico monolitone, fare quest'operazione diventa piuttosto complicato. In un mondo a microservizi, questa operazione diventa molto più semplice, perché hai magari un numero di microservizi nel linguaggio vecchio, e questo numero deve essere sempre basso, la maggior parte dei microservizi nel linguaggio dominante, e alcuni microservizi nel linguaggio nuovo.

Sperimentare un nuovo linguaggio o una nuova tecnologia in un mondo a microservizi è molto più semplice. Puoi provarlo in uno o più microservizi e se non ti piace è molto più facile fare rollback. Anche l’aggiornamento di una libreria o della versione stessa linguaggio risulta molto più semplice e graduale. In un monolite l’operazione è globale e spesso non è così semplice.

Un altro esempio che facevamo prima era quello dei database: ogni microservizio può avere il database che gli serve, però se il database relazionale di riferimento è sempre diverso, averli tutti diversi ti crea molti problemi. Meglio scegliere un database relazionale di riferimento. Idem per il documentale.

Se stai introducendo i microservizi in azienda, non aggiungere anche un nuovo linguaggio. Parti da quello che conosci già: prima ti occupi dei microservizi, poi pensi al resto. Se invece già li usi, introdurre un nuovo linguaggio sarà facile.

Avanscoperta: Ultima domanda da parte di Simone, che ringraziamo: “framework consigliati per microservizi node.js?”.

Gianluca: Ne ho visti alcuni ma sinceramente non me la sento di consigliarne perché non li ho mai provati in produzione.

In generale non sono un grande amante dei framework, preferisco le librerie, e qui si potrebbe aprire un dibattito su cosa è un framework e cosa è una libreria… sinceramente non saprei cosa consigliarti.

Uno dei vantaggi dei microservizi e DDD è che se conosci la teoria poi implementarla diventa abbastanza abbastanza semplice e forse un preframework non ti aiuta più di tanto.

Imparare i microservizi avendo un framework e non conoscendo la teoria secondo me è pericoloso, perché i microservizi sono pronti a morderti in ogni istante. Quindi è meglio prima conoscere la teoria e poi dopo magari decidere se quel framework li fa bene ed è in linea con le tue esigenze.

Cover photo: Colin Lloyd su Unsplash

Small Talk con Gianluca Padovani: il video - il podcast.

Learn with Gianluca Padovani

Gianluca è il trainer di Microservices Practical Workshop.

Vuoi continuare a leggerci? Iscriviti alla nostra Newsletter 📩 (disponibile in italiano e in inglese).
Ti faremo compagnia ogni venerdì mattina. ☕️

La lista completa dei nostri corsi: Avanscoperta Workshops.