Quale architettura per il nostro software?

Scegliere l’architettura di un software consiste nell’operare scelte strutturali fondamentali che sono difficili e costose da mutare una volta implementate. L’architettura del software consiste nelle strutture fondamentali di un sistema e nella metodologia di realizzazione di tali strutture e sistemi.

Possiamo distinguere essenzialmente tra tre paradigmi architetturali del software.

Architettura a strati

In un’architettura a layer la progettazione strutturale del sistema viene modellata secondo le responsabilità delle parti fondamentali di quasi tutte le applicazioni che gestiscono dati.

• La logica di business è contenuta nelle sezioni di codice comprendenti gli algoritmi essenziali a risolvere i problemi a fronte di semplici input ed output.
• Lo strato di presentazione si occupa di rappresentare all’utente i dati in forma comprensibile (interfacce web, shell¹, API², dispositivi hardware).
• Lo strato di persistenza gestisce il flusso dei dati tra un database ed un altro.
• Quarto ed ultimo strato è costituito dai database.

Questi quattro strati sono piuttosto semplici da collegare tra loro, da testare e da mettere in produzione. Il limite di tale architettura è costituito dalle prestazioni, in quanto il vincolo dovuto ai quattro layers rende il sistema indivisibile e poco adatto a sopportare grossi carichi di lavoro.

Architettura ad eventi

A differenza dell’architettura precedente, in quella ad eventi esiste un punto di ingresso nel sistema che funge da direttore del traffico dei dati prelevando l’informazione in arrivo e mappandola in un evento.

L’evento costituisce una rappresentazione dei dati, la descrizione di qualcosa che accade nel sistema che viene successivamente trasmesso tramite specifici canali di informazione.

Le applicazioni sono costituite da piccole componenti che ricevono gli eventi da questi canali intercettando i dati secondo la loro responsabilità e ritrasmettendoli successivamente nel canale di risposta.

Questa architettura consente di raggiungere elevate prestazioni su larga scala, ma il testing risulta molto complesso perché, per replicare una situazione, può essere necessario ricostruire grandi quantità di eventi. Anche il deploy del gestore degli eventi può essere molto complicato, poiché da esso dipendono tutti i servizi.

Architettura a microservizi

L’architettura a microservizi vede una galassia di applicazioni indipendenti per sviluppo e gestione che comunicano tra loro a mezzo protocolli e linguaggi quali http³ e gRPC⁴. Viene stabilita la specifica protocollare di integrazione tra le applicazioni prima di iniziare la comunicazione.

Tale architettura consente di creare più punti di ingresso al sistema e diverse topologie di interazione senza il vincolo di un unico nodo centrale. Ogni singolo servizio assolve ad una specifica funzionalità che può essere atomica a piacere. Ogni microservizio definisce le proprie regole di comunicazione con il mondo esterno e mette in atto il proprio ciclo di deploy.

I vantaggi di decomporre un’applicazione in diversi servizi più piccoli sono numerosi:

• Modularità: questo rende l’applicazione più semplice da comprendere, sviluppare e testare;
• Scalabilità: poiché i microservizi sono implementati e distribuiti indipendentemente l’uno dall’altro, ovvero eseguiti all’interno di processi indipendenti, possono essere monitorati e ridimensionati in modo indipendente;
• Integrazione di sistemi eterogenei e legacy: i microservizi sono considerati un mezzo per modernizzare le applicazioni software legacy monolitiche esistenti attraverso un approccio incrementale;
• Sviluppo distribuito: parallelizza lo sviluppo consentendo a piccoli team autonomi di sviluppare, distribuire e ridimensionare i rispettivi servizi in modo indipendente. Le architetture basate su microservizi facilitano l’integrazione, la consegna e l’implementazione continue.

Si tratta ad oggi dell’approccio architetturale ritenuto più adatto al cloud e alla containerizzazione come descritto nel mio articolo “DevOps: Dalle macchine virtuali ai container”⁵.

Svantaggio di tale architettura sono però i limiti di performance imposti dal ricorso al network in uso e l’overhead di gestione del protocollo che può essere paragonabile se non superiore alle dimensioni del dato stesso.

¹ https://en.wikipedia.org/wiki/Shell_(computing) 
² https://en.wikipedia.org/wiki/Application_programming_interface
³ https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol 
⁴ https://en.wikipedia.org/wiki/GRPC
⁵ https://www.digital4pro.com/en/2020/07/14/devops-from-virtual-machines-to-containers/

Bibliografia:

• DevOps Guida per integrare Development e Operations e produrre software di qualità, Fabio Mora
• Clean architecture. Guida per diventare abili progettisti di architetture software, Robert C. Martin