In che modo il passaggio ai microservizi crea un problema di runtime?

Il seguente commentatore scrive :

I microservizi spostano la disfunzione organizzativa da un problema di compilazione a un problema di runtime.

Questo commentatore si espande sul problema dicendo:

Funzionalità non bug. Problema di runtime => prod problemi => feedback più forte e più rapido sulla disfunzione per i responsabili

Ora lo capisco con i microservizi :

• aumentare potenzialmente la latenza del through-put, che è un problema di produzione e di runtime.
• aumentare il numero di "interfacce di rete" nel codice in cui potrebbero esserci potenziali errori di runtime dell'analisi.
• può potenzialmente fare distribuzioni blu-verdi. Questi potrebbero essere ostacolati da disallineamenti dell'interfaccia (vedi interfacce di rete). Ma se le distribuzioni blu-verdi funzionano, è più una preoccupazione di runtime.

La mia domanda è: cosa significa che il passaggio ai microservizi crea un problema di runtime?

Ho un problema. Usiamo i microservizi! Ora ho 13 problemi distribuiti.

Dividere il sistema in componenti incapsulati, coesivi e disaccoppiati è una buona idea. Ti consente di affrontare diversi problemi separatamente. Ma puoi farlo perfettamente in una distribuzione monolitica (vedi Fowler: Microservice Premium ). Dopo tutto, questo è ciò che OOP ha insegnato per molti decenni! Se decidi di trasformare i tuoi componenti in microservizi, non otterrai alcun vantaggio architettonico. Ottieni una certa flessibilità per quanto riguarda la scelta della tecnologia e possibilmente (ma non necessariamente!) Una certa scalabilità. Ma ti viene garantito un certo mal di testa derivante da (a) la natura distribuita del sistema e (b) la comunicazione tra i componenti. Scegliere i microservizi significa che hai altri problemi che sono così urgenti che sei disposto a usare i microservizi nonostante questi problemi.

Se non si è in grado di progettare un monolite suddiviso in modo chiaro in componenti, non sarà nemmeno possibile progettare un sistema di microservizi. In una base di codice monolitico, il dolore sarà abbastanza evidente. Idealmente, il codice semplicemente non si compila se è orribilmente rotto. Ma con i microservizi, ogni servizio può essere sviluppato separatamente, possibilmente anche in lingue diverse. Eventuali problemi nell'interazione dei componenti non diventeranno evidenti fino a quando non si integreranno i componenti e a quel punto è già troppo tardi per riparare l'architettura generale.

La prima fonte di bug è la mancata corrispondenza dell'interfaccia. Potrebbero esserci errori eclatanti come un parametro mancante o esempi più sottili come dimenticare di controllare un codice di errore o dimenticare di controllare un prerequisito prima di chiamare un metodo. La digitazione statica rileva tali problemi il più presto possibile: nell'IDE e nel compilatore, prima che il codice venga mai eseguito. I sistemi dinamici non hanno questo lusso. Non esploderà finché non verrà eseguito quel codice difettoso.

Le implicazioni per i microservizi sono terrificanti. I microservizi sono intrinsecamente dinamici. Se non si passa a un linguaggio di descrizione formale del servizio, non è possibile verificare alcun tipo di correttezza dell'utilizzo dell'interfaccia. devi testare, testare, testare! Ma i test sono costosi e di solito non esaustivi, il che lascia la possibilità che possano sussistere problemi nella produzione. Quando diventerà evidente questo problema? Solo quando viene intrapreso quel percorso difettoso, in fase di esecuzione, in produzione. L'idea che i problemi con i prodotti produrrebbe un feedback più rapido èesilarante pericolosamente sbagliato, a meno che tu non sia divertito dalla possibilità di perdita di dati.

Il primo tweet è stato il mio, quindi lo espanderò:

Supponiamo di avere 100 sviluppatori che lavorano su un'applicazione monolitica. Sono troppe le persone per comunicare in modo efficace tra loro, quindi la società deve lavorare sodo per dividerle in team più piccoli e creare buoni modelli di comunicazione tra di loro. Quando l'organizzazione è "disfunzionale", i team probabilmente non parlano tra loro, non sono allineati a un obiettivo più ampio, non sono d'accordo su priorità ecc. - Di conseguenza, impiegano un'eternità a spedire qualcosa. È un "problema di compilazione", nel senso che la disfunzione è evidente prima della produzione del software. Il progetto è probabilmente una marcia della morte o non verrà mai spedito ("compilare").

Penso che molte persone siano attratte dai micro servizi e si stiano muovendo verso di loro, non a causa dei vantaggi tecnici / architettonici intrinseci, ma perché consente loro di ignorare la disfunzione organizzativa. Invece di cercare di allineare 100 sviluppatori, sperano di poter avere piccoli team che lavorano in silos, ognuno focalizzato sul proprio piccolo micro servizio. Se fai parte di un'organizzazione così disfunzionale, questo è così attraente: ti dà un permesso molto maggiore per evitare le persone che non ti piacciono, per non comunicare.

Sfortunatamente diventa un "problema di runtime" perché una volta che il software è in produzione, una buona comunicazione diventa altrettanto importante. I problemi con l'organizzazione - i team e il modo in cui sono allineati e comunicano - si manifestano in "fase di esecuzione".

Il punto del mio tweet era: se quello che hai è un problema di persone , una nuova architettura non ti aiuterà. Ritarderà semplicemente gli effetti del problema. Penso che l'attrattiva dei micro-servizi per molte persone sia la speranza che risolva magicamente questi problemi.

La mia domanda è: cosa significa che il passaggio ai microservizi crea un problema di runtime?

Cioè non è che cosa quei tweets hanno da dire! Non dicono nulla sul passaggio ai microservizi , né dicono nulla sulla creazione di problemi. Dicono solo qualcosa sui problemi di spostamento .

E mettono una limitazione contestuale alle loro affermazioni, vale a dire che la tua organizzazione è disfunzionale.

Quindi, ciò che sostanzialmente dice il primo tweet sono due cose:

• "se la tua organizzazione non è in grado di progettare sistemi complessi ora senza microservizi, non sarà magicamente in grado di progettare sistemi complessi con microservizi" e
• "i problemi causati da quella incapacità che ora si presentano durante la fase di compilazione, cioè durante lo sviluppo, verranno mostrati durante il runtime, cioè durante la produzione" (tecnicamente, potrebbero anche presentarsi durante i test, ma ricorda che la citazione si limita alle organizzazioni disfunzionali, che probabilmente hanno un regime di sperimentazione sub-standard)

Il secondo tweet afferma che il fatto che i problemi si manifestino solo nella produzione, cioè dove i clienti li vedono, è una caratteristica, non un bug, perché quando i clienti si lamentano, tende a essere ascoltato in luoghi diversi rispetto a quando si rompe una build, vale a dire in luoghi che sono in grado di fare qualcosa per la disfunzione organizzativa (es. gestione di alto livello). Poiché la disfunzione organizzativa di solito è un fallimento della gestione di alto livello, ciò significa che i clienti insoddisfatti riflettono male su coloro che sono alla fine responsabili di tale insoddisfazione, mentre la bassa qualità del codice causata da errori di gestione di livello superiore di solito si riflette solo sugli sviluppatori, che sono , tuttavia, non è in colpa e incapace di fare qualcosa al riguardo.

Quindi, il primo tweet afferma che i microservizi spostano i problemi causati da una cattiva gestione dal momento della compilazione, in cui solo gli sviluppatori li vedono, in fase di esecuzione, dove i clienti li vedono. Il secondo tweet dice che è una buona cosa, perché poi i problemi fanno male a coloro che ne sono responsabili.

Crea un problema di runtime invece di un problema di compilazione .

Un'app monolitica è difficile e costosa da compilare. Ma una volta compilato puoi essere ragionevolmente sicuro che non esistono incompatibilità estremamente stupide tra i componenti, perché il sistema di tipi può catturarli. Lo stesso errore in un sistema di microservivi potrebbe non apparire fino a quando due componenti specifici non interagiranno effettivamente in un modo specifico.

Sia nei sistemi monolitici che nei microservizi è necessario definire le interfacce tra i sottosistemi. Le interfacce dovrebbero essere ben progettate, ben documentate e il più stabili possibile. Questo è lo stesso di OOP.

Se la tua organizzazione non è in grado di farlo, anche i microservizi non risolveranno il problema. Nei microservizi hai interfacce Web pubbliche. Quindi devi anche spendere più sforzi nella progettazione dell'interfaccia.

Se l'interfaccia non è progettata correttamente, otterrai due tipi di problemi di runtime:

1. Se l'interfaccia non viene utilizzata correttamente, verrà visualizzato un errore in fase di esecuzione, non in fase di compilazione.
2. La chiamata a un'interfaccia Web è piuttosto lenta, quindi è possibile ottenere problemi di prestazioni.

Penso che produrre problemi di runtime non sia il modo giusto di comunicare i problemi organizzativi a coloro che sono responsabili.