SOA service model decomposition: i servizi, atto secondo.


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:

image

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 corso la timeline che rappresenta l’avanzamento della spedizione è fornita da un servizio di terze parti:

image

Quelle informazioni non sono sotto il controllo di Amazon, solo la visualizzazione è gestita da Amazon, potremmo quindi dire che uno scenario come il seguente è perfettamente accettabile nel mondo reale*:

  • Marketing: SalesForce, cloud.
  • Sales: SAP installato internamente
  • Shipping: realizzato internamente e deployato internamente
  • Warehouse: SAP installato internamente
  • Publishing: realizzato internamente e deployato internamente
  • Shipment Tracking: fornito da terze parti, in base al corriere scelto per ogni spedizione

I nostri modelli possono quindi essere su sistemi diversi, non necessariamente sotto il nostro controllo e non necessariamente deployati internamente. Potremmo quindi riorganizzare l’elenco di cui sopra nel seguente modo:

  • SAP, interno:
    • Sales
    • Warehouse
  • Interno / API e hosting condivisi (o condivisibili):
    • Shipping
    • Publishing
  • terze parti:
    • Marketing
    • Shipment tracking

Perché distinguere tra “SAP, interno” e “terze parti”? Principalmente per una questione di ownership, sul SAP interno abbiamo un minimo di controllo e con un certo sforzo possiamo apportare cambiamenti e aggiustamenti che sulle terze parti sono esclusi a priori.

Post in questa serie:

* I servizi che sto usando negli esempi, e la loro separazione, non sono quelli di Amazon, provengono comunque da un caso reale e sono effettivamente organizzati come delineato.

author: Mauro Servienti | posted @ lunedì 29 agosto 2016 9.01 | Feedback (0)

Reinventing Organizations: da leggere!


Se come me vivete in una realtà diversa da una tradizionale. Se siete curiosi di capire come si sono evoluti, e perché, i modelli organizzativi dalla notte dei tempi ad oggi. Se desiderate scoprire come questi modelli si evolveranno Reinventing Organizations è il libro da leggere.

(Amazon: Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness)

image

Il testo è utile anche per tutti gli scettici, per tutti quelli che dicono che un modello diverso da quello attuale, un modello ad esempio (ma non solo) totalmente basato sul self-management, non sia possibile.

Tutti quelli che “…funziona solo per certe realtà…”, “…funziona solo per quelle piccole…”, “….non funziona per noi perché noi siamo diversi…”, “…funziona solo per quelli che fanno servizi…”, etc..etc..insomma il solito campionario di scuse di quelli a cui non piace ne cambiare ne mettersi in gioco.

Utile perché fa una cosa molto semplice: elenca e analizza realtà attuali, e grandi, come ad esempio Patagonia o Southwest Airlines, che da tempo hanno abbandonato con successo un modello organizzativo tradizionale in favore di qualcosa di diverso.

Cambiare un’organizzazione è una sfida molto complessa, che deve essere condivisa da tutti e che non ci si può aspettare che sia indolore (anzi). È inoltre una sfida difficile da progettare perché non c’è una ricetta, c’è semplicemente un set di linee guida che devono essere comprese a fondo e poi adattate per essere applicate alla realtà che si sta cercando di cambiare.

Quello che vi posso garantire è che secondo me è una sfida affascinante che val la pena di essere “sfidata”. Se volete sapere cosa e come leggete il libro o venite ai Community Days :-)

author: Mauro Servienti | posted @ sabato 27 agosto 2016 11.11 | Feedback (0)

Raccontare una storia


Avete presente quel momento in cui siete al cinema e il film non vi piace? e vi rendete conto che il film non vi piace perché la storia non sta insieme, non ha ne capo ne coda, è congegnata male, o semplicemente non funziona.

La storia è tutto

La storia che vogliamo raccontare è tutto, sia un film, una pubblicità, un post come questo, una serie di post o una presentazione. Quindi perché vi fate del male e:

  • Le slide? mezz’ora prima della sessione.
  • Gli esempi? ma si li costruisco al volo durante le demo

Tutto sbagliato

Sapete perché? perché si percepisce. Esattamente come quando siete al cinema e vi annoiate e vorreste uscire se la presentazione è raffazzonata in qualche modo si capisce, le persone si annoiano, vogliono uscire e la volta dopo non tornano. Questo impatta su chi presenta ma anche su chi organizza la conferenza oltre che ovviamente su chi viene per ascoltare.

La preparazione è tutto…

…e alla base di una buona preparazione c’è una buona storia. Non solo, chiedetevi perché lo volete raccontare, a chi lo volete raccontare e come lo volete raccontare. Mi sono reso conto che da un po’ ho messo in atto quello che Lorenzo chiama procrastinazione creativa. Le slide le preparo fisicamente comunque molto tardi, di solito qualche giorno prima, ma la storia nasce, si modifica, si distrugge, e rinasce a volte, per settimane in alcuni casi mesi prima dell’evento.

Un esempio

Ai Community Days parlerò di lavoro da remoto, è la terza volta che erogo quella sessione, sarà per la terza volta una sessione completamente diversa. La storia che voglio raccontare sta cambiando nella mia testa, ma soprattutto sta cambiando il modo in cui la voglio raccontare perché le prime due volte che l’ho raccontata il messaggio che ho comunicato non mi ha soddisfatto. Fondamentalmente perché, a parer mio, in un caso la storia era debole e nell’altro mal orchestrata.

La preparazione è tutto; e preparazione e allenamento vanno a braccetto, sempre.

author: Mauro Servienti | posted @ venerdì 26 agosto 2016 10.47 | Feedback (0)

La definizione del problema.


Avete presente quelle “amene” situazioni in cui le discussioni si protraggono all’infinito senza alcuna apparente possibilità di soluzione?

Tipicamente diciamo che siamo in stallo o in conflitto….in realtà il problema potrebbe essere un altro. Spesso quello che succede è che i contendenti non stanno discutendo dello stesso problema o il problema di cui stanno discutendo è troppo ampio.

Quello che succede nel primo caso è che qualcuno solleva un problema, magari un po’ vago, dai contorni non ben definiti o mal descritto. Qualcun altro interviene e dato che il problema non è ben definito interpreta la questione generando un punto di vista diverso, leggermente o abissalmente, rispetto a quello di chi ha sollevato il problema.

A questo punto il consenso è pressoché impossibile perché non stiamo discutendo della stessa cosa.

Il secondo scenario è una variazione del primo: se il problema è troppo ampio/vasto è molto facile che i punti di vista divergano rapidamente generando ancora una volta stallo o conflitto.

Lo stallo o il conflitto sono quindi un buon indicatore, non sempre ma spesso, del fatto che probabilmente quello che manca, o che non è abbastanza chiaro, è la definizione e condivisione del problema che vogliamo risolvere.

Val la pena quindi in situazioni di stallo o di conflitto fermarsi un attimo ed essere certi che si stia discutendo della stessa cosa.

author: Mauro Servienti | posted @ mercoledì 24 agosto 2016 8.45 | Feedback (1)

“starters” e “finishers”


Non esistono persone sbagliate, esistono persone al posto sbagliato. Ci sono persone molto brave ad iniziare le cose e ci sono persone molto brave a portare avanti fino alla fine le cose iniziate da altri. È più difficile trovare una persona che sia brava, ho detto brava non in grado, a gestire da sola tutto la genesi e la produzione di qualche cosa.

A mio modo di vedere questo è il motivo per cui è molto importante lavorare in team, conoscere molto bene le caratteristiche delle persone che compongono il gruppo e mixare le persone con caratteristiche complementari.

Il sottoscritto ad esempio è un pessimo “finisher”, il sottoscritto perde entusiasmo una volta che il problema è stato identificato e concettualmente risolto. Questo non vuol dire che non sia in grado di portare a termine le cose vuol dire che mi devo concentrare più di altri, che probabilmente non sono così interessati a smontare a rimontare i problemi. Io, a differenza di altri, adoro avere a che fare con i problemi. Altri adorano una vita tranquilla fatta di routine derivante dal fatto che gente come me ha preso di petto il problema e magari ha preso anche qualche schiaffone per capire come affrontarlo.

Sono io meglio degli altri? Sono gli altri meglio di me?

Siamo due lati della stessa medaglia, complementari. Gli uni senza gli altri non serviamo a nulla, o nella migliore delle ipotesi in un primo caso produciamo soluzioni lente e che si trascinano mentre in un secondo produciamo soluzioni che non sono necessariamente quelle del problema che vogliamo risolvere.

Questo apre ad un interessante problema :-) stay tuned :-P

author: Mauro Servienti | posted @ lunedì 22 agosto 2016 9.44 | Feedback (0)

“Everybody, all together, from the early on”


Sempre Luigi:

image

Quoto, e rilancio con pre-sales e supporto all'utente finale ;-)

DevOps e' l'anello tecnico di un processo di business piu' complesso, che include dinamiche economiche e politiche, oltre che puramente tecniche o funzionali.

Ho avuto la fortuna di lavorare in aziende piccole, dove oltre a dover gestire la parte tecnica (sviluppo, ops), mi sono trovato dover vendere il prodotto e il progetto di turno, a discutere di requisiti in termini di costo e di opportunita', oltre che di fattibilita' tecnica, a parlare con il Direttore di X di turno della grande azienda cliente (anche quando ero un junior con un anno di esperienza) e a gestire gli utenti incazzati perche' il sistema era andato giu' sotto carico.

Sono straconvinto che senza questa palestra non tecnica le mie skill di sviluppatore oggi sarebbero molto piu' limitate

Prima o poi mi piacerebbe sentir parlare di passaggio da DevOps a Dev+, ossia un profilo professionale di estrazione tecnica, ma che e' in grado di capire e gestire il processo di business a 360 gradi

Lo scrivevo e ne parlavo all’Agile Day, con Timothy, nel 2012: Everybody, all together, from the early on”.

author: Mauro Servienti | posted @ mercoledì 17 agosto 2016 9.40 | Feedback (0)

Typora: Electron / take 2


Gli editor, decenti, di file Markdown languono nel mondo Windows. E no VS Code non è, ancora, un editor decente.

Please Welcome Typora

image

Typora è il primo che posso ritenere decente, grazie al mio collega John per la dritta, decente ovviamente in base all’uso piuttosto intenso che facciamo di Markdown.

Il vero merito di Typora però è un altro, dimostrare quanto tecnologie come Electron possano essere una scelte vincente per abbracciare mondi che altrimenti rischiano di essere lontanissimi tra loro.

Un’altra cosa che mi piace molto di Electron è che porta la qualità del design, tipica del mondo Mac, anche su Windows a costo zero. Il che mi fa restare su Windows anche se di motivi ne ho ben pochi.

Inoltre Electron, ovvia conseguenza direi, fa si che Mac, Linux e Windows possano essere visti come una sola piattaforma dal punto di vista dello visto di certe applicazioni.

author: Mauro Servienti | posted @ venerdì 12 agosto 2016 8.39 | Feedback (0)

Services UI Composition - tecniche di recupero delle informazioni: IT/Ops


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:

Questo post sarebbe dovuto arrivare prima del “recap”, chiedo perdono, ho bisogno di ferie :-)

Abbiamo i servizi

Quando abbiamo a che fare con una UI che deve visualizzare informazioni che provengono da sorgenti fisicamente diverse il nostro primo obiettivo deve essere quello di tenere sotto controllo il numero delle richieste che le parti della UI faranno ai vari (micro)servizi. È importante perché è molto facile che la cosa ci sfugga di mano generando problemi molto simili, ma potenzialmente su scala più ampia, a quelli che genera quello che ricade sotto il nome di “SELECT N+1”.

Vediamo un esempio in cui il problema emerge immediatamente, usiamo il solito mock-up che ci ha guidato fino ad oggi:

image_thumb
image_thumb

Ma…diciamo che gli elementi sono una lista. Se un elemento da solo genera un minimo di chiamate pari al <numero-di-servizi>, quello che non vogliamo è che una lista generi ( <n-elementi-lista> * <numero-di-servizi> ) + 1. Quello che vogliamo ottenere è invece in questo scenario che la nostra formula sia ( <numero-di-servizi>  + 1 ).

( <numero-di-servizi>  + 1 )

Il nostro obbiettivo è aggregare le richieste in uscita verso i servizi in modo da fare solo le seguenti operazioni:

  1. recuperare la lista degli “Id / chiavi primarie / identificatori univoci” delle cose che dobbiamo visualizzare
  2. Andare da ogni servizio con la lista degli “Id” recuperare tutte le informazioni in un solo colpo
  3. Una volta che le informazioni sono sul client ri-suddividerle tra i vari attori che vivono nel client

Abbiamo fondamentalmente due strategie per farlo, entrambe con pregi e difetti.

IT/Ops

Nel mondo SOA ricadono sotto il nome di IT/Ops quei componenti infrastrutturali che si occupano di aggregazione delle informazioni, o disaggregazione delle informazioni (capiremo cosa significa disaggregazione quando affronteremo il discorso scritture). Il modello IT/Ops mima esattamente quello che abbiamo appena delineato come strategia, a prescindere da dove questo avvenga, client o server, quello che succede è:

  1. Ottengo la lista delle chiavi degli elementi che devo visualizzare
  2. Preparo un contenitore per i dati, ad esempio un “dictionary”
  3. Notifico i componenti di IT/Ops che la lista è pronta
  4. Ogni componente aggrega la lista come meglio crede e chiede al suo servizio i dati che gli servono
  5. Ottenuti i dati, che ovviamente sono una lista, li disaggrega in modo da relazionarli con le chiavi di cui al punto 1 e riempie il dictionary
  6. A questo punto abbiamo una lista i cui dati sono composti da informazioni che provengono da servizi diversi

Tutto questo, che sembra molto complesso, in realtà è piuttosto semplice e può essere graficamente rappresentato come segue:

image

L’unico vero difetto di questo approccio è che è invasivo, impone cioè che tutto lo stack, dal componente della UI in giù sappiano come parlare con i servizi di back-end. Se ci pensiamo questo impone che anche chi, quindi persone, si occupa di UI sappia abbastanza bene come funziona tutto il giro, cosa non necessariamente desiderabile in team grandi.

Batching

Il sogno sarebbe poter dire al 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.

La cosa è possibile anche se la mia esperienza dice che è esageratamente complessa e rognosa da gestire sul lungo periodo. Nel prossimo post vedremo quali sono le tecniche di batching, cosa risolvono e cosa complicano.

author: Mauro Servienti | posted @ giovedì 11 agosto 2016 8.53 | Feedback (1)

Nessuno dice che sia facile. Tutt’altro.


Nazareno, ma quanto parla Nazareno :-D, commenta:

image

Tu vedi un lato della medaglia... io l'altro... continuo a vedere team che non si spostano da quello che conoscono e "accettano" di "morire di manutenzione" per evitare di uscire dalla loro zona di confidenza: "in VB6 usavo il Recordset foward-only, read-only... ma non trovo il Recordset in .NET"

Come al solito "in media stat virtus"... non bisogna andare dietro solo al proprio ego, come non bisogna sedersi su quello che già conosciamo.

Fino a un po' di tempo fa pensavo che tutti i dev fossero proattivi da questo punto di vista... mi sbagliavo... purtroppo...

Ma i risultati di questo "immobilismo" o "troppa figagine" che comunque si ribalta sull'utente finale penalizza tutta la "nostra categoria".

My2Cents

Sono due problemi molto diversi quando parlo di “sincero fastidio” mi riferisco a quella attitudine, fastidiosa per me, che spinge lo sviluppatore a inventare feature che nessuno gli ha chiesto e a arzigogolare soluzioni ingegneristicamente notevoli a problemi che tipicamente hanno soluzioni molto più semplici ma molto meno allettanti. In una parola: sovra-ingegnerizzazione.

L’immobilismo è un problema molto diverso, meno fastidioso secondo me per certi versi, ma che comunque va affrontato.

Paura?

Cosa genera immobilismo? Credo (e se ci sono altre motivazioni fatevi sotto) sia la paura del cambiamento, cambiare è difficile, ci vuole coraggio e bisogna essere pronti a fallire. Tutte cose ovviamente non facili, ma nessuno ha mai detto che sia facile.

L’immobilismo probabilmente in una prima fase ha senso, ho creato, funziona, adesso lo uso per un po’ così. Ecco quando “per un po’” diventa “per un po’ troppo” scivoliamo dall’ammortizzare l’investimento all’immobilismo.

Essere pronti a fallire per imparare.

Cambiare significa principalmente essere pronti a sbagliare e fallire. Nessuno dice che sia facile, se però partiamo dal presupposto che il fallimento è un risultato accettabile la nostra prospettiva cambia radicalmente.

Si potrebbe quindi cambiare la prospettiva e dire:

quale è l’errore più piccolo che posso fare nel più breve periodo possibile per imparare il più possibile sul percorso che sto intraprendendo?

Necessita un profondo cambio della mentalità aziendale che deve essere pronta ad abbracciare il fallimento come uno dei mezzi per perseguire il successo.

author: Mauro Servienti | posted @ lunedì 8 agosto 2016 8.29 | Feedback (0)

DevOps significa (anche) condivisione delle conoscenze


Un giorno di qualche tempo fa in una conversazione tra dev:

Utilizzando HTTP si possono scambiare facilmente informazioni tra servizi remoti. Il limite è che il client deve sapere innanzitutto dove si trova (IP) il server, problema risolvibile con un file di configurazione. Un altro problema è come possiamo inserire altre macchine in modo che le richieste vengano bilanciate. Diventa necessario far si che il client sappia quante e quali macchine server sono disponibili e quando sono disponibili.

E così la conversazione continuava.

Ora lasciamo perdere per un secondo l’assurdità della conversazione, DNS, Load Balancer e Cluster, questi sconosciuti e immaginiamo che sia sostenibile pensare di essere un Dev che non ha nozioni di Ops, la frittata seguendo la conversazione di cui sopra è fatta: sovra-ingegnerizzazione alle stelle.

DevOps è anche una strada per abbracciare semplicità, per avere diversità di vedute nel team, vedute che possono portare sul piatto soluzioni a cui da soli non avremmo potuto pensare.

Dove da soli significa anche circondati e sostenuti da gente che vede il mondo con un paraocchi uguale al nostro.

author: Mauro Servienti | posted @ sabato 6 agosto 2016 17.06 | Feedback (0)