Architetture a microservizi

Architetture a microservizi - concetti base

Introduzione

Ho trattato questo argomento in maniera dettagliata per quanto riguarda la realizzazione di microservizi con JHipster in altri post che riporto nel capitolo "Approfondimenti" finale.

Qui raccolgo in sintesi alcuni concetti di base.

Dalla monolitica ai microservizi

L'architettura a microservizi è una evoluzione adatta allo sviluppo di soluzioni software di media, grande e grandissima complessità. Rappresenta la concretizzazione dei concetti di modularità, disaccoppiamento e riusabilità tanto trattati in letteratura.

Inizialmente l'architettura de-facto di tantissime soluzioni era quella rappresentata sotto come "Monolitica". La soluzione e microservizi prevede che ogni blocco logico di funzionalità sia effettivamente un "programmino"... microservizio, appunto.

I microservizi, se ben sviluppati, sono assolutamente indipendenti (funzionano anche da soli o in contesti diversi da quello iniziale) e quindi realmente ed altamente riusabili. Quando dipendono da altri microservizi restano comunque riusabili, in quanto quel set di microservizi interdipendenti possono essere messi in un contesto nuovo e usati in altre soluzioni.

Soluzione consolidata

Anche la monolitica, ai suoi tempi, era una "soluzione consolidata"... questa proposta sotto è la "soluzione consolidata" oggi per quanto riguarda i microservizi.

Prevede dei Clients che possono essere dispositivi mobili, fissi, ma anche altre applicazioni dalle quali si accede ai servizi implementati dalla soluzione.

Un API Gateway che implementa l'interfaccia con il mondo esterno intesa come UI (User Interface) web ma anche come interfaccia mediante API per altre applicazioni esterne che fanno da client. I microservizi, che implementano effettivamente le funzionalità fornite dalla soluzione software sono "naturalmente" containerizzabili (JHipster li crea mediante il suo wizard già con il supporto a docker) e quindi facilmente distribuibili mediante Container Orchestration che ne favorisce la scalabilità.

Il livello Data Store è rimasto invariato.

Vantaggi

Riutilizzo: se ben scritti possono rappresentare, in una architettura cloud "la soluzione" al gruppo di funzionalità richieste ed implementate dal singolo microservizio. Immagino un microservizio che si occupa della "messaggistica". In una soluzione cloud ad esso verranno inviati, dagli altri componenti dell'ecosistema cloud, i messaggi da inviare nelle vari forme previste costituiti da [Destinatari][Oggetto][Messaggio][Modalità di invio][Opzioni a corredo] ed esso si occuperà di inviare il messaggio via sms, mail, chat, fax ...

Efficienza: possono essere costituiti anche da progetti open source collaborativi ed evoluti da tanti contributor e quindi arrivare ad essere estremamente efficienti perché frutto delle tante esperienze di ognuno dei contributors.

Resilienza: si adattano, se ben scritte e ben documentate le loro interfacce, ai cambiamenti della soluzione cloud complessiva.

Distribuzione: due colpi di tastiera e l'immagine docker di un microservizio può essere spostata da un cloud ad un altro, configurata e messa a disposizione.

Bilanciamento: l'orchestratore può bilanciare i carichi e replicare il singolo microservizio per farlo lavorare su carichi estremamente eterogenei.

Scalabilità: replicando le istanze, aumentando le risorse di calcolo i microservizi aumentano le loro performance senza nessun intervento sul codice o sulla loro configurazione.

Problematiche

Tutti questi vantaggi hanno, chiaramente dei "costi" e cioè degli elementi che vanno presi in considerazione e delle componenti a contorno che si rendono necessarie per poter abbattere qusti costi. Qui elenco le soluzioni che propongo alle problematiche di questa architettura:

Tracciamento: se un servizio risulta lento o non risponde e si rende necessario un debug o replicare il problema in una architettura complessa è necessario dotarsi di uno strumento di tracciabilità. Zipkin può rappresentare una soluzione.

Monitoraggio: verificare costantemente che tutte le componenti stiano funzionando ed essere allertati in caso di anomalie è fondamentale per non scoprire che qualcosa non va solo quando ormai è troppo tardi. Una soluzione di alerting e monitoraggio è la JHipster console.

Documentazione: è indispensabile disegnare e documentare adeguatamente le componenti. Esistono modelli di documentazione ben consolidata per le REST/Api che è indispensabile adottare da subito per poter manutenere ed evolvere soluzioni a microservizi. Swagger propone una soluzione completa.