Composable Architecture: istruzioni per l’uso

Viviamo in tempi incerti. 

La volatilità in termini di mercato, business e esigenze dei clienti è diventata una costante con cui confrontarsi. 

Il Covid19, la crisi in Ucraina e l’avanzare rapido del progresso tecnologico ci obbligano a porci un interrogativo: come progettare un futuro che continua a cambiare? 

Una risposta è l'architettura componibile o Composable Architecture o Composable Business. 

In questo articolo del nostro CTO Mario Stefanutti, viene illustrata l'importanza della componibilità e come utilizzare l'architettura componibile per aiutare le organizzazioni a trasformarsi e tenere il passo con i cambiamenti.  

------------------------------------------------------------------------------

Composable Business, un nuovo approccio che coinvolge tutta l’azienda e che vi aiuterà nel costruire un’architettura IT che non teme nulla.

1. Composable Architecture - Scenario
2. Composable Architecture - Il parere di un esperto (OpenAI ChatGPT) 🤣 🤣
3. Come funziona una Composable Architecture
4. A cosa serve una Composable Architecture
5. Composable Architecture - Leggere bene le istruzioni d’uso
6. Quali framework utilizzare per adottare una Composable Architecture?
7. Composable Architecture - Conclusioni

Composable Architecture - Scenario

Quanti differenti modi per memorizzare informazioni sono stati inventati nel recente passato? Oltre i database relazionali classici, e già di questi se ne contano centinaia, abbiamo i database colonnari, object-oriented, a grafo, knowledge base, DB probabilistici, DB chiave valore, ibridi e tanti altri con altre specificità. Lo stesso vale per i sistemi di messaggistica, per i framework per realizzare web application, per i container di servizi, e per tutte le aree IT, nessuna esclusa. Ed Il ritmo di queste evoluzioni e cambiamenti cresce velocemente.

Tra questi framework o prodotti ce ne sono alcuni rivoluzionari, che diventano maturi velocemente e di fatto cambiano il panorama dell’IT in modo radicale. Molti altri, per fortuna la maggior parte direi, muore altrettanto velocemente.

Ma perché questo ritmo, questo aumento? Da cosa dipende?

Due fattori sono importanti e questi si alimentano l’uno con l’altro:

• Nuovo business impone l’evoluzione delle tecnologie
• L'evoluzione delle tecnologie, permette di inventare nuovo business

Il business diventa sempre più esigente ed inventivo: nuove start-up, con l'evolversi delle tecnologie, inventano nuovi modi per creare un valore alla società e fare business. E questa frenesia impone cambiamenti tecnologici sempre più rapidi. I cambiamenti tecnologici e la maggiore interconnessione tra uomo e tecnologia provocano l'aumento dei dati generati, raccolti e analizzati. Questo porta allo sviluppo di nuove tecnologie e tecniche per memorizzare, gestire e analizzare i dati, come il big data e la scienza dei dati. L’internet degli oggetti ne è un esempio pratico. Nuove possibilità tecniche portano poi a nuove possibilità di business.

Diventa estremamente critico per le aziende conoscere bene come evolve l’ecosistema delle tecnologie IT, in un mercato così dinamico. Da queste conoscenze e dalle scelte che si fanno, né può dipendere la vita o la morte di un’idea, su cui una start-up o azienda investe tempo e risorse.

In questo blog parleremo di composable architectures e come questo modello architetturale può aiutare a vivere bene tutti questi cambiamenti.

Composable Architecture - Il parere di un esperto (OpenAI ChatGPT) 🤣 🤣

Gartner prevede che entro il 2023 le organizzazioni che hanno adottato un approccio componibile saranno in grado di implementare nuove funzionalità ad una velocità dell'80% superiore rispetto ai competitor che hanno usato un soluzioni ad-hoc. E 80% più veloce non è certo poco. 80%!

Devo ammettere che per curiosità, dato che non si parla di altro su internet, ho provato a fare alcune domande inerenti le composable architectures ad OpenAI ChatGPT, per vedere cosa rispondeva. Ora riporto qui le risposte. Naturalmente molte informazioni e la definizione di composable architectures si possono trovare su molti altri siti di tecnologia: IBM, Gartner, Oracle, Google, Amazon, Microsoft e altri.

Lascio ora la parola a OpenAI ChatGPT, poi naturalmente continuerò io, con considerazioni più personali sull’argomento.

Beh, è impressionante il livello di qualità della conversazione di OpenAI ChatGPT, ma questa è un’altra storia.

Riprendiamo ora l’articolo, ma teniamo comunque presente le risposte di OpenAI ChatGPT alle domande riportate sopra.

Come funziona una Composable Architecture

Il concetto di composable architecture, tecnicamente parlando, non è nuovo. Forzando un po’ la mano lo possiamo mandare molto indietro nel tempo. Modularità, flessibilità, scalabilità e riutilizzabilità (seconda risposta di ChatGPT) sono sempre stati presenti nella progettazione dei sistemi e l'obiettivo già allora era quello di proteggere il business, per evolverlo più facilmente.

Ricordo che negli anni 90, per realizzare buone architetture componibili già c’erano molti metodi e tool. CORBA (1991), nonostante tutti i problemi e critiche fatte nel passato, nasceva proprio a tale scopo. Tibco, Tuxedo di BEA, successivamente acquisita da Oracle, già permettevano di implementare architetture con buon livello di modularità, ma erano comunque soluzioni proprietarie ed ancora non si poteva parlare di componibilità. Successivamente, proprio alla fine del secolo (Dicembre 1999) nasceva J2EE e non molto dopo le architetture SOA oriented. La SOA è uno dei metodi per realizzare architetture componibili (terza risposta di ChatGPT). Era tecnicamente più complesso realizzare architetture componibili, ma da un altro punto di vista il numero di scelte tecnologiche a disposizione era molto minore e questo semplifica un po’ la vita degli architetti e programmatori. DB ce ne erano 4 o 5, non centinaia come oggi, e lo stesso valeva per i sistemi di messaggistica, che potevi scegliere tra 2-3 sistemi diversi e non decine se non centinaia come ora.

La cosa che cambia nel tempo è la consapevolezza del concetto di composable architecture e la qualità e consistenza dell’edificio teorico che è stato costruito e che rappresenta le fondamenta delle architetture componibili, e dell’ecosistema di prodotti/framework nati per realizzare architettura componibili. Tanti concetti embrionali inventati tempo fa sono evoluti per convergere in un nucleo di concetti che permette oggi a pieno titolo di parlare di composable architecture. Da un lato c’è stata l’evoluzione di molti aspetti tecnici: microservizi, la nascita dei prodotti headless, i concetti di API first, cloud native, le architetture service mesh e molti altri. Dall’altro ci sono aspetti di business, che impongono a figure di livello C (CEO, CIO, CFO, etc.) di considerare le scelte sulle architetture componibili come fondamentali per la buona crescita del proprio business, proteggendolo dalle dinamicità dei cambiamenti IT. Comprende molti aspetti, atteggiamento strategico dell’azienda, insieme delle tecnologie e dei processi che consentono alle organizzazioni di innovare e adattarsi alle esigenze aziendali in continuo mutamento.

A cosa serve una Composable Architecture

Le problematiche dei building blocks intercambiabili sono state portate ad un livello molto più alto di prima. Ecco alcuni esempi delle necessità in questo settore:

• Cambiare l’intero CRM attualmente basato su una soluzione custom verso una soluzione di mercato (Hubspot, Salesforce, SugarCRM, Zoho CRM per citarne alcuni in ordine alfabetico)
• Cambiare il sistema di CMS ed utilizzare una soluzione SaaS completamente managed
  • Alcuni esempi di CMS headless includono Strapi, Directus e Cockpit.
• Cambiare il database dei BigData da architettura proprietaria ad architettura open source
• Spostare tutto il sistema dall’attuale soluzione on-premise ad un provider di servizi Cloud (AWS, Azure, Google per citare i principali in ordine alfabetico) e contemporaneamente sostituire tutti i database con soluzione completamente managed dal provider

Esigenze evolutive molto più dinamiche, in cui i tempi di reattività ad cambiamenti sono fondamentali. È un tempo complesso ma glorioso per gli architetti enterprise. Nuove tecnologie da imparare ogni giorno.

Composable Architecture - Leggere bene le istruzioni d’uso

Vediamo gli aspetti fondamentali per l’impostazione di una buona composable architecture:

• Capire bene le necessità di business e predisporre una strategia di crescita adeguata
  • Una cosa è sapere che si partirà con 10 clienti entro i primi tre mesi del 2023 che poi aumenteranno di 10 ogni mese, un’altra cosa è sapere che il business scalerà velocemente già da subito a milioni di clienti. Un database relazionale, fermo restando l’interazione standardizzata con esso (SQL), può essere scelto tra soluzioni con richieste dimensionali e prestazionali molti differenti nei due caso
• Capire quali sono le scelte tecnologiche possibili e disponibili nell’ecosistema IT delle architetture componibili e creare una mappa di corrispondenza con le esigenze di business
  • Un CRM come elemento elementare ed intercambiabile nelle architetture componibili, può essere scelto tra soluzioni costruite ad-hoc, soluzioni open source, soluzioni commerciali self-managed installabili su differenti cloud o soluzioni completamente managed da provider stessi del servizio. Mi vengono in mente ad esempio Hubspot o Salesforce
• Eseguire le scelte architetturali più adeguate per la fase di crescita del business. Si è in una fase di sperimentazione, di avvio, di crescita del business, di consolidamento del business? Le differenti fasi di vita del prodotto, dovranno preferibilmente impattare solo sugli aspetti di scalabilità del sistema: start small, think big
• Build della soluzione e attenzione ai cambiamenti. Se l’architettura è pensata bene, allora il cambiamento di un componente non deve essere visto come un problema, ma come un’opportunità di migliorare il business

Naturalmente a parte la strategia migliore per adottare una composable architecture, ci sono anche gli aspetti tecnici che sono alla base dei sistemi IT:

• Scalabilità, modularità, robustezza, sicurezza, no vendor lock-in
  • In particolare la scalabilità può essere intesa non solo a livello tecnico, ma anche legata alla crescita del business. Molti cloud moderni offrono servizi completamente managed che possono partire a costo zero e poi crescere nel tempo
• API based e modalità di funzionamento headless
  • La possibilità di interagire con i building block via API, garantisce un isolamento delle componenti e una contrattualizzazione ben precisa con i servizi stessi
• Supporto al multi-cloud e soluzioni intrinsecamente cloud native
  • In altre parole, il supporto al multi-cloud consente a una tecnologia o a una soluzione di essere utilizzata su più piattaforme cloud, mentre le soluzioni intrinsecamente cloud native sono progettate per sfruttare appieno le risorse del cloud e fornire un'esperienza ottimale agli utenti
• Modello di funzionamento e costo del componente scelto
  • Pay per use: In questo modello, gli utenti pagano solo per le risorse del cloud che utilizzano effettivamente, ad esempio il numero di ore di utilizzo di una macchina virtuale o il volume di dati immagazzinato in un database. Spesso considerato vantaggioso perché permette agli utenti di pagare solo per ciò che effettivamente utilizzano, evitando costi fissi e inutili
  • Flat fee: prevede che gli utenti paghino una tariffa fissa per l'accesso a un set predefinito di risorse del cloud, indipendentemente dal loro effettivo utilizzo. Questo modello può essere vantaggioso per le aziende che prevedono un utilizzo costante e prevedibile delle risorse del cloud
  • Free tier: prevede che i provider di cloud offrano una quantità limitata di risorse del cloud gratuitamente per un periodo di tempo definito. Questo modello può essere utile per gli sviluppatori che desiderano provare il cloud o per le piccole aziende che hanno bisogno di una quantità limitata di risorse
  • Reserved: in cui gli utenti pagano una tariffa scontata per riservare le risorse del cloud per un periodo di tempo definito, solitamente un anno o tre anni. Questo modello può essere vantaggioso per le aziende che prevedono un elevato utilizzo delle risorse del cloud e desiderano garantirsi un prezzo fisso per un periodo di tempo prolungato
  • Spot: in cui gli utenti possono acquistare le risorse del cloud a prezzi scontati in base alla disponibilità e alla domanda
  • Hybrid: Un misto dei modelli descritti sopra
• Scelta e valutazione dei prodotti open source o comunque con base di partenza open source (Kafka, MySQL, Hadoop, etc.)
  • Licenza: Assicurarsi di comprendere i termini della licenza open source scelta e di essere in grado di rispettarla
  • La comunità: Valutare la dimensione e l'attività della comunità che supporta la soluzione open source scelta: quante persone, da quando. Su piattaforme Git, controlla anche i grafici dell’attività sul progetto. Molte comunità open source, specialmente quando le tecnologie hanno una distribuzione a livello mondiale, hanno anche grandi società che ne supportano l’attività, spesso come componenti dei team di sviluppo
  • La documentazione: Verificare che la soluzione open source scelta sia correttamente documentata e che siano disponibili guide e tutorial per l'utilizzo e la configurazione della soluzione
  • La maturità: Una soluzione più matura potrebbe essere più stabile e affidabile, ma potrebbe anche essere meno flessibile rispetto a soluzioni più giovani. Va bilanciato bene il rischio nella scelta
  • Supporto: Che tipo di supporto viene fornito dalla soluzione open source scelta: online, solo documentazione, supporto commerciale
  • Sicurezza: Valutare la sicurezza della soluzione open source scelta e verificare che siano disponibili patch e aggiornamenti per risolvere eventuali vulnerabilità.
  • Altri fattori da tenere in considerazione sono: capacità di integrazione, se personalizzabile, i costi naturalmente, la qualità del codice, le prestazioni, l’indipendenza, la reputazione (i like sui social), valutare il futuro della soluzione, l’adozione di standard, l’indipendenza da altre soluzioni, e valutare le alternative disponibili

Quali framework utilizzare per adottare una Composable Architecture?

Ci sono diverse tecnologie e framework che sono legati alle composable architecture, tra cui:

• Microservices e containers: i microservizi sono piccole applicazioni autonome che possono essere sviluppate, deployate e gestite indipendentemente come componenti modulari e riutilizzabili. In genere i microservizi vengono inseriti in “container” che consentono di isolare le applicazioni in un ambiente virtuale che include tutte le dipendenze necessarie per l'esecuzione. Kubernetes, che è diventato in breve tempo un riferimento nelle architetture moderne, è un esempio di implementazione di architetture componibili
• GraphQL: è un linguaggio di query e un runtime per l'esecuzione di query sulle API. È spesso utilizzato in architetture componibili per creare API modulari e facilmente riutilizzabili
• Jamstack: utilizza le API per integrare le funzionalità dinamiche nel front-end, è possibile utilizzare CMS headless che forniscono un'API per gestire i contenuti, senza dover utilizzare un'interfaccia utente predefinita. Ciò consente di scegliere il CMS più adatto alle esigenze di business e di integrarlo facilmente con il front-end sviluppato con Jamstack
• Service mesh: è una tecnologia che viene utilizzata per gestire le comunicazioni tra i microservizi in un'architettura componibile. Una service mesh fornisce un insieme di funzionalità, come il routing del traffico, la gestione degli errori, il monitoraggio e la sicurezza, per facilitare la gestione e la scalabilità delle comunicazioni tra i microservizi. In un'architettura componibile, la service mesh consente di gestire facilmente le comunicazioni tra i diversi microservizi, indipendentemente dalla tecnologia o dal linguaggio di programmazione utilizzati. Ciò consente agli sviluppatori di creare facilmente microservizi modulari e riutilizzabili, che possono essere facilmente combinati e utilizzati in diverse situazioni per creare nuove applicazioni e soluzioni. Istio, Consul, Linkerd, Envoy sono esempi che consentono di creare architetture cloud native
• API-first design: quando si sviluppa un'applicazione o un servizio, la prima cosa che si fa è progettare e creare le interfacce di programmazione (API) che verranno utilizzate per accedere alla funzionalità del servizio. Con questo approccio, l'API diventa fondamentale per definire e determinare le funzionalità e le possibilità del servizio. Spesso questo metodo viene utilizzato insieme a un'architettura di microservizi per creare un sistema altamente modulare e componibile. In un'architettura componibile, i singoli componenti o servizi possono essere combinati e utilizzati in modi diversi per creare nuove funzionalità

Composable Architecture - Conclusioni

Ci sono molte altre tecnologie che andrebbero citate per dare un quadro più completo delle evoluzioni IT nel campo delle composable architectures, ma questo lo lasciamo allo studio personale di ognuno … e poi se siete arrivati fino a fine articolo vuol dire che l’argomento fa parte delle vostre necessità quotidiane.

Per concludere, l’esigenza di realizzare una composable architecture, deve necessariamente essere percepita come fondamentale da tutti i livelli e gruppo aziendali e non isolata a mera problematica tecnica.

Per i reparti tecnici, quello che mi sento di consigliare è focalizzare lo studio sempre più sull’ecosistema in continua evoluzione, scegliendo con cura le architetture, bilanciando bene le scelte disponibili con le esigenze di business. Questo significa 1-2 ore al giorno da dedicare allo studio delle tecnologie.

Quindi buono studio.