Volevo scrivere un articolo sulla microservizi da tempo, ma sono sempre stato fermato da due aspetti: più mi immergevo nell'argomento, più mi sembrava che ciò che sapevo fosse ovvio, mentre ciò che non sapevo richiedesse ancora studio. D'altra parte, ritengo che ci sia già molto di cui discutere con un pubblico più ampio. Pertanto, opinioni alternative sono benvenute.
La legge di Conway e il legame tra affari, organizzazione e sistema informativo
Permettetemi di citare ancora una volta:
«Qualsiasi organizzazione che progetti un sistema (in senso ampio) otterrà un design la cui struttura copia la struttura delle squadre in quell'organizzazione»
— Melvyn Conway, 1967
A mio avviso, questa legge si riferisce più alla ragionevolezza di organizzare un'impresa piuttosto che direttamente a un sistema informatico. Spiegherò con un esempio. Supponiamo di avere un'opportunità imprenditoriale abbastanza stabile con un ciclo di vita così lungo da giustificare l'organizzazione di un'iniziativa (non è un errore di battitura, ma mi piace molto questo termine che ho ripreso). È naturale che il sistema a supporto di questo business sia organizzativamente e processualmente in linea con esso.
Orientamento al business dei sistemi informatici
Spiegherò con un esempio. Supponiamo di avere un'opportunità imprenditoriale per organizzare un'attività di vendita di pizze. Nella versione V1 (chiamiamola pre-informativa), l'azienda era una pizzeria, una cassa e un servizio di consegna. Questa versione è durata a lungo in condizioni di bassa variabilità del mondo circostante. Poi è arrivata la versione 2 — più avanzata e in grado di utilizzare un sistema informatico come base per un business con architettura monolitica. E qui, a mio avviso, si presenta una vera e propria ingiustizia nei confronti dei monoliti — un'architettura monolitica apparentemente non corrisponde al modello di dominio aziendale. Se così fosse, il sistema non potrebbe funzionare affatto - in contraddizione con la stessa legge di Conway e il buon senso. No, l'architettura monolitica si adatta perfettamente al modello di business in questa fase di sviluppo dell'azienda — e intendo ovviamente la fase in cui il sistema è già stato creato e messo in produzione. Il fatto sorprendente è che, indipendentemente dall'approccio architettonico, sia l'architettura orientata ai servizi versione 3 sia l'architettura a microservizi versione N funzioneranno altrettanto bene. Qual è il trucco?
Tutto scorre, tutto cambia o i microservizi sono un mezzo per combattere la complessità?
Prima di continuare, esaminiamo alcuni dei fraintendimenti riguardanti l'architettura a microservizi.
I sostenitori dell'approccio ai microservizi affermano spesso che suddividere un monolite in microservizi semplifica lo sviluppo riducendo la base di codice di singoli servizi. A mio avviso, questa affermazione è completamente insensata. Sul serio, l'interazione evidente all'interno di un monolito e di codice omogeneo sembra complessa? Se fosse davvero così, tutti i progetti sarebbero inizialmente costruiti come microservizi, mentre la pratica dimostra che la migrazione da un monolite ai microservizi è molto più comune. La complessità non scompare, semplicemente si sposta da singoli moduli a interfacce (che siano bus dei dati, RPC, API e altri protocolli) e sistemi di orchestrazione. E questo è difficile!
Il vantaggio di utilizzare uno stack eterogeneo è anch'esso discutibile. Non dirò che ciò sia impossibile, ma nella realtà è raro (A proposito, dovrebbe avvenire – ma più come conseguenza che come vantaggio).
Il ciclo di vita del prodotto e il ciclo di vita del servizio
Dai un'occhiata di nuovo al diagramma sopra. Non ho segnato casualmente la diminuzione del ciclo di vita di una singola versione aziendale: nelle condizioni moderne, è proprio l'accelerazione del passaggio dell'azienda tra le versioni a determinare il suo successo. Il successo del prodotto è definito dalla velocità con cui vengono verificate le ipotesi aziendali al suo interno.. E qui, a mio avviso, si trova il principale vantaggio dell'architettura a microservizi. Ma andiamo con ordine.
Passiamo al prossimo stadio dell'evoluzione dei sistemi informatici: l'architettura orientata ai servizi SOA. Quindi, a un certo punto, abbiamo identificato nel nostro prodotto servizi a lunga durata — servizi che, nel passaggio tra le versioni del prodotto, hanno la possibilità di avere un ciclo di vita più lungo rispetto al ciclo di vita di una nuova versione del prodotto. Sarebbe logico non modificarli affatto: ciò che ci interessa è proprio la velocità nel passare alla versione successiva. È proprio questo il nostro obiettivo.. Ma purtroppo, siamo costretti a apportare modifiche costanti ai servizi — e qui ci viene in aiuto qualsiasi pratica, sia il DevOps che la containerizzazione e altro — qualsiasi cosa venga in mente. Ma questo non è ancora microservizio!
I microservizi come strumento per gestire la complessità… della gestione della configurazione
E qui possiamo finalmente fare riferimento al ruolo chiave dei microservizi: si tratta di un approccio che semplifica la gestione della configurazione del prodotto. Più precisamente, la funzione di ciascun microservizio descrive una specifica funzione aziendale all'interno del prodotto secondo il modello di dominio — e queste sono cose che non abitano in una versione a breve termine, ma in un'opportunità di business a lungo termine. Il passaggio alla successiva versione del prodotto avviene in maniera quasi impercettibile: si modifica o si aggiunge un microservizio, o forse semplicemente si riorganizza il modo in cui interagiscono e ci si ritrova improvvisamente nel futuro, lasciando indietro i concorrenti che continuano a saltare tra le versioni dei loro monoliti. Ora immaginate di avere un numero sufficiente di microservizi con interfacce e opportunità aziendali predefinite. Arrivate e costruite la struttura del vostro prodotto utilizzando i microservizi già pronti — semplicemente tracciando un diagramma, per esempio. Congratulazioni: avete creato una piattaforma — e ora potete costruire il vostro business. Sogni, sogni.
Conclusioni
- L'architettura del sistema deve essere determinata dal ciclo di vita dei componenti che ne fanno parte. Se un componente è legato a una versione del prodotto, non ha senso aumentare la complessità del sistema adottando un approccio a microservizi.
- L'architettura a microservizi deve basarsi sul modello di dominio, poiché l'opportunità commerciale è l'area più duratura.
- Le pratiche di consegna (pratiche DevOps) e l'orchestrazione rivestono un'importanza fondamentale per l'architettura a microservizi, in quanto l'aumento della velocità di cambiamento dei componenti impone requisiti elevati sulla rapidità e qualità della consegna.
Fonte: habr.com
