Perché dovremmo voler progettare un sistema autonomo, isolato, e a eventi? Quale dovrebbe essere il driver principale delle nostre scelte architetturali? Secondo noi la risposta è tutt'altro che ovvia: il driver principale dovrebbe essere l'utente e la qualità che l'utente è in grado di percepire utilizzando il nostro software. Parleremo di user experience, di design for failure, di sistemi self healing, di resilienza, e di come queste caratteristiche siano supportate da un’architettura a Microservizi. By Matteo Varotto e Federico Carrer

1. CLOUD
CONFERENCE
ITALIA
2019

2. SPONSOR

3. MICROSERVIZI: IDEE PER UN’ARCHITETTURA CON AL CENTRO
L’UTENTE
Federico Carrer
Matteo Varotto

4. WHO WE ARE?
Matteo Varotto
QA Architect
Quid Informatica
Federico Carrer
carrerfe@gmail.com
MatteoVarotto
matteo.varotto@gmail.com
Federico Carrer
Cloud Architect
Quid Informatica

5. GOOD OLD DAYS...
▪ Semplice da comprendere
▪ Semplice da implementare
▪ Semplice da testare

6. ...QUALCHE ANNO DOPO...

7. OGGI
 Semplice da comprendere
 Semplice da implementare
 Semplice da testare
 Scalabilità limitata
 Difficile da evolvere
 Aggiornamenti rischiosi

8. FEATURE, FEATURE, FEATURE

9. QUAL È LA
RISPOSTA?

10. MICROSERVIZI
▪ Scomposizione in servizi autonomi e
indipendentemente:
▪ scalabili
▪ rilasciabili
▪ evolvibili
▪ testabili
▪ Team indipendenti che lavorano su
moduli indipendenti
▪ Problema scomposto in parti più
facilmente gestibili
▪ Scalabilità a livello di funzionalità
▪ Stack tecnologico selezionabile per
esigenze singolo componente

11. QUINDI TUTTO RISOLTO?

12. MONOLITH: ONLINE STORE

13. MICROSERVICES: ONLINE STORE

14. WITH GREAT POWER COMES GREAT RESPONSIBILITY
 Consistenza dei dati
 Partial Failure
 Distributed Transaction

15. WITH GREAT POWER COMES GREAT RESPONSIBILITY
 Consistenza dei dati
 Partial Failure
 Distributed Transaction
 Comunicazione asincrona
 Race conditions

16. WITH GREAT POWER COMES GREAT RESPONSIBILITY
 Consistenza dei dati
 Partial Failure
 Distributed Transaction
 Comunicazione asincrona
 Race conditions
 Performance
 Network latency

17. TORNIAMO DAL NOSTRO UTENTE
▪ 503 Service Unavailable
▪ Please wait
▪ Timeout
▪ Session expired

18. TORNIAMO DAL NOSTRO UTENTE
Cosa percepisce l'utente?
▪ Fragilità del sistema
▪ Lentezza
▪ Scarsa affidabilità

19. COSA POSSIAMO FARE?
▪ Limitare le conseguenze
▪ monitoraggio attivo
▪ interventi automatici (restarts, mail a backoffice, ecc.)
▪ circuit breaker
▪ bulkheading

20. COSA POSSIAMO FARE?
▪ Limitare le conseguenze
▪ monitoraggio attivo
▪ interventi automatici (restarts, mail a backoffice, ecc.)
▪ circuit breaker
▪ bulkheading
▪ Ridurre l'impatto su UX
▪ caching
▪ architettura ad eventi
▪ layer di resilienza

21. COSA POSSIAMO FARE?
▪ Limitare le conseguenze
▪ monitoraggio attivo
▪ interventi automatici (restarts, mail a backoffice, ecc.)
▪ circuit breaker
▪ bulkheading
▪ Ridurre l'impatto su UX
▪ caching
▪ architettura ad eventi
▪ layer di resilienza
▪ Intervenire sui processi
▪ CAP Theorem

22. COSA POSSIAMO FARE?
▪ Limitare le conseguenze
▪ monitoraggio attivo
▪ interventi automatici (restarts, mail a backoffice, ecc.)
▪ circuit breaker
▪ bulkheading
▪ Ridurre l'impatto su UX
▪ caching
▪ architettura ad eventi
▪ layer di resilienza
▪ Intervenire sui processi
▪ CAP Theorem
Design (for failure)

23. ESPERIENZA UTENTE E RESILIENZA
 All’utente interessa un “sistema che funziona”
 Disponibile
 ad esempio al 99,9%
 Affidabile
 capace di riprendersi dopo un’anomalia
 Resiliente
 capace di funzionare in modo accettabile anche in presenza di qualche malfunzionamento
 L’utente ci giudica anche in base a come risolviamo i problemi
 Service Recovery Paradox

24. ESPERIENZA UTENTE E RESILIENZA
Pattern di comunicazione REST ?

25. ESPERIENZA UTENTE E RESILIENZA
Pattern di comunicazione REST ?

26. ESPERIENZA UTENTE E RESILIENZA
Retry ?

27. ESPERIENZA UTENTE E RESILIENZA
Pattern di comunicazione Event-Driven

28. ESPERIENZA UTENTE E RESILIENZA
Pattern di comunicazione Event-Driven

29. ESPERIENZA UTENTE E RESILIENZA
Pattern di comunicazione Event-Driven

30. ESPERIENZA UTENTE E RESILIENZA
Pattern di comunicazione Event-Driven

31. ESPERIENZA UTENTE E RESILIENZA
Pattern di comunicazione Event-Driven

32. ESPERIENZA UTENTE E RESILIENZA
Pattern di comunicazione Event-Driven

35. MONITORAGGIO

36. MONITORAGGIO

37. MONITORAGGIO

38. MONITORAGGIO

39. TIMEOUT

40. CIRCUIT BREAKER

42. CONSISTENZA
Sistemi monolitici
 ACID
 L’asse del tempo è una retta unica
Sistemi distribuiti
 Difficile garantire consistenza dei dati
 Ogni componente ha la sua visione del
tempo

43. THE GUARANTEE THAT ANY
TRANSACTIONS STARTED IN
THE FUTURE NECESSARILY SEE
THE EFFECTS OF OTHER
TRANSACTIONS COMMITTED
IN THE PAST
CONSISTENZA?

44. COORDINAMENTO - TWO PHASE COMMIT

45. COORDINAMENTO - TWO PHASE COMMIT

46. COORDINAMENTO - TWO PHASE COMMIT

47. COORDINAMENTO - TWO PHASE COMMIT

48. ...QUINDI
PROBLEMA
RISOLTO?

49. 2PC
 Scambio di molti messaggi
 Network latency
 Throughput limitato
 Coordinator rappresenta un Single point of failure
 Protocollo bloccante
 Se uno dei partecipanti fallisce abbiamo deadlock, non possiamo procedere con altre transazioni

50. COME POSSIAMO FARE?
Il mondo nel quale viviamo è inconsistente

51. COMPENSAZIONE
In genere nel mondo reale quando qualcosa non funziona:
 Ci riprovo
 Provo ad annullare gli effetti di quello che ho fatto

52. COMPENSAZIONE - SAGA
Consiste nel riscrivere la nostra transazione “lunga” come una sequenza di transazioni
In Saga o tutte le transazioni sono completate con successo oppure vengono eseguite le transazioni di
compensazione

53. SAGA

54. SAGA

55. SAGA

56. SAGA RINUNCIA A
ISOLAMENTO PER OTTENERE
UNA MIGLIORE AVAILABILITY

57. RINUNCIARE
ALL’ISOLAMENTO???? NON
SAREBBE MEGLIO AVERE UN
SISTEMA CHE GARANTISCA SIA
ISOLAMENTO CHE
CONSISTENZA?

58. COSA VUOLE IL NOSTRO UTENTE?
 un sistema perfettamente transazionale?
 che vengano garantite le regole di business dell’applicazione e le invarianti applicative?

59. CAP THEOREM
Un qualunque sistema distribuito può garantire
solo 2 su 3 tra
 Consistency
 Availability
 Partition Tolerance

60. CAP THEOREM – PARTIAL KNOWLEDGE
In questo momento abbiamo partitioning
 I messaggi di Catalog non vengono recapitati
Cosa possiamo fare?
 Consistency over Availability
 Availability over Consistency

61. CAP THEOREM – CONSISTENCY OVER AVAILABILITY
Potremmo decidere di progettare il sistema per
garantire la consistenza
In questo caso possiamo scusarci e chiedere
all’utente di riprovare più tardi
Abbiamo rinunciato alla AVAILABILITY

62. CAP THEOREM – AVAILABILITY OVER CONSISTENCY
Abbiamo rinunciato alla Consistency
In questo caso completo l’ordine anche se non
conosco le scorte di magazzino
Si tratta di gestire il rischio

63. CAP THEOREM – GESTIONE DEL RISCHIO
Blocco la possibilità di fare ordini
 Rischio di bloccare le vendite
Non blocco gli ordini
 Aspetto di ricevere nuove scorte del prodotto
prima di spedire
 Il prodotto è andato fuori commercio e non
riesco a reperirlo? Chiedo scusa

64. DESIGN FOR FAILURE
Partial knowledge spesso ci porta a dover fare
scelte basate su conoscenza locale
Un sistema distribuito spesso è portato a fare
congetture invece che prendere decisioni
…congetture che potrebbero essere corrette
come no
Quindi?

65. GRAZIE!