A short Summary of Resilience Patterns & DevOps Collaboration, rich of resources and references (in Italian, speech for Crafted Software 7th Edition - https://www.meetup.com/Crafted-Software/events/255035472/)

1. RESISTERE AGLI URTI
Patterns di Resilienza in un mondo non-stabile!
STEFANO FAGO - Crafted Software: 7th Edition

2. RESISTERE AGLI URTI
Patterns di Resilienza in un mondo non-stabile!
STEFANO FAGO - Crafted Software: 7th Edition

3. Resilienza?
Il concetto di Resilienza ha molteplici definizioni
La definizione che useremo è:
… La Capacità di qualsiasi Sistema di
riprendersi da Problemi/Difficoltà ...

4. Cos'è un Sistema Resiliente?
<< ...è un Sistema che all'esterno sembra complesso ma che è
caratterizzato da una struttura modulare più semplice fatta di
componenti che, alla necessità, possono staccarsi e riconfigurarsi:
questo impedisce che i problemi di una parte si ripercuotano a
cascata sulle altre... >>
[A. Zolli - http://resiliencethebook.com/]
Un Sistema Resiliente è caratterizzato da:
– dinamicità
– modularità
– diversità
– disaccoppiamento
– contro-meccanismi integrati

5. Perché un Sistema Resiliente?
● Perché dire che è 24/7 ed affidabile 99.99999... è FIGO!?!
● Perché voglio essere un ingegnere... DA PAURA!?!
● Perché non voglio far perdere soldi al mio Business!
<< ...Many systems are built to pass QA testing rather than to survive
the world after launch... >>
[Michael Nygard - https://pragprog.com/book/mnee2/release-it-second-edition]

6. Miti sui Sistemi Distribuiti
● La Rete è affidabile
● La Latenza è nulla
● La Banda di Rete è infinità
● La Rete è sicura
● La Topologia non cambia
● C'è un solo amministratore
● Il costo del Trasporto è nullo
● La Rete è omogenea
[https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing]
[https://www.rgoarchitects.com/Files/fallacies.pdf]

7. Le Leggi di Murphy della Resilienza
● Se c'è qualcosa che si può rompere nel Sistema, si romperà!
● Se c'è qualcosa che può rompere il Sistema, c'è almeno un Cliente
che la troverà!
● Sotto pressione... le cose peggiorano!
● Le dimensioni contano ma... Tu le sbaglierai comunque!
<< ...tre tipi di fallimenti maggiormente osservati sono dovuti a: 1) cambio del
traffico in ingresso, includendo sovraccarichi e andamenti inattesi 2)
esaurimento di risorse quali CPU, Memoria, IO Loop, Risorse di Rete 3)
fallimenti sulle dipendenze, includendo infrastrutture, archivi, servizi
correlati … >> [UBER Engineering]

8. Resilienza nei Sistemi Distribuiti :
Cosa implica?
● Trappola del 100%: non SE si romperà ma... QUANDO si romperà!
<< ...the normal state of operation is partial failure... >> [Adrian Hornsby]
● Non è una qualità perfetta!
<< ...it is impossible for a system to have all three properties of consistency,
resilience and partition-tolerance... >> [Architectural Design for
Resilience - Dong Liu, Ralph Deters, and W.J. Zhang (2010)]
● Implica complessità, non la riduce!
● Vuole studio, misura, comprensione degli obiettivi di business!

9. Resilienza nei Sistemi Distribuiti :
Elementi Base
● Isolamento
● Basso Accoppiamento
● Modalità di Comunicazione
● Mitigare i Fallimenti
Decomporre in Parti, Autonomia delle Parti, Evitare la propagazione dei
Fallimenti
Complementare all'Isolamento, contribuisce alla non propagazione dei
Fallimenti, le Parti sono ignoranti delle altre
Condiziona come si modella il dominio ed i meccanismi di recupero, può essere
eterogenea
Anticipare i fallimenti inevitabili e adottare meccanismi di recupero sia di
sistema che applicativi

10. Resilienza nei Sistemi Distribuiti :
Elementi Base
...già sentito? Vediamo alcuni numeri ed accendiamo
l'intuizione...
FAILURE & CHANGE [Mark Hibberd - https://www.youtube.com/watch?v=_VftQXWDkfk]

11. Patterns di Resilienza (di Uwe Friedrichsen)

13. Pattern di Resilienza: Bulkhead
Isolate! Don't Propagate!
● Ridondanza di Sistemi e Risorse: Lì dove possibile, moltiplicare una risorsa
critica perché sia prontamente sostituibile
● Categorized Resource Allocation: Classificare le Risorse e scomporle in pool di
riferimento misurabili e manipolabili
Warning: Questi elementi possono variare nel tempo ed alcuni sono condizionati
da più di un fattore

14. Pattern di Resilienza: Queueing
Take Your Time!
● Deferrable Work : posticipare un'attività non urgente
● Bounded Queue/ Load-Levelling Queue: zone di ammortamento di richieste
operative o zone di politiche di troppo-pieno
● BackPressure/Throttling: politiche di gestione di sovraccarico su code per
evitarne la crescita indefinita
WARNING: Le eventuali asincronie rendono complesso il coordinamento ed è
necessario raffinare l'approccio sulle misurazioni derivanti dalla realtà

15. Pattern di Resilienza: Timeout
Stop to Wait: Fail Fast & Don't Propagate!
● Rendere deterministica la durata di un'attività
● Ci si pone un obiettivo, si misura, si raffina in base alla realtà
WARNING: La scadenza è specifica di una risorsa e non impatta le altre; come
gestire gli errori di timeout?

16. Pattern di Resilienza: Retry
If you fail once, try again!
Alcuni fallimenti sono temporanei o recuperabili...
...Riprovare richiede di determinare: il numero di ritentativi, la
presenza di un degrado temporale tra i ritentativi (backoff)
https://aws.amazon.com/it/blogs/architecture/exponential-backoff-and-jitter/
WARNING: Presuppone lo studiare l'Idempotenza delle attività coinvolte

17. Pattern di Resilienza: Fallback/Fail Silent
Don't Fail... Degrade gracefully!
Non fallire con azioni distruttive ma con azioni di approssimazione o
alternative
● Default Value/Derived Value
● Alternative Actions/Invocations
● Caching
WARNING: E' necessario recepire le condizioni di Business a contorno!

18. Pattern di Resilienza: Limiter
No Stress, Know Your Limit!
● Rate-Limiter
● Concurrency-Limiter
● Adaptive Resource Sizing
● BackPressure/Throttling
WARNING: Queste politiche non devono comunque sostituire uno sforzo nel
comprendere il Resource-Sizing, usare algoritmi opportuni e il raffinare sulla realtà
di dati a riguardo.

19. Pattern di Resilienza: Circuit Breaker
Don't do it if it hurts!
Interrompere una situazione patologica con un fallimento controllato e
immediato. Lo stato di fallimento viene revocato secondo indici o
condizioni temporali.
WARNING: La definizione dei parametri sia di attivazione del fallimento che
quelli di ripresa funzionale possono essere un'attività non semplice ed è necessario
studiare le conseguenze sul percorso critico di esecuzione dei servizi

20. Pattern di Resilienza: Decoupling By Events
Describe in terms of the things that happen (Event), not the things that
do the work (Command)
Isolare/Disaccoppiare componenti, Modellare per Domini, accettare i
Fallimenti con notifiche che permettano la rinascita della/e delle componenti /
sotto sistemi
● Event-Sourcing / CQRS / Message-Passing
● SAGA ( in alternativa alle transazioni)
WARNING: Le eventuali asincronie, la modellazione dei domini rendono
complesso il sistema. Può stimolare l'abuso di code e reti di listener. Tradeoff tra
Transazionalità e Attività Compensative.

21. Pattern di Resilienza: Chaos Engineering
<< ...Chaos Engineering è il processo di test di un sistema distribuito per
garantire che il sistema stesso possa sopportare interruzioni impreviste nelle
attività... >> [https://www.oreilly.com/ideas/chaos-engineering]
● Attuare Testing in Produzione, con dati e volumi realistici!
● Avere l'infrastruttura per continui esperimenti di...Chaos!
● Imparare da ogni fallimento/Inventare sempre nuovi fallimenti!
WARNING: Startup complesso, Skill specifici, munirsi di prodotti e <<...don't use
the term Chaos Engineering, use Continuous limited scope disaster recovery
instead. You might actually get a budget that way...>> [Russ Miles]

22. Da Resiliente a Riparabile
Obiettivi di Maturità Architetturale [Bilgin Ibryam]

23. Da Resiliente a Riparabile
La prima tentazione è quella di adottare questi pattern solo come soluzione
applicativa.
E' proprio in questo ambito che pratiche e strumenti DevOps diventano parte
integrante di una visione più ampia
– container e orchestrazione di container
– ciclo di vita degli artefatti
– distribuzione di certificati, configurazioni ed artefatti
– monitoring & metriche
WARNING: adottare DevOps implica complessità, skills, organizzazione e <<
...application safety and correctness, in a distributed system is still the
responsibility, of the application... >> [Christian Posta]

24. Da Resiliente a Riparabile
L'automazione infrastrutturale, presuppone che un servizio deve essere:
– Idempotente per riavvii (un servizio può essere spento e avviato più
volte).
– Idempotente per il ridimensionamento verticale/orizzontale (un
servizio può essere scalato automaticamente su più istanze).
– Idempotente come Produttore (altri servizi possono riprovare a
chiamare).
– Idempotente come Consumatore (il servizio o l'ecosistema può
riprovare a effettuare chiamate in uscita).
In presenza di queste caratteristiche una piattaforma di servizi diventa
riparabile in modo autonomo.
[https://www.infoq.com/articles/microservices-post-kubernetes - Bilgin
Ibryam]

25. Resilienza e Performance Anti-Patterns
Siete in dubbio? Il sistema si complica? Raffrontate il disegno del Sistema, dei
servizi o dei pattern di resilienza adottati, rispetto ai seguenti anti-pattern!
● N+1 Calls (...ad Esempio i loop non sono amici dei sistemi distribuiti)
● N+1 Query (...come esempio precedente ma per i DB)
● Payload flood (...ma è proprio giusto avere messaggi da un mega ripetuti per
ogni servizio?)
● Granularity (...forse hai spezzato troppo il tuo sistema?)
● Tigh-Coupling (...un classico!)
● Inefficient Service Flow (...il giringiro!)
● Dependencies (...conosci le dipendenze del tuo Sistema?)

26. La Realtà cambierà ancora ma...
...non sprecate soldi! Siate Resilienti e
Riparabili!
Grazie a Tutti!!!