In che modo passare ai microservizi crea un problema di runtime?

Ho un problema Usiamo Microservices! Ora ho 13 problemi distribuiti.

Dividere il sistema in componenti incapsulati, coesi e disaccoppiati è una buona idea. Ti consente di affrontare diversi problemi separatamente. Ma puoi farlo perfettamente in una distribuzione monolitica (vedi Fowler: Microservice Premium ). Dopotutto, questo è ciò che OOP ha insegnato per molti decenni! Se decidi di trasformare i tuoi componenti in microservizi, non ottieni alcun vantaggio architettonico. Ottieni una certa flessibilità per quanto riguarda la scelta della tecnologia e possibilmente (ma non necessariamente!) Una certa scalabilità. Ma ti è 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 così urgenti che sei disposto a utilizzare i microservizi nonostante questi problemi.

Se non si è in grado di progettare un monolite suddiviso in modo pulito in componenti, non sarà possibile progettare un sistema di microservizi. In una base di codice monolitica, il dolore sarà abbastanza ovvio. Idealmente, il codice semplicemente non verrà compilato 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 correggere l'architettura generale.

La fonte n. 1 di bug è la mancata corrispondenza dell'interfaccia. Potrebbero esserci errori evidenti come un parametro mancante, o più sottili esempi come dimenticare di controllare un codice di errore o dimenticare di controllare una condizione preliminare prima di chiamare un metodo. La tipizzazione statica rileva tali problemi il prima possibile: nel tuo IDE e nel compilatore, prima il codice viene 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. A meno che non si passi a una lingua di descrizione del servizio formale, non è possibile verificare alcun tipo di correttezza nell'utilizzo dell'interfaccia. devi testare, testare, testare! Ma i test sono costosi e solitamente non esaustivi, il che lascia la possibilità che i problemi possano ancora esistere nella produzione. Quando questo problema diventerà evidente? Solo quando quel percorso difettoso è preso, in fase di esecuzione, in produzione. L'idea che i problemi con i pasticci porterebbero a un feedback più veloce è esilarante pericolosamente sbagliato, a meno che non ti diverta la possibilità di perdita di dati.

Il primo tweet era mio, quindi lo espanderò:

Supponiamo di avere 100 sviluppatori, che lavorano su un'applicazione monolitica. Sono troppe le persone per comunicare efficacemente tra loro, quindi l'azienda deve lavorare sodo per dividerle in team più piccoli e creare buoni modelli di comunicazione tra loro. Quando l'organizzazione è "disfunzionale", i team probabilmente non parlano tra loro, non sono allineati a un obiettivo più grande, non sono d'accordo sulle priorità ecc. - di conseguenza, impiegano per sempre a spedire qualcosa. È un "problema di tempo di compilazione" nel senso che la disfunzione è ovvia prima che il software venga prodotto. Il progetto è probabilmente una marcia della morte o non verrà mai spedita ("compilare").

Penso che molte persone siano attratte dai micro servizi e si stanno muovendo verso di loro, non a causa di vantaggi tecnici / architettonici intrinseci, ma perché consentono loro di ignorare la disfunzione organizzativa. Invece di cercare di allineare 100 sviluppatori, sperano che possano avere piccoli team che lavorano in silos, ognuno focalizzato sul proprio piccolo micro servizio. Se sei in una organizzazione così disfunzionale, è così attraente: ti dà un permesso molto più grande di evitare le persone che non ti piacciono, di non comunicare.

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

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

My question is: What does it mean that shifting to microservices creates a run-time problem?

Questo è non cosa stanno dicendo quei tweet! Non dicono nulla sul passaggio da ai microservizi , né dicono nulla sui creare problemi. Dicono solo qualcosa sui problemi di spostamento .

E hanno messo una restrizione contestuale alle loro affermazioni, ovvero che la tua organizzazione è disfunzionale.

Quindi, quello che il primo tweet sta fondamentalmente dicendo è 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 quell'incapacità che ora si presentano durante la fase di compilazione, cioè durante lo sviluppo, verranno visualizzati durante il run-time, cioè in produzione" (tecnicamente, potrebbero anche apparire durante il test, ma ricorda, la citazione si limita alle organizzazioni disfunzionali, che probabilmente hanno un regime di test sub-standard)

Il tweet secondo dice 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 ad essere ascoltato in luoghi diversi rispetto a quando una costruzione si rompe, in particolare in luoghi che sono in grado di fare qualcosa per la disfunzione organizzativa (ad 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 coloro che alla fine sono responsabili di tale insoddisfazione, mentre la bassa qualità del codice causata da errori di gestione di livello superiore di solito si riflette solo male sugli sviluppatori, che sono , tuttavia, non è colpa e non è in grado di fare qualcosa al riguardo.

Quindi, il primo tweet dice che i microservizi trasferiscono i problemi causati da una cattiva gestione dal momento della compilazione, dove solo gli sviluppatori li vedono, in tempo di esecuzione, dove i clienti li vedono. Il secondo tweet dice che è una buona cosa, perché poi i problemi feriscono coloro che sono responsabili per loro.

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

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 dei tipi può catturarli. Lo stesso errore in un sistema di microservives potrebbe non essere visualizzato fino a due componenti specifici in realtà interagisci in un modo specifico.

Sia nei sistemi monolitici che nei microservizi devi definire le interfacce tra i sottosistemi. Le interfacce dovrebbero essere ben progettate, ben documentate e il più possibile stabili. È 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 dedicare più impegno alla progettazione dell'interfaccia.

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

1. Se l'interfaccia non viene utilizzata correttamente, si otterrà un errore in fase di esecuzione, non in fase di compilazione.
2. Chiamare un'interfaccia Web è piuttosto lento, quindi puoi avere problemi di prestazioni.

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