Era da molto tempo che volevo scrivere un articolo sul tema dell'architettura dei microservizi, ma due cose continuavano a fermarmi: più mi immergevo nell'argomento, più mi sembrava che quello che so fosse ovvio, mentre quello che non sapevo fosse ovvio. La conoscenza deve essere studiata e studiata. D'altra parte, penso che ci sia già qualcosa di cui discutere tra un vasto pubblico. Quindi sono ben accetti pareri alternativi.
La legge di Conway e il rapporto tra impresa, organizzazione e sistema informativo
Ancora una volta mi permetto di citare:
“Qualsiasi organizzazione che progetta un sistema (in senso lato) riceverà un progetto la cui struttura replica la struttura dei team di quell’organizzazione”.
– Melvyn Conway, 1967
A mio avviso, è più probabile che questa legge si riferisca alla fattibilità dell'organizzazione di un'impresa, piuttosto che direttamente al sistema informativo. Lasciatemi spiegare con un esempio. Diciamo che abbiamo un'opportunità di business abbastanza stabile con un ciclo di vita così lungo che ha senso organizzare un'impresa (non è un errore di battitura, ma mi piace molto questo termine che ho rubato). corrisponderà a livello organizzativo e processuale a questa attività.
Orientamento al business dei sistemi informativi
Lasciatemi spiegare con un esempio. Diciamo che esiste un'opportunità commerciale per organizzare un'attività che vende pizza. Nella versione V1 (chiamiamola pre-informazione), l'azienda era una pizzeria, un registratore di cassa e un servizio di consegna. Questa versione è stata longeva in condizioni di bassa variabilità ambientale. A sostituirlo è poi arrivata la versione 2, più avanzata e in grado di utilizzare al centro un sistema informativo per il business con un'architettura monolitica. E qui, secondo me, c'è semplicemente una terribile ingiustizia nei confronti dei monoliti - l'architettura presumibilmente monolitica non corrisponde al modello di business del dominio. Sì, se così fosse, il sistema non potrebbe funzionare affatto, in contraddizione con la stessa legge di Conway e con il buon senso. No, l'architettura monolitica è pienamente coerente con il modello di business in questa fase di sviluppo del business: intendo ovviamente la fase in cui il sistema è già stato creato e messo in funzione. È assolutamente meraviglioso che, indipendentemente dall’approccio architettonico, sia la versione 3 dell’architettura orientata ai servizi che la versione N dell’architettura dei microservizi funzioneranno ugualmente bene. Qual è il problema?
Tutto scorre, tutto cambia o i microservizi sono un mezzo per combattere la complessità?
Prima di continuare, esaminiamo alcune idee sbagliate sull'architettura dei microservizi.
I sostenitori dell’utilizzo di un approccio basato sui microservizi spesso sostengono che suddividere un monolite in microservizi semplifica l’approccio di sviluppo riducendo la base di codice dei singoli servizi. Secondo me questa affermazione è una totale assurdità. Scherzi a parte, l'ovvia interazione all'interno di un codice monolite ed omogeneo sembra complicata? Se così fosse, tutti i progetti verrebbero inizialmente realizzati come microservizi, mentre la pratica dimostra che la migrazione da monolite a microservizi è molto più comune. La complessità non scompare; si sposta semplicemente dai singoli moduli alle interfacce (che si tratti di bus dati, RPC, API e altri protocolli) e ai sistemi di orchestrazione. E questo è difficile!
Anche il vantaggio di utilizzare uno stack eterogeneo è discutibile. Non voglio sostenere che anche questo sia possibile, ma in realtà accade raramente (guardando avanti - questo dovrebbe accadere - ma piuttosto come una conseguenza che come un vantaggio).
Ciclo di vita del prodotto e ciclo di vita del servizio
Dai un'altra occhiata al diagramma sopra. Non è un caso che ho notato la diminuzione del ciclo di vita di una versione separata di un'azienda: nelle condizioni moderne, è l'accelerazione della transizione di un'azienda tra le versioni a essere decisiva per il suo successo. Il successo di un prodotto è determinato dalla velocità con cui vengono testate le ipotesi di business in esso contenute. E qui, a mio avviso, risiede il vantaggio principale dell’architettura a microservizi. Ma andiamo con ordine.
Passiamo alla fase successiva nell'evoluzione dei sistemi informativi: all'architettura orientata ai servizi della SOA. Quindi, ad un certo punto abbiamo evidenziato il nostro prodotto servizi di lunga durata - di lunga durata, nel senso che quando si passa da una versione all'altra di un prodotto, esiste la possibilità che il ciclo di vita del servizio sia più lungo del ciclo di vita della versione successiva del prodotto. Sarebbe logico non cambiarli affatto: noi Ciò che conta è la velocità di transizione alla versione successiva. Ma ahimè, siamo costretti ad apportare continue modifiche ai servizi - e qui tutto funziona per noi, pratiche DevOps, containerizzazione e così via - tutto ciò che ci viene in mente. Ma questi non sono ancora microservizi!
Microservizi come mezzo per combattere la complessità... gestione della configurazione
E qui possiamo finalmente passare al ruolo determinante dei microservizi: si tratta di un approccio che semplifica la gestione della configurazione del prodotto. Più in dettaglio, la funzione di ciascun microservizio descrive esattamente la funzione aziendale all'interno del prodotto in base al modello di dominio: e queste sono cose che vivono non in una versione di breve durata, ma in un'opportunità di business di lunga durata. E il passaggio alla versione successiva del prodotto avviene letteralmente inosservato: modifichi/aggiungi un microservizio, e forse solo lo schema della loro interazione, e all'improvviso ti ritrovi nel futuro, lasciando dietro di te concorrenti piangenti che continuano a saltare tra le versioni di i loro monoliti. Immaginiamo ora che esista un volume piuttosto elevato di microservizi con interfacce e funzionalità aziendali predefinite. E tu vieni e costruisci la struttura del tuo prodotto da microservizi già pronti, semplicemente disegnando un diagramma, ad esempio. Congratulazioni: hai una piattaforma e ora puoi attirare affari per te stesso. Sogni Sogni.
risultati
- L'architettura del sistema dovrebbe essere determinata dal ciclo di vita dei suoi componenti. Se un componente si trova all'interno di una versione del prodotto, non ha senso aumentare la complessità del sistema utilizzando un approccio a microservizi.
- L'architettura dei microservizi dovrebbe essere basata sul modello di dominio, perché l'opportunità di business è il dominio più longevo
- Le pratiche di consegna (pratiche DevOps) e l'orchestrazione sono tra le più importanti per l'architettura dei microservizi, poiché l'aumento del tasso di modifica dei componenti pone maggiori richieste sulla velocità e sulla qualità della consegna
Fonte: habr.com