Dopo un anno di utilizzo e di pratica sul campo, vi spiego che cosa ho imparato sull’architettura microservice e perché è destinata a diventare il paradigma vincente
Partiamo da ciò che c’è di buono. Costruiamo piccoli componenti, ognuno da due a sei servizi circa. La componente PDF, per esempio, che non fa altro che generare file PDF da un template con alcuni dati, oppure una componente “customer” che permette agli utenti di cercare i clienti esistenti.
Questi componenti offrono la giusta dimensione rispetto a numerosi riguardi: codice, comprensibilità, documentazione, test e distribuzione. Quando è stata delineata l’architettura di base per i microservice, sono anche state fissate alcune linee guida: non stiamo costruendo solo piccoli componenti, ma anche piccole applicazioni web per un singolo scopo. Le applicazioni possono comunicare con altre, e possono parlare con i componenti.
Il buono
I componenti gestiscono la propria persistenza e lo storage, e possono anche parlare con altri componenti. Le applicazioni non parlano direttamente allo storage, e i componenti non parlano con lo storage di altri. Per noi, queste linee guida funzionano. I microservice realizzano alcune delle loro promesse: si possono scegliere i meccanismi tecnologici e di persistenza adeguati per ciascuno dei loro componenti. Alcuni componenti persistono per database relazionali (DB2 o SQL Server), mentre altri persistono per database di documenti (MongoDB, nel nostro caso). Abbiamo anche affermato che ogni applicazione e componente ha un proprio modello di dominio. Dato che i nostri componenti sono piccoli, i modelli di dominio sono abbastanza semplici, e quindi gestibili.
Il cattivo
Ma, come sempre, c’è un rovescio della medaglia. Quando ci si avvia a percorrere la strada dei microservice, per qualunque ragione la si trovi vantaggiosa, è necessario rendersi conto che si tratta di un percorso completamente nuovo. Pensiamoci un secondo: se non stai lavorando per Netflix o Amazon, come fai a conoscere qualcuno che si occupa già di microservice? Chi ha attivamente implementato servizi in produzione e a pieno regime? A chi si può chiedere qualcosa?
È necessario essere consapevoli del fatto che si ha realmente bisogno di scavare a fondo e sporcarsi le mani. Si dovrà fare un sacco di ricerca da soli. Non ci sono ancora standard. Ci si renderà conto che tutte le scelte che si adottano in materia di tecniche, protocolli, framework e strumenti, sono probabilmente temporanee. Quando si sta imparando ogni giorno, diventano disponibili o necessarie nuove e migliori opzioni, e le scelte si modificheranno di conseguenza. Quindi, se si è alla ricerca di un kit “stile Ikea” già pronto per implementare i microservice nel modo giusto, forse sarebbe opportuno stare lontani dai microservice per i prossimi cinque-sette anni, e aspettare i grandi vendor, che si getteranno nella mischia abbastanza presto, visto che le opportunità di fare soldi non mancano.
Dal punto di vista del design, si dovrà cominciare a pensare in modo diverso. Progettare piccoli componenti non è facile come sembra. Di solito c’è un sacco di cablaggio da tagliare, e nel frattempo sarà necessario garantire che il sistema non si rompa. Inoltre, ci sarà bisogno di una buona dose di conoscenza di dominio per rendere in componenti i sistemi esistenti.
Alla base, abbiamo scoperto che i componenti non sono così stabili come pensavamo. Di tanto in tanto, fondiamo componenti tra loro, mentre sembrava molto più facile dividere i componenti in altri più piccoli per avere un riutilizzo e un time-to-market più rapido. A titolo di esempio, abbiamo tirato fuori un componente “Q&A” dal componente “Prodotto”, che ora fornisce questionari per altri scopi invece che a farlo solo sui prodotti. E più recentemente abbiamo creato un nuovo componente che si occupa solo della convalida e dell’archiviazione di questionari compilati.
Ma ci sono anche numerose questioni tecniche alle quali bisogna rispondere. Qual è l’architettura di un componente? Anche un’applicazione è un componente? E così via. In effetti, per assicurarsi che i servizi siano più o meno chiamati in modo uniforme, sarebbe meglio creare un piccolo framework che fa le richieste e che si occupa di risposte e degli errori, in modo da gestire questa comunicazione bidirezionale in maniera uniforme per ogni richiesta. Ma vi è anche la necessità di standardizzare parte del codice che si sta scrivendo. La libertà tecnologica è un’ottima cosa, ma se ogni componente è letteralmente implementato in modo diverso, si finirà per avere una base di codice quasi impossibile da mantenere, soprattutto perché è probabile che nessuno sorvegli tutto il codice che viene scritto. Io suggerisco energicamente di assicurarsi che vi sia coerenza nei vostri componenti su aspetti della vostra base di codice che si potrebbero, e probabilmente si dovrebbero, unificare. Si pensi ai componenti dell’interfaccia utente (griglie, pulsanti, pop-up, error box), alla validazione (di modelli di dominio), o al dialogo coi database oppure infine a come sono formulate le risposte dai servizi.
Il brutto
Ma allora quali sono le parti veramente sgradevoli dei microservice? Cominciamo con i percorsi di implementazione. Una delle promesse dei microservice è che questi possono e devono essere implementati e rilasciati singolarmente. Quindi, se attualmente si è abituati ad avere un unico percorso di realizzazione e di implementazione per il sistema che si sta costruendo o estendendo, si potrebbe avere una piacevole sorpresa, in quanto con i microservice si creano percorsi individuali per i singoli componenti. E poi, rilasciare la prima versione di un componente non è difficile. Ma un aspetto che può preoccupare è il controllo delle versioni. Se già è abbastanza difficile dare le versioni per poche applicazioni collaboranti, cosa dire allora di un centinaio di applicazioni e componenti, ciascuna delle quali si basa su una serie di altre per l’erogazione dei servizi richiesti? Naturalmente, tutti i vostri servizi sono indipendenti, come promette il paradigma dei microservice. Ma è solo insieme che i servizi diventano il sistema. Come si fa a evitare di trasformare la vostra bella architettura microservice nell’inferno delle versioni, che poi sembra davvero un discendente diretto dell’inferno delle DLL? A essere onesti, in questo momento non potrei consigliarvi bene su questo argomento, ma un avvertimento amichevole può essere saggio. Abbiamo iniziato con un semplice schema di numerazione a tre cifre (come 1.2.5): il numero più a destra cambia quando i bug minori vengono risolti, mentre il numero al centro sale quando ulteriori funzionalità minori vengono aggiunte a un componente, e il numero più a sinistra cambia quando si distribuisce una nuova versione di un componente con sostanziali modifiche alla sua interfaccia. Lungi da noi l’idea di promuovere un cambiamento regolare delle interfacce, ma almeno sappiamo che succede.
In conclusione
Siamo a uno stadio troppo iniziale della partita? Sì, perché siamo sulla rotta dei microservice da circa un anno. E io ancora non ho capito se ci troviamo sulla scala verso il paradiso o sulla strada per l’inferno. Suppongo, com’è già capitato con i predecessori storici, che finiremo da qualche parte nel mezzo, anche se penso davvero che abbiamo la tecnologia per far lavorare bene questo nuovo paradigma, e non mi riferisco solo a Netflix, Amazon o a qualche società di telefonia mobile particolarmente “hipster”, ma anche alle normali aziende di medie dimensioni per le quali opero. Ma funzionerà? Per essere onesti, non lo so ancora, nonostante o forse anche a causa di tutto l’hype che circonda oggi i microservice. Quello che ho notato è che, data la complessità di tutto ciò che li riguarda, ci vorrà un po’ di tempo prima di avere i primi servizi attivi e funzionanti, e stiamo solo passando da questo punto. Quindi, se c’è una cosa che ho imparato nel corso dell’ultimo anno, è di essere pazienti, una parola che decisamente non era ancora nel mio dizionario. Non cercate di far rispettare tutti i tipi di norme (anche aziendali) se solo non esistono ancora. Cercate di immaginare al volo. Concedetevi di imparare. Procedete un passo alla volta. Basta provare a fare tutto un po’ meglio rispetto al giorno prima. E, come sempre, buon divertimento!
Sander Hoogendoorn
Mentore, allenatore, software architect, sviluppatore, speaker e scrittore. Apprezzato dai suoi numerosi clienti internazionali come grande innovatore nello sviluppo software, è autore del best-seller “This is Agile”. Ha scritto libri anche sul linguaggio UML e il modelling Agile, e ha pubblicato più di 250 articoli su riviste specializzate. Oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo.
Sander Hoogendoorn presenterà a Roma per Technology Transfer i seminari “Agile, Scrum, XP, Kanban e Continuos Delivery in pratica” il 22 aprile 2016 e “Progettare, sviluppare e implementare una Microservices Architecture” il 10 giugno 2016.
