Qualche anno fa mi fu chiesto di svolgere un audit su un grande progetto presso una banca internazionale, al quale lavoravano più di duecento persone. Naturalmente, era un progetto a cascata. Nelle fasi introduttive, era emerso che i diversi team del progetto operavano in numerose ampie stanze situate lungo un corridoio. Per prime, vi erano due grandi sale piene di sviluppatori, poi una stanza con analisti funzionali e una sala più piccola con i tester. Successivamente, veniva la stanza degli architetti del software e, infine, il team di gestione del progetto, perché in effetti c’era un team di project manager, al quale era stata assegnata una stanza più spaziosa alla fine del corridoio.

La semplicità di Scrum

Dopo aver trascorso alcuni giorni in banca, mi sono presto reso conto che nessuno di questi team comunicava faccia a faccia con l’altro. È per questo che ho organizzato alcuni workshop multidisciplinari. Sebbene queste persone fossero nello stesso progetto da oltre un anno, durante il primo workshop si sono effettivamente strette la mano e si sono presentate. Era ovvio che il progetto avesse bisogno di un po’ di agilità. Nonostante all’epoca esistessero già molti approcci e filosofie Agile, dopo alcuni anni, Scrum è diventato il più utilizzato, probabilmente per la semplicità del framework e forse anche per i suoi ruoli sempre chiari. C’è il team di sviluppo con tutti coloro che contribuiscono a rilasciare il prodotto, poi c’è il ruolo di Scrum master per aiutare la squadra a raggiungere i propri obiettivi in modo Agile. E, ultimo ma non meno importante, c’è il product owner. In genere, il product owner è responsabile del prodotto e quindi del backlog del prodotto: secondo la guida ufficiale di Scrum, il product owner è l’unico responsabile della gestione del backlog del prodotto ed è a lui che viene assegnata la responsabilità del prodotto.

#Trasformazione #agile Se il product owner diventa un collo di bottiglia @aahoogendoorn
Click To Tweet

Mappare i ruoli

Immaginiamo ora di essere il CEO della grande banca internazionale. Lentamente si comincerà a capire che i grandi progetti a cascata non si comportano come previsto. È quindi probabile che si inizierà a implementare Agile e Scrum così come fanno i concorrenti. Ma presto si presenterà un problema interessante: quello della mappa dei ruoli. Da un lato si hanno tester, sviluppatori, analisti, architetti e project manager. E dall’altro il team, lo Scrum master e il product owner. Ma come funziona questa mappa? Nel corso degli anni, ho assistito a un bel po’ di questi programmi di trasformazione Agile. Alcuni sono più efficienti e di maggior successo di altri, ma tutti presentano questo problema di mappatura. Quando si tratta di operazioni, tester e sviluppatori, è abbastanza facile: finiscono sempre nei team. E nella maggior parte dei casi, il team imparerà come assegnare anche il ruolo di Scrum master. Il vero problema è come assegnare il ruolo del product owner. Nella maggior parte delle organizzazioni in cui ho assistito a questo problema di mappatura, i principali candidati per questo ruolo erano gli ex project manager oppure gli ex analisti. Ma dato che i team Agile si concentrano molto sulla realizzazione di software, nessuno di questi ruoli sembra avere un posto nel team. Pertanto, la maggior parte dei ruoli di product owner viene assegnata ai project manager tradizionali o dagli analisti funzionali tradizionali

Cross-funzionale e auto-organizzato

A mio parere, i team Agile hanno la responsabilità di costruire il prodotto giusto nel modo giusto al momento giusto. I migliori team con cui ho lavorato sono quelli che si impegnano e che sono in grado di prendere le proprie decisioni, gestire il proprio flusso di lavoro e sono interfunzionali e auto-organizzati, il che è molto diverso dall’essere completamente autonomi. Questi sono gruppi che di solito non necessitano di molte indicazioni, ma chiederanno indicazioni se e quando ne avranno bisogno. Quando un’organizzazione va verso questi team responsabili che migliorano ed estendono continuamente i prodotti dell’azienda, il ruolo del product owner sembra attenuarsi o persino essere in contraddizione. Spesso proveniente da un background più tradizionale, il product owner si impiglia nella “gestione” del progetto, nella “gestione” del team, nella redazione di report settimanali di avanzamento, nella facilitazione di tutti i tipi di riunioni, nella manutenzione delle schede Jira, nell’interazione esclusiva con i clienti e nelle prove del prodotto.

Se una sola persona fa da collo di bottiglia

Questo è in genere il lavoro tradizionalmente svolto da un project manager o da un analista, indipendentemente dal titolo di product owner. Anche negli ultimi tempi, in un progetto che stava per scadere, ho notato che il product owner passava almeno un giorno alla settimana per la consegna di report su Excel. Ho visto troppo spesso che questa interfaccia singola diventa un collo di bottiglia. Svolgendo le attività di “micromanagement” che dovrebbero in realtà essere del team, si creano piccoli feudi isolati nell’organizzazione, e si perde via la sensazione che i team debbano essere responsabili. Non sono sicuro che ogni team dovrebbe avere un product owner solo perché la guida di Scrum lo dice.

Introduzione ad #Agile @aahoogendoorn sarà presente a Roma il 7-8 giugno per @techtran
Click To Tweet

La squadra è il fattore chiave

Secondo me, la maggior parte del lavoro svolto dai product owner è in realtà quella del team. Bisogna lasciare ai team la decisone su come e quando gestire le schede, e permettere al team di parlare con il cliente: sì, gli sviluppatori e i tester possono effettivamente comunicare con i clienti. Il team è responsabile per il prodotto. È anche il caso di smettere di scrivere tutti questi report: se le persone dell’azienda vogliono sapere come sta procedendo il team, perché non vengono a parlare con il team stesso? Discutendo sul ruolo del product owner, non sto ovviamente dicendo che non dobbiamo pensare ai prodotti: pensare e discutere dei nostri prodotti è sempre fondamentale. Ma ritengo che la maggior parte, se non tutto il lavoro svolto dai product owner possa e debba essere gestito dal team, e non dalla roccaforte di una sola persona che è il product owner tradizionale. È il team che è il vero responsabile chiave.

Sander Hoogendoorn

Mentore, allenatore, software architect, sviluppatore e apprezzato innovatore nello sviluppo del software. Autore del best-seller “This Is Agile”, oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo su Agile, Scrum, Kanban, continuous delivery, architettura software, Microservices, modeling e UML.

Sander Hoogendoorn presenterà a Roma per Technology Transfer i seminari “Introduzione ad Agile, Scrum, XP, Kanban e Continuos Delivery in pratica” il 7 giugno 2018 e “Progettare, sviluppare e implementare una Microservices Architecture” l’8 giugno 2018.

L'articolo Trasformazione Agile. Se il product owner diventa un collo di bottiglia proviene da Data Manager Online.

Quello dei microservice è un tema scottante. Sul quale è tutto un fiorire di opinioni, di discussioni in conferenze e di post sui blog. Io stesso ho iniziato a fare microservice tre anni e mezzo fa, quando stavo progettando un sistema per una compagnia di assicurazioni. Da allora, su questo tema ho tenuto spesso conferenze, ho pubblicato numerosi articoli e tenuto molti corsi di formazione. Di solito, chiedo a chi partecipa ai miei corsi se dispongono di un grande sistema monolitico del quale vorrebbero liberarsi. Nella maggior parte dei casi, ovviamente ce l’hanno. Non sarebbero venuti alle mie conferenze, né mi avrebbero invitato a tenere corsi se non fosse stato così. E c’è più di un buon motivo per cui si intende abbandonare i monoliti. Vediamo alcuni esempi pratici, tratti dalla vita reale.

I monoliti – Uno dei miei clienti gestiva gran parte del suo software di produzione su un mainframe. Il codice era stato scritto in un interessante dialetto Cobol, con 18 milioni di righe di codice. Solo mantenere in vita il mainframe costava più di un milione di euro all’anno. Senza contare che la maggior parte dei programmatori di Cobol sono ormai in vista del pensionamento. Un’altra società con cui ho lavorato ha iniziato con due ragazzi, di cui uno ha scritto codice. In VBA. Quando la società ha cominciato a crescere, hanno migrato a Visual Basic. Attualmente, l’azienda impiega oltre 20 sviluppatori e scrive codice sia in C# sia in VB.NET. Il prodotto è cresciuto a quasi 4 milioni di righe di codice. Un ultimo esempio. Nel corso di 12 anni, una terza società ha scritto 3 milioni di righe di applicazione di codice. In PHP. La complessità del database e le numerose domande di codice on top rendono difficile aggiungere nuove funzionalità.

.@aahoogendoorn presenterà a Roma per @techtran il 9 e 10 nov. 2017
Click To Tweet

Le analogie – Diverse aziende, diversi scenari. Ma ciò che mi ha colpito è il numero di somiglianze presenti in questi scenari: 1) In tutte e tre le aziende, diverse persone avevano lavorato su questi sistemi per molti anni, con inevitabili differenze in termini di intuizioni, idee architetturali e stili di coding. 2) Di conseguenza, nel corso del tempo l’architettura si è sfilacciata ed è divenuta sempre più difficoltosa da mantenere o estendere. 3) Non ci sono test automatici (unità o integrazioni) in nessuno di questi scenari. Con il Cobol posso capirlo, ma con linguaggi più moderni come Java, C#, VB.NET o PHP, non c’è nessuna scusa. In tutti e tre gli scenari, aggiungere nuove funzionalità è diventato praticamente impossibile. Come mi hanno spiegato i tester: «Per ogni bug che risolviamo, ne introduciamo uno nuovo».

Serve velocità – Ma allora cosa è andato storto in questi esempi? Le chiare analogie in questi scenari indicano un possibile fallimento dell’architettura. Queste aziende hanno lasciato che il loro software crescesse nell’arco di lunghi periodi di tempo: vent’anni, o dodici anni. E si sono trovate continuamente a scegliere tra l’aggiunta di nuove funzionalità e il mantenimento della qualità. Se vuoi avere un codice che sia nel tempo manutenibile, dovrai trovare un buon equilibrio tra caratteristiche e qualità.

La rana bollita – C’è una vecchia metafora che si adatta al comportamento di tali società: la sindrome della rana bollita. Se una rana viene messa di colpo in acqua bollente, salterà fuori. Ma se viene messa in acqua tiepida che poi viene portata lentamente a bollore, non avverte il pericolo e verrà bollita viva. Anche se si tratta di una leggenda, come metafora è abbastanza azzeccata. Le aziende sembrano sempre aver bisogno di crescere. C’è sempre bisogno di velocità. Il business tira sempre fuori più caratteristiche di quanto i team riescano ad aggiungere ai sistemi. Di conseguenza, le aziende spesso optano per i benefici a breve termine invece che per quelli a lungo termine, cioè per le nuove funzionalità invece che per la manutenibilità. «Aggiungeremo i test più avanti». Oppure: «Lasciamo alcuni “to do” nel codice, e più avanti li aggiusteremo». Ma il problema è che il tuo codice non si rompe quando lo crei per la prima volta: si rompe dieci o quindici anni dopo. E in posti che non avresti mai pensato. Questo è lo stato in cui di solito trovo le aziende: rane bollite che mi chiedono di aiutarle a sbarazzarsi dei loro monoliti non manutenibili, nei quali l’architettura è un pasticcio e non ci sono test automatici, oppure il sistema non scala bene e a ogni variazione di codice il sistema crolla da un’altra parte.

Buttarsi sui microservice? – Dato che l’espressione è stata coniata quasi quattro anni fa, le aziende ora credono che i microservice risolveranno i loro problemi e che porteranno cose buone, in quanto componenti piccoli e indipendenti che consentono di scalare e scrivere un codice gestibile e testabile. Tuttavia, l’implementazione di microservice comporta anche molte domande alle quali è necessario trovare una risposta lungo il percorso, come per esempio:

• Cosa rende un componente un microservice?
• Come integro tutti questi piccoli componenti indipendenti?
• Come progettare le interfacce di questi componenti, le API?
• Cosa significa essere RESTful?
• Come progettare l’implementazione dei miei componenti?
• Come faccio a organizzare l’autorizzazione e l’autenticazione?
• Quali tecnologie posso utilizzare per costruire, testare e distribuire i miei microservice?
• Come posso impostare e mantenere le pipeline di deployment automatizzato?
• Posso integrare i miei microservice con altri sistemi più tradizionali?
• Ultimo ma non meno importante: i microservice implicano che il sistema è distribuito. Quindi, come posso organizzare l’integrità e la coerenza dei miei dati se uno dei servizi non è temporaneamente disponibile?

Nel complesso, i microservice sono una scelta architettonica interessante se si intende eliminare il monolite, ma hanno anche alcune conseguenze non secondarie. Trovare le risposte giuste alle domande appena viste, specifiche per la propria azienda, può essere una sfida. È per questo che bisogna intraprendere seriamente il percorso verso i microservice. Ci vuole tempo, fatica e preferibilmente esperienza. Se non sei stato in grado di tenere in ordine l’architettura, il codice e i test negli ultimi 15 anni, pensi di poter implementare i microservice, che sono un’architettura ancora più difficile?

.@aahoogendoorn Come Progettare e implementare una architettura #Microservice
Click To Tweet

Ma hai davvero bisogno dei microservice adesso? – Sono convinto che i microservice siano l’architettura giusta per questa epoca altamente scalabile. I loro vantaggi non sono pochi: migliorano la scalabilità e consentono di distribuire singole parti piccole e sostituibili in tutta l’infrastruttura. Ma aggiungono anche un altro livello di complessità all’infrastruttura stessa: pensiamo alla progettazione di API RESTful, o all’autorizzazione e all’autenticazione, oppure ancora alle nuove infrastrutture (cloud) e al fatto che adesso state costruendo sistemi distribuiti.Tuttavia, alla maggior parte delle rane che bollono mancano il tempo e l’esperienza per operare tali migrazioni su larga scala dei loro prodotti, ed è per questo che dovrebbero indagare se hanno bisogno di migrare adesso ai microservice. Ci sono molti aspetti dei microservice che già da soli forniscono molti miglioramenti, senza dover per forza ricorrere a tutto il pacchetto completo:

• Fanno aderire a un approccio più agile.
• Migliorano la collaborazione in team e comprendono sia le attività sia le operazioni.
• Migliorano il design modulare dei monoliti.
• Aumentano i test automatizzati, rendendo meno difficile il refactoring a un design più modulare.
• Impostano le pipeline per il deployment automatizzato, che consentono di passare a implementazioni più regolari, eliminando così tutti i tipi di attività di distribuzione manuale.

Forse la sfida principale è migliorare la qualità e la manutenzione del codice. O ridurre il time to market. O forse innovare più velocemente. In questi casi, le tecniche elencate sopra aiuteranno a ottenere risultati senza necessità di passare direttamente ai microservice in una sola volta. Quindi? Stai pensando di spostarti verso nuove architetture? Verso i microservice? O verso il serverless? L’importante è cominciare sempre rispondendo alla domanda: “che cosa mi serve davvero per migliorare?”. E solo dopo aver risposto a questa domanda si migliorerà gradualmente. E si eviterà di entrare a far parte della prossima generazione di rane bollite.

Sander Hoogendoorn

Mentore, allenatore, software architect, sviluppatore, speaker e scrittore. Apprezzato dai suoi numerosi clienti internazionali come grande innovatore nello sviluppo software, è autore del best-seller “This is Agile”. Oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo su diversi argomenti tra i quali: Agile, Scrum, Kanban, continuous delivery, architettura software, Microservices, modeling e UML.

Sander Hoogendoorn presenterà a Roma per Technology Transfer i seminari “Progettare, sviluppare e implementare una Microservices Architecture” il 9 novembre 2017 e “Introduzione a Agile, Scrum, XP, Kanban e Continuos Delivery in pratica” il 10 novembre 2017.

L'articolo Arrivano i microservice. Quando sbarazzarsi dei monoliti. E quando no proviene da Data Manager Online.

Nel 2009 mi sono rivolto a un imprenditore edile per costruire una casa. Insieme a un architetto abbiamo delineato le caratteristiche: oltre a prevedere un seminterrato, abbiamo scelto con cura i materiali, la posizione delle finestre, la disposizione delle stanze e del sottotetto, cioè tutto ciò che occorreva all’impresario per stabilire un prezzo e una data di consegna. La casa è stata completata in circa un anno e mezzo. Se si esamina da una lunga distanza un progetto come questo, sembra trattarsi proprio di un normale progetto di costruzione: sono stati specificati i requisiti, l’impresario ha fornito un prezzo e una data, e tutto è stato consegnato circa un anno e mezzo dopo. Si potrebbe suggerire che questo modello per i progetti di costruzione sia abbastanza adatto anche per i progetti di sviluppo software: si specificano i requisiti, si impostano prezzo e data di consegna, e si parte. In effetti, molti project manager suggeriscono questo modello per i progetti di sviluppo software, supportati dal fatto che questo modello è stato usato fin dagli anni Settanta, da quando veniva spesso definito “a cascata” o “lineare”.

Purtroppo, il modello a cascata o lineare, nel quale si identificano tutti i requisiti e si mettono in concreto prima di iniziare la costruzione vera e propria, non funziona proprio bene. Sono molti gli imprenditori che non riescono a soddisfare i budget o le scadenze, oppure realizzano solo una piccolissima parte dei requisiti concordati. Recenti pubblicazioni su grandi progetti governativi in Olanda documentano di numerosi risultati negativi e di progetti falliti. I clienti danno la colpa agli appaltatori, e questi a loro volta ce l’hanno con i clienti perché impongono di eseguire i progetti seguendo il modello lineare. Molti progetti finiscono in tribunale e la nostra amata disciplina di sviluppo software gode di un’immagine pubblica negativa.

#SviluppoSoftware Sander Hoogendoorn La metafora del #progetto non funziona
Click To Tweet

Ma quindi dove sta l’errore? Permettetemi di cercare di spiegare.

Lo sviluppo software è una disciplina molto giovane

Quando cerchiamo di modellare i nostri progetti di sviluppo software su una metafora proveniente dall’ingegneria civile dimentichiamo che l’ingegneria civile esiste da migliaia di anni. C’è tutto un mondo di esperienze e conoscenze nel settore dell’edilizia che fa capo a Babilonesi, Greci, Egiziani, al Medioevo, al Rinascimento e alle rivoluzioni industriali. Duemila anni fa, gli antichi Romani utilizzavano già il calcestruzzo. Tutta questa esperienza contribuisce al modo in cui i progetti di costruzione vengono eseguiti oggi. Ma lo sviluppo del software è una disciplina piuttosto giovane: se la matematica e il calcestruzzo sono con noi da moltissimo tempo, i linguaggi di programmazione hanno solo circa sessant’anni. È forse per questo che l’applicazione di un modello di progetto derivato da una disciplina che ha migliaia di anni potrebbe non adattarsi benissimo: non abbiamo tutta questa esperienza, o almeno non ancora.

Anche i progetti di costruzione falliscono

Tuttavia, anche con migliaia di anni di esperienza e di sviluppo tecnologico, i progetti di costruzione che utilizzano questo modello “single-pass”, cioè in un solo passaggio, possono fallire. Subito dopo che la mia nuova casa è stata consegnata dall’impresario, abbiamo iniziato a notare un odore terribile dai bagni. Dopo due settimane la situazione è peggiorata. Non potevamo più nemmeno usare lo sciacquone, perché il sistema era completamente intasato. Per farla breve, l’impresario si era completamente dimenticato di collegare la casa alla rete fognaria centrale della città. La riparazione di questo “bug” ha fatto sì che il mio giardino appena finito sia stato rovinato.

Così il modello single-pass in realtà non va bene nemmeno per le costruzioni. E la costruzione di una sola casa non è un grosso progetto. Quando si esaminano progetti di costruzione molto più grandi, i progetti che hanno effettivamente rispettato i requisiti concordati in termini di tempo e di budget costituiscono le eccezioni e non la regola. Quindi, se i progetti di costruzione non funzionano su un modello lineare, come potrebbero farlo i progetti di sviluppo software?

Nello sviluppo software i requisiti possono cambiare

E c’è di più. Quando ho costruito la mia casa, ho dovuto prendere molte decisioni iniziali. Per esempio, anche se non ho dovuto decidere l’altezza delle prese sulle pareti, non è complicato da capire che è molto più difficile aggiungere uno scantinato dopo che una casa è completamente costruita. E lo stesso vale per la rete fognaria. Si potrebbe ben dire che la maggior parte dell’architettura e del design devono essere realizzati all’inizio. Tuttavia, lo sviluppo del software è davvero molto diverso. Il software può sempre cambiare. Anche in un progetto in ritardo si è sempre in grado di cambiare requisiti, interfaccia utente e anche architettura. Pertanto, non abbiamo bisogno di un grande progetto iniziale. Il fatto che (anche) molti progetti si basino ancora su un grande “disegno” iniziale è perché stiamo applicando il modello sbagliato. L’applicazione di un grande progetto iniziale nello sviluppo software ha un effetto negativo sul risultato di questi progetti, perché non consente il cambiamento. E il cambiamento è benefico. Essere in grado di cambiare nel corso di un progetto, anche in ritardo, migliora semplicemente la qualità, e migliora la capacità di massimizzare i vantaggi del software che realizziamo per i nostri clienti.

Il fatto che possiamo cambiare i requisiti, il design e anche l’architettura rende i progetti di sviluppo software molto diversi da altre opere di costruzione. Il software è fluido, non lineare, e dovremmo trarre beneficio da questo.

#SviluppoSoftware Sander Hoogendoorn il 27 e il 28 aprile a Roma per @techtran
Click To Tweet

I progetti non sono la metafora giusta

Ma questo, a mio parere, non è tutto. Come abbiamo visto prima, dopo che abbiamo elaborato le caratteristiche della mia nuova casa, l’impresario ci ha comunicato prezzo e data di consegna: cioè, abbiamo fissato le caratteristiche, il prezzo e la data di consegna. In sostanza, gli stessi tre fattori che vengono utilizzati per monitorare il successo dei progetti di sviluppo software. Spesso chiedo ai project manager di descrivere quando considerano che i loro progetti sono riusciti, e la risposta che spesso ricevo è che se tutti i requisiti vengono consegnati in tempo e all’interno del budget, il progetto è un successo.

Ma è davvero così? Prendiamo in considerazione Word: un prodotto con migliaia di caratteristiche di cui molti ne utilizzano solo un numero molto limitato. Sarebbe stato un prodotto di successo anche se fosse stato consegnato solo con la limitata serie di funzioni perlopiù usate e per una frazione del budget che ci è voluto per realizzarlo? La mia ipotesi è che lo sarebbe stato: ho da tempo sostituito Word con un editor di testo semplice e diretto. Che cosa succede se invece di utilizzare il modello di progetto si decide di realizzare il nostro software funzione per funzione? E se realizziamo solo la versione minima appena sufficiente di tali caratteristiche? Potremmo chiedere continuamente al cliente come intende utilizzare le successive parti di tempo e denaro che ha a disposizione: dobbiamo realizzare una versione più sofisticata delle funzionalità esistenti o la versione minima delle funzionalità successive in lista? Ogni prodotto costruito in questo modo avrebbe l’insieme minimo di funzionalità, realizzato per un budget minimo in una quantità minima di tempo. Consegnato prima di quanto sarebbe stato utilizzando un modello di progetto, lineare o agile che sia, e consegnato a minori costi che non con l’utilizzo di un modello di progetto. E solo con quelle caratteristiche di cui abbiamo veramente bisogno. Costruito così, Word sarebbe stato un editor striminzito ed essenziale, senza tutte le caratteristiche abbondanti che ha oggi.

Ecco perché a mio parere, il software non dovrebbe essere costruito utilizzando un modello di progetto. Mai. Il software dovrebbe invece essere realizzato caratteristica per caratteristica, offrendo un prodotto minimo valido. E nel caso in cui ve lo stiate chiedendo, la mia casa non è stata consegnata in tempo e i limiti di budget non sono stati rispettati. Quindi è proprio il caso di smettere di fare progetti!

Sander Hoogendoorn

Mentore, allenatore, software architect, sviluppatore, speaker e scrittore, apprezzato come grande innovatore nello sviluppo software. Autore del best-seller “This Is Agile”, ha scritto libri anche su UML e pubblicato più di 250 articoli su riviste specializzate. Oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo su diversi argomenti quali, tra gli altri: Agile, Scrum, Kanban, continuous delivery, architettura software, Microservices, modeling e UML.

Sander Hoogendoorn presenterà a Roma per Technology Transfer i seminari “Introduzione a Agile, Scrum, XP, Kanban e Continuos Delivery in pratica” il 27 aprile 2017 e “Progettare, sviluppare e implementare una Microservices Architecture” il 28 aprile 2017.

L'articolo Sviluppo software, la metafora del progetto non funziona proviene da Data Manager Online.

Partiamo da ciò che c’è di buono. Costruiamo piccoli componenti, ognuno da due a sei servizi circa. La componente PDF, per esempio, che non fa altro che generare file PDF da un template con alcuni dati, oppure una componente “customer” che permette agli utenti di cercare i clienti esistenti.

Questi componenti offrono la giusta dimensione rispetto a numerosi riguardi: codice, comprensibilità, documentazione, test e distribuzione. Quando è stata delineata l’architettura di base per i microservice, sono anche state fissate alcune linee guida: non stiamo costruendo solo piccoli componenti, ma anche piccole applicazioni web per un singolo scopo. Le applicazioni possono comunicare con altre, e possono parlare con i componenti.

#Agile Che cosa renderà i #microservice il paradigma vincente? @techtran @aahoogendoorn
Click To Tweet

Il buono

I componenti gestiscono la propria persistenza e lo storage, e possono anche parlare con altri componenti. Le applicazioni non parlano direttamente allo storage, e i componenti non parlano con lo storage di altri. Per noi, queste linee guida funzionano. I microservice realizzano alcune delle loro promesse: si possono scegliere i meccanismi tecnologici e di persistenza adeguati per ciascuno dei loro componenti. Alcuni componenti persistono per database relazionali (DB2 o SQL Server), mentre altri persistono per database di documenti (MongoDB, nel nostro caso). Abbiamo anche affermato che ogni applicazione e componente ha un proprio modello di dominio. Dato che i nostri componenti sono piccoli, i modelli di dominio sono abbastanza semplici, e quindi gestibili.

Il cattivo

Ma, come sempre, c’è un rovescio della medaglia. Quando ci si avvia a percorrere la strada dei microservice, per qualunque ragione la si trovi vantaggiosa, è necessario rendersi conto che si tratta di un percorso completamente nuovo. Pensiamoci un secondo: se non stai lavorando per Netflix o Amazon, come fai a conoscere qualcuno che si occupa già di microservice? Chi ha attivamente implementato servizi in produzione e a pieno regime? A chi si può chiedere qualcosa?

È necessario essere consapevoli del fatto che si ha realmente bisogno di scavare a fondo e sporcarsi le mani. Si dovrà fare un sacco di ricerca da soli. Non ci sono ancora standard. Ci si renderà conto che tutte le scelte che si adottano in materia di tecniche, protocolli, framework e strumenti, sono probabilmente temporanee. Quando si sta imparando ogni giorno, diventano disponibili o necessarie nuove e migliori opzioni, e le scelte si modificheranno di conseguenza. Quindi, se si è alla ricerca di un kit “stile Ikea” già pronto per implementare i microservice nel modo giusto, forse sarebbe opportuno stare lontani dai microservice per i prossimi cinque-sette anni, e aspettare i grandi vendor, che si getteranno nella mischia abbastanza presto, visto che le opportunità di fare soldi non mancano.

Dal punto di vista del design, si dovrà cominciare a pensare in modo diverso. Progettare piccoli componenti non è facile come sembra. Di solito c’è un sacco di cablaggio da tagliare, e nel frattempo sarà necessario garantire che il sistema non si rompa. Inoltre, ci sarà bisogno di una buona dose di conoscenza di dominio per rendere in componenti i sistemi esistenti.

#Agile Sander Hoogendoorn a Roma il 22 aprile e il 10 giugno @techtran @aahoogendoorn
Click To Tweet

Alla base, abbiamo scoperto che i componenti non sono così stabili come pensavamo. Di tanto in tanto, fondiamo componenti tra loro, mentre sembrava molto più facile dividere i componenti in altri più piccoli per avere un riutilizzo e un time-to-market più rapido. A titolo di esempio, abbiamo tirato fuori un componente “Q&A” dal componente “Prodotto”, che ora fornisce questionari per altri scopi invece che a farlo solo sui prodotti. E più recentemente abbiamo creato un nuovo componente che si occupa solo della convalida e dell’archiviazione di questionari compilati.

Ma ci sono anche numerose questioni tecniche alle quali bisogna rispondere. Qual è l’architettura di un componente? Anche un’applicazione è un componente? E così via. In effetti, per assicurarsi che i servizi siano più o meno chiamati in modo uniforme, sarebbe meglio creare un piccolo framework che fa le richieste e che si occupa di risposte e degli errori, in modo da gestire questa comunicazione bidirezionale in maniera uniforme per ogni richiesta. Ma vi è anche la necessità di standardizzare parte del codice che si sta scrivendo. La libertà tecnologica è un’ottima cosa, ma se ogni componente è letteralmente implementato in modo diverso, si finirà per avere una base di codice quasi impossibile da mantenere, soprattutto perché è probabile che nessuno sorvegli tutto il codice che viene scritto. Io suggerisco energicamente di assicurarsi che vi sia coerenza nei vostri componenti su aspetti della vostra base di codice che si potrebbero, e probabilmente si dovrebbero, unificare. Si pensi ai componenti dell’interfaccia utente (griglie, pulsanti, pop-up, error box), alla validazione (di modelli di dominio), o al dialogo coi database oppure infine a come sono formulate le risposte dai servizi.

Il brutto

Ma allora quali sono le parti veramente sgradevoli dei microservice? Cominciamo con i percorsi di implementazione. Una delle promesse dei microservice è che questi possono e devono essere implementati e rilasciati singolarmente. Quindi, se attualmente si è abituati ad avere un unico percorso di realizzazione e di implementazione per il sistema che si sta costruendo o estendendo, si potrebbe avere una piacevole sorpresa, in quanto con i microservice si creano percorsi individuali per i singoli componenti. E poi, rilasciare la prima versione di un componente non è difficile. Ma un aspetto che può preoccupare è il controllo delle versioni. Se già è abbastanza difficile dare le versioni per poche applicazioni collaboranti, cosa dire allora di un centinaio di applicazioni e componenti, ciascuna delle quali si basa su una serie di altre per l’erogazione dei servizi richiesti? Naturalmente, tutti i vostri servizi sono indipendenti, come promette il paradigma dei microservice. Ma è solo insieme che i servizi diventano il sistema. Come si fa a evitare di trasformare la vostra bella architettura microservice nell’inferno delle versioni, che poi sembra davvero un discendente diretto dell’inferno delle DLL? A essere onesti, in questo momento non potrei consigliarvi bene su questo argomento, ma un avvertimento amichevole può essere saggio. Abbiamo iniziato con un semplice schema di numerazione a tre cifre (come 1.2.5): il numero più a destra cambia quando i bug minori vengono risolti, mentre il numero al centro sale quando ulteriori funzionalità minori vengono aggiunte a un componente, e il numero più a sinistra cambia quando si distribuisce una nuova versione di un componente con sostanziali modifiche alla sua interfaccia. Lungi da noi l’idea di promuovere un cambiamento regolare delle interfacce, ma almeno sappiamo che succede.

#microservice Sander Hoogendoorn Il #Buono il #Brutto e il #Cattivo @aahoogendoorn @techtran
Click To Tweet

In conclusione

Siamo a uno stadio troppo iniziale della partita? Sì, perché siamo sulla rotta dei microservice da circa un anno. E io ancora non ho capito se ci troviamo sulla scala verso il paradiso o sulla strada per l’inferno. Suppongo, com’è già capitato con i predecessori storici, che finiremo da qualche parte nel mezzo, anche se penso davvero che abbiamo la tecnologia per far lavorare bene questo nuovo paradigma, e non mi riferisco solo a Netflix, Amazon o a qualche società di telefonia mobile particolarmente “hipster”, ma anche alle normali aziende di medie dimensioni per le quali opero. Ma funzionerà? Per essere onesti, non lo so ancora, nonostante o forse anche a causa di tutto l’hype che circonda oggi i microservice. Quello che ho notato è che, data la complessità di tutto ciò che li riguarda, ci vorrà un po’ di tempo prima di avere i primi servizi attivi e funzionanti, e stiamo solo passando da questo punto. Quindi, se c’è una cosa che ho imparato nel corso dell’ultimo anno, è di essere pazienti, una parola che decisamente non era ancora nel mio dizionario. Non cercate di far rispettare tutti i tipi di norme (anche aziendali) se solo non esistono ancora. Cercate di immaginare al volo. Concedetevi di imparare. Procedete un passo alla volta. Basta provare a fare tutto un po’ meglio rispetto al giorno prima. E, come sempre, buon divertimento!

Sander Hoogendoorn

Mentore, allenatore, software architect, sviluppatore, speaker e scrittore. Apprezzato dai suoi numerosi clienti internazionali come grande innovatore nello sviluppo software, è autore del best-seller “This is Agile”. Ha scritto libri anche sul linguaggio UML e il modelling Agile, e ha pubblicato più di 250 articoli su riviste specializzate. Oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo.

Sander Hoogendoorn presenterà a Roma per Technology Transfer i seminari “Agile, Scrum, XP, Kanban e Continuos Delivery in pratica” il 22 aprile 2016 e “Progettare, sviluppare e implementare una Microservices Architecture” il 10 giugno 2016.

L'articolo Il buono, il brutto e il cattivo dell’architettura microservice proviene da Data Manager Online.

By Sander Hoogendoorn

Nel lontano 1988, al mio primo impiego presso una società per scrivere software, il mondo era abbastanza semplice. L’ambiente di sviluppo era basato su caratteri. Il database era integrato e attraversato da cursori. E avevamo costruito un intero nuovo sistema amministrativo che copriva tutto tranne il lavello della cucina. Ci vollero cinque anni per completare il progetto, soprattutto perché il cliente continuava a cambiare idea spesso e perché ogni cambiamento nel codice avrebbe potuto rompere il codice in altre parti del sistema. L’unit testing non era ancora stato inventato e il collaudo veniva svolto dagli utenti finali, in produzione.

Fin qui si trattava di monoliti, ma nel 1994 passai a un’azienda che realizzava applicazioni desktop. Non dimentichiamo che il world wide web era nato solo da un paio di anni e che le applicazioni web non erano ancora state inventate. Utilizzavamo un ottimo strumento chiamato PowerBuilder e ora avevamo due componenti di cui preoccuparci: l’applicazione sul desktop e il database sul server. Le applicazioni che costruivamo di solito servivano per i reparti o talvolta anche per l’intera azienda. Non erano molto complicate, ma nemmeno altamente scalabili. Insomma, ci divertivamo, almeno fino a quando è durato il paradigma client-server.

#Agile Che cosa renderà i #microservice il paradigma vincente? @techtran @aahoogendoorn
Click To Tweet

Lo sviluppo basato sui componenti

Ma il mondo divenne più complesso a metà degli anni Novanta: le aziende volevano applicazioni web, in genere eseguite su intranet, per potersi sbarazzare delle implementazioni desktop, e chiedevano applicazioni necessarie per servire più reparti e talvolta anche per andare oltre i confini aziendali. Nacque un nuovo paradigma: lo sviluppo basato sui componenti, noto anche come CBD, component based development. Il paradigma prometteva il riutilizzo, la scalabilità, la flessibilità e un modo per raccogliere il codice esistente (di solito scritto in COBOL). Così iniziammo a scomporre i nostri sistemi in grandi blocchi funzionali, e a cercare di far comunicare tra di loro quei componenti. Fu inventato Java, e tutti improvvisamente volevano scrivere codice in Java (e a quanto pare alcuni cercano di farlo ancora oggi). I componenti venivano eseguiti su tecnologie impossibili come application server e CORBA (se volete impressionare i vostri collaboratori, cercate quest’ultimo su Wikipedia). Ah, i bei vecchi tempi degli object request broker!

In quel periodo lavoravo per una grande banca internazionale, cercando di impostare una metodologia per fare sviluppo basato sui componenti. Ma anche con un team pesantemente armato di consulenti Andersen ci vollero tre anni per scrivere il sistema: alla fine, sia il paradigma sia la tecnologia erano troppo complessi per scrivere software decenti e performanti. Semplicemente non decollò mai.

#Agile Sander Hoogendoorn a Roma il 22 aprile e il 10 giugno @techtran @aahoogendoorn
Click To Tweet

La service oriented architecture

Poi, nei primi anni di questo secolo, pensavo che ci fossimo sbarazzati dello sviluppo software distribuito e avessimo felicemente iniziato a costruire applicazioni web. Credo che tutti ignorassero coraggiosamente la prima legge di Martin Fowler sugli oggetti distribuiti: non distribuite i vostri oggetti. A poco a poco ci siamo spostati nel paradigma successivo del computing distribuito, reimpacchettando le promesse dello sviluppo basato su componenti in un insieme rinnovato di tecnologie. Così, iniziammo a sviluppare business process modeling (BPM) e a implementare questi processi in Enterprise Service Bus (ESB), con servizi di fornitura dei componenti. Eravamo nell’età della Service Oriented Architecture, meglio conosciuta come SOA. Venendo dal CBD, la SOA sembrava più facile. Finché i componenti – i producer – sono agganciati nell’enterprise service bus, eravamo in grado di costruire sistemi scalabili e flessibili, visto che ora avevamo componenti molto più piccoli che si potevano davvero estrarre dai nostri sistemi esistenti (e ormai non scritti solo in COBOL, ma anche in PowerBuilder, .NET e Java). I libri con gli schemi obbligatori di progettazione erano stati pubblicati e il mondo era pronto ad andare avanti: questa volta sarebbe stata quella giusta!

Mi sono trovato a lavorare per una società di trasporti internazionali, realizzando felicemente applicazioni sul middleware SAP, fornendo tool ESB e BPM. Non avevamo bisogno solo di regolari sviluppatori Java e .NET, ma anche sviluppatori di middleware e consulenti SAP. E anche se la metodologia agile era stata introdotta per accelerare lo sviluppo (lo so, questo non è l’argomento più adatto), i progetti mostravano ancora una certa lentezza. Ma soprattutto, una volta messi a posto tutti i pezzi del puzzle, abbiamo iniziato a capire che i test di integrazione e l’implementazione di nuove release diventavano sempre più complicati di giorno in giorno.

Finalmente i microservice!

Spero che i lettori mi perdoneranno per questa lunga e tortuosa introduzione al tema attuale: i microservice, che qualcuno chiama anche microservizi. Certamente si potrebbe obiettare sulla necessità di avere un altro articolo sui microservice, visto che sull’argomento c’è già molta letteratura. Ma se si guarda da vicino al diluvio di articoli che si trovano su internet, la maggior parte descrivono solo i vantaggi e le possibilità dei microservice, e alcuni prendono in esame i pochi esempi famosi (Netflix, Amazon, e Netflix, e Amazon e Netflix e …). Solo un paio di articoli scavano davvero nel profondo, e di solito consistono nell’elencare le tecnologie che si usano nell’implementazione dei microservice. Forse siamo ancora a uno stadio iniziale.

Per questo, un po’ di prospettiva storica non farà male. Trovo interessante constatare che i benefici e le possibilità dei predecessori dei microservice sono ancora con noi. I microservice sembrano promettere sistemi scalabili e flessibili, basati su piccoli componenti che possono essere facilmente implementati in modo indipendente, e quindi promuovono l’uso delle migliori scelte nel campo delle tecnologie per componenti. Fondamentalmente, si tratta delle stesse promesse tipiche di CBD e SOA, quindi parrebbe non esserci nulla di nuovo, ma questo non vuol dire che non sia utile indagare sui microservice.

#microservice Sander Hoogendoorn Il #Buono il #Brutto e il #Cattivo @aahoogendoorn @techtran
Click To Tweet

Questa volta è diverso?

Insomma, cosa c’è di diverso questa volta? Cosa renderà i microservice il paradigma vincente, come invece non erano i suoi predecessori? Che cosa lo fa emergere? Come sviluppatore, non c’è dubbio che sono piuttosto entusiasta dei microservice, ma lo ero anche (più o meno) quando vennero fuori CBD e SOA. Io suppongo che ci siano alcune differenze. Per la prima volta, sembra che siano disponibili tutte le tecnologie necessarie per realizzare questo tipo di architetture. Tutto il middleware frivolo e complesso è sparito, e ci si affida esclusivamente su protocolli web e su tecnologie di base e soprattutto esistenti da lunga data: basta solo confrontare REST a CORBA. Inoltre, ci sembra di comprendere molto meglio il deployment, alla luce del fatto che abbiamo imparato come fare l’integrazione continua, l’unit testing e anche l’erogazione continua. Queste differenze suggeriscono che questa volta siamo in grado di far funzionare tutto. Eppure, dal mio punto di vista storico, un certo scetticismo è inevitabile. Anche dieci anni fa, eravamo davvero convinti che la SOA sarebbe stata tecnologicamente fattibile, avrebbe risolto tutti i nostri problemi e ci avrebbe messo in grado di costruire rapidamente cose più riutilizzabili e più affidabili. Quindi, per essere onesti, il fatto che noi crediamo che la tecnologia sia pronta, non costituisce un argomento particolarmente valido. Perché nel frattempo, anche il mondo è diventato più complesso. Nel corso dell’ultimo anno, ho avuto a che fare con una società che si sta allontanando dal mainframe (troppo caro) e da una serie di monoliti Java meno recenti (troppo grandi e difficili da mantenere). Anche il time-to-market svolge un ruolo importante: l’IT deve supportare l’introduzione di un nuovo prodotto nell’arco di pochi mesi, se non di settimane. Così abbiamo deciso di essere alla moda e adottare i microservice.

Ma se volete conoscere il buono, il brutto e il cattivo dell’architettura microservice, così come ho avuto modo di vedere nel corso del nostro primo anno di utilizzo, dovete leggere il mio riepilogo sul prossimo numero di Data Manager.

Sander Hoogendoorn

Mentore, allenatore, software architect, sviluppatore, speaker e scrittore. Apprezzato dai suoi numerosi clienti internazionali come grande innovatore nello sviluppo software, è autore del best-seller “This is Agile”. Ha scritto libri anche su UML e pubblicato più di 250 articoli su riviste specializzate. Oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo.

Sander Hoogendoorn presenterà a Roma per Technology Transfer i seminari “Agile, Scrum, XP, Kanban e Continuos Delivery in pratica” il 22 aprile 2016 e “Progettare, sviluppare e implementare una Microservices Architecture” il 10 giugno 2016.

L'articolo Il buono, il brutto e il cattivo. Microservice: che cosa cambia? proviene da Data Manager Online.