Consistente? De-normalizzazione, consistenza eventuale e assenza di transazioni, perché sono un vantaggio e non un problema.

Presentazione sul tema: "Consistente? De-normalizzazione, consistenza eventuale e assenza di transazioni, perché sono un vantaggio e non un problema."— Transcript della presentazione:

1 Consistente? De-normalizzazione, consistenza eventuale e assenza di transazioni, perché sono un vantaggio e non un problema.

2 Mauro Servienti CTO @ Managed Designs mauro.servienti@manageddesigns.it @mauroservienti //milestone.topics.it //blogs.ugidotnet.org/topics RavenDB trainer NServiceBus trainer/support Microsoft MVP – Visual C#

3 DEFINIZIONI Cominciamo con il metterci d’accordo sull’argomento

4 Consistenza è il grado di accordo tra le parti che guardano uno stesso sistema in un dato momento T più le parti concordano su quello che vedono più il sistema è consistente

5 Accoppiamento è il grado di interdipendenza tra le parti più il cambiamento di una parte impatta sulle altri più il sistema è accoppiato

6 Accoppiamento temporale è una forma specifica di accoppiamento più la non disponibilità di una parte impatta sulle altre più il sistema è accoppiato

7 ABBIAMO UN PROBLEMA?

8 Contesto e requisiti È fondamentale identificare il contesto; senza contesto i problemi sono aria fritta; I requisiti determinano i confini del problema ma ancora di più della soluzione; Una soluzione è valida quando è validata dai requisiti altrimenti è inutile sovra- ingegnerizzazione;

9 Un esempio teorico Single Picker per Batch Multiple Picker per Batch

10 IL REQUISITO

11 e-commerce Abbiamo un “piccolo” portale di e-commerce che sta rapidamente crescendo e vogliamo: – Migliorare i tempi di risposta del portale; – Dare in out-sourcing la gestione delle spedizioni; – Espandere il nostro business ad altri paesi extra europei;

12 TEMPI DI RISPOSTA Diamo per scontato che abbiamo identificato il problema e non è il nostro codice

13 Sharding e Replica Se il database va piano la prima cosa da guardare è l’hardware, fine, spesso un buon SSD risolve tutti i problemi con un impatto nullo sull’architettura; Se un SSD non basta Sharding e Replica sono l’unica vera soluzione, soluzione drastica e dolorosa;

14 E le transazioni? Non è più pensabile a questo punto fare in una singola passata (aka Commit): – Modifica del carrello; – Checkout; – Creazione dell’ordine; – Creazione della spedizione “Banalmente” potrebbero essere su database diversi;

15 OUT-SOURCING DELLE SPEDIZIONI

16 Accoppiamento Store Front End Shipping Service

17 Accoppiamento #2 L’accoppiamento con un servizio è molto pericoloso, a prescindere: – Leghiamo due componenti che nonostante siano sotto il nostro controllo non possiamo garantire essere disponibili nello stesso momento; L’accoppiamento con un servizio esterno, non sotto il nostro controllo è un suicidio: – Non abbiamo neanche lontanamente la possibilità di garantire nulla;

18 ESPANSIONE DEL BUSINESS

19 …e le time-zone? Ci espandiamo dall’Europa verso agli Stati Uniti e il nostro concetto di alta disponibilità cambia drasticamente: – Passiamo da 3 fusi orari a 12 – La finestra temporale in cui possiamo essere offline è ridotta all’osso È un problema sia di affidabilità ma anche di deploy

20 Accoppiamento temporale La distruzione geografica di un monolite è impossibile, comporta l’impossibilità di evolvere il monolite; – Oltre a tutti i problemi di cui già abbiamo parlato; L’alta disponibilità su un range orario ampio è possibile solo se non abbiamo dipendenza “temporale” tra le parti; – Naturalmente non va d’accordo con un’architettura tradizionale;

21 IL MODELLO MENTALE DELL’UTENTE

22 Mettiamoci in testa che… noi, dev, non siamo la soluzione di un bel nulla, siamo lo strumento per raggiungere la soluzione -- Non siamo pagati per inventare iperboliche soluzioni ma per risolvere problemi

23 Una strana realtà… Arriva un ordine; l’azienda si blocca perché stiamo processando l’ordine finché non abbiamo capito se le giacenze a magazzino sono in grado di soddisfare il nuovo ordine; La produzione nel frattempo è sospesa perché deve capire come pianificare il nuovo ordine che però in coda per le giacenze che sono bloccate da un pick della produzione che è ferma…

24 DEADLOCK

25 La realtà… L’ovvia e unica conseguenza di scalare un monolite lasciandolo un monolite è il collasso del sistema; La realtà: – Non sa cosa sono le transazioni; – Ha un bassissimo, se non nullo, accoppiamento tra le parti; – Non ha accoppiamento temporale;

26 Non è proprio così vero… All’interno di un’azienda è pensabile che: – Ci sia accoppiamento in un reparto/OU; – Ci sia accoppiamento temporale tra alcune parti Produzione e magazzino materie prime – C siano all’interno di un reparto alcune operazioni che devo essere coordinate da un supervisore (DTC)

27 ALL’INTERNO DI UN REPARTO…

28 BOUNDED CONTEXT

29 Bounded Context e Ubiquitous Language Due dei concetti più snobbati da chi pratica DDD; L’unico vero modo per trasformare il monolite in tante piccole parti che parlano tra di loro con: – Basso accoppiamento (nullo è impossibile); – Nessun accoppiamento temporale; – In maniera eventualmente consistente

30 EVENTUALMENTE CONSISTENTE

31 Torniamo alla nostra azienda… Chiediamo ad un manager lo stato di avanzamento di una commessa – dove la produzione è conto terzi in Malesia La risposta: – A ieri alle 5 la situazione era…bla bla…non so ancora nulla di XYX perché arriva dagli Stati Uniti e iniziano a lavorare far 6 ore, ti aggiorno stasera;

32 Il grado di accordo tra le parti Diventa molto basso; Ogni comunicazione deve portare con se la versione (a ieri alle 6) consentendoci di discernere e mettere in ordine eventuali comunicazioni multiple; Le parti sono però libere di “muoversi” come vogliono: – Evolvere perché l’accoppiamento è basso; – esserci/non esserci perché l’accoppiamento temporale non esiste;

33 E LE TRANSAZIONI?

34 Ci servono ancora? All’interno del nostro orticello (BC) perché no? In base alla tecnologia di persistenza potremmo essere obbligati ad usarle; Cross-BC assolutamente no; Se modelliamo la realtà non ci interessa più essere consistenti (fully) ma ci basta essere certi che prima o poi lo saremo;

35 La posta e il postino Una mail è consistente? No; Il nostro rapporto con il server di posta è consistente? Si; Il rapporto tra i singoli server SMTP è consistente? Si; Il rapporto tra l’ultimo server e la mailbox del destinatario è consistente? Si;

36 L’intero sistema è consistente? No Ci da però delle garanzie: – Ogni singolo passaggio è consistente; – Se un passaggio fallisce avremo, con la stessa logica, indietro un’informazione che la nostra richiesta è fallita; Abbiamo bisogno delle transazioni distribuite? No;

37 EVENTUALMENTE CONSISTENTE -- DEMO