Riassunto esame Enterprise applications, Prof. Dodaro Carmine, libro consigliato Patterns of enterprise application architecture, Addison, Wesley

CONCETTI CHIAVE DEI MICROSERVIZI

Rilascio indipendente ogni servizio può essere modificato, testato e rilasciato



senza interferire con gli altri; ma devono essere loosely coupled (debolmente

accoppiati), quindi bisogna definire contratti espliciti e stabili tra i servizi.

Progettazione sul dominio di business (DDD) I microservizi dovrebbero



essere progettati sul dominio di business, così è più facile sviluppare nuove

funzionalità.

Stato e database si dovrebbero evitare i database condivisi tra più microservizi.



Se un microservizio ha bisogno di un dato che questi dati al microservizio piuttosto

di accedere al suo db. Questo favorisce l’incapsulamento (si decide cosa far vedere

e cosa tenere nascosto), e la separazione tra interno (funzionalità che cambiano

liberamente) e esterno (interfaccia esterna che viene cambiata raramente).

Dimensione “micro” non ha una misura standard. Un microservizio deve essere



facile da comprendere da parte del team.

Flessibilità siccome ogni servizio è indipendente è anche più flessibile.



Allineamento di architettura e organizzazione negli ultimi anni è cambiato il



modo di sviluppare e rilasciare software, i team moderni sono eterogenei, i rilasci

sono frequenti e i teams sono formati da persone con tante competenze diverse. I

microservizi si adattano a questa nuova realtà meglio dell’architettura a 3 strati.

VANTAGGI DEI MICROSERVIZI

Supporta Continuous Delivery (sviluppo continuo) e Continuous Deployment

(integrazione continua del codice) e risponde a tre esigenze per effettuare

continuous delivery e deployment

Testabilità → essendo i microservizi piccoli sono più facili da testare

 Deployabilità → rilascio indipendente

 Autonomia → ogni team lavora in autonomia → sviluppo più veloce



Servizi piccoli → codebase semplice, facile manutenzione e debugging

55

Ogni servizio può essere scalato e deployato in modo indipendente su hardware

dedicato, ad esempio se un microservizio si occupa di effettuare operazioni di

intelligenza artificiale, potrebbe richiedere una macchina con buone GPU.

Gli errori possono essere isolati, se c’è un fallimento da una sola parte questo non

fa crashare tutto il sistema. Inoltre è facile adottare nuove tecnologie per singoli

servizi, si possono quindi scegliere linguaggi e framework diversi.

SVANTAGGI DEI MICROSERVIZI

Non esiste un algoritmo o una strategia per decomporre un app monolite in

microservizi. I microservizi richiedono che i sistemi siano distribuiti, quindi i servizi

devono garantire un modo per comunicare tra di loro e ogni servizio deve essere

capace di gestire comunicazioni e fallimenti parziali.

Siccome ci sono più database che devono comunicare è difficile fare query

complesse e gestire la consistenza dei dati, inoltre devo trovare un modo per poter

annullare una transazione; la soluzione a ciò è sagas.

Testare più servizi insieme è complicato, e anche fare il deploy di funzionalità che

coinvolgono più servizi è difficile perché bisogna coordinare più gruppi di lavoro.

È difficile generare report completi, servono nuove soluzioni, posso creare dei

report parziali.

Monitoraggio, in un monolite è facile capire dove sta il problema (l’app o funziona

o no), ma nei microservizi è difficile capire se è fallita una singola istanza o è un

servizio che occupa tutta la cpu.

Siccome nei microservizi i dati viaggiano sulla rete sono più esposti a

intercettazioni e manipolazioni. Latenza maggiore rispetto ai monoliti (per via delle

chiamate di rete e sistema distribuito) e quindi peggioramento delle performance.

Non è facile capire quando iniziare a usare i microservizi, partire subito con

microservizi può rallentare lo sviluppo se non necessario, e inoltre bisogna

conoscere bene il dominio applicativo.

GARTNER HYPE CYCLE

È un ciclo che rappresenta le fasi dell’adozione di una nuova tecnologia.

1. Technology Trigger: una tecnologia nuova emerge. Arrivano le prime prove e i

media cominciano a fare pubblicità e hype mediatico. In questo stadio non ci sono

prodotti esistenti usabili e nessuno ha mai usato la tecnologia a scopi commerciali.

2. Peak of Inflated Expectations: le prime pubblicità producono storie di

successo e alimentano delle aspettative irrealistiche.

3. Trough of Disillusionment: arrivano i primi fallimenti nelle implementazioni.

L’interesse cala e la tecnologia sembra sopravvalutata.

4. Slope of Enlightenment: si comincia a capire come usare concretamente la

tecnologia, ed emergono prodotti migliori che usano queste tecnologie.

5. Plateau of Productivity, c’è un’adozione di massa della tecnologia visto che è

ben delineato il suo campo di utilizzo. La tecnologia continua a crescere nella

propria nicchia di mercato.

QUANDO USARE E NON USARE I MICROSERVIZI?

Quando non usarli?

Quando i domini sono poco chiari e in evoluzione rapida, dato che è difficile

 stabilire i confini tra i microservizi e i requisiti cambiano spesso.

Quando ci sono dei team piccoli, perché il costo di gestione è più alto dei

 benefici; essendoci meno sviluppatori si fa più fatica a gestire i servizi

distribuiti.

56 Quando il software deve essere utilizzato dai clienti che potrebbero avere

 problemi nel gestire i microservizi. Se il controllo del sistema rimane in mano

all’azienda si può gestire la complessità.

Quando usarli?

Quando più team devono lavorare contemporaneamente sullo stesso progetto

 i microservizi servono per non intralciarsi

Quando bisogna creare delle applicazioni SaaS (software as a service), che

 sono dei servizi disponibili online sempre attivi. Questo perché i microservizi

permettono aggiornamenti frequenti e indipendenti. (netflix)

CREAZIONE DI UN MICROSERVIZIO

Un servizio è una parte autonoma del software, che può essere sviluppata,

distribuita e aggiornata in modo indipendente. Si occupa di una specifica

funzionalità (es. gestione degli studenti).

Caratteristiche principali:

Espone un’API per farsi chiamare da altri (client o altri servizi).

 Ha due tipi di operazioni:

 Comandi: modificano dati (es. createStudent()).

o Interrogazioni: leggono dati (es. findStudentById()).

o

Può pubblicare eventi, notificando che qualcosa è cambiato (es. “studente

 creato”).

Le API nascondono l’implementazione interna → non si può aggirare il

 servizio come si farebbe in un monolite.

Usa spesso una architettura esagonale:

 Gli adapter fanno da ponte tra l’esterno (API, eventi) e la logica di

o business interna.

La logica può generare eventi, poi pubblicati tramite altri adapter.

o

Quando si modella un microservizio bisogna seguire 3 passaggi:

1. Identificare le operazioni di sistema, capire cosa dovrà fare l’applicazione.

Capire quali sono le richieste che quel microservizio deve gestire, i comandi, le

query e le capacità del microservizio verso l’esterno.

Le operazioni sono comandi o interrogazioni; per definirle, si parte dai requisiti e si

costruisce un modello astratto del dominio (senza pensare ancora a tecnologia o

codice).

2. Stabilire i boundaries dei servizi, ovvero decidere cosa sta dentro ogni

microservizio. Si possono usare diverse strategie:

Suddividere in base alle funzioni di business (es. Servizio Studenti, Servizio

 Esami…).

Usare il Domain-Driven Design (DDD): si modellano i servizi attorno a concetti

 chiave del dominio.

Usare altri approcci, l’importante è avere confini chiari.



3. Definire le API e le collaborazioni, una volta capiti i comandi/interrogazioni e i

confini dei servizi si definiscono le API pubbliche (REST, gRPC, eventi, ecc.); e si

descrive come i servizi parlano tra loro (es. ExamService chiama StudentService per

sapere se uno studente è iscritto?).

57

1. IDENTIFICAZIONE DELLE OPERAZIONI DI SISTEMA

Si crea un modello ad alto livello e vengono definite le operazioni.

Per identificare le operazioni di sistema si crea prima un modello ad alto livello

usando delle tecniche come intercettare i nomi utilizzati e gli scenari descritti dagli

Esempio:

esperti di dominio durante l’analisi dei requisiti.

il docente crea un appello di esame

 attore docente

 

comando createExam(prof id, corso id, date, room…)

 

precondizioni il professore esiste, il corso esiste, il prof può creare un

 

esame per quel corso, c’è una data

postcondizioni l’appello è creato nel sistema, gli studenti possono

 

prenotarsi

2. DEFINIZIONE DEI BOUNDARIES

I boundaries (confini) servono per stabilire cosa fa ogni microservizio e quali dati

gestisce, così che i vari servizi siano ben separati (basso coupling). Bisogna

rispettare 3 principi:

Information hiding, concetto proprio della programmazione a oggetti, e consiste

nel nascondere quanti più dettagli possibili all’interno della classe/microservizio.

- Questo incrementa la velocità di sviluppo dato che gli sviluppatori possono

lavorare in parallelo.

- Ogni servizio è isolato dall’esterno, chiaro e comprensibile da solo .

- Maggiore flessibilità, ogni servizio può essere modificabile e riutilizzabile

senza impattare gli altri.

Cohesion, il codice che cambia insieme deve stare insieme, se viene fatta

un’operazione su un microservizio e una porzione di codice viene cambiata, e se

questo fa si che anche un’altra parte di codice deve essere modificata allora queste

parti di codice devono stare nello stesso microservizio perché sono dipendenti.

Coupling, accoppiamento, se i microservizi sono debolmente accoppiati (loosely

coupled) allora un cambio di un microservizio non ha impatto sugli altri; se sono

fortemente accoppiati (tighly coupled) si viola l’architettura dei microservizi.

Cohesion e coupling sono correlati; la coesione si applica a relazioni tra cose che

sono all’interno dello stesso microservizio, il coupling si occupa di relazioni fuori il

servizio, per microservizi diversi.

Si vuole ottenere un’alta cohesion e un basso coupling. Ci sono diversi tipi di

coupling:

1. Domain coupling, un servizio ha bisogno di chiamare un altro perché serve

(GestoreOrdini chiama GestorePagamenti per far pagare

una sua funzionalità.

un ordine). Questo tipo di interazione è necessaria perché ogni microservizio

ha bisogno di comunicare con gli altri per effttuare delle operazioni. Ma

bisogna li