Passa ai contenuti principali

Architetture a microservizi - concetti base

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. 


Approfondimenti

Microservizi con JHipster

Microservizi con JHipster 2

Monitoraggio

Zipkin



Licenza Creative Commons
Quest'opera è distribuita con Licenza Creative Commons Attribuzione - Condividi allo stesso modo 4.0 Internazionale

Commenti

Post popolari in questo blog

Telecamere Ip con accesso "nascosto"

Telecamere Ip con accesso "nascosto" Storia triste di un auto-hacking obbligato che mi ha fatto scoprire come la nostra privacy è realmente messa a rischi. Storia Ho acquistato dal mercatino/fiera del Radioamatore di Fasano quattro telecamere IP. La scatola riporta "Smart Camera" LF4810. Ne ho montata una e testata in tutte le sue funzionalità per oltre un mese. Chiaramente la manualistica scarsissima, come da tradizione in questi prodotti cinesi di costo molto concorrenziale, consiste in un "pieghevole" di 4 facciate. Chiaramente non erano documentate le impostazioni necessarie per attivare i protocolli ONVIF e RTSP che mi sono indispensabili per l'uso che ne devo fare. Nonostante questa scarsa documentazione dopo l'installazione base fatta con l'apposita app: tutto sembrava corretto. Chiaramente la prima azione che ho compiuto è stata quella di cambiare la password che di default è "123". Subito dopo h

Alzatapparella con Shelly 2 e Alexa

Alzatapparella con Shelly 2 e Alexa Qui spiego tutti i passaggi per installare lo Shelly 2 per automatizzare una tapparella e come configurarlo in Alexa. Impianto attuale Collegamenti da effettuare: Schema teorico: Collegamenti reali: Impostazioni: Dopo aver collegato tutto si procede alla configurazione. Prima di tutto installare la App "Shelly" cercandola nel proprio store e create un account: Il dispositivo verrà visto come doppio interruttore. Andare sulla "i" "Impostazioni": Nella sezione "MODO" ed impostare "Roller Shutter" Poi su "APRI/CHIUDI TEMPO DI LAVORO" ed impostare tipo 20 secondi. Altro passaggio importante in caso di tapparelle è quello relativo alla calibrazione (schermata relativa a "Shelly 2.5"). Se si omette questo passaggio non sarà possibile vedere in che stato è (aperta/chiusa

UPS Monitor via USB

Collegamenti Ho collegato l'UPS Mustek PowerMust 800 mediante il cavo USB al server con Ubuntu Linux 18.04. Software Ho installato: $ sudo apt-get install nut nut-cgi Configurazione Ho impostato i permessi di accesso: $ sudo chown root:nut /etc/nut/* $ sudo chown 640 /etc/nut/* Ho impostato nel file ups.conf (il file di configurazione del servizio) [mustek] driver = blazer_usb port = auto desc = "Musteck Power 800 usb" Ho impostato nel file upsd.conf (il file di configurazione del demone del servizio) LISTEN 127.0.0.1 3493 ACL all 0.0.0.0/0 ACL localhost 127.0.0.1/32 ACCEPT localhost REJECT all Ho impostato nel file upsd.users (il file di configurazione degli utenti del servizio) [mustek] password = 123456 allowfrom = localhost upsmon master Ho impostato nel file upsmon.conf (il file di configurazione del servizio di monitoraggio) MONITOR mustek@localhost 1 local_mon 123456 master Ho abilitato il servizio di moni