Volevo scrivere un articolo sul tema dell'architettura a microservizi da tempo, ma due aspetti mi hanno sempre fermato: più mi immergevo nell'argomento, più mi sembrava che ciò che sapevo fosse ovvio, e ciò che non sapevo dovesse ancora essere studiato. D'altro canto, ritengo che ci sia già qualcosa di cui discutere con un pubblico più ampio. Quindi, opinioni alternative sono benvenute.
La legge di Conway e il legame tra business, organizzazione e sistema informativo
Mi permetto di citare ancora una volta:
«Qualsiasi organizzazione che progetti un sistema (in senso ampio) otterrà un design la cui struttura copia la struttura dei team in quella organizzazione»
— Melvyn Conway, 1967
A mio avviso, questa legge si riferisce maggiormente alla ragionevolezza dell'organizzazione aziendale, piuttosto che direttamente al sistema informativo. Lo spiego con un esempio. Supponiamo di avere un'opportunità di business sufficientemente stabile con un ciclo di vita così lungo da giustificare l'organizzazione di un'impresa (non è un refuso, ma mi piace molto questo termine che ho rubato). È naturale che il sistema di supporto di questo business sarà organizzativo e processualmente adeguato a questo business.
Orientamento al business dei sistemi informativi
Lo spiego con un esempio. Supponiamo di avere un'opportunità di business legata all'organizzazione di un'attività di vendita di pizze. Nella versione V1 (chiamiamola pre-informativa), l'azienda era composta da una pizzeria, una cassa e un servizio di consegna. Questa versione è durata a lungo in un contesto di bassa variabilità dell'ambiente circostante. Poi è arrivata la versione 2 — più avanzata e capace di utilizzare un sistema informativo come base per un business con architettura monolitica. E qui, a mio avviso, si presenta una terribile ingiustizia nei confronti dei monoliti — si sostiene che l'architettura monolitica non corrisponda al modello di dominio del business. Se fosse così, il sistema non potrebbe funzionare affatto - in contraddizione con la stessa legge di Conway e il buon senso. No, l'architettura monolitica corrisponde perfettamente al modello di business in questa fase dello sviluppo aziendale — intendo chiaramente la fase in cui il sistema è già stato creato e messo in esercizio. È un fatto assolutamente notevole che, indipendentemente dall'approccio architetturale, sia l'architettura orientata ai servizi di versione 3 che l'architettura a microservizi di versione N funzioneranno altrettanto bene. Dove sta il trucco?
Tutto scorre, tutto cambia, o i microservizi sono un mezzo per combattere la complessità?
Prima di procedere, consideriamo alcuni fraintendimenti riguardo l'architettura a microservizi.
I sostenitori dell'uso dell'approccio a microservizi affermano spesso che spezzare un monolite in microservizi semplifica l'approccio allo sviluppo grazie alla riduzione della base di codice di servizi singoli. A mio avviso, questa affermazione è completamente insensata. Sul serio, l'interazione ovvia all'interno di un monolite 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 a microservizi è ben più comune. La complessità non svanisce, semplicemente si trasferisce da singoli moduli a interfacce (che si tratti di bus di dati, RPC, API e altri protocolli) e sistemi di orchestrazione. Ed è questo—è complicato!
Il vantaggio dell'uso di uno stack eterogeneo è altrettanto dubbio. Non discuterò che sia possibile, ma nella realtà è raro (per anticipare — dovrebbe avere luogo, ma piuttosto come conseguenza, piuttosto che come vantaggio).
Il ciclo di vita del prodotto e il ciclo di vita del servizio
Dai un'altra occhiata al diagramma sopra. Non ho segnato per caso il ciclo di vita decrescente di ogni singola versione del business - nelle attuali condizioni, proprio l'accelerazione del passaggio tra le versioni è determinante per il suo successo. Il successo del prodotto è determinato dalla velocità di verifica delle ipotesi di business in esso.. E qui, a mio avviso, è sepolto il vantaggio chiave dell'architettura a microservizi. Ma andiamo con ordine.
Passiamo al prossimo livello dell'evoluzione dei sistemi informativi: l'architettura orientata ai servizi SOA. Quindi, a un certo punto, abbiamo identificato nel nostro prodotto servizi a lungo termine — longevi nel senso che durante il passaggio tra le versioni del prodotto c'è la possibilità che il ciclo di vita del servizio sia più lungo del ciclo di vita della versione del prodotto successiva. Sarebbe logico non modificarli affatto — per noi è importante proprio la velocità di transizione alla versione successiva. Purtroppo, siamo costretti a fare modifiche costanti ai servizi — e qui abbiamo tutto ciò che serve, dalle pratiche DevOps, alla containerizzazione, e altro ancora — tutto ciò che ci viene in mente. Ma non stiamo ancora parlando di microservizi!
Microservizi come mezzo per combattere la complessità… gestione della configurazione
E qui possiamo finalmente passare al ruolo definitorio dei microservizi: è un approccio che semplifica la gestione della configurazione del prodotto. In altre parole, la funzione di ogni microservizio descrive precisamente una funzione di business all'interno del prodotto secondo il modello di dominio — e queste sono già cose che non vivono in una versione a breve termine, ma in un'opportunità di business a lungo termine. E il passaggio alla versione successiva del prodotto avviene in maniera praticamente impercettibile: si modifica / si aggiunge un microservizio, o magari semplicemente lo schema delle loro interazioni, e ci si ritrova improvvisamente nel futuro, lasciando dietro di sé concorrenti piangenti, che continuano a saltare tra le versioni dei loro monoliti. Ora immaginate di avere una quantità sufficiente di microservizi con interfacce e opportunità di business già definite. E voi arrivate e costruite la struttura del vostro prodotto a partire da microservizi pronti — semplicemente disegnando un diagramma, per esempio. Congratulazioni: avete creato una piattaforma e ora potete generare affari.
Conclusioni
- L'architettura del sistema deve essere definita dal ciclo di vita dei componenti che la compongono. Se un componente vive all'interno della versione del prodotto, non ha senso aumentare la complessità del sistema utilizzando l'approccio ai microservizi.
- L'architettura microservizi deve basarsi sul modello di dominio — per il semplice motivo che l'opportunità di business è l'area più durevole.
- Le pratiche di consegna (DevOps) e orchestrazione hanno un'importanza fondamentale per l'architettura a microservizi, poiché l'aumento della velocità di cambiamento dei componenti richiede elevate prestazioni e qualità della consegna.
Fonte: habr.com
