Bertelliiii…self-management ne abbiamo?


Parafrasando: https://youtu.be/N6uUeh8IDqo?t=127

Trovo che sia talmente importate che vale un post. Assolutamente da leggere, scettici in particolare: 7 cose (belle) che succedono quando il capo non controlla.

Ma anche:

Se dovessi riassumere i 4 post scegliendo una frase userei questa:

Chi critica un cambiamento di solito non ha speso alcuna energia per realizzarlo.

Cambiare è difficile.

Direi lapalissiano. Meno lapalissiano è che non esiste la ricetta giusta per il cambiamento che vogliamo in un certo contesto.

Se il vostro obiettivo da neopatentati è guidare come un pilota di Formula 1, non c’è una ricetta giusta per voi e non vi basta osservare, anche in maniera super dettagliata il risultato finale per imparare come si fa.

Il percorso da neopatentato a pilota di Formula 1 lo dovete fare tutto, coadiuvati nel vostro cambiamento da linee guida, non una ricetta, e osservazione del risultato finale al fine di carpire dettagli importanti, dettagli che probabilmente saranno sempre più utili più vi avvicinate al risultato finale.

Questo in soldoni vuol dire che il percorso dal punto dove siete oggi alla destinazione scelta lo dovete fare tutto.

La meta può essere fuorviante

Nell’esempio di cui sopra abbiamo in apparenza un obiettivo preciso, in apparenza perché durante il nostro percorso evolutivo potremmo scoprire che il pilota professionista di rally ci attira di più e a fronte di un cambio così radicale, nonostante siano tutti e due piloti professionisti di macchine da corsa, il percorso deve necessariamente cambiare.

Questa cosa è ancora più vera quando parliamo di self-management, provare per credere. Dire a freddo voglio passare da un’azienda tradizionale, fatta di gerarchie rigide e manager (sto iper-semplificando) ad un’azienda auto-gestita è la peggior cosa che potete fare a voi stessi, perché il risultato sarà che tutte le forze punteranno ad un obiettivo noto cercando di seguire una ricetta e osservando e cercando di replicare nel dettaglio quelli che sono i modelli di riferimento.

Non funziona. L’unica cosa che potete dire è: Non voglio più un’azienda tradizionale.

Una volta che il problema è condiviso può iniziare il lungo e faticoso percorso di cambiamento alla ricerca di quella che è la vostra destinazione. Ovvio che osserverete e cercherete di carpire cosa hanno fatto gli altri, ma il tutto dovrà essere filtrato, adattato e infine calato nel vostro contesto.

Lungo, faticoso e lastricato di insidie. È un fatto, non scappate, la ricetta per il successo non esiste.

Adesso vado in vacanza. Ciao.

author: Mauro Servienti | posted @ mercoledì 21 settembre 2016 7.41 | Feedback (1)

Services UI Composition - tecniche di recupero delle informazioni: Proxy


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 non è ASP.Net MVC, nulla ci vieta, ad esempio, di piazzare davanti al nostro bel web server un reverse proxy, come ad esempio nginx, che ci permette di fare una serie di cose alquanto interessanti:

  1. prendere in carico la richiesta HTTP e in base ad una serie di regole decidere chi sia responsabile di gestirla
  2. data la risposta del responsabile, risposta che può contenere una serie di TAG/Attributi custom, applicare altre regole per decidere se ci sono altri attori che devono partecipare a quella risposta
  3. invocare gli altri attori
  4. aggregare le risposte così ottenute per comporre una risposta HTTP completa

È molto semplice e lineare, e se lo volete vedere in azione vi consiglio questa bella sessione del Team di Auto Scout 24.

È ancora più semplice: è tutto oro quel che luccica?

Come al solito non esiste la soluzione definitiva. Un reverse proxy come nginx è ovviamente un approccio interessante, approccio che porta con se tanta semplicità apparente e un paio di insidie nascoste, che il sottoscritto tende ad identificare sotto il termine di Orchestrator. E se a qualcuno si sono rizzati i peli sulla schiena pensando a BizTalk ha pensato bene.

All’aumentare della complessità le regole che abbiamo citato diventano il collo di bottiglia della soluzione di cui sopra, non necessariamente in termini prestazionali, quanto piuttosto in termini di gestione e complessità. Abbiamo cioè un robo che alla lunga diventerà il centro della nostra attenzione, robo in cui sarà concentrata tanta logica di business nonostante il robo non sia assolutamente pensato per gestire logica di business.

Ma anche un reverse proxy resta un possibile approccio che in certi scenari potrebbe rivelarsi semplice e diritto al punto con pochi fronzoli.

Post in questa serie:

Piccolo spazio pubblicità:

Tratterò di questi temi, e molto altro ancora, in un workshop durante l’edizione milanese di Codemotion 2016: Microservices development deep dive.

author: Mauro Servienti | posted @ lunedì 19 settembre 2016 8.15 | Feedback (1)

Services UI Composition - tecniche di recupero delle informazioni: Batching


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 su una Single Page Application, quello che sarebbe bello è evitare di avere per forza il concetto di IT/Ops nel client e lasciare che il client possa emettere tutte le richieste http che vuole e queste vengano in qualche modo raggruppate come meglio possibile.

Si-Può-Fare <cit.>

Come al solito un’immagine vale mille parole:

image

Quello che succede è “abbastanza” semplice:

  1. Ottengo la lista delle chiavi degli elementi che devo visualizzare
  2. Notifico il mondo client che la lista di chiavi è pronta
  3. Ogni componente client emette tutte le richieste http che vuole
  4. Il “client side request tracker”
    1. intercetta, ogni framework per SPA vi permette di farlo, tutte le richieste uscenti
    2. accumula le richieste su base temporale, quindi fintanto che per x millisecondi non c’è una richiesta, accumulo
    3. Sfruttando il supporto di HTTP per il batching emette una richiesta HTTP batch
  5. La risposta che torna indietro è automaticamente gestita da HTTP e spacchettata

È molto, ma molto, più semplice: è tutto oro quel che luccica?

Direi che la semplicità della cosa è evidente, se non altro superficialmente evidente. Ci sono due insidie però che devono essere attentamente valutate prima di scegliere questa strada oppure quella basata sui concetti di IT/Ops:

  1. Nel raggruppare le richieste HTTP uscenti bisogna tener conto della destinazione, ergo non possiamo banalmente raggruppare, ma dobbiamo raggruppare ciò che va verso Shipping con Shipping e Warehouse con Warehouse, non è complesso ma come sappiamo il diavolo sta nei dettagli
  2. Una volta che abbiamo raggruppato client side, abbiamo solo spostato il problema, è questa è una rogna:
    1. La richiesta HTTP Batch arriva al server
    2. Il server in maniera trasparente la “spacchetta” e invoca le risorse come se fossero richieste fisicamente separate
    3. Questo comporta che se stiamo richiedendo 10 descrizioni di prodotti diversi, abbiamo 1 richiesta HTTP uscente, ma 10 diverse esecuzioni server side e una risposta HTTP. Le 10 esecuzioni server side sono nuovamente il select n + 1 da cui stiamo scappano

L’unica vera soluzione è quindi scrivere, se la tecnologia server side lo consente, un “HTTP batch handler” che sappia come gestire questo scenario. Ecco, io personalmente, eviterei anche.

Ci sono ancora due possibili approcci che sono una variazione sul tema IT/Ops o Batching, approcci che per certi versi possiamo raggruppare sotto il cappello Proxy. Un po’ di pazienza e svisceriamo anche quello.

Post in questa serie:

Piccolo spazio pubblicità:

Tratterò di questi temi, e molto altro ancora, in un workshop durante l’edizione milanese di Codemotion 2016: Microservices development deep dive.

author: Mauro Servienti | posted @ venerdì 16 settembre 2016 8.06 | Feedback (0)

"Microservices development deep dive" @CodemotionIT in Milan: Pub/Sub


Volete capire come progettare e gestire la comunicazione tra Microservices in maniera affidabile ed efficace?

Workshop: Microservices development deep dive.

codemotion-workshop

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 Aggregati.

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 la comunicazione tra Microservices e tutte le problematiche legate al deploy. Ponendo attenzione anche ad un dettaglio spesso dimenticato come la necessità di visualizzare informazioni provenienti da diversi Microservices su una singola UI, coerente e consistente.

La logistica

Il 24 Novembre, durante l’edizione milanese di Codemotion 2016 avrò il piacere e l’onore, oltre che l’onere, di erogare il workshop “Microservices development deep dive”.
Onere, ed onore, perché è la versione italiana del workshop che noi di Particular generalmente facciamo con Udi Dahan, il nostro CEO, in inglese in giro per il mondo.

Per maggiori informazioni e iscrizioni: http://milan2016.codemotionworld.com/workshop/microservices-development-deep-dive/

author: Mauro Servienti | posted @ giovedì 15 settembre 2016 7.30 | Feedback (0)

DevOpsHeroes, 29 ottobre, Parma.


Sono felicissimo di poter partecipare a DevOpsHeroes, il 29 ottobre a Parma.

DevOps e scelte architetturali: due scenari reali

DevOps è principalmente cultura aziendale e di team, DevOps è una nuova visione in cui alcune di quelle che sono le barriere tra mondo dello sviluppo e mondo operations vengono abbattute al fine di generare sinergie inimmaginabili prima.

Vorrei raccontare due esperienze vissute in due scenari molto diversi tra loro, due scenari in cui DevOps è stato da un lato il traguardo di un processo evolutivo dal monolite ingestibile a SOA/Microservices e dell'altro invece DevOps è stato il motivo scatenante finalizzato a superare tutta una serie di ostacoli amministrativi e burocratici che rendevano impossibile il deploy in produzione.

Come si evince dall’abstract la sessione verte a raccontare due esperienze di vita vissuta, come direbbero a Pomeriggio Cinque con faccia contrita, esperienze che per motivi diversi hanno portato sia a DevOps che ad implementare un’architettura basata sui dettami di SOA.

O è il contrario? È SOA che ha portato a DevOps? :-)

Vi aspetto.

author: Mauro Servienti | posted @ mercoledì 14 settembre 2016 7.07 | Feedback (0)

…e uso AdBlocker.


Ciao mi chiamo Mauro, vivo in pieno Digital Divide e uso un AdBlocker.

In perfetto stile anonima alcolisti ammetto che senza un AdBlocker la mia vita online, in particolare quella da lavoratore remoto, sarebbe ben peggiore di quello che è.

image

Non me ne vogliano quelli di Milano Today, ma loro malgrado sono stati il sito che mi ha fatto saltare all’occhio il problema.

Ebbene si, il 45% (86 in termini assoluti) delle richieste HTTP fatte, per caricare la sola home page, viene “usato” per operazioni relative alla pubblicità e al tracking. Io tendo a comprendere che la pubblicità sia una fonte di guadagno importante però mi sa che stiamo superando il limite.

full-mailbox

La banda è la mia e nella condizione di digital divide che vivo quella banda è preziosissima. Ripeto la pubblicità è probabilmente importante, dico probabilmente perché mi sembra di leggere che l’efficacia sia dubbia, ma forse stiamo esagerando.

author: Mauro Servienti | posted @ lunedì 12 settembre 2016 8.03 | Feedback (0)

"Microservices development deep dive" @CodemotionIT in Milan: UI-Composition


Volete scoprire come costruire una UI per Microservices efficace, funzionale e facile da manutenere?

Workshop: Microservices development deep dive

codemotion-workshop

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 la comunicazione tra Microservices e tutte le problematiche legate al deploy. Ponendo attenzione anche ad un dettaglio spesso dimenticato come la necessità di visualizzare informazioni provenienti da diversi Microservices su una singola UI, coerente e consistente.

La logistica

Il 24 Novembre, durante l’edizione milanese di Codemotion 2016 avrò il piacere e l’onore, oltre che l’onere, di erogare il workshop “Microservices development deep dive”.
Onere, ed onore, perché è la versione italiana del workshop che noi di Particular generalmente facciamo con Udi Dahan, il nostro CEO, in inglese in giro per il mondo.

Per maggiori informazioni e iscrizioni: http://milan2016.codemotionworld.com/workshop/microservices-development-deep-dive/

author: Mauro Servienti | posted @ venerdì 9 settembre 2016 10.46 | Feedback (0)

Services UI Composition: consistenza eventuale


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.

image

Ciao Mauro, leggo con piacere questa serie ma la domanda mi sorge spontanea.
In questo caso, non avrebbe senso esporti in GET una Projection, magari un bel DTO che rappresenta la tua riga template di dati da visualizzare?

Sbagliato?

No. Come ho già detto più volte quando si parla di architettura, in particolare, non ci sono scelte giuste o scelte sbagliate. Le scelte sono da calare in un contesto e in base al contesto possiamo fare valutazioni.

Se ho ben compreso il commento di Raffaele, nel caso sono più che lieto di essere smentito, possiamo rappresentare la cosa in questo modo:

image

Il diagramma li sopra funziona alla perfeziona, ma:

  • Ci obbliga ad introdurre un attore che non ha nulla a che con il business ma ha solo un ruolo tecnico, alla fine è una sorta di enorme cache;
  • Introduce un “single point of failure” obbligandoci a rendere quell’elemento altamente disponibile, cosa non necessariamente semplice;
  • Ci obbliga ad abbracciare il concetto di consistenza eventuale;
  • Ci impone di introdurre nuova infrastruttura per capire come “sincronizzare” i dati;
  • Complica un po’ le cose quando le strutture dati evolvono perché dobbiamo introdurre trasformazioni da qualche parte nel processo di sincronizzazione;

Sono tutti ma che ovviamente non sono bloccanti, dobbiamo però comprenderli e valutarli nel nostro contesto. Non sono a priori sbagliati. Uno solo è particolarmente rognoso a mio modo di vedere.

Consistenza eventuale

La consistenza eventuale è in alcuni scenari probabilmente un male necessario, ma se possiamo evitare il problema tout court è decisamente meglio. Diciamo che abbiamo fatto i compiti a casa e:

Cosa non sappiamo?

Non sappiamo se la sorgente ha un’informazione più aggiornata e se quello che vediamo noi sia quindi l’ultima informazione disponibile o meno. Abbiamo quindi necessariamente a che fare con dati definiti stale con poche, o nessuna, informazioni per aiutarci a gestire lo scenario.

Infine se diamo un’occhiata a come abbiamo ipotizzato i nostri servizi:

  • SAP, interno
  • Interno / API e hosting condivisi (o condivisibili)g
  • terze parti

Ci scontriamo con il dettaglio che tutti i servizi devono poter dialogare con il “robo” centrale, cosa sicuramente fattibile ma anche in questo caso è necessario valutare bene se il gioco vale la candela.

Services UI Composition

Ecco perché in molte realtà si sta cominciando ad affrontare il problema partendo da un angolo diverso, chiedendosi se non sia possibile eliminare in toto i possibili problemi di cui sopra spostandosi verso un approccio come il seguente:

image

Questa serie di post mira a approfondire questo secondo approccio,  evidenziando pro e contro perché ovviamente non è tutto oro quel che luccica. Le realtà che fino ad oggi ho supportato in questo approccio sono “scappate” da quello precedente perché al crescere intrinseco dei sistemi e delle realtà stesse l’approccio di prima stava cominciando a vacillare.

Post in questa serie:

Piccolo spazio pubblicità:

Tratterò di questi temi in un workshop durante l’edizione milanese di Codemotion 2016: Microservices development deep dive.

author: Mauro Servienti | posted @ mercoledì 7 settembre 2016 10.12 | Feedback (0)

Dimenticavo, un po’ di autostima non fa male.


Allenamento e disciplina sono fondamentali, ma non basta. Ci vogliono anche dei buoni preparatori e un briciolo di autostima di certo non fa male:

image

Quindi vedere che i lettori ci sono è sicuramente uno stimolo per andare avanti ed è anche gratificante. Poi…non cambierò la mia strategia perché non ho come obiettivo finale quello di massimizzare i lettori, altrimenti non bloggherei di lunedì, non bloggherei alle 8 circa, ma dopo le 10.30 e prima delle 14, non bloggherei seguendo vari percorsi spesso casuali e poco organici. Scrivo perché piace a me e in alcuni casi ha un fine simil-peripatetico, scrivere mi aiuta a mettere in fila e razionalizzare.

author: Mauro Servienti | posted @ lunedì 5 settembre 2016 7.29 | Feedback (1)

Il fatto che non sia facile non significa che debba essere difficile (was: risultati di un interessante esperimento)


Ho iniziato a leggere “Everybody Writes”:

image

Poi per motivi lavorativi mi sono dato ad altro, ma ci tornerò. Ann Handley inizia con un’osservazione interessante, dice (parafrasando) che chiunque può scrivere, chiunque, è solo ed esclusivamente una questione di allenamento.

Cioè, non sei mai andato in biciletta in vita tua, non ti puoi aspettare che al primo tentativo una tappa del giro d’Italia sia alla tua portata, ma ti puoi aspettare che con l’allenamento giusto una tappa del giro d’Italia diventi alla tua portata. C’è poi il problema che il giro d’Italia è fatto di tante tappe, di nuovo allenamento.

Ann sostiene che scrivere sia uguale, e vi dice di provarci.

Ci ho provato.

Mi sono messo d’impegno e ci ho provato, come ogni buon allenamento che si rispetti richiede disciplina, molta disciplina. Verso fine aprile mi sono detto: OK, da settimana prossima 3 post la settimana, lunedì, mercoledì e venerdì. Stessa ora, alle 8.30 del mattino.

Esattamente come se dovessi uscire in bicicletta. Non c’è santo che tenga, il post deve essere pubblicato, unica scusa accettabile è sono in viaggio con la famiglia. inoltre divieto assoluto di pianificare i post, non si fa un allenamento la domenica e lo si spaccia per quello del lunedì.

Il primo mese è stata una fatica bestiale, non avevo idee, se le avevo la frizione all’iniziare a scrivere era elevatissima, quando iniziavo era una fatica bestiale portare a termine il compito.

Ci sono riuscito.

Sono passati 4 mesi, e ho pubblicato 55 post a fine agosto.

Facile a dirsi

image

Nazareno commenta:

Facile a dirsi... i cambi di mindset sono complessi

Ovvietà mi permetto di dire io :-) non usatela come scusa. Se abbiamo un obiettivo e pianifichiamo bene l’allenamento i cambi di mindset sono molto meno complessi di quello che ci si aspetta. Gli errori tipici sono aspettarsi che lo cose siano facili, che le cose cambino da sole e da un giorno con l’altro, che la gente ci aiuti e che noi non dobbiamo fare nulla.

Se penso allo scrivere su un blog, tipicamente le risposte che sento sono:

  • Non so di cosa scrivere. Balle! neanche io sapevo di cosa scrivere a fine aprile, adesso ho una lista di “abstract” infinita che si allunga di giorno in giorno. Allenamento, anche la nostra fantasia, o la nostra capacità di astrazione richiede allenamento;
  • Quello che scrivo non interessa a nessuno. Balle! Quello che voi pensate sia interessante per un pubblico che non conoscete è sicuramente diverso da quello che il potenziale pubblico trova interessate;
  • Ma non ho tempo. Davvero? Non trovi 15 minuti per scrivere un post come questo? Hai un problema molto serio. Molto serio, e non è scrivere.

Non dico che sia facile, dico che si può fare.

E dico che è solo ed esclusivamente una questione di allenamento. L’allenamento vi porta a scrivere alla svelta, a fare meno errori, ad essere più precisi e diretti al punto, con meno fronzoli che richiedono tempo. L’allenamento è quello che vi da la confidenza per dire: si può fare. (cit.)

Questo post non vuole essere un invito a scrivere, vuole semplicemente essere un monito a quelli che “si ma loro…”, vi faccio un altro esempio: pensate che Igor e Alessandro vivano in una torre d’avorio foraggiata dal Gaggi? Pensate che  produrre tutti i sacrosanti giorni DevInPills sia una cosa facile?

O pensate forse che Andrea Benedetti si sia alzato dal divano un giorno e abbia detto domani vado a fare la 4K Alpine Endurance? 350Km e 25.000 metri di dislivello positivo…non scherziamo. Si è fatto un culo infinito per arrivare li.

No, no e no: impegno, allenamento, devozione e disciplina. All’inizio è una fatica pazzesca, poi pian piano la tappa del giro d’Italia diventa sempre più un obiettivo raggiungibile.

Allenamento e disciplina

Due facce della della stessa medaglia, senza disciplina l’allenamento è impossibile, bisogna però allenarsi anche ad essere disciplinati. Importante è scegliere l’obiettivo giusto, significativo, lontano ma raggiungibile. Si può sempre scegliere un nuovo obiettivo raggiunto il primo.

author: Mauro Servienti | posted @ venerdì 2 settembre 2016 9.20 | Feedback (2)