siamo tornati al punto di partenza con microservizi, tornando a approcci di vecchia scuola?

TL; DR. Ho avuto il piacere di bere un sacco di Kool-Aid al sapore di Microserver, quindi posso parlare un po 'delle ragioni che stanno dietro di loro.

Pro:

• I servizi sanno che le loro dipendenze sono stabili e hanno avuto il tempo di cuocere
• Consenti il rollover delle nuove versioni
• Consenti il ripristino dei componenti senza influire sui livelli superiori.

Contro:

• Non puoi utilizzare le nuove e brillanti funzionalità delle tue dipendenze.
• Non puoi mai rompere la compatibilità dell'indietro dell'API (o almeno non per molti cicli di sviluppo).

Penso che fondamentalmente fraintendano il modo in cui un'architettura di microservice dovrebbe funzionare. Il modo in cui dovrebbe essere eseguito è che ogni microservizio (a cui si fa riferimento da qui in poi come MS) ha un'API rigida su cui tutti i suoi clienti sono d'accordo. MS può apportare le modifiche che desidera purché l'API sia preservata. La MS può essere buttata fuori e riscritta da zero, a patto che l'API sia preservata.

Per facilitare l'accoppiamento lento, ogni SM dipende dalla versione n-1 delle sue dipendenze. Ciò consente alla versione corrente del servizio di essere meno stabile e un po 'più rischiosa. Permette anche alle versioni di uscire in onde. Il primo server viene aggiornato, quindi la metà e infine il resto. Se la versione corrente sviluppa mai seri problemi, la MS può essere riportata ad una versione precedente senza perdita di funzionalità negli altri livelli.

Se l'API deve essere modificata, deve essere modificata in un modo che sia retrocompatibile.

Ogni tecnica di sviluppo del software che abbiamo mai inventato riguarda la gestione della complessità in qualche modo. Una grande parte di essi è stata e continua ad essere relativa all'astrazione, all'incapsulamento e all'accoppiamento lento. I microservizi sono ancora un altro modo di fare queste cose, che è probabilmente il motivo per cui assomiglia a molte vecchie tecniche ad un livello teorico elevato, ma ciò non lo rende meno utile o rilevante.

Per quanto riguarda l'accoppiamento lento, penso che tu abbia frainteso un po 'l'obiettivo. Se l'attività A ha bisogno di chiamare l'attività B, non ci sarà mai modo di rendere A + B al 100% disaccoppiato. Non succederà mai. Quello che puoi fare è assicurarti che, se l'attività B chiama l'attività C, l'attività C non dovrebbe mai preoccuparsi delle modifiche ad A. Se queste tre attività sono tutte collegate insieme in un blob grande, passando le strutture l'una all'altra, allora c'è un possibilità significative che tutti dovranno cambiare se qualcuno di loro lo fa. Ma se tutti e tre sono microservizi, in sostanza sei garantito che una modifica ad A costringerà solo B ad aggiornare (a meno che non si tratti di un così grande cambiamento delle funzionalità di base di A che probabilmente avresti dovuto renderlo un servizio completamente nuovo). Ciò è particolarmente vero se tutti gli aggiornamenti dei microservizi vengono eseguiti in un modo compatibile con le versioni precedenti, che dovrebbero essere.

Riguardo al commento agile, posso dirti per esperienza personale che il nostro codice microservice-y funziona molto meglio con agilità rispetto al nostro codice "collegato a un blob grande". Nel secondo caso, ogni volta che qualcuno corregge un bug in una funzione di basso livello, deve letteralmente inviare all'intero reparto R & D un'e-mail che recita "Ricollega le tue attività o arriveranno tutte a venerdì". Ne riceviamo un paio ogni settimana . Se il suo codice fosse in un microservizio, tutti noi beneficerebbero automaticamente della correzione non appena ha distribuito una nuova versione.

Non capisco perfettamente il commento su COBRA e MDB, in quanto non sembrano essere architetture software ma piuttosto componenti di una; per quanto ne so sono potenziali modi di definire i protocolli di messaggistica dei tuoi microservizi e / o di implementare detti microservizi, non di per sé alternative ai microservizi.

How is it somehow better that these services are scattered across different machines?

A causa del cloud.

Hai già finito di ridere? Seriamente però - per molte aziende, il costo maggiore per il software non è più il software. È la larghezza di banda, l'hardware, i costi della CDN, ecc. Ora che tutti hanno un dispositivo mobile, c'è molto più traffico. E questo peggiorerà solo quando il tuo tostapane avrà la sua connettività Internet.

Quindi le aziende stanno cercando di gestire tali costi. Nello specifico, stanno cercando di gestire il problema aziendale di "se questa cosa esploderà, come posso servire milioni di persone a prendere / usare il mio software - senza pagare in anticipo perché i server possano servire milioni di persone che ricevono / usano il mio software ?".

Why is horizontal scaling so prevalent, or at least desirable?

Perché risponde a questo (enorme e crescente) problema aziendale.

Quando hai una dozzina di utenti, puoi lanciare tutti i servizi su una casella. Questo è buono, dal momento che si desidera pagare solo una scatola. Inoltre, non desideri pagare le modifiche all'app per suddividere i vari servizi quando la tua azienda scala. In questi giorni, non hai tempo per farlo prima che la folla di clienti accenda i tuoi server in fiamme comunque.

È anche utile perché ti permette di destreggiarti tra le allocazioni del server in modo che tu possa:

1. usa la maggior parte dei server che hai, lasciando poco da "sprecare".
2. misura la performance dei singoli elementi del tuo software.
3. ridurre la distribuzione / il tempo di inattività causato dalle versioni.

Una distribuzione molto dettagliata rende queste due cose più facili / migliori (oltre a contribuire a rafforzare la separazione delle preoccupazioni).