Affrontare in modo efficace la sfida dei microservizi

Lo stile architetturale a microservizi é da diversi anni oggetto di particolare attenzione in ambito di sviluppo software, a seguito dei vantaggi dimostrati dalla sua adozione da parte di compagnie quali Uber, Netflix e Amazon.
Strutturare una applicazione con i microservizi puó infatti fornire benefici ampiamente documentati, tra i quali un processo di sviluppo piú agile, maggior flessibilitá nell'adozione di nuove tecnologie e una naturale propensione alla scalabilitá.
Ciononostante, approcciare il design a microservizi puó dimostrarsi arduo per sviluppatori familiari con il piú classico stile monolitico, dal momento che le architetture distribuite richiedono non solo una efficace suddivisione delle funzionalitá tra i diversi servizi, ma implicano anche la presenza di aspetti e criticitá aggiuntive quali la comunicazione "inter-process" (IPC), la moltiplicazione dei point of failure potenziali e un processo di deployment piú complesso.
La risoluzione di questi problemi richiede la conoscenza di svariati pattern di design aggiuntivi che nascono come naturale conseguenza del pattern a microservizi; per questo motivo, iniziare a sviluppare microservizi puó diventare piú complesso del previsto.
In questo talk impiegheremo un esempio concreto per illustrare come abbiamo approcciato la prima architettura a microservizi da noi sviluppata, partendo dalle decisioni di design preliminari e coprendo l'intero ciclo evolutivo dell'architettura.
Il risultato é un sistema dal design altamente scalabile, che combina le best practices raccomandate dalle maggiori aziende che ad oggi impiegano i microservizi con strumenti allo stato dell'arte quali Eureka, Zuul, Spring Cloud e OpenShift.
Lo scopo del talk é trasmettere le lezioni che abbiamo appreso durante lo sviluppo e suggerire come affrontare in modo efficace la sfida dei microservizi a chi vi si affaccia per la prima volta.

Transcript

1. • Matteo Codogno(@teo1690): I am a software developer at WellD, with a particular focus on Java EE technologies. I love to experiment with new technologies, open source projects and design Software architectures. 1 ABOUT US • Simone D’Avico (@simonedavico): I recently attained a Master of Informatics at USI, Lugano, and joined the software development team at WellD shortly afterwards. I am particularly passionate about functional programming and software architecture.
2. DON’T PANIC ! THE BIRTH AND EVOLUTION OF A MICROSERVICES ARCHITECTURE MadLabs, June 2017
3. 3 THE NEED • Many branches worldwide • Needs centralised access to pipelined orders • Had a hard-to-scale legacy solution • Needed a full refactoring
4. 4 THE PRODUCT Source 1 Source N … Orders repository Distributed File System Search API
5. + Few features - Huge, distributed document repository (file system based) - Complex search criteria involving an algorithm to determine which paths to explore during the search + Granular scalability was a key concern + We had a container orchestrator available 5 IDEA: LEVERAGE MICROSERVICES
7. 7 CONTAINER ORCHESTRATION Container Orchestrator (OpenShift) V V Pod Volume Container
9. 9 HOW DO WE DESIGN A MICROSERVICES ARCHITECTURE ? Monolithic Application Service 1 Service 2 Service 3
10. 10 THE MONOLITH Users Groups Auth Orders Products Search Files SOAP API Settings UI Auth UserManager SecurityService OrderService SearchService SettingManger User Group Role Order OrderType Product File Faq News
11. 11 THE MONOLITH Users Groups Auth Orders Products Search Files SOAP API Settings UI Auth UserManager SecurityService OrderService SearchService SettingManger User Group Role Order OrderType Product File Faq News Authentication Orders Search Settings UI
12. • User authentication • User authorisation • CRUD user, group and role 12 AUTH MICROSERVICE Auth config migrations
13. 13 IMPORT MICROSERVICE • Import orders data from external sources Auth Import
14. 14 IMPORT MICROSERVICE Import
15. 15 ORDERS MICROSERVICE • Builds orders hierarchy from flat structure • Provide an API to access orders details: 1. GET /orders/search/{term} 2. POST /orders/search Auth Orders Import
16. 16 SEARCH MICROSERVICE • Complex search into file system to extract order files • Search is customised on a per-role basis • Download files Auth Orders Search Import
17. 17 AUTHENTICATION IN A DISTRIBUTED CONTEXT How can microservices authenticate external requests? :( Replicate Auth service logic into every microservice :) Leverage the auth service to handle the authentication for other microservices OAuth2 (Token-based) Auth Import Orders Search
18. 18 CURRENT STATE OF THE SYSTEM OAuth2 Auth Orders Search Import
19. HOW DO MICROSERVICES TALK TO EACH OTHER? INTER SERVICE COMMUNICATION
20. 20 HOW CAN MICROSERVICES FIND EACH OTHER? Auth Orders Search
21. IF YOU DON'T KNOW WHERE YOU GO, THEN IT DOESN'T MATTER WHICH PATH YOU TAKE. Cheshire Cat 21 WHERE ARE YOU?
22. 22 DISCOVERY MICROSERVICE Orders Auth Search
23. 23 EUREKA !! Orders Auth Search Discovery
24. 24 UI MICROSERVICE Auth Orders Search UI Discovery Import
26. 26 GATEWAY MICROSERVICE (ZUUL) • Single entry point • Routing • Solves CORS • Reverse proxying • Downstream authentication • Request filtering Auth Orders Search UI Discovery Service Gateway Import Settings
27. 27 OAUTH2 WITH ZUUL SERVICE GATEWAY AUTH
 (OAUTH2) ORDERS GET /orders 302: location=/uaa/oauth/token GET /uaa/oauth/token login/authorization page POST /login {token} JSESSIONID GET /orders 200: { orders: [{…}, {…}, {…}] }
28. 28 SCALING MICROSERVICES CONFIGURATION DEV
29. 29 SCALING MICROSERVICES CONFIGURATION DEV TEST
30. 30 SCALING MICROSERVICES CONFIGURATION DEV QA TEST
31. 31 SCALING MICROSERVICES CONFIGURATION DEV QA TEST PROD
32. 32 SCALING MICROSERVICES CONFIGURATION DEV QA TEST PROD 4 ENVIRONMENTS X N MICROSERVICES = CONFIGURATION MADNESS!
33. 33 CONFIG MICROSERVICES Auth Orders Search UI Discovery Config Gateway Import
34. 34 MICROSERVICES ARCHITECTURE WORKS!
35. 35 DECOUPLING COMMUNICATION Schindler wants to track users’ interactions with the system • Login/logout • Searches • Downloads • …
36. 36 DECOUPLING COMMUNICATION - ATTEMPT 1 Auth Orders Search Settings “user logged in” “order xyz searched” “system put into maintenance”
37. 37 DECOUPLING COMMUNICATION - ATTEMPT 2 Auth Orders Search Settings “user logged in” “order xyz searched” “system put into maintenance” Tracking
38. 38 ALMOST OK…
39. 39 DECOUPLING COMMUNICATION - ATTEMPT 2 Auth Orders Search Settings Tracking Interceptor (on Service Gateway) /login /search /maintenance publish 
 {event} Tracking subscribe to 
 “userActivity” topic
40. 40 MICROSERVICES ARCHITECTURE WORKS!
41. + Modularity + Flexibility + Scalability + Decoupling - Additional overhead: services > features! - Scalability - Decoupling 41 TAKEAWAY MESSAGES
42. 42 IMPORT MICROSERVICE Import
43. 43 IMPORT MICROSERVICE Import
44. The failure of one service can potentially cascade to other services throughout the application. 44 CASCADING FAILURE Consumer Consumer Service A Service B Service C Service D
45. The failure of one service can potentially cascade to other services throughout the application. 45 CASCADING FAILURE Consumer Consumer Service A Service B Service C Service D
46. The failure of one service can potentially cascade to other services throughout the application. 46 CASCADING FAILURE Consumer Consumer Service A Service B Service C Service D
47. The failure of one service can potentially cascade to other services throughout the application. 47 CIRCUIT BREAKING A B A B A B Timeout, Repeated Failure Available Loaded/Unavailable Circuit Breaking Request Response Request Fallback
48. Load balancing improves the distribution of workloads across multiple computing resources. 48 LOAD BALANCING A A Balancer B1 B2 BN B1 B2 BN Dedicated Balancer Client-Side Balancer Discovery
49. microservices.io
50. …SO LONG, AND THANKS FOR ALL THE FISH !!