siamo tornati al punto di partenza con i microservizi, tornando agli approcci della vecchia scuola?

In termini di architettura e design del software, in che modo i microservizi "impilano" (gioco di parole) contro il middleware? Sto venendo da Java, e sembra che mentre ti allontani dal REST come API, e allontani diversi livelli e parametri di connessione, almeno in Java, sei quasi tornato al punto di partenza per alcune idee di vecchia scuola . Siamo tornati alla virtualizzazione ... dove la JVM è già virtuale.

In modo agnostico, puoi, e direi i vantaggi, astrarre un'API RESTful su CORBA. Oppure, in modo più incentrato sul Java, JMS o MDB.

Un tempo EJB era un grosso problema in Java, poi è stato riconosciuto come un po 'un effetto cluster, ma, ora, siamo tornati all'inizio?

Oppure, i microservizi offrono qualcosa di cui manca CORBA, o meglio, MDB? Quando leggo (TLDR) Martin Fowler che spiega i microservizi, mi sembra una buona soluzione a un cattivo problema, se vuoi. O meglio, un approccio di mentalità chiusa che introduce un livello di complessità solo spingendo il problema in giro. Se i servizi sono veramente micro e sono numerosi, ognuno ha un costo in dollari per gestirlo e mantenerlo.

Inoltre, se un micro servizio tra molti cambia la sua API, allora tutto a seconda di quel servizio si rompe. Non sembra vagamente accoppiato, sembra il contrario di agile. O sto abusando di quelle parole?

Certamente, ci sono una quantità indeterminata di scelte tra questi estremi.

Squalo contro Gorilla ... vai! (Per il pedante, questo è pensato per essere ironico, e non è affatto mia intenzione. La domanda è pensata per essere presa al valore nominale. Se la domanda può essere migliorata, per favore fallo, o commenta e riparerò. )

Immagina una moltitudine di microservizi in esecuzione nella docker, tutti su una macchina, che parlano tra loro ... follia. Difficile da mantenere o amministrare, e quasi impossibile cambiare mai nulla perché qualsiasi cambiamento si sovrapporrà e causerà errori imprevedibili. In che modo è meglio che questi servizi siano sparsi su macchine diverse? E, se distribuiti, sicuramente alcune tecniche molto vecchie della scuola hanno risolto, almeno in una certa misura, il calcolo distribuito.

Perché il ridimensionamento orizzontale è così diffuso o almeno desiderabile?

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

Professionisti:

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

Contro:

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

Penso che fondamentalmente fraintendiate come dovrebbe funzionare un'architettura di microservizi. Il modo in cui dovrebbe essere eseguito è che ogni microservizio (indicato da qui in poi come MS) ha un'API rigida su cui tutti i suoi clienti concordano. A MS è consentito apportare tutte le modifiche che desidera purché l'API venga conservata. La MS può essere eliminata e riscritta da zero, purché l'API sia preservata.

Per facilitare l'accoppiamento libero, ogni Stato membro dipende dalla versione n-1 delle sue dipendenze. Ciò consente alla versione corrente del servizio di essere meno stabile e un po 'più rischiosa. Inoltre consente alle versioni di uscire a ondate. Il primo 1 server viene aggiornato, quindi la metà e infine il resto. Se la versione attuale sviluppa problemi seri, è possibile ripristinare la versione precedente di MS senza perdita di funzionalità in altri livelli.

Se l'API deve essere modificata, deve essere modificata in modo compatibile con le versioni precedenti.

Ogni tecnica di sviluppo software che abbiamo mai inventato riguardava in qualche modo la gestione della complessità. Una gran parte di essi è stata e continua a riguardare l'astrazione, l'incapsulamento e l'accoppiamento libero. I microservizi sono ancora un altro modo di fare queste cose, motivo per cui assomiglia a molte tecniche più vecchie ad un alto livello teorico, ma ciò non lo rende meno utile o pertinente.

Per quanto riguarda l'accoppiamento lento, penso che tu abbia frainteso un po 'l'obiettivo. Se l'attività A deve chiamare l'attività B, non ci sarà mai modo di separare A e B al 100%. 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 in un unico grande BLOB, passando le strutture l'una all'altra, allora c'è un possibilità significative che dovranno cambiare tutti se qualcuno lo fa. Ma se tutti e tre sono microservizi, allora sei sostanzialmente sicuro che una modifica ad A costringerà B ad aggiornare (a meno che non sia una modifica così grande alla funzionalità di base di A che probabilmente avresti dovuto renderlo un servizio nuovo di zecca). Ciò è particolarmente vero se tutti gli aggiornamenti dei microservizi vengono eseguiti in modo compatibile con le versioni precedenti, come dovrebbero essere.

Per quanto riguarda il commento agile, posso dirti per esperienza personale che il nostro codice microservizio-y gioca molto meglio con l'agile del nostro codice "collegato in un grande blob". In quest'ultimo caso, ogni volta che qualcuno risolve un bug in una funzione di basso livello, deve letteralmente inviare una e-mail all'intero dipartimento R&D dicendo "ricollega i tuoi compiti o andranno tutti in crash venerdì". Ne riceviamo un paio ogni settimana . Se il suo codice fosse in un microservizio, trarremmo tutti benefici automatici dalla correzione non appena avesse distribuito una nuova versione.

Non capisco appieno il commento su COBRA e MDB, poiché non sembrano essere architetture software ma piuttosto componenti di una; a mio avviso sono potenziali modi per definire i protocolli di messaggistica dei microservizi e / o implementare detti microservizi, non di per sé alternativi ai microservizi.

In che modo è meglio che questi servizi siano sparsi su macchine diverse?

A causa del cloud.

Hai già riso? Scherzi a parte - 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'è solo molto più traffico. E questo peggiorerà solo quando il tuo tostapane ottiene la propria connettività Internet.

Quindi le aziende stanno cercando di gestire quei costi. In particolare, stanno cercando di gestire il problema aziendale di "se questa cosa esplode, come posso servire milioni di persone a ottenere / utilizzare il mio software - senza pagare in anticipo che i server servano milioni di persone a ottenere / usare il mio software ?".

Perché il ridimensionamento orizzontale è così diffuso o almeno desiderabile?

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

Quando hai una dozzina di utenti, puoi lanciare tutti i servizi su una casella. Questo va bene, dal momento che vuoi pagare solo per una scatola. Inoltre, non vuoi pagare per le modifiche all'app per suddividere i vari servizi quando la tua attività viene ridimensionata. In questi giorni, non hai tempo per farlo prima che la folla di clienti accenda comunque i tuoi server in fiamme.

È utile anche perché consente di destreggiarsi tra le allocazioni del server in modo da poter:

1. usa la maggior parte dei server che hai, lasciando poco da "sprecare".
2. misurare le prestazioni dei singoli elementi del software.
3. ridurre i tempi di distribuzione / downtime causati dalle versioni.

Avere distribuzioni molto granulari rende queste due cose più facili / migliori (oltre a contribuire a rafforzare la separazione delle preoccupazioni).