SOA
È 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...
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...
Alessandro Melchiori da qualche settimana millanta che avrebbe scritto dei post inerenti all’argomento Services UI Composition, ecco millanta :-D Forza Ale pubblica qualcosa! Per cercare di smuovere ancora un po’ le acque sto preparando una nuova sessione che al momento è così definita: Tutti i nostri aggregati sono sbagliati Inizia sempre tutto bene, il requisito è semplice e l'implementazione procede senza intoppi. Poi i requisiti aumentano e ci ritroviamo con una strana sensazione allo stomaco e con la necessità di introdurre alchimie tecnologiche che non ci piacciono, ma non sappiamo...
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 ...
Lo dico una volta per tutte: I microservice sono una cagata pazzesca. L’aspetto a mio personalissimo modo di vedere problematico e che porta troppo spesso ad errori di design madornali è che la teoria dei microservice confonde: gli aspetti di design (SOA) con gli aspetti di deploy con gli aspetti infrastrutturali legati al come garantisco alta scalabilità e alta affidabilità infine siccome non era abbastanza detta anche un assioma sulla dimensione. I microservice, se interpretati con il minestrone li sopra, sono una cagata pazzesca....
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?
Quest’anno avrò il piacere e l’onore di essere parte del team di speaker della CloudConf 2016 che si svolgerà a Torino il 10 marzo. L’argomento è uno dei miei cavalli di battaglia oltre ad uno di quelli che mi sta più a cuore: The road to a Service Oriented Architecture (SOA) is paved with a message based infrastructure One of the options on the table when implementing a Service Oriented Architecture (SOA) is based on messages and an enterprise service bus (ESB), this talk will introduce messaging basic concepts, drive you...
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...
Il commento di Roberto al post che parla di `domain event` e di commistione degli stessi con il concetto di `event` in Pub/Sub mi porta a fare una considerazione: Un sistema complesso porta con se delle complessità, direi che è quasi lapalissiano. Quello che vogliamo evitare come la peste è che le complessità si tramutino in complicazioni che hanno il solo effetto di ritorcersi contro il sistema stesso. La complessità purtroppo difficilmente la possiamo evitare, probabilmente la possiamo arginare, ma la cosa importante è avere gli strumenti che ci permettano di capire...
Anche quest’anno come tanti amici avrò il piacere di parlare a WPC. La sessione ha come obiettivo comprendere cosa vuol dire progettare un’architettura service oriented (SOA), quali sono i vantaggi e le problematiche tecniche che dobbiamo affrontare e come il ServiceBus di Azure sia una delle tecnologie fondamentali per muoverci nella direzione giusta. Giorno: Martedì 1 - Orario: 17:45 - 18:45 - Sala: Sala Verde
L’acronimo SOA sta per Service Oriented Architecture, Architettura Orientata ai Servizi. È fondamentale comprendere che quando si parla di servizi in un contesto SOA si parla di servizi logici non fisici, quindi non fate l’errore, peraltro molto comune, di pensare a servizi nel senso di Windows Service. Spesso mi capita di sentire persone commentare cose del tipo: No, noi possiamo usare SOA perché non vogliamo complicarci la vita con il deploy di molti servizi. L’architettura non ha nulla a che spartire con il deploy fisico, semmai l’architettura è in grado di aprire...
…e non avete mai osato chiedere.
DotNetCampania Workshop: SOA, Messaggi e Microservices
“Le moderne applicazioni software necessitano di architetture avanzate per poter garantire requisiti quali la scalabilità, modularità, manutenibilità. Soprattutto la richiesta della scalabilità ha portato all'idea di applicazioni che utilizzino un insieme di "microservizi" pubblicabili in maniera indipendente ma in grado di comunicare tra loro tramite scambio di messaggi.
L'associazione culturale DotNetCampania ha organizzato per il 16 Ottobre 2015 a Napoli presso ReWork (isola E2, Centro Direzionale) una giornata completamente gratuita dedicata ai Messaggi e ai Microservizi nella quale speaker di rilievo internazionale ci introdurranno a questa...