Business Driven Architectures - Parte 3
In questo articolo continuiamo ad esplorare il concetto di architetture Business Driven, tenendo in considerazione gli aspetti più concreti di questo tipo di architetture.
Nell'Information Tecnology il modello X as a Service è facile da comprendere. Ci indica che alcuni servizi vengono forniti da un fornitore di terze parti oppure internamente gestendoli come se fossero servizi esterni.
Utilizzando un'architettura a microservizi dovremmo operare questo cambiamento di prospettiva per ogni servizio. Il modello infatti garantisce, indipendenza al team che lo gestisce e un modello di utilizzo chiaro e ben documentato per i team che lo utilizzeranno.
Identity as a Service
Adottare un servizio di Identity as a Service è probabilmente una delle prime necessità per supportare questo tipo di architetture.
Le applicazioni / servizi devono poter contare su un servizio che gli consenta di condividere le utenze.
Le alternative presenti sul mercato sono molteplici e generalmente fanno utilizzo di protocolli di autenticazione standard (OAuth2, Open ID Connect 1.0, SAML, AD/LDAP). Questo ci garantisce un certo margine di portabilità tra una soluzione e l'altra.
Scegliere un fornitore di terze parti (Okta, Auth0, AWS Cognito, ...) che si occupi di tutto il lavoro, ad esempio in caso di assenza di competenze interne, necessità di scaling su larga scala, riduzione dei costi, compliance con normative e regolamenti.
In base alle necessità e qualora si decida di eseguire carichi sulla propria infrastruttura si potrebbe optare per la gestione diretta del servizio.
Anche in questo caso ci sono diverse alternative su cui indirizzare la nostra scelta, citiamo ad esempio Ory Hydra , Keycloak e CAS oltre a quella di crearne uno da zero.
Se il nostro obiettivo non è quello di rivendere il servizio di Identity, l'implementazione personalizzata è poco praticabile, non avremmo possibilità di acquistare supporto, una community che identifichi bug e migliori il prodotto.
Scegliendo invece un prodotto occorre essere pragmatici e valutare adeguatamente pro e contro di ognuno di essi. Ory Hydra e CAS ad esempio offrono ampi margini di personalizzazione ma richiedono un costo di integrazione più elevato, Keycloak invece è una soluzione sicuramente più completa ma può in alcuni casi risultare più vincolante per alcuni aspetti. (fixme Federation, Spid, TFA)
A prescindere da quale soluzione si scelga occorre ragionare attentamente sul processo di adozione che deve coinvolgere progressivamente applicazioni/servizi pre-esistenti o da creare. Percorrere questa strada richiede un impegno notevole, occorre prevedere migrazioni di utenze, librerie o componenti di integrazione per applicazioni pre-esistenti, documentazione e supporto adeguato.
Su questi temi facciamo un po' di auto-promozione ai nostri contributi opensource:
iad-osiad-osiad-osEvent-Driven Architecture
Le architetture a microservizi e quelle serverless richiedono l'utilizzo di architetture event driven per:
- rendere l'esperienza utente reactive e interattiva (notifiche, chat, collaborazione online, etc)
- applicare il pattern "Inversion of Control" tra i singoli servizi, consentendo una maggiore coesione e un basso accoppiamento tra di essi.
Chi scatena l'evento non è a conoscenza di quali saranno i suoi utilizzatori, quindi un cambiamento su uno di questi servizi non produce nessun effetto su chi lo ha generato; - implementare la Consistenza Eventuale: L'impossibilità di avere transazioni ACID su un sistema distribuito (CAP Theorem), nelle situazioni dove non è stato possibile risolvere il problema attraverso un'oculata scelta dei contesti transazionali ci porta a considerare soluzioni capaci di convergere ad una situazione di consistenza, consistenza eventuale appunto.
Questi meccanismi utilizzano eventi per raggiungere questo traguardo; - utilizzare gli eventi per produrre informazioni aggregate utili a fini di monitoring, alerting e BI.
Le principali caratteristiche di un sistema adeguato alle nostre necessità dovrebbe:
- gestire un numero adeguato di eventi e connessioni
- garantire una durabilità degli eventi stessi
- essere facile da integrare e con il supporto ai principali modelli di utilizzo (es. publish/subscribe, request/reply, queue group, ...)
A seconda delle necessità esistono diverse soluzioni da poter metter in campo. La scelta deve avvenire in base alle necessità effettive di progetto.
NATS, è una soluzione opensource che fornisce performance elevate, scalabilità, sicurezza e resilienza nella gestione di sistemi "hyperconnected".
Il punto di forza di NATS è nella sua "ergonomicità" di utilizzo. In altre parole consente agli sviluppatori di gestire diversi casi d'uso con estrema semplicità.
Apache Kafka è una piattaforma di event streaming utilizzata per applicazioni con data pipeline ad elevate performance, streaming analytics, data integration e applicazioni mission-critical.
La sua robustezza e le performance lo rendono adatto alla creazione di requisiti complessi. Purtroppo la sua natura non gli consente di avere la stessa "ergonomicità" di NATS e la sua gestione operativa è molto più complessa rispetto alle altre soluzioni.
GitOps
Il GitOps è una metodologia che ci consente di gestire il deployment di applicazioni Cloud Native. Lo sviluppatore viene messo in condizione di poter gestire direttamente l'infrastruttura utilizzando gli strumenti con cui ha già familiarità, incluso Git e i tools di Continuous Deployment
GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping.
— Kelsey Hightower
Attraverso il GitOps è possibile ottenere allo stesso tempo automazione e controllo. Questo risultato viene ottenuto utilizzando un approccio dichiarativo in tutti i livelli.
Tutti i passaggi necessari, dal provisioning infrastrutturale (es. IaaS) fino ad arrivare al rilascio in produzione, sono descritti all'interno di un repository Git.
Per creare un nuovo ambiente o effettuare il rilascio di una singola commit non serve più ingaggiare il gruppo di operations.
Gli interventi una volta sottoposti ad un processo di approvazione supervisionato o automatico, vengono accettati e realizzati direttamente dal sistema.
Il modello di contribuzione stesso viene inserito in questi repository, per convenzione denominato CONTRIBUTING.md.
In questo modo i singoli team possono disegnare la loro infrastruttura di base, lasciando ai gruppi di Operations l'opportunità di adattarle in una fase successiva.
I singoli team non hanno nemmeno accesso diretto agli ambienti dove verranno eseguiti i loro workload, stabilendo un livello di sicurezza elevato.
Uno degli strumenti che ci consente di applicare questa metodologia è ArgoCD.
Why ArgoCD?
Application definitions, configurations, and environments should be declarative and version controlled. Application deployment and lifecycle management should be automated, auditable, and easy to understand.
Conclusioni
Questi sono solo alcuni dei problemi e i relativi strumenti su cui occorre fare una riflessione.
Senza questi strumenti le architetture orientate al Business sono quasi impossibili da gestire e proibitive nei costi operativi e di gestione.
Anche se si può procedere ad un'adozione incrementale che vada di pari passo con il nostro business, avere già un obiettivo e una strategia di breve e medio termine ci consente di non precludere l'utilizzo di questi strumenti.