Lean MURI-MURA-MUDA

Come Comprendere in "Learning Time Zero" la metodologia Lean di sviluppo ? 

Ebbene vi propongo il metodo Giapponese MURI-MURA-MUDA !
Cosa Vuol dire ?
Supponete di possedere un camion con una portata di due tonnellate e di dover trasportare 6 tonnellate, cosa fareste ?
Per buonsenso distribuireste il lavoro facendo 2 portate da 3 tonnellate l'una, ecco questo è Lean.

MUDA vuol dire spreco (fisico, visibile), la sua identificazione ed eliminazione. Ma nel lean thinking, anche le altre due indicano sprechi, ma in forma diversa rispetto a sette tipi di spreco classici che si notano immediatamente, e rappresentati da muda (sovrapproduzioni, trasporti, attività non necessarie, movimentazioni, difetti, inventari e attese). Ma non vuol dire che sono meno importanti. Vediamole:

MURI è il termine che indica il sovraccarico delle persone o delle risorse. Cosa comporta il sovraccarico delle persone o delle risorse? Quello delle persone può provocare a lungo termine la possibilità di infortuni o malattie professionali, dovuti alle posture esagerate che vengono richieste in continuazione dai lavoratori. Anche a breve termine può provocare gli strappi muscolari o altre cose simili. Ciò poi causa (nel migliore dei casi…) l’assenza dal lavoro per periodi più o meno lunghi e insoddisfazione generale delle persone che si sentono sfruttate (secondo voi, quale è il motivo dell’esistenza dei sindacati dei lavoratori in Italia?…). Pensate per analogia ad un camion che viene sollecitato con il doppio del carico nominale in continuazione: la prima volta probabilmente non succederà nulla, la seconda neanche, … , alla n-esima volta invece succede che si rompe un’asse e il camion non è più utilizzabile o ha bisogno di lunghi tempi di riparazione. Questo deve farvi pensare: ma vale veramente la pena sollecitare le persone e le risorse oltre il loro limite fisico per avere un beneficio a breve termine? O volete pensare a lungo termine e usare le persone e le risorse in modo ottimale? Come fate a sapere che le persone sono sovrasollecitate? Basta chiedere a loro. Vi diranno loro che quella postura non va bene, che quel carico è troppo pesante ecc. Ma dovete anche osservare il lavoro ed accorgervi da soli che ci sono attività che potrebbero essere fatte in maniera più efficace ed anche veloce, e che tolgono il sovraccarico dalle persone. Il lean thinking insegna proprio questo: di vedere!

MURA invece indica le fluttuazioni, variazione, irregolarità del carico del lavoro (della domanda). Cosa comportano le fluttuazioni? Comportano la creazione delle fasce dove c’è un sovraccarico (spreco di muri…) e delle fasce nelle quali c’è un sottocarico ottimale (ad esempio spreco di attese – muda…). Il flusso produttivo sicuramente nè risulta disturbato. Quale è la causa delle fluttuazioni? E’ la non standardizzazione della domanda attraverso l’utilizzo dei metodi che servono per appiattire i picchi e le valli (ad esempio attraverso l’utilizzo del box heijunka). Facciamo un esempio, sempre del nostro camion: supponiamo di dover trasportare 6t di materiale e camion ne porta 3t. Uno spreco di muri vorrebbe dire portare 6t tutti in una volta. Il muda sarebbe di portare 3 volte per 2t. Mura sarebbe di portare una volta 4t e un’altra volta 2t (o 5t e 1t, indifferentemente…). L’ottimale sarebbe invece di portare 2 volte 3t (non ci sono sovraccarichi, non c’è la fluttuazione della domanda, non ci sono sottocarichi o sprechi delle risorse, un flusso equilibrato e continuo).

Che cosa sono i microservizi?

Contesto
Dagli anni ‘90 il modello multi-strato (multi-tier architecture) è stato considerato un pattern architetturale fondamentale per costruire un sistema software. Secondo tale modello le varie funzionalità software sono logicamente separate su più strati che comunicano tra di loro. Ogni strato comunica con gli strati adiacenti in modo diretto richiedendo ed offrendo servizi. In effetti in questa architettura il sistema software, sia pure se logicamente suddiviso in strati, risulta essere un unico sistema monolitico.
L’avvento e la diffusione del cloud computing, le pratiche di continuous delivery, l’approccio alla gestione della complessità del software basato sul DDD (Domain-Driven Design), l’organizzazione agile delle aziende in team di sviluppo piccoli ed autonomi (3-7 persone) sono il contesto in cui è emerso il modello dell’architettura a microservizi.
Che cosa sono i microservizi?
In breve i microservizi sono dei servizi “piccoli” ed autonomi che interagiscono tra di loro e che hanno come finalità quella di fare una cosa e di farla bene; sono a tutti gli effetti dei sistemi distribuiti. Per dare una definizione più precisa possiamo riprendere le parole di Martin Fowler che afferma:
Lo stile architetturale a microservizi è un approccio allo sviluppo di una singola applicazione come insieme di piccoli servizi, ciascuno dei quali viene eseguito da un proprio processo e comunica con un meccanismo snello, spesso una HTTP API.
Ma quanto devono essere piccoli i microservizi?
Non è facile rispondere a questa domanda. Infatti non è possibile fornire una risposta, ad esempio, in termini di numero di righe di codice che definiscono la giusta taglia: alcuni linguaggi di programmazione sono più concisi di altri, riuscendo ad esprimere molto senza essere verbosi, per non parlare poi di librerie e dipendenze o della complessità del dominio del software in oggetto.
Secondo Jon Eaves, famoso autore di testi del mondo Java, un microservizio deve essere tale da poter essere riscritto in due settimane. Ovviamente va considerato che tale risposta ha validità nel contesto lavorativo di Real Estate Australia dove Eaves lavora. In sostanza la taglia corretta deve essere identificata in accordo alla struttura organizzativa aziendale.
Teniamo sempre in mente che man mano che la dimensione di un servizio decresce, aumentano i benefici relativi all’indipendenza tra le parti, ma cresce anche la complessità di gestire un numero elevato di parti.
Autonomia
Ogni microservizio è un’entità separata che viene generalmente pubblicata su una piattaforma PaaS oppure eseguita da uno processo di sistema ad hoc.
La comunicazione tra i servizi avviene attraverso la rete al fine di garantire l’indipendenza tra i servizi ed evitare ogni forma di accoppiamento.
Ogni microservizio si propone all’esterno come una black-box, infatti espone solo un Application Programming Interface (API), astraendo rispetto al dettaglio di come le funzionalità sono implementate e dallo specifico linguaggio o tecnologia utilizzati. Ciò mira a far si che il cambiamento di ciascun microservizio non abbia impatto sugli altri.
Vantaggi
L’utilizzo dell’architettura a microservizi ha indubbiamente dei vantaggi:
• Velocizzare i tempi di rilascio del software e reagire velocemente alle esigenze del mercato
In generale, nell’architettura a microservizi, ogni singolo servizio è autonomo rispetto agli altri, di coseguenza può raggiungere l’ambiente di produzione in modo indipendente dagli altri, senza che tale attività abbia effetti drammatici sul resto del sistema. Disporre di un processo di deployment snello e veloce consente di poter aggiungere o modificare funzionalità di un sistema software in modo efficace ed efficiente, rispondendo alle necessità di mercato e utenti sempre più esigenti.
• Sperimentare più facilmente nuove tecnologie
Molto spesso, la principale barriera per adottare una nuova tecnologia risiede nel rischio associato all’utilizzo di qualcosa di nuovo e con il quale si ha poca esperienza. Confinando questo rischio ad una piccola porzione di un sistema software, che è possibile riscrivere in appena due settimane di lavoro, il rischio risulta molto contenuto e quindi è una sfida da accettare.
• Migliori performance grazie all’utilizzo di tecnologie ad hoc
L’utilizzo di linguaggi e tecnologie eterogenee consente di poter utilizzare gli stack più performanti per implementare specifiche funzionalità: ad esempio è possibile introdurre una particolare tipologia di base dati che risulta naturale per mappare un determinato dato, oppure eseguire un calcolo in un modo particolarmente efficiente.
• Resilienza
In un’architettura a microservizi, quando una componente non funziona non è automatico che tutto il sistema software smetta di funzionare. In molti casi è possibile isolare il problema ed intervenire mentre il resto del sistema continua a funzionare, cosa non possibile in un’architettura monolitica. Va però sottolineato che l’architettura a microservizi, essendo un insieme di sistemi distribuiti, espone ad una nuova fonte di problemi legati ai disservizi di rete.
• Scalabilità
In generale risulta molto più semplice ed economico scalare un microservizio rispetto ad un sistema software monolitico di grandi dimensioni. Il modello a microservizi consente di poter effettuare provisioning delle parti del sistema software in modo dinamico ed intelligente.
• Facilità di deployment
Modificare poche righe di codice su un sistema software monolitico di grandi dimensioni ed effettuarne il deploy è generalmente un’attività non banale, che espone a rischi significativi considerando anche l’impatto che tali modifiche possono avere. Questa paura generalmente porta a raccogliere un certo numero di modifiche prima di avviare un’attività così onerosa e rischiosa.
Con l’approccio a microservizi ogni singolo servizio può raggiungere l’ambiente di produzione in modo indipendente, sicché se si verifica un problema esso è facilmente isolato e possono essere intraprese azioni di rollback più velocemente.
• Componibilità
Tra le opportunità più interessanti dell’architettura a microservizi vi è la possibilità di riusare le funzionalità. Infatti è possibile che una stesso servizio venga utilizzato in modi differenti e per scopi diversi. Si pensi ad esempio ad un sistema software che deve poter dialogare non solo col mondo web ma anche con applicazioni mobile, dispositivi wearable, etc.
• Sostituibilità
Quando un sistema software è organizzato a microservizi, il costo di sostituire un servizio con un altro più efficiente e migliore è limitato a circa due settimane di sviluppo, così come banale è il costo di rimuovere un servizio inutile.
Svantaggi
Da quanto fin qui trattato, potrebbe sembrare che l’architettura a microservizi risulti essere la manna dal cielo, non è così. Infatti non possiamo dimenticare di ribadire che utilizzare tanti servizi che dialogano tra di loro attraverso la rete, vuol dire di fatto avere a che fare con un sistema distribuito, con tutti i problemi dal caso.
Si pensi, ad esempio, a cosa vuol dire autenticare un utente su un’architettura distribuita volendo garantire il single sign-on, oppure a come gestire la mutua autenticazione tra i servizi che compongono il sistema software. E ancora: cosa vuol dire testare un sistema software di questo tipo?
Infine, vengono fuori altre tematiche tipiche dei sistemi distribuiti come la gestione di situazioni in cui è necessario che il sistema software sia in grado di riconfigurarsi al volo quando una nuova istanza di un servizio viene creata e il resto della rete può automaticamente trovare essa ed iniziare a comunicare con essa. Questo processo è chiamato service discovery.

Bibliografia
• Appunti della CloudConf 2015 di Torino
• Building Microservices, Sam Newman, O’Relly
• Micro services, what even are they? Jon Eaveshttp://techblog.realestate.com.au/micro-services-what-even-are-they/
• Microservices, Martin Fowlerhttp://martinfowler.com/articles/microservices.html
• Road to Microservices, Salvatore Cordianohttp://www.slideshare.net/parallelit/road-to-microservices