Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Favorire i feature teams con architetture microservices

1,000 views

Published on

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.

Published in: Business
  • Be the first to comment

Favorire i feature teams con architetture microservices

  1. 1. MICROSERVICES FAVORIRE I "FEATURE TEAMS" CON ARCHITETTURE @giulioroggero agilereloaded.it
  2. 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. 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. 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. 5. LE TRASFORMAZIONI PARTONO SEMPRE CON BUONI PROPOSITI…
  6. 6. …E COSA ACCADE?
  7. 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. 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. 9. WATERFALL 2.0 IL RISULTATO È INEVITABILE foto - zolakoma
  10. 10. ALCUNI TEAM LAYER TEAMS DATA BACKEND FRONT-END Ogni team è cliente di un altro team FEATURE
  11. 11. ALCUNI TEAM UI TEAMS DATA BACKEND ANDROID IOS DESKTOP Stesse feature replicate FEATUREFEATUREFEATURE
  12. 12. ALCUNI TEAM COMPONENT TEAMS COMP COMP ANDROID IOS DESKTOP Ulteriori dipendenze tra i team COMP COMP FEATURE
  13. 13. SEMPLIFICHIAMO
  14. 14. FEATURE TEAMS!
  15. 15. foto - Nicholas Jones end endto
  16. 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. 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. 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. 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. 20. NON BASTA ORGANIZZARSI QUINDI…
  21. 21. MICROSERVICES
  22. 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. 23. UNIX PIPE! IL PRIMO MICROSERVICE
  24. 24. QUANTO È GRANDE UN MICROSERVICE? Da un pizza team a una persona
  25. 25. https://www.youtube.com/watch?v=BeNrVl2_nyI
  26. 26. https://labs.spotify.com/2016/02/25/spotifys-event-delivery-the-road-to-the-cloud-part-i/
  27. 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. 28. MESSAGGI ESEMPIO DI ARCHITETTURA A MICROSERVICE
  29. 29. PATTERN ARCHITETTURA PRODUCER - CONSUMER CONSUMERCHANNEL MSG PRODUCER
  30. 30. CONSUMERCHANNEL MSG PRODUCER CONSUMER CONSUMER PRODUCER - BROADCAST TO CONSUMERS PATTERN ARCHITETTURA
  31. 31. SUBSCRIBERCHANNEL MSG PUBLISHER SUBSCRIBER SUBSCRIBER PUBLISH - SUBSCRIBE PATTERN ARCHITETTURA
  32. 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. 33. MICRO SERVICE MICRO SERVICE CHANNEL request message request message subscribe message response message response message
  34. 34. SENECA CODICE… https://github.com/giulioroggero/microservice_node_demo senecajs.org
 microservice toolkit
  35. 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. 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. 37. REST API gateway
 microservice 
 Ascolto sulla 2999 per messaggi Ascolto sulla 3000 per REST
  38. 38. DEPLOY AUTOMATICO LA CONTINUOUS INTEGRATION E’ UN ANELLO FONDAMENTALE
  39. 39. MICROSERVIZI SONO PROCESSI SEPARATI E MONITORATI CONTROLLO
  40. 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. 41. CONCLUDENDO
  42. 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. 43. L’ORGANIZZAZIONE DELLE AZIENDE AGILI RIFLETTE L’ARCHITETTURA DEI LORO SISTEMI INFORMATIVI @giulioroggero foto - Miroslav Petrasko

×