Il talk parte da una osservazione sui progetti che sto sviluppando: Agile Scaling significa prima di tutto Software Scaling. Si parla spesso di come "scalare agile" e di quali siano le strategie migliori per dominare la complessità che comporta il moltiplicarsi dei canali di comunicazione di tante persone che lavorano sullo stesso progetto. Molte soluzioni sono proposte ed adottate, a volte hanno successo a volte falliscono. Molti concordano che team organizzati a "strati" sono disfunzionali e alla lunga portano a conflitti e colli di bottiglia. Organizzarsi a Feature Teams, Spotify ne è un esempio, favorisce la semplificazione delle relazioni e un miglioramento di qualità e velocità di sviluppo. Ma come? La risposta non è semplice e dipende da tanti fattori tra i quali: maturità del prodotto, cultura aziendale e competenza delle persone. La soluzione che presenterò si basa sul principio che le persone si organizzano per lavorare al meglio sulla codebase che stanno creando. Il vero cambiamento culturale agile avviene quando questo si riflette sul codice. Cambiare tutta l'azienda e avere ancora il codice organizzato a silos è comunque inefficiente e alla lunga porterà nuovamente ad un'organizzazione a Silos 2.0 :-) In questo talk vedremo come sia possibile favorire la riorganizzazione dei team adottando un pattern architetturale a microservizi con esempi pratici di team che hanno iniziato ad adottare questo approccio e si sono ri-organizzati in modo naturale.

1. MICROSERVICES
FAVORIRE I "FEATURE TEAMS" CON ARCHITETTURE
@giulioroggero
agilereloaded.it

2. ANY ORGANIZATION THAT DESIGNS A
SYSTEM … WILL INEVITABLY PRODUCE A
DESIGN WHOSE STRUCTURE IS A COPY OF
THE ORGANIZATION'S COMMUNICATION
STRUCTURE.
Melvin Conway, 1968
foto - dani andcoconut
http://www.melconway.com/research/committees.html

3. TEXT
SAM NEWMAN SCRIVE
“Organizations for a few years now have understood this link between organizational
structure and software they create, and have been embracing new structures in order to
achieve the outcome they want. Netflix and Amazon for example structure themselves
around multiple small teams, each one with responsibility for a small part of the overall
system. These independent teams can own the whole lifecycle of the services they
create, affording them a greater degree of autonomy than is possible for larger teams
with more monolithic codebases. These services with their independent concerns can
change and evolve separately from one another, resulting in the ability to deliver
changes to production faster. If these organizations had adopted larger team sizes, the
larger monolithic systems that would have emerged would not have given them the
same ability to experiment, adapt, and ultimately keep their customers happy.”
https://www.thoughtworks.com/insights/blog/demystifying-conways-law

4. IN UNA TRASFORMAZIONI AGILE
VOGLIAMO MIGLIORARE
▸ Time to market
▸ Efficacia dei prodotti e servizi erogati
▸ Stile di vita e la cultura aziendale
foto - Mark Strobl

5. LE TRASFORMAZIONI PARTONO
SEMPRE CON BUONI PROPOSITI…

6. …E COSA ACCADE?

7. UNA MIA OSSERVAZIONE EMPIRICA
… IL CAMBIO ORGANIZZATIVO NON
PORTA AD EFFETTIVI BENEFICI DI
BUSINESS PERCHÉ GLI ASPETTI
TECNOLOGICI SONO CONSIDERATI
SECONDARI E I SISTEMI
INFORMATIVI PRE-ESISTENTI
RIMANGONO IL VERO COLLO DI
BOTTIGLIA.
foto - francesco scaramella

8. COSA HO VISTO ACCADERE
ESEMPI
▸ Sistema legacy monolitico
organizzazione: 3 team Scrum
problema: dipendenze tra i team che si organizzano a layer
▸ Sistema client-server con diverse UI, dal mobile al desktop
organizzazione: 4 team Scrum
problema: lentezza dei singoli canali che insistono sullo stesso layer di API

9. WATERFALL 2.0
IL RISULTATO È INEVITABILE
foto - zolakoma

10. ALCUNI TEAM
LAYER TEAMS
DATA
BACKEND
FRONT-END
Ogni team è cliente di un altro team FEATURE

11. ALCUNI TEAM
UI TEAMS
DATA
BACKEND
ANDROID IOS DESKTOP
Stesse feature replicate
FEATUREFEATUREFEATURE

12. ALCUNI TEAM
COMPONENT TEAMS
COMP
COMP
ANDROID IOS DESKTOP
Ulteriori dipendenze tra i team
COMP
COMP
FEATURE

13. SEMPLIFICHIAMO

14. FEATURE TEAMS!

15. foto - Nicholas Jones
end endto

16. DEFINIZIONE
UN FEATURE TEAM…
▸ è stabile e lavora in modo efficace rilasciando in produzione nuove caratteristiche di
prodotto nel tempo
▸ è interdisciplinare e attraversa tutti i componenti della piattaforma software
▸ condivide gli stessi spazi fisici o digitali
▸ lavora su una caratteristica del prodotto orientata all’utente finale dalla sua ideazione, al
design, sviluppo, test, contenuti e quello che serve per risolvere i problemi dell’utente
▸ è composto da persone “specializzate-generaliste”
▸ è piccolo

17. ALCUNI TEAM
FEATURE TEAMS
COMP
COMP
ANDROID IOS DESKTOP
I team attraversano tutta
l’architettura e condividono la
proprietà della codebase
COMP
COMP
FEATURES FEATURES

18. ALCUNI TEAM
FEATURE TEAMS
COMP
COMP
ANDROID IOS DESKTOP
I team attraversano tutta
l’architettura e condividono la
proprietà della codebase
COMP
COMP
FEATURE FEATURE

19. WOW E FUNZIONA!?
COMPLESSITÀ DEI FEATURE TEAMS
▸ difficile formare team con competenze che riescano ad attraversare tutta
l’architettura
▸ lavorare in contemporanea da parte di più team sugli stessi componenti non è
sempre semplice
▸ rilasciare in modo indipendente

20. NON BASTA ORGANIZZARSI
QUINDI…

21. MICROSERVICES

22. DEFINIZIONE
UN’ARCHITETTURA A MICROSERVICES …
▸ è un uno stile architetturale
▸ è un’applicazione composta da piccoli e indipendenti processi che
comunicano tra di loro utilizzando API indipendenti dal linguaggio
▸ ogni microservice è fortemente disaccoppiato dagli altri e svolge un compito
preciso

23. UNIX PIPE!
IL PRIMO MICROSERVICE

24. QUANTO È GRANDE UN
MICROSERVICE?
Da un pizza team a una persona

25. https://www.youtube.com/watch?v=BeNrVl2_nyI

26. https://labs.spotify.com/2016/02/25/spotifys-event-delivery-the-road-to-the-cloud-part-i/

27. PORTANO BENEFICI MA ANCHE QUALCHE PROBLEMA…
BENEFICI E PROBLEMI
▸ pro: contesti ben definiti
contro: i sistemi distribuiti sono più difficili da programmare
▸ pro: posso fare deploy in modo indipendente
contro: possibili inconsistenze
▸ pro: posso essere poliglotta
contro: è necessario un team di esperienza per orientarsi

28. MESSAGGI
ESEMPIO DI ARCHITETTURA A MICROSERVICE

29. PATTERN ARCHITETTURA
PRODUCER - CONSUMER
CONSUMERCHANNEL
MSG
PRODUCER

30. CONSUMERCHANNEL
MSG
PRODUCER
CONSUMER
CONSUMER
PRODUCER - BROADCAST TO CONSUMERS
PATTERN ARCHITETTURA

31. SUBSCRIBERCHANNEL
MSG
PUBLISHER
SUBSCRIBER
SUBSCRIBER
PUBLISH - SUBSCRIBE
PATTERN ARCHITETTURA

32. REST
GATEWAY
WEB
SOCKETS
GATEWAY
CHANNEL
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MSG
MSG
MSG
MOBILE
DESKTOP
WEB CLIENT
M2M
MICRO
SERVICE
MICRO
SERVICE
DATA
PERSISTENCE
DATA
PERSISTENCE
DATA
PERSISTENCE
ESEMPIO DI ARCHITETTURA A MICROSERVIZI

33. MICRO
SERVICE
MICRO
SERVICE
CHANNEL
request message
request message
subscribe message
response message
response message

34. SENECA
CODICE…
https://github.com/giulioroggero/microservice_node_demo
senecajs.org
microservice toolkit

35. Echo microservice
I will respond to messages with the
pattern {role: 'user', cmd: 'echo'}
I register my API to Gateway
{role:'microservice',cmd:'register', message:
{ clientPort: 3002, role: 'user', cmd: 'echo'}
You can call me on port 3002

36. {role:'microservice',cmd:'register', message: { clientPort: 3002, role: 'user', cmd: 'echo'}
{role:'microservice',cmd:'register', message: { type: “redis”, role: 'user', cmd: 'echo'}
redis

37. REST API gateway
microservice
Ascolto sulla 2999 per messaggi
Ascolto sulla 3000 per REST

38. DEPLOY AUTOMATICO
LA CONTINUOUS INTEGRATION E’ UN ANELLO FONDAMENTALE

39. MICROSERVIZI SONO PROCESSI SEPARATI E MONITORATI
CONTROLLO

40. ATTENZIONE
NON FA PER TUTTI, INFATTI SERVE
▸ Provisioning rapido delle risorse
▸ Monitoraggio dei servizi
▸ Veloce catena di deployment
▸ Cultura di DevOps pervasiva
▸ Coraggio di uscire dagli schemi
foto - leg0fenris

41. CONCLUDENDO

42. ESPERIENZA
CONSIGLI
▸ Attenzione ai valori Agili
▸ Comprendere bene le regole e i ruoli
▸ Partire da subito pensado alla cantina
tecnologica end-to-end
▸ Far emergere l’architettura
▸ Partire con pochi microservizi e poi dividerli o
aggregarli
▸ Test a livello di: unit, microservice, integration e
infine UI
agilereloaded.it

43. L’ORGANIZZAZIONE DELLE
AZIENDE AGILI RIFLETTE
L’ARCHITETTURA DEI LORO
SISTEMI INFORMATIVI
@giulioroggero
foto - Miroslav Petrasko