Quando evitare i Microservizi

Quando evitare i Microservizi. L’architettura a microservizi ha lo scopo di semplificare e accelerare lo sviluppo, ma solo quando è realizzata correttamente.
Uno degli obiettivi principali dell’architettura a microservizi è accelerare lo sviluppo migliorando l’esperienza dello sviluppatore. Ad esempio, immaginiamo che siate un membro del team di gestione delle consegne, responsabile dello sviluppo del sottodominio di gestione delle consegne dell’applicazione FTGO (food-to-go delivery application). Il vostro obiettivo è sviluppare il miglior algoritmo di pianificazione dei corrieri, in modo che la vostra azienda possa massimizzare la soddisfazione dei consumatori e battere la concorrenza in un mercato molto competitivo. Qualsiasi cosa che rallenti lo sviluppo potrebbe mettere a rischio l’esistenza stessa dell’azienda. La sfida, ovviamente, è che la pianificazione delle consegne è un sottodominio complesso. Non esiste una risposta giusta e l’unico modo per fare progressi è quello di iterare e sperimentare costantemente. Per farlo, è necessario essere in grado di apportare frequentemente modifiche, distribuirle in produzione e ottenere un feedback.

In questo articolo descriviamo perché l’utilizzo dell’architettura a microservizi può accelerare la consegna del software. Verranno illustrati due comuni architetture che possono avere l’effetto opposto e rallentare lo sviluppo. Descriveremo anche come non sia sufficiente adottare semplicemente i microservizi. È necessario adottare anche le giuste pratiche di sviluppo e la struttura del team.

Iniziamo a capire perché l’architettura monolitica non è sempre la scelta migliore.

Un’architettura monolitica a volte può rallentare il lavoro: Quando evitare i Microservizi.

Non c’è nulla di intrinsecamente sbagliato nell’architettura monolitica. Ma per un’azienda come FTGO, che ha molti team che lavorano su un’applicazione molto grande utilizzando pratiche come DevOps e la distribuzione continua, un’architettura monolitica può essere un ostacolo alla rapidità dello sviluppo. In particolare, può essere difficile risolvere le questioni interne, che possono causare vari problemi, tra cui:

• Mancanza di autonomia del team – L’autonomia del team può risentirne perché i team devono regolarmente coordinare le loro modifiche.
• Pipeline di distribuzione lenta – L’implementazione di una pipeline di distribuzione veloce, in grado di supportare un alto tasso di push/PR (ad esempio, almeno una volta per sviluppatore al giorno) senza diventare un collo di bottiglia, può essere difficile, se non impossibile, a causa delle dimensioni e della complessità dell’applicazione.
• Difficoltà a cambiare lo stack tecnologico – La modifica o l’aggiornamento dello stack tecnologico dell’applicazione è particolarmente difficile perché richiede che tutti i team si aggiornino contemporaneamente.

Questi problemi sono particolarmente gravi se si sta sviluppando un sottodominio, come la gestione delle consegne, che richiede frequenti sperimentazioni.

L’uso dei microservizi dovrebbe accelerare lo sviluppo.
Spesso ha senso, quindi, implementare sottodomini, come la gestione delle consegne, che necessitano di una rapida iterazione, come servizi separati.

Per il team di Delivery Management, i vantaggi di avere un Delivery Service sono molteplici, tra cui:

• Maggiore autonomia del team – il team di Delivery Management può sviluppare, costruire, testare e distribuire il servizio indipendentemente da ciò che fanno gli altri team.
• Pipeline di distribuzione più veloce – il Delivery Service è significativamente più piccolo dell’applicazione complessiva e il tasso di commit è molto più basso, quindi è improbabile che sia un collo di bottiglia.
• Gestione più semplice dello stack tecnologico – il team di Delivery Management può prendere decisioni sulle tecnologie, ad esempio sulle versioni delle librerie, senza doversi coordinare con il resto dell’organizzazione.

Un servizio di consegna autonomo consente al team di gestione della consegna di concentrarsi sull’algoritmo di pianificazione dei corrieri e di eseguire frequentemente esperimenti per migliorarlo. Il team avrà meno carico cognitivo, più autonomia e riceverà un feedback più rapido dalla produzione. O almeno dovrebbe, ma ….

Ma è necessaria un’architettura di microservizi ben progettata: Quando evitare i Microservizi.
Purtroppo, l’uso di “un mucchio di servizi”, che superficialmente assomiglia a un’architettura di microservizi, non garantisce un’accelerazione dello sviluppo. L’architettura deve essere ben progettata. Ci sono due comuni tipi di architettura che possono ostacolare lo sviluppo:

• Servizi strettamente accoppiati
• Architettura a grana troppo fine

L’accoppiamento stretto in fase di progettazione uccide la produttività
Un errore comune è quello di ignorare il concetto essenziale di accoppiamento in fase di progettazione e creare servizi strettamente accoppiati tra loro. Se, ad esempio, il servizio di consegna è strettamente accoppiato ad altri servizi, la produttività del team di gestione della consegna ne risentirà, poiché dovrà spesso coordinarsi con altri team. O il team di gestione delle consegne sarà costantemente bloccato in attesa che gli altri team apportino le modifiche necessarie ai loro servizi. Oppure cambierà frequentemente il proprio servizio per supportare le modifiche degli altri servizi.

Analizzare i commit Git per rilevare l’accoppiamento stretto in fase di progettazione
Un modo per individuare l’accoppiamento stretto tra progettazione e tempo è analizzare i commit di Git per identificare i servizi che cambiano frequentemente in modo concatenato. Se si vedono regolarmente problemi su JIRA (ad esempio) che sono implementati da commit per lo stesso gruppo di servizi, questo è un indice di stretto accoppiamento in fase di progettazione. La documentazione di CodeScene, ad esempio, descrive in modo più dettagliato come rilevare l’accoppiamento in fase di progettazione (quello che viene chiamato accoppiamento delle modifiche).

Riformulare per eliminare l’accoppiamento stretto in fase di progettazione
Immaginiamo, ad esempio, che il Servizio consegne e il Servizio ordini, di proprietà di un team diverso, cambino regolarmente insieme. Una soluzione potrebbe essere quella di unire i due servizi, il che semplifica lo sviluppo anche se potrebbe non risolvere il problema dell’autonomia del team.

Un’altra opzione sarebbe quella di riassegnare le responsabilità e ridefinire le API per ridurre il grado di accoppiamento. Ad esempio, in QConPlus 2021: Burrito da asporto e minimizzazione dell’accoppiamento in tempo di progettazione in un’architettura a microservizi, viene descritto come lo spostamento del calcolo del subtotale di un ordine dal servizio ordini al servizio ristorante abbia ridotto l’accoppiamento in tempo di progettazione tra i due servizi.

Un’architettura a grana troppo fine può anche rallentare il lavoro: Quando evitare i Microservizi.
L’accoppiamento stretto in fase di progettazione non è l’unico problema architettonico. Un altro problema di un’architettura a grana troppo fine è l’anti-pattern “Più siamo meglio è”. Questo perché più un’architettura è a grana fine, maggiore è la complessità delle interazioni tra i servizi. Se fatta bene, può semplificare lo sviluppo, come ho descritto prima, perché i servizi sono più semplici. Ma se si esagera, invece di potersi concentrare sulla logica di business, ci si ritrova a spendere troppo per scrivere logica di collaborazione.

Invece di potersi concentrare sulla logica di business, si dovranno implementare costantemente i pattern di collaborazione con i servizi: Saga, API Composition e CQRS.

Un servizio al massimo per team è un obiettivo ragionevole
Ma una regola approssimativa è che un servizio per team è un obiettivo ragionevole. E che l’architettura, fin troppo comune, di un servizio per sviluppatore è probabilmente troppo fine.

Analizzare i commit Git per rilevare l’accoppiamento stretto in fase di progettazione
Un modo per individuare l’accoppiamento stretto tra progettazione e tempo è analizzare i commit di Git per identificare i servizi che cambiano frequentemente in modo concatenato. Se si vedono regolarmente problemi su JIRA (ad esempio) che sono implementati da commit per lo stesso gruppo di servizi, questo è un indice di stretto accoppiamento in fase di progettazione. La documentazione di CodeScene, ad esempio, descrive in modo più dettagliato come rilevare l’accoppiamento in fase di progettazione (quello che viene chiamato accoppiamento delle modifiche).

Riformulare per eliminare l’accoppiamento stretto in fase di progettazione: Quando evitare i Microservizi.
Immaginiamo, ad esempio, che il Servizio consegne e il Servizio ordini, di proprietà di un team diverso, cambino regolarmente insieme. Una soluzione potrebbe essere quella di unire i due servizi, il che semplifica lo sviluppo anche se potrebbe non risolvere il problema dell’autonomia del team.

Progettare una migliore architettura di microservizi utilizzando Assemblage
Progettare una migliore architettura di microservizi è difficile e comporta numerosi compromessi. Un buon approccio è quello di utilizzare il processo di definizione dell’architettura Assemblage, che utilizza le forze dell’energia oscura e della materia oscura per dare forma all’architettura.

È necessario anche il resto del triangolo del successo
La semplice adozione dell’architettura a microservizi non è sufficiente per accelerare lo sviluppo. È necessario adottare anche gli altri due elementi del triangolo del successo: DevOps, come definito dal manuale DevOps, e una struttura organizzativa composta da piccoli team non accoppiati, come descritto da Team Topologies.

Ignorare questi due elementi è un anti-pattern comune nell’adozione dei microservizi.

L’architettura dei microservizi aiuta o ostacola lo sviluppo?
Ci sono un paio di modi per rispondere a questa domanda:

• Chiedere agli sviluppatori
• Raccogliere le metriche DORA

Sondare gli sviluppatori
Un buon modo per determinare se un’architettura a microservizi sta aiutando o ostacolando lo sviluppo è chiedere agli sviluppatori tramite un sondaggio. Ad esempio, il sondaggio DORA DevOps include domande come “Completare il proprio lavoro senza comunicare e coordinarsi con persone esterne al proprio team”, che è una caratteristica dei team ad alte prestazioni. Si possono anche porre domande sulla facilità di apportare modifiche e su quanto tempo viene dedicato alla logica di business rispetto alla logica di collaborazione.

Raccogliere le metriche DORA
È importante anche raccogliere le metriche DORA, compresi i tempi di esecuzione e la frequenza di distribuzione.

Il DORA DevOps Quick Check
Il DORA DevOps Quick Check è una semplice valutazione in cinque domande per valutare il livello di erogazione del software.

Migliorare le metriche DORA: Quando evitare i Microservizi.
Se si usano i microservizi, ma i tempi di consegna sono alti e la frequenza di distribuzione è bassa, è segno che qualcosa non va. Forse la consegna del software è rallentata dal tipo di architettura descritta prima. O forse ci sono problemi con il processo, come il mancato o cattivo utilizzo di DevOps definito dal manuale Devops. Oppure se ci sono problemi con la organizzazione, come ad esempio la presenza di gruppi di lavoro a sé stanti piuttosto che di un insieme di gruppi di lavoro liberamente accoppiati, come descritto da Team Topologies. Il sito web di DORA offre alcune valutazioni di follow-up che possono aiutare a identificare gli aspetti da migliorare.

Sintesi: Quando evitare i Microservizi.
Uno degli obiettivi principali dei microservizi è accelerare lo sviluppo.
Ma per raggiungere questo obiettivo è necessaria un’architettura ben progettata. In particolare, è necessario evitare:

• Servizi strettamente accoppiati in termini di design, altrimenti dovrete costantemente coordinarvi con altri team.
• Un’architettura a grana troppo fine, altrimenti si spenderà troppo tempo nella logica di collaborazione.

Infine è bene determinate se i microservizi stanno aiutando o ostacolando lo sviluppo facendo un sondaggio tra gli sviluppatori e raccogliendo le metriche DORA.

(fonte)

Innovaformazione, scuola informatica specialistica promuove la cultura dello sviluppo moderno e a microservizi. Nell’offerta formativa per le aziende trovate l’elenco corsi sui microservizi QUI.

INFO: info@innovaformazione.net – tel. 3471012275 (Dario Carrassi)