Microservices
È tanto che non parliamo di Services Composition e mi sono appena reso conto che abbiamo lasciato il discorso in sospeso. L’ultima volta che abbiamo toccato l’argomento abbiamo delineato cosa succede quando componiamo informazioni che provengono da più servizi e lo scopo è visualizzare un singolo elemento, come ad esempio 1 prodotto. Cosa succede se dobbiamo visualizzare una lista? Sia nello screenshot di cui sopra, che nel seguente, stiamo visualizzando un insieme di elementi, tutti a loro volta frutto di un processo di composizione. Salta probabilmente subito all’occhio il potenziale problema in cui possiamo...
Ci siamo lasciati a questo punto, con una overview ancora architetturale di come funzionano le cose: Il commento di Raffaele mi da lo spunto per entrare un minimo nel tecnico: Back-end Facciamo un esempio con il mero scopo di capire come potrebbero funzionare nella realtà le cose. Marketing è un nostro sistema interno scritto in .NET che espone un’API tramite WebAPI. Sales è un’istanza di SalesForce che paghiamo profumatamente. Shipping sono i servizi del/i corriere/i espresso/i che ci forniscono servizi e li possiamo interrogare sempre tramite un’API basata su HTTP. Warehouse è...
Dopo aver introdotto ViewModel Composition e prima di parlare di UI Composition, lasciatemi approfondire un attimo la parte di composizione perché è propedeutica a quando inizieremo a parlare di scritture. La volta precedente ci siamo lasciati qui: Dicendo che ViewModel Composition è il risultato del lavoro prodotto da IT/Ops nell’orchestrare il dialogo tra client e servizi. OK, ma come? Quello che succede può schematizzato nel seguente modo Tutto inizia con il client interessato ad una risorsa che possiamo identificare con un URL, come ad esempio “/orders/1” dove 1 nel diagramma di cui...
Fino a questo momento non abbiamo fatto distinzioni tra ViewModel Composition e UI Composition, diciamo che in maniera generica abbiamo trattato di Services Composition. Abbiamo sempre usato un diagramma tipo il seguente senza mai addentrarci nei meandri di cosa succede nel client, a livello di UI. Diventa abbastanza ovvio che ci addentriamo nei meandri dello stack tecnologico, cosa che sappiamo non mi interessa, e che quindi per ora non farò. I concetti però sono la prima cosa che dobbiamo digerire. IT/Ops Nel mondo servizi/SOA si tende a etichettare con IT/Ops tutto ciò che è...
Abbiamo parlato a lungo su questo blog di Services UI Composition, in calce a questo post il dettaglio delle “puntate”. Ad inizio maggio a Bristol ho avuto il piacere di parlare proprio di questo argomento presentando il lavoro (lungo) fatto per passare da una primissima ed embrionale versione ad una finalmente solida ed utilizzabile. La prima versione era nata a supporto di un post scritto sul blog aziendale: The secret of better UI composition. La seconda versione Un secondo passaggio nasce invece come primo passo verso qualcosa di più solido, e avrà come primo scopo quello di...
Siete curiosi di scoprire cosa sia GraphQL e perché sia Facebook che GitHub sembra non ne possano più fare a meno? Venerdì 10 marzo, alle 14, sarò ospite di un webinar gratuito, organizzato da Codemotion, durante il quale faremo una chiacchierata introduttiva a GraphQL, ponendo l’accento sulla interessante relazione che ci può essere con un’architettura SOA. GraphQL and Microservice Architecture Come possiamo progettare la comunicazione tra UI e back-end quando quest'ultimo è composto da decine (se non di più) di Microservices? Abbiamo la giusta separazione e autonomia lato back-end, ma tutto alla...
L’edizione romana del workshop “Microservices development deep dive” punta a rivoluzionare il vostro modo di pensare ad un aggregato, introducendo il concetto di componente autonomo. Una delle cose che affronteremo nel dettaglio, con anche tante demo, è proprio cosa significa modellazione di dominio quando si parla di servizi e componenti per SOA. Se siete quindi curiosi di capire perché come abbiamo immaginato gli aggregati fino ad oggi non è detto che sia il sistema migliore questo è il workshop che fa per voi :-) Se invece è la prima volta che sentite parlare di questo workshop, qui di...
Fate un favore a voi stessi, non fate la corsa al nome (parafrasando la corsa all’oro). Torno sull’argomento importanza del linguaggio perché mi sto rendendo conto che noi tecnici siamo governati dalla frenesia del mettere in ordine, dalla necessità di trovare nel più breve tempo possibile il posto giusto per le cose. Questa stessa frenesia ci spinge, quando modelliamo, a dare molto rapidamente un nome alle cose anche se spesso non abbiamo ancora compreso a fondo. Mai errore fu più grave Modellare, o per dirla in termini Domain Driven Design identificare i boundary, è l’attività più difficile...
Una delle cose su cui ho stressato molto a Codemotion durante il workshop “Microservices development deep dive” e forse ancora di più nella maratona di 50 minuti all’evento KLab è quanto sia rischioso, in un sistema distribuito, condividere dati: All’aumentare della condivisione perdiamo facilità di evoluzione. La ricerca sembra essere uno di quegli argomenti/requisiti che può essere risolto solo ed esclusivamente con un calderone unico in buttare dentro tutto ciò che è cercabile. Ma è veramente così? Quando Google arrivò ed educò gli utenti che una ricerca poteva essere semplice e non...
Ieri a WPC 2016 ho avuto il piacere di parlare di Services UI Composition, tante domande e una bella discussione a seguire. Ovviamente la domanda più gettonata era: OK, tutto bello…ma quando devo scrivere? L’utente in moltissimi casi non deve solo leggere dati, ma ci deve anche interagire, manipolando le informazioni che sono “sparse”sui vari servizi. Il vero segreto non è la tecnologia ma la conoscenza profonda dei processi di business È necessario spendere tempo, tanto tempo, per comprendere a fondo come sono modellate le interazioni nella realtà, quali informazioni sono...
La domanda di Fabio mi spinge a trattare subito IT/Ops: immagina una ui che vede dal canale di lettura una projection di nome SuperOrder che è un mix di quello che server side avviene a fronte dell'evento dal canale di scrittura di OrderUpdated\Created and CustomerUpdated\Created e dalle quali viene creata una denormalizzazione che confluisce in SuperOrder tutto chiaro, il “problema” è che se scegliamo Services UI Composition come strada una projection risultato un mix tra quello che succede in servizi diversi non esiste, a meno che non ci sia uno specifico caso d’uso...
Abbiamo toccato per la prima volta il problema quando abbiamo parlato della differenza tra eventi ed eventi di dominio per tornarci, grazie a Roberto, con un approfondimento e infine per lanciare la stoccata finale: I fat event non esistono. Non abbiamo però mai detto che cosa sia un fat event. Cosa sono Un esempio vale mille parole, nel mondo Pub/Sub delineato da SOA un evento è (in pseudo codice json) una cosa del tipo: { Id: ‘invoicePaidEvent/some-weird-unique-id’, InvoiceId: ‘the paid...
Quando abbiamo parlato di tecniche di recupero delle informazioni abbiamo introdotto il concetto di proxy. GraphQL sembra essere la soluzione di tutti i mali :-) permettendovi di fare due cose, che voglio approfondire: Implementare il concetto di “proxy” come lo abbiamo descritto liberarvi del male assoluto che rappresentato dal versioning delle API REST pubbliche Mentre il primo punto continua a farmi storce il naso, il secondo è in linea con la mia convinzione che i fat events non esistono. Appena iniziamo a parlare di scritture in un modello distribuitoci ritorneremo....
In effetti mi sono dimenticato anche questo :-) Di materiale ce ne è già un po’, sparso: Microservices Workshop, esercizi: https://github.com/Particular/Workshop.Microservices, il repo ufficiale del workshop, gli esempi in quanti tali sono ridotti all’osso e per certi aspetti un po’ lontani da un progetto reale; Composite-UI-Sample: https://github.com/mauroservienti/Composite-UI-Sample, la prima bozza che ha dato inizio a tutto; Services-UI-Composition: https://github.com/mauroservienti/Services-UI-Composition, un lungo e corposo lavoro di evoluzione della prima bozza finalizzato a costruire un esempio molto real world; Post in questa serie: SOA service...
Volete capire come progettare e gestire i cosiddetti “long running busness process” in un mondo basato su Microservices in maniera affidabile ed efficace? Workshop: Microservices development deep dive. Il programma, parte 3: Saga Il workshop è diviso in 4 macro-blocchi, ogni blocco corredato da esempi ed esercizi. La terza parte evolve dalla sessione precedente introducendo il concetto di “long running business process” o se vogliamo, in maniera più volgare, workflow; affronteremo quindi, dal punto di vista architetturale prima e tecnologico poi, concetti come Saga, Orchestrator e Workflow al fine di comprendere a fondo come coordinare...
Abbiamo parlato di IT/Ops e Batching, un ultimo approccio ricade sotto il nome di Proxy. Quello che abbiamo detto è che a fronte di una domanda è sempre possibile identificare un responsabile per la risposta, parlando di tecnologia potremmo quindi dire che a fronte di una richiesta HTTP identificata da un URI c’è sempre un endpoint che si prenderà carico di gestire/orchestrare la risposta. Per uno sviluppatore .NET viene quasi istintivo tradurre la frase precedente in “…a fronte di una richiesta HTTP identificata da un URI c’è sempre una Action MVC che si prenderà carico…”. Ma HTTP...
Abbiamo introdotto una prima modalità di recupero dei dati, modalità che abbiamo definito IT/Ops. Vi ricordo che IT/Ops è un termine abbastanza generico nel mondo SOA che tipicamente viene usato per identificare quei componenti prettamente tecnologici il cui scopo è gestire l’aggregazione di dati. Il problema che vogliamo risolvere credo sia abbastanza chiaro, nel caso nel post precedente ne parliamo in dettaglio. Batching Come dicevamo il sogno sarebbe poter dire al client, ma soprattutto al team di sviluppatori che gestiscono il client: fai quello che vuoi come l’hai sempre fatto. Per capirci meglio immaginate uno scenario basato...
Volete capire come progettare e gestire la comunicazione tra Microservices in maniera affidabile ed efficace? Workshop: Microservices development deep dive. Il programma, parte 2: Pub/Sub Il workshop è diviso in 4 macro-blocchi, ogni blocco corredato da esempi ed esercizi. La seconda parte evolve dalla sessione precedente cominciando ad analizzare quali sono le tecniche di comunicazione intra-Microservices; affronteremo quindi, dal punto di vista architetturale prima e tecnologico poi, concetti come RPC, Pub/Sub e tutto il mondo legato alle code, come ad esempio RabbitMQ, per addentrarci anche nei meandri di DDD parlando di Ownership, Bounded Contexts e...
Volete scoprire come costruire una UI per Microservices efficace, funzionale e facile da manutenere?
Workshop: Microservices development deep dive
Il programma, parte 1: UI per Microservices
Il workshop è diviso in 4 macro-blocchi, ogni blocco corredato da esempi ed esercizi. La prima parte si focalizza su come costruire una UI per i nostri Microservices, partiamo cioè da quello che in apparenza è il problema finale, che come vedremo non è assolutamente l’ultimo da affrontare, ma anzi uno dei primi.
Obiettivi
Il workshop mira a sviscerare dalla A alla Z cosa sono i Microservices, quale sia il loro rapporto con le architetture SOA, come gestire...
Torniamo a noi e prima di chiudere il discorso tecniche di recupero dei dati cerchiamo di dare una risposta al commento di Raffaele. Commento che sottolinea che mi sono dimenticato di una cosa di cui ho parlato al compleanno di UGI e evidenzia come sia fondamentale la storia che vogliamo raccontare, storia che nel caso di questi post su UI Composition non è abbastanza ben definita, piuttosto, si sta trasformando mano a mano che li scrivo. Ciao Mauro, leggo con piacere questa serie ma la domanda mi sorge spontanea. ...
Nel mio peregrinare nei meandri del mondo SOA e in particolare di Services UI Composition mi sto sempre più convincendo che i così detti “fat events” non hanno ragione di esistere. È un’affermazione forte lo so, e non è ancora una convinzione, ne parleremo ancora magari cercando di sviscerare la questione fino in fondo. Tipologie di eventi Se penso alla parola “event” la penso declinata nei seguenti modi: Domain Event Thin Event Fat Event Abbiamo già detto, e approfondito, che Domain Event è...
Prima di dare un’occhiata al commento di Raffaele devo fare un altro passaggio. Nella nostra analisi ad un certo punto abbiamo introdotto e definito i servizi che servono per soddisfare il requisito. Tempo fa abbiamo anche parlato di cosa sia un servizio nel mondo SOA. Abbiamo definito i nostri servizi: Che sono: per forza logicamente separati possono essere fisicamente separati possono essere, tutti o in parte, servizi di terze parti Un esempio Quando un ordine su Amazon è in...
Nei nostri esperimenti con UI Compostiion fino a questo momento abbiamo dato per scontato che ci sia un solo modo per “parlare” con i servizi di backend, come potete immaginare non è proprio così. Di seguito l’elenco dei post che trattano l’argomento: SOA service model decomposition: il requisito SOA service model decomposition: un tentativo SOA service model decomposition: i modelli SOA service model decomposition: i servizi Services UI Composition: Recap Questo post sarebbe dovuto arrivare prima del...
Al compleanno di UGI parlando di “Services UI Composition” ho sottolineato un dettaglio che a pensarci bene è di una banalità disarmante, banalità che a volte è meglio ripetersi un paio di volte di troppo al fine di evitare fantasmagorici castelli di carta, o come dicono i francesi “seghe mentali” :-) In DDD esiste il concetto di Ownership, in SOA esiste il concetto di Ownership, quando si parla di sistemi di messaggistica, Command e Pub/Sub, esiste il concetto di Ownership. Quando si parla di UI? silenzio… In realtà se ci pensiamo bene ogni volta...
Direi che ci siamo, dato il contesto che abbiamo ipotizzato i nostri attori sono i seguenti: Marketing Warehouse Sales Shipping Publishing La cosa importantissima che abbiamo identificato a questo punto, e che è la base fondante di un buon design, sono i rispettivi Owner dei vari modelli. Ognuno degli attori in gioco è responsabile di un pezzetto dell’informazione che vediamo stilizzata nella figura di cui sopra, e “Publishing” è responsabile non del tutto, come purtroppo...
Ci siamo lasciati con un primo tentativo che sebbene praticabile espone comunque il fianco ad sacco di potenziali magagne. Prendiamo la solita immagine che abbiamo usato usato fino ad ora e proviamo ad applicare sull’immagine delle etichette che rappresentano gli attori di cui abbiamo parlato nel post precedente, l’obiettivo di questo esercizio è trovare gli owner, trovare quindi quali porzioni dell’informazione che stiamo visualizzando sono gestite da chi. I nostri attori potrebbero essere i seguenti, potrebbero essercene di più o di meno ovviamente in base al contesto: Marketing Warehouse ...
Siamo partiti da questa immagine: Partendo dall’assioma che rappresenti un requisito espresso da uno stakeholder non tecnico, ad esempio un product owner o una porzione dell’information flow frutto di una analisi di user experience. Kudos a Luca che accoglie la sfida e ci prova: Io direi un ViewModel principale (che so ProductsViewModel) ed una serie di template in base a diversi fattori : origine dei dati, prospettive di evoluzione della UX, necessità di rendering, etc... È sbagliato? non necessariamente, è giusto? non necessariamente :-) dipende? non direi, diciamo...
Workshop 1 Anno 2016 - Introduzione a DotNetCore, Microservice e ServiceFabric Per la serie come potete mancare ad un evento del genere? DotNetLiguria organizza questa serata per (s)parlare di DotNetCore, Microservice, SOA, DDD, ServiceFabric e Docker. Ci si vede li?
A Napoli abbiamo parlato di “Services UI Composition” e per arrivare li siamo partiti dal problema che vogliamo risolvere problema inevitabilmente generato da una corretta implementazione dei dettami di SOA e DDD. Prima di tornare a parlare di “Services UI Composition”, argomento vastissimo e complesso, vorrei fare un escursus sul processo di modellazione che, se basato su DDD e SOA, porta a risultati che per alcuni possono essere inaspettati. Fate un favore a voi stessi dimenticatevi la tecnologia, evitate cioè di cercare immediatamente una soluzione tecnologica a tutto quello che diremo, è controproducente. Inoltre ricordatevi che cosa è un...
Secondo me il problema è tutto li e ruota attorno all’uso del singolare e il problema siamo sempre noi sviluppatori. Abbiamo parlato di bene e male ci siamo lasciati con una domanda, poco tempo fa abbiamo invece dettagliato che cosa sia un servizio. In quest’ultimo periodo mi rendo sempre più conto che quando sento parlare di architettura, applicata ad uno scenario reale, sento sempre parlare di una sola architettura, perché tendiamo a pensare all’applicazione, o peggio ancora al sistema, nel suo insieme. I bounded context di DDD, che possono essere per certi versi accumunati con i servizi di...
Ora che //BUILD ha ufficialmente sdoganato anche in casa Microsoft due concetti fondamentali come Microservices e DevOps è definitivamente giunto il momento di capire come far si che le nostre architetture siano adeguate, pronte e/o adeguabili a questo nuovo mondo che si sta spalancando davanti ai nostri occhi. Quello dei microservices è ad oggi un mondo alquanto fumoso, c’è ancora molta discussione su cosa sia un microservice, se in questa confusione ci mettiamo pure tanta nuova tecnologia, una su tutte Docker, che sta per invadere, o ha già invaso le nostre macchine, le cose si fanno ancora più complicate....
Vi ricordate quando da piccoli giocavate, e magari come me lo fate ancora :-), con il LEGO? Nel 2009 dicevo, quotando me stesso: Se modelliamo il nostro mondo in tanti piccoli, magari molto piccoli e molto tanti…, componenti che collaborano otteniamo un modello complesso, probabilmente molto complesso, ma facilmente testabile, manutenibile, evolvibile, etc… Al tempo il concetto era molto più in linea con il single responsibility principle che con le architetture distribuite ma se oggi mettiamo insieme quel concetto con le potenzialità offerte da una metafora come il LEGO e troviamo qualcosa che...