Favorire i feature teams con architetture microservices
3 likes1,763 views
Il documento discute l'importanza dei 'feature teams' all'interno delle architetture a microservizi, evidenziando come questi team autonomi possano migliorare la velocità e l'efficacia nella delivery del software. Viene evidenziato che una corretta organizzazione dei team può prevenire problemi derivanti da dipendenze e migliorare la gestione delle complessità. Tuttavia, l'implementazione dei microservizi richiede competenze specifiche e una cultura aziendale che favorisca la collaborazione e il monitoraggio continuo.
Favorire i feature teams con architetture microservices
- 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…
- 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
- 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
- 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
- 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
- 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