Microservizi, Micro Frontends e Feature Team

Agilità: un bilancio tra obiettivi tecnici e obiettivi di business

Il punto per Giulio è fare agilità per fare business. Facciamo nostre le tecnologie e i framework di ultima generazione, ma non dimentichiamo gli obiettivi di business.
Da un lato abbiamo gli obiettivi lato tecnico e tecnologico che ogni team di sviluppo dovrebbe prefiggersi:

• Riduzione debito tecnico
• Semplicità
• Innovazione
• Apprendimento continuo

Dall’altro si ha il business:

• Effetto wow
• Time to market: essere più veloci di tutti nel rilasciare il prodotto sul mercato, ad oggi è uno dei fattori critici di successo per aziende che operano in contesti fortemente competitivi, come quello del software
• Customer satisfaction
• Up-selling / cross-selling: strategie di marketing molte diffuse
  • Up-selling: tecnica di vendita con la quale si incentiva il cliente all’acquisto di una quantità di prodotto maggiore rispetto a quanto inizialmente richiesto
  • Cross-selling: strategia di vendita consistente nel proporre al cliente che ha già acquistato un particolare prodotto o servizio anche l’acquisto di altri prodotti o servizi complementari.

Trovare un bilanciamento non è semplice, ma non impossibile.
Rispetto a 10, 20 anni fa il mondo si è evoluto e anche il modo in cui si sviluppa software.
Oggigiorno un sistema IT è basato su tre pilastri:

• Dati al centro: Big Data
• Interconnessione: API as a Product (pensate a Facebook, Google o Amazon)
• Capacità di evoluzione: esistono diversi stili architetturali, dalle architetture monolitiche a microservizi

Con il tempo anche il modo di lavorare e di organizzarsi è cambiato. Si adottano metodologie e pratiche Agili, oppure Lean.
Per poter implementare e rilasciare software, e quindi valore, in maniera continuativa è oltretutto necessario adottare un nuovo approccio. Non più solo sviluppatore, o dev come si usa in gergo, bensì dev + ops, che sta per  operations (pipeline di Continuos Integration/Continuous Deployment ad esempio). Quindi DevOps, termine ad oggi molto in voga.

Gli ingredienti ci sono, come utilizzarli al meglio?

L’evoluzione dei sistemi porta ad un’evoluzione dell’organizzazione

Riprendendo la legge di Melvin Conway

Any organization that designs a system … will inevitably produce a design whose structure is a copy of the organization’s communication structure.

Giulio è concorde sul fatto che un’organizzazione che progetta un sistema lo farà inevitabilmente ad immagine e somiglianza della sua struttura comunicativa.
Ribaltiamo questa legge e facciamo sì che l’intera struttura organizzativa segua gli sviluppi e le modifiche del sistema. Questo propone Giulio.

Cerchiamo di abbattere il “muro” che spesso si erge tra cliente e fornitore. Come sostiene Sam Newman nel suo libro Monolith to Microservices, il “noi” e “loro” rallenta le decisioni e aumenta i costi. Riorganizzarsi e allinearsi con le esigenze dei clienti finali diventa più efficace e riduce costi aumentando la velocità di delivery.

A tal proposito si potrebbe, anzi si dovrebbe passare dai classici Component team ai Feature team.
I componenti di un Feature team sono in grado di mettere mano a tutti i componenti di un sistema e completare quindi uno o più feature richieste dal P.O.
Questo perché un Feature team non è creato per avere una durata circoscritta allo sviluppo di una o più funzionalità, bensì è stabile e gestisce tutto il ciclo di vita dell’insieme delle features che sono di sua responsabilità.
I membri di questo tipo di team hanno la conoscenza e le skill necessarie per completare feature nella loro interezza. Qualora ci siano lacune, è compito del team colmarle in un processo di apprendimento continuo.

Nell’ultima parte del suo intervento Giulio ha riportato due esempi concreti tratti dalla sua esperienza, Trenord e MIA-platform.

Trenord e MIA-platform: esempi pratici

Trenord

Trenord in cinque anni ha costruito una piattaforma digitale in modo incrementale agganciando man mano nuovi canali e facendo evolvere l’architettura in base allo scaling degli utenti.

A livello di API si è passati da gestire 10 richieste al secondo al 4000 richieste al secondo,  in un sistema inizialmente composto da Microkernel e Fast Data a miniservizi e Fast Data.
Brevemente, per Fast Data si intende una applicazione dei Big data laddove la vera sfida non sta più nella storicizzazione del dato bensì nel creare batch di dati più piccoli per lo streaming in tempo reale.
Il passaggio da un unico microkernel all’avere anche dei microservizi non è stato netto, ma graduale con attenzione sempre rivolta al feedback del cliente.
Come tecnica di rilascio è stata applicata Canary Releases sia lato mobile app che lato microservizi.
In breve, Canary Releases è una tecnica per ridurre i rischi legati all’introduzione di una nuova versione del software in produzione distribuendo la modifica a un piccolo sottoinsieme di utenti prima di rilasciarla all’intera infrastruttura e renderla quindi disponibile a tutti.

A livello organizzativo Giulio e i suoi collaboratori si sono organizzati in un team unico con metodologia Scrum, sprint da una settimana e rilasci continui. Tre ambienti: integrazione, beta e produzione.
Il team ha responsabilità di mantenere viva l’applicazione 24/7 dal backend al frontend, con attività di customer care e analisi di analitici per poi proporre nuove feature.

MIA-platform

Una delle giovani realtà nel mondo dello sviluppo software, è un Digital Integration Hub.
Giulio ha raccontato l’evoluzione dal 2017, forti dell’esperienza con il lavoro sulla app di Trenord e i Feature team.
Si è passati da un unico team core a team core e diversi contributor team.
Ogni contributor team ha responsabilità specifiche sui progetti del cliente e fanno evolvere la platform in stile open source implementando nuovi servizi e nuovi componenti con l’opportunità di utilizzare nuove tecnologie e framework qualora lo ritengano necessario.

Parliamo quindi di microfrontend, che in estrema sintesi è uno stile architetturale in cui tante piccole applicazioni frontend indipendenti sono composte in una più grande.

Nel caso di MIA-platform, la base è data da librerie comuni Javascript per integrare diversi framework e librerie.
Più un insieme di regole comuni sulla gestione dei feature branch, merge request e code design.
Le pipeline automatizzate in diversi ambienti per Continuous Delivery.
Per condividere la conoscenza, vengono svolti Kata e applicate tecniche eXtreme Programming come Mob Programming e Pair Programming.

Giulio ha chiuso il suo intervento ricordando che la cultura è il nostro asset, coltivarla affinché sia personale e non fare un copia-incolla da aziende di successo.
Questa è la vera chiave per il successo!

Riferimenti

• Slide della presentazione
• MIA-Platform
• Melvin Conway
• Monolith to microservices, libro di Sam Newman
• Feature team
• Canary release
• Microfrontend