Services UI Composition: la ricerca, maledetti utenti


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 necessariamente un incubo

imagemotore-ricerca-interno-joomla

Una parte del mondo esultò, una piccola parte (noi dev) cominciò a cercare spigoli di marmo su cui sbattere la fronte.

Cercare può essere molto complesso

Di primo acchito quando pensiamo ad un sistema distribuito e cerchiamo di immaginare la ricerca in tale modello pensiamo immediatamente di avere compreso cosa sia un ossimoro. Ma probabilmente non è proprio così.

Se state cercando una spedizione andrete da che gestisce le spedizioni, se state cercando un semi-lavorato probabilmente dal magazzino, se siete interessati a tutto ciò che ha a che fare con il cliente “Mauro” andrete dal CRM e poi con l’ID di Mauro da tutti gli altri.

Più complesso ovviamente se siete alla ricerca di tutto ciò che ha a che fare con “Mauro”, e gli ordini spediti il cui peso di spedizione sia compreso da X e Y. Distribuire questo secondo tipo di ricerca diventa un po’ più complesso, non impossibile, ma sicuramente più complesso.

Se in più ci mettete che magari volete paginare e ordinare ecco che le cose si fanno rognose, perché ad esempio paginazione distribuita è un simpatico incubo.

Andiamo con ordine

Prendiamo come esempio la ricerca di Amazon:

image

(il porta banana è il nostro esempio preferito :P)

Ci sono tante cose affascinanti che si possono dedurre (o ipotizzare) da come sono strutturati i risultati.

La prima domanda che ci possiamo fare è: chi è responsabile di quella ricerca?
Nel modello che abbiamo usato fino ad oggi in questa serie: Marketing.

Quindi Marketing inietta nella UI composta il form di ricerca:

image

A fronte di una richiesta Marketing riceve:

  • il testo della query: portabanana
  • l’ID della categoria, diciamo in questo caso <null> che identifica nessuna categoria specifica

Marketing fa la sua bella query full text, con qualsivoglia tecnologia volete e ritorna la lista di ID che soddisfano la ricerca. La visualizzazione dei risultati si risolve facile, è un caso comune di UI Composition.

image

Meno ovvio sembrano essere le facet sul lato sinistro:

imageLa prima informazione che troviamo è l’elenco delle categorie che corrispondono ai risultati della ricerca.

Questa è abbastanza facile da fare anche client-side sempre seguendo le regole di UI Composition: Marketing torna come risultato della ricerca gli ID dei prodotti, e per ogni prodotto l’ID della categoria.
A questo punto ci basta una distinct sulla lista degli ID delle categorie per avere le informazioni necessarie per comporre quella parte di UI.


In maniera molto smile possiamo risolvere anche il resto:

imageMandiamo a Shipping e CustomerCare gli ID dei risultati e loro si preoccuperanno di fare i loro ragionamenti per produrre quelle facet.


 

La domanda ovvia a questo punto potrebbe essere:

ma cosa c’è di male a buttare tutto in un bel robo fatto con Elastic Search?
E la risposta sarebbe: nulla, non c’è nulla di sbagliato.

La cosa sbagliata è pensare che l’unica soluzione sia buttare tutto in un robo fatto con Elastic Search.

Come abbiamo già detto quando avete a che fare con un sistema veramente distribuito la condivisione delle informazioni vi si può ritorcere contro molto rapidamente e quando succede fa  molto male.

Quindi una buona domanda da farsi è: ma voglio veramente un sistema distribuito? O sto pensando prima al mio ego e poi ai requisiti?

Fino ad ora siamo quindi riusciti a soddisfare il requisito ricerca senza introdurre un sistema centralizzato.

Ma è sempre così?

C’è un ultimo elemento su quella pagina che potrebbe farci dire che alcune cose vanno centralizzate in qualche modo:

image

Le informazioni necessarie per cambiare l’ordinamento vengono da servizi diversi, e questo comporta che per ordinare i risultati l’interazione tra i vari servizi sia un po’ complessa, forse un po’ troppo.

Lo scopo di questo post era dimostrare che non è strettamente necessario condividere informazioni neanche per cercare. Con i prossimi due post sul team SOA/Services UI Composition affronteremo invece due scenari in cui le informazioni in qualche modo devono essere condivise tra servizi diversi nello stesso sistema.

Post in questa serie:

author: Mauro Servienti | posted @ venerdì 9 dicembre 2016 17.05 | Feedback (0)

Un doveroso grazie ai ragazzi di @klabcommunity.


Anche l’ultimo evento KLab del 2016 è andato, io personalmente mi sono divertito parecchio. Mi rendo conto che comprimere in 50 minuti quello che di solito si fa in 2 giorni di workshop è un delirio niente male, ho fatto del mio meglio per trasmettervi cosa vuol dire realizzare un’applicazione veramente distribuita.

Le demo della serata sono disponibili su GitHub: https://github.com/mauroservienti/KLab-Services-UI-Composition-Demos.
Nello stesso repository c’è un file demos.md che è il canovaccio che ho seguito durante la sessione, potete usare quello per ripercorrere la stessa strada.

Ovviamente se avete domande fatevi sotto, il form di contatto è li apposta.

Ancora...

In ordine di importanza:

  • Carlo è mitologico.
    • Ha fatto una sessione perfetta, e difficile, parlando di Octopus Deploy in salsa DevOps in 50 minuti.
    • Ha sdoganato il processo di installazione alla Carlona
    • Ha parlato di Belen… non ho parole :-P
  • Se volete approfondire le tematiche trattate la categoria SOA di questo blog è un buon posto per iniziare.

Services UI Composition

Non so chi l’ha notato, ieri sera durante la demo di Carlo è diventato palese che “Services UI Composition” è intorno a noi pressoché ovunque. Carlo ad un certo punto ha puntato il browser sul repository contenente la mia demo, ed è successa una cosa interessante. Ha visualizzato la pagina solito di GitHub, ma le descrizioni dei commit (evidenziate nella figura seguente) sono arrivare in ritardo:

SNAGHTML647005b5

La pagina è arrivata senza le descrizioni, che sono poi state aggiunte client side, evidente che le informazioni arrivano da due servizi diversi e la pagina fa UI Composition.

author: Mauro Servienti | posted @ mercoledì 7 dicembre 2016 7.43 | Feedback (0)

L’incubo della chat del portale Trenitalia.


Ma questi sono fuori. Sul portale c’è una chat, che sembra essere l’unico modo per contattarli con mezzi moderni, visto che su Twitter vi rimbalzano li:

image

Solo che la chat funziona allo stesso modo di un call center, e se non sei veloce a scrivere e pigiare invio il tuto bel messaggio viene cancellato appena qualcuno è più veloce di te.

Poveri noi :-(

author: Mauro Servienti | posted @ lunedì 5 dicembre 2016 8.28 | Feedback (2)

Services UI Composition: le scritture. In anteprima con @klabcommunity


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 condivise e come, quali sono gli SLA e quali sono i rapporti di downstream/upstream tra le parti in gioco. Una volta che si è padroni di questo, ed è la cosa veramente difficile, l’implementazione è veramente un dettaglio e spesso un gioco da ragazzi.

Faccio sempre un esercizio, che per come sono fatto io funziona molto bene. Dato un processo di business che devo comprendere a modellare, mi chiedo:

Come farebbero un gruppo di umani, senza tecnologia, a risolvere il problema?

Comprensione del dominio

Questo è il tema caldo quando si parla di sistemi distribuiti. Martedì prossimo mi cimenterò nella titanica impresa di mostrare un flusso di manipolazioni di dati in un sistema distribuito. In 40 minuti.
Se volete una live preview di quelli che saranno i prossimi post, ma soprattutto del codice non potete mancare.

Maggiori informazioni: http://www.klabcommunity.org/klab-201606/

Post in questa serie:

author: Mauro Servienti | posted @ mercoledì 30 novembre 2016 8.11 | Feedback (0)

@CodemotionIT una piacevole esperienza.


Sono reduce da quasi 3 intere giornate passate a Codemotion, quasi 3 perché sabato sono stato un po’ latitante :P.

È stata la prima volta e nel complesso devo dire che è stata una priva volta che non dimenticherò. Il workshop è andato molto bene, con tantissima partecipazione attiva, quindi è andato molto bene grazie a voi che avete partecipato. Quello che ho visto della conferenza nel complesso mi è piaciuto, devo dire che la cosa che mi ha colpito di più è stata la quantità di gente. Il mio collega Sean Farmar venerdì mattina è arrivato prima di me e mi manda un SMS:

It is mad here, loads of people.

Che descrive abbastanza bene lo scenario. Ho visto anche qualche sessione, e nel complesso mi sono piaciute. Ho scelto cose molto distanti dal mio background tecnico/tecnologico background che per certi versi un po’ mi ha stufato.Devo dire che il formato 40 minuti mi piace molto.

author: Mauro Servienti | posted @ lunedì 28 novembre 2016 9.35 | Feedback (2)

KLab 2016 #6


Martedì 6 dicembre sarò all’evento KLab a Fiorenzuola D’Arda. La serata sarà super DevOps oriented.

Due sessioni con le mani in pasta nella realtà di tutti i giorni

Inizierà il sottoscritto con una sessione di live coding finalizzata a realizzare un piccolo esempio di sistema distribuito basato sui dettami di SOA e usando NServiceBus per l’implementazione.
A seguire Carlo ci farà vedere come usare Octopus Deploy per gestire tutto il ciclo di rilascio.

Fatevi sotto!

L’evento è gratuito ed è l’occasione perfetta per passare una piacevole serata in compagnia e per godere anche di un ottimo buffet piacentino, che male non fa.

Per iscrizioni ed informazioni logistiche: https://www.eventbrite.com/e/biglietti-klab-2016-6-29404493632

author: Mauro Servienti | posted @ venerdì 25 novembre 2016 12.07 | Feedback (0)

Trenitalia fa peggio di tutti. Ovviamente.


Come CartaSi e Telepass fallisce miseramente nell’esporre la pagina di login su HTTP con POST verso HTTPS, con l’aggravante che lo fa verso un dominio diverso. Ma perché?

image

Il problema del POST da HTTP verso HTTPS è che basta fare tampering della pagina di partenza reindirizzare la POST verso un altro dominio e abbiamo le credenziali dell’utente.

Ma si può fare di peggio

La password è salvata in chiaro, te la mandano allegramente per posta, ed è pure case insensitive. Oh my…

image

Scappate a gambe levate. Qui non ci sono consigli da dare, se non evitate di salvare qualsivoglia dato importante nel profilo di Trenitalia.

author: Mauro Servienti | posted @ mercoledì 23 novembre 2016 6.50 | Feedback (1)

“Irreperibili e felici” (cit.)


Citando: http://www.internazionale.it/opinione/oliver-burkeman/2015/10/27/irreperibili-felici-stress

È sempre piacevole trovare conferme alle proprie convinzioni:

Non è tutto li.

Ho sempre di più la sensazione, spiacevole sensazione, che la cosa ci stia un po’ sfuggendo di mano. Con Lucia andiamo ogni tanto in un ristorante giapponese a Pavia, e puntualmente incrociamo una coppia (che quindi deduco ci vada molto più spesso di noi) che passa la cena nel seguente modo:

  • Ordinano con il cellulare in mano mentre fanno non si sa bene cosa
  • Fanno foto a tutto quello che arriva
  • Non mollano mai il cellulare per tutta la sera
  • Non spiccicano una parola, ma non si guardano neanche in faccia.

Ora, secondo mia moglie il sottoscritto è un orso che parla poco ma confronto a quei due sono la socialità fatta a persona. Quelli probabilmente sono ad un estremo dello spettro, ma sempre più spesso mi capita di osservare (o di essere coinvolto) situazioni in cui il device interrompe prepotentemente e in maleducatamente una conversazione.

E non è il device quello prepotente e maleducato.

author: Mauro Servienti | posted @ lunedì 21 novembre 2016 7.34 | Feedback (5)

Telepass: il reset della password e la security…oh my.


Un po’ come fa CartaSi anche Telepass cade nel falso senso di sicurezza.

image

Praticamente ci manda una “one time password” in chiaro via mail. Questo perché sappiamo tutti che SMTP è un protocollo sicuro per definizione. Ergo qualcuno intercetta la mail, fa login prima di voi, cambia la password e ciaone.

Consiglio: non c’è mezzo di avere un processo di reimpostazione della password sicuro. Assicuratevi di averne una molto complessa e che non usate da nessun’altra parte (cosa che dovrebbe essere il comportamento standard)

author: Mauro Servienti | posted @ venerdì 18 novembre 2016 7.17 | Feedback (0)

“GitFlow e GitHubFlow” @ WPC 2016 con @OverNetE


Vi ho già detto di “Progettare una UI per Microservices”. A questo il divertimento è doppio:

GitFlow & GitHubFlow: gestire al meglio prodotti e progetti con Git (e non solo)

Un sistema di Source Control è solo uno strumento per conservare, condividere e versionare il codice? O possiamo sfruttare il nostro motore di Source Control per gestire e semplificare il processo di sviluppo? L'obiettivo è comprendere a fondo Semantic Versioning, le differenze tra GitFlow e GitHubFlow, come usare branch e PR per gestire il ciclo di vita e di rilascio e infine capire cosa sia GitVersion. Senza dimenticare che CI e build automatiche dovrebbero essere la norma.

Dettagli: http://milestone.topics.it/events/wpc-2016-milano.html

WPC 2016 mi da l’opportunità anche di raccontare cosa sia GitFlow, come e perché lo usiamo in Particular. La sessione (purtroppo) non sarà così articolata come da abastract perché è stata convertita in una sessione di mezz’ora, invece che i soliti 75 minuti di WPC, ci concentreremo quindi su GitFlow e sull’impatto che ha sul modello di sviluppo, soprattutto in ottica Semantic Versioning.

Ci vediamo a Milano, settimana prossima, il 30/11 alle: 14:30 in Sala Gialla.

author: Mauro Servienti | posted @ giovedì 17 novembre 2016 7.14 | Feedback (0)