C’era una volta la velleità di avere il mega-sistemone che facesse tutto, velleità rapidamente abbandonata al crescere del monolite per ovvi motivi. Nel tentativo di realizzare il monolite ci si scontra molto rapidamente con il fatto che tipicamente i requisiti di business cambiano più rapidamente del tempo necessario per la realizzazione, ci si scontra con il fatto che non è possibile pensare di fare il deploy del monolite bloccando ogni volta tutta l’infrastruttura, ci si scontra con il dettaglio che non è possibile far evolvere indipendentemente le varie parti del monolite.

Tutto questo, e molto altro, ci fa dire che tentare di realizzare un monolite non ha senso, o meglio non è economicamente sensato, perché è plausibile ipotizzare che dato un quantitativo di risorse sensate sia possibile abbattere in misura sensibile i problemi di cui sopra rendendolo possibile, ma non necessariamente sensato.

Detto questo diventa evidente che dobbiamo convivere con sistemi eterogenei, con un ciclo di vita, e di rilascio, indipendente gli uni dagli altri; sistemi che hanno ognuno le proprie logiche e i propri formati di persistenza, e tante belle (o brutte) cose che li rendono molto isolati e distanti tra loro.

Risulta altresì vero che i requisiti di business sempre più spesso ci spingono verso la necessità di far parlare tra loro questi sistemi, in una parola si rende necessario parlare di integrazione.

Ma quando abbiamo a che fare con sistemi che non sono, almeno nel ciclo di vita, sotto il nostro controllo diventa necessario introdurre qualcosa che protegga il nostro sistema da evoluzioni non retro-compatibili dei sistemi esterni con cui desideriamo dialogare.

Un ACL ha quindi lo scopo di frapporsi far i due:

Se abbiamo quindi due mondi molto diversi che in qualche modo devono poter dialogare, due mondi molto diversi come nell’esempio di cui sopra, ha molto senso mettere un cuscino di sicurezza che faccia da mediatore nel dialogo e che in alcuni casi ci possa dare molto di più.

esagerato :-)

Il cuscino, il nostro ACL, in questo caso è molto ma molto di più di un semplice cuscino, abbiamo:

• un sistema (AS400) la cui forma dei dati è molto, ma molto diversa da quello che servirebbe a noi, inoltre noi non siamo gli unici a cui servirebbero quei dati;
• c’è quindi un software commerciale di terze parti il cui unico scopo è quello di travasare, ogni 15 minuti, da AS400 a SQL Server i dati, una gran quantità di dati, e anche di fare un primo passaggio di normalizzazione/trasformazione;
• a questo punto da SQL Server siamo in grado di lanciare (al termine di ogni sync) un processo che capisce cosa è effettivamente cambiato dall’ultima sync e si limita a mettere in una coda queste informazioni;
• c’è quindi un servizio in ascolto su quella coda privata che estrae le informazioni da SQL, fa un po’ di ragionamenti e le trasforma nella forma definitiva che il mondo esterno desidera salvando i dati su MongoDB;
• infine il processo di salvataggio su MongoDB notifica su una coda pubblica l’evento avvenuto;

Che cosa otteniamo alla fine?

Una cosa fantastica un sistema push che notifica tutti gli interessati di ogni modifica che avviane sul sistema di origine.

Ovviamente con lo scotto dei 15 minuti di ritardo e con il fatto che se nella finestra temporale ci sono più modifiche le perdiamo, ma ci interessa poco perché se ci pensate passiamo dal non avere nulla di nulla ad avere una catena di integrazione facilissima da utilizzare per qualsivoglia tecnologia ci sia la fuori.

Easy peasy, lemon squeezy… ;-)

.m