AUTORI

Maurizio Maddaloni
Senior Solutions Architect
@Bip xTech

Introduzione

Da circa due decenni assistiamo al diffondersi di diversi stili architetturali di realizzazione del software, per rispondere alle continue e sempre più sfidanti richieste di digitalizzazione.

Partendo dalla più longeva e tradizionale delle architetture, ovvero la “Monolithic Architecture” che prevede la realizzazione di applicazioni pensate per essere autonome e autoconsistenti, si è passati alla “Service Oriented Architecture (SOA)”, una modalità di realizzazione di componenti software che permettono la riutilizzabilità e l’interoperabilità attraverso interfacce generiche di servizi, che possano essere rapidamente e facilmente incorporati in nuove applicazioni. Da qualche anno, invece, è andata man mano sempre di più diffondendosi l’ormai nota ”Architettura a Microservizi (MSA)”, ovvero uno stile architetturale attraverso cui un’applicazione è realizzata da componenti indipendenti, che eseguono ciascun processo applicativo come un servizio. Tali servizi comunicano attraverso un’interfaccia ben definita che utilizza API leggere.

Questi stili architetturali sono tutt’oggi utilizzati e ognuno ha una serie di pro e contro che guida gli architetti a protendere verso uno piuttosto che verso l’altro, in base anche al contesto e alla tipologia di progettualità in cui si trova ad operare.

In contesti di tipo Enterprise, in cui sono sempre maggiori le esigenze di scalabilità e modularità, da qualche anno hanno iniziato a diffondersi modelli architetturali come le “Layered Architectures” e le “Segmented Architectures”.

Le prime sono basate sul principio dello scambio dati tra diversi livelli. I moduli o componenti con funzionalità simili sono organizzati in strati orizzontali, di conseguenza ogni livello svolge un ruolo specifico all’interno dell’applicazione e la comunicazione tra essi avviene principalmente tramite chiamate ad API; per tale motivo vengono definite “API-centric”. Tuttavia, un’architettura a strati si traduce nella realizzazione di componenti software strettamente accoppiati tra loro.

Le “Segmented Architectures” rappresentano un’evoluzione dell’architettura a strati, aggiungendo a quest’ultima il concetto di segmentazione, ovvero la categorizzazione dei diversi componenti, ad esempio in base ai diversi domini di business. Questo introduce una maggiore flessibilità nello sviluppo software, consentendo di identificare aree diverse di competenza che possono essere demandate anche a team diversi.

Con l’introduzione delle architetture a microservizi (MSA) e delle infrastrutture cloud native, gli architetti hanno iniziato a progettare architetture quasi completamente greenfield. Tuttavia, la realtà è che molte aziende hanno bisogno di integrare anche sistemi e dati brownfield, necessari per gestire l’attività. Poiché le architetture di riferimento esistenti si rivolgono in maniera distinta a sistemi greenfield o brownfield, è nata nel tempo l’esigenza di una tipologia architetturale ibrida, che fosse in grado di riutilizzare i sistemi e i dati esistenti, nonché di crearne di nuovi in modalità greenfield. Senza contare che il numero di sistemi e/o di microservizi in esecuzione nelle aziende aumenta ogni giorno e, di conseguenza, concetti come la composizione del servizio, la governance, la sicurezza e l’osservabilità stanno diventando sfide sempre più importanti da implementare e incorporare.

Una “Cell-based Architecture” è un approccio che può essere applicato allo sviluppo e alle tecnologie attuali o future per affrontare i problemi appena citati. Questo approccio, indipendente dalla tecnologia, aiuta i team di sviluppo cloud-native a diventare più efficienti, agire in modo più auto-organizzato, accelerare i tempi di rilascio e di gestione e, soprattutto, favorisce l’integrazione di dati e sistemi di diversa natura (monolitici, SOA, basati su MSA, …), concetto molto importante in contesti di tipo enterprise.

Cos’è una Cell-based Architecture

Una Cell-based Architecture (CBA) rappresenta un modello architetturale in grado di raggruppare le diverse funzionalità di business di un’azienda di tipo enterprise, in singole unità definite “celle”, attraverso cui viene favorito un continuo scambio di dati e flussi informativi, garantendo quindi una gestione completamente decentralizzata e una capacità di evoluzione nel tempo, tarata sulle esigenze del business.

L’obiettivo di questa architettura è migliorare l’agilità della realtà che la implementa, intesa come capacità di rispondere repentinamente e in modo efficace ai cambiamenti dell’ambiente e/o della strategia aziendale e dei requisiti dell’utente. Tale agilità viene create attraverso quattro proprietà fondamentali:

• Scalabilità: intesa come la capacità di gestire carichi di lavoro sempre maggiori e in evoluzione, utilizzando le risorse disponibili. Questa è una delle proprietà essenziali delle moderne infrastrutture cloud, che consentono a componenti come i container di ridimensionarsi in modo efficace, a condizione che siano progettati nel modo corretto;
• Modularità: è l’idea secondo cui i componenti di un’architettura siano versionabili, replicabili e abbiano interfacce ben definite, permettendo inoltre di nascondere i dettagli del funzionamento interno;
• Componibilità: permette la creazione di un’architettura in maniera ricorsiva e uniforme, in cui nuovi componenti o sistemi si aggiungono alla piattaforma complessiva in modo continuo;
• Governance: ovvero la possibilità di creare sistemi gestiti, monitorati e resilienti, con la garanzia che le politiche organizzative possano essere applicate.

Fondamentalmente, l’architettura basata su celle è una strategia di raggruppamento dei componenti al fine di ridurre il numero di unità di distribuzione nel sistema, cosa fondamentale per la gestione dei microservizi.

Come menzionato all’inizio del paragrafo, l’unità di un’architettura enterprise che implementa questo pattern è rappresentata dalla cella.

Una cella si definisce come un insieme di componenti raggruppati, a partire dalla sua progettazione, passando per l’implementazione, fino alla sua distribuzione. Si tratta quindi di un’entità completamente autoconsistente, distribuibile, gestibile e osservabile in maniera indipendente.

Ogni cella ha una propria architettura interna cloud-native, che ha la possibilità di integrare componenti di diversa tipologia, favorendo eventualmente la migrazione graduale da architetture di tipologia differente.

Ogni cella ha una gestione completamente autonoma in termini di lifecycle, pertanto i gruppi di lavoro impegnati nello sviluppo di ogni cella sono indipendenti, sia da un punto di vista tecnologico che in termini di gestione dei rilasci, nonché di gestione di interventi evolutivi e manutentivi.

Le diverse celle possono ovviamente comunicare tra loro, attraverso interfacce standard, rendendo la CBA un’architettura decentralizzata.

I componenti di una singola cella sono riutilizzabili e instanziabili in diverse celle. Come anticipato, sono ammessi componenti di diversa tipologia, a patto che siano riconducibili a container. Le principali categorie di componenti sono:

Legacy and Data Services: ovvero database, sistemi legacy (o monoliti), processi di business, archivi, …

Microservices e componenti serverless: ovvero componenti che integrano logica di business, trasformazione, …

Gateway e brokers: ovvero componenti per lo scambio di informazioni tramite API, messaggistica, Identity brokers, …

Componenti di governance e utilities: ovvero strumenti di automazione, di gestione del ciclo di vita, …

Una cella è quindi un “API product” e le API messe a disposizione devono essere documentate, auto esplicative, consistenti ed affidabili. Le API, inoltre, fanno parte della definizione di cella stessa; questo fa sì che una cella può essere continuamente modificata e versionata, a patto che mantenga le sue interfacce esterne immutate.

In questo pattern, il gateway si configura quindi come punto unico di accesso per la cella e per tale motivo rappresenta anche un punto di monitoraggio e punto di rafforzamento delle policy di sicurezza.

Le Cell-based architecture, quindi, vanno oltre le tradizionali architetture a strati o segmentate ma creano un vero e proprio framework per la decentralizzazione.

Come i loro componenti, anche le celle possono essere categorizzate. Un primo livello di categorizzazione può essere dato dal provider: le celle di prodotti interni all’organizzazione vengono categorizzate in “celle interne” mentre le celle di terze parti, come partners tecnologici o service provider esterni, vengono considerate “celle esterne”. Sono state, quindi, individuate sette macro-categorie di celle:

• Logiche: Microservizi, funzioni, microgateway o, in generale, servizi cloud-native che eseguono funzioni di business;
• Integratione: MicroESB o altri microservizi di integrazione, piccole aree di storage e/o cache;
• Legacy: sistemi già esistenti, servizi legacy, sistemi COTS;
• Esterne: SaaS e sistemi di partner tecnologici;
• Dati: RDBMS, database NoSQL, file di dati, message broker;
• Sicurezza: gestori di identità e di funzionalità associate alle utenze;
• Canale: applicativi Web, mobile, IoT (per utenti finali)

Vantaggi

Uno dei principali vantaggi di una Cell-based architecture è dato dal livello di isolamento e dall’agilità che le celle possono fornire, rispetto ad un’architettura a strati o segmentata. Come accennato in precedenza, infatti, questo approccio permette di scomporre facilmente un’architettura aziendale in singole unità, applicando tre livelli di architettura iterativa:

• Un primo livello è dato dal fatto che i singoli componenti possono iterare individualmente all’interno di una cella;
• Ogni cella a sua volta può iterare singolarmente;
• Infine, l’architettura aziendale può iterare nel suo insieme.

Altro vantaggio molto importante è che, soprattutto in contesti di tipo enterprise, garantisce che le operazioni di replatforming e riprogettazione architetturale possano essere condotte in maniera graduale, risolvendo di fatto anche uno dei problemi menzionati nella parte introduttiva, ovvero la necessità di integrare soluzioni greenfield e brownfield in un’unica architettura. I nuovi progetti, infatti, possono seguire un approccio top-down definendo prima la cella e sviluppando poi i componenti che ne faranno parte. Al contrario, in situazioni in cui i componenti sono già stati sviluppati e sono già presenti nell’infrastruttura, questi possono essere riorganizzati e ricondotti a celle. In generale, la combinazione dei due approcci è quella che solitamente viene attuata e rappresenta il miglior approccio.

Un altro vantaggio è dato proprio dall’isolamento delle celle, che permette di isolare i malfunzionamenti e/o aggiornamenti di versione del software.

Una vista sul mercato

Asanka Abeysinghe, Chief Technology Evangelist di WSO2, ha introdotto le Cell-based Architectures nella seconda metà del 2018, ad un convegno, in seguito ad uno studio condotto su quattro macro-aree apparentemente distanti tra loro: informatica quantistica, Kubernetes, microbiologia e biologia dei sistemi.

Il tema è stato poi approfondito negli anni successivi dallo stesso Abeysinghe e da altri esperti del settore.

Successivamente, diverse startup hanno iniziato ad utilizzare le Cell-base Architectures. Tra queste ritroviamo:

• Tumblr: con oltre 15 milioni di visualizzazioni al mese e una crescita mensile di circa il 30%, opera su scale enormi, ossia 500 milioni di pagine visualizzate in un giorno, un picco di richieste pari a circa 40 mila al secondo e circa 3 TB al giorno di nuovi dati da immagazzinare, il tutto in running su oltre 1000 server. La direzione in cui si stanno muovendo è verso un modello di servizi distribuiti basato su un’intrigante architettura basata su celle.
• Flickr: Utilizza un approccio federato dove tutti i dati di un utente vengono immagazzinati su un cluster di servizi diversi (shard).
• Facebook: Il Servizio Messages di Facebook ha come elemento costitutivo di base del proprio sistema un cluster di macchine e servizi basati su architettura a celle. Tali celle vengono aggiunte in modo incrementale, in caso di necessità di maggiore potenza.
• Salesforce: Salesforce è progettato in termini di pod, ossia insiemi autonomi di funzionalità costituiti da 50 nodi, server RAC e server di applicazioni Java. Ogni pod supporta diverse migliaia di clienti.

Ad oggi, molte realtà di tipo enterprise implementano o si stanno muovendo verso questo approccio architetturale. Ma come per ogni cosa, probabilmente nel breve termine potremo assistere alla nascita di nuovi pattern architetturali che indirizzeranno la risoluzione delle problematiche tipiche a cui si va incontro con l’adozione di questa scelta o che, semplicemente, massimizzeranno ulteriormente i benefici per la aziende.

Conclusioni

Come detto in precedenza, i progressi tecnologici e le modifiche ai modelli di business spingono le aziende a muoversi verso architetture sempre più agili, in quanto le architetture tradizionali, fortemente centralizzate, non permettono di soddisfare più le aspettative del business e dei consumatori.

L’architettura a microservizi è un approccio eccellente alla creazione di sistemi decentralizzati. Tuttavia i microservizi risultano essere troppo granulari quando si tratta di ristrutturare architetture brownfield di grandi dimensioni.

Le Cell-based Architecture rappresentano una valida soluzione, in particolar modo quando sono richieste grandi dosi di governance e/o policy integrate in ogni interazione.

Why Bip xTech

xTech è il centro d’eccellenza del Gruppo Bip con una lunga storia nell’accompagnamento dei propri clienti lungo il processo di digitalizzazione. Al suo interno, la community Solutions può contare su decine di professionisti impegnati sulla progettazione e l’implementazione di architetture software ed enterprise.

In seguito a diverse analisi di mercato ed attente riflessioni in merito, abbiamo iniziato a proporre l’applicazione di questo pattern architetturale a diversi clienti di tipo enterprise e riteniamo essere una scelta vincente, visti anche i benefici in termini di risparmio di tempo e costi nei programmi di replatforming.

Come sempre, restiamo vigili per aiutare i nostri clienti a cogliere tutte le opportunità che il mercato offre, anche in ambito architetturale, per essere sempre al loro fianco nel continuo percorso di digitalizzazione.

---

Se sei interessato a saperne di più sulla nostra offerta o vuoi avere una conversazione con uno dei nostri esperti, invia un’email a [email protected] con oggetto “Cell-based Architecture” e sarai contattato immediatamente.