Ciò che è veramente diverso tra SOA e Microservices

disconoscimento

Spero di non calpestare nessuno o offendere gli appassionati di entrambi i concetti

sfondo

Ho cercato differenze reali tra l'architettura orientata ai servizi e i microservizi, senza trovare una risposta chiara.

Ho letto cose come:

• gli effetti collaterali della SOA
• La SOA è anti-pattern
• I microservizi sono venuti per correggere gli errori della SOA
• Gli ESB non sono in realtà ESB invece sono EAI
• Fiducia eccessiva nei broker di messaggi
• I venditori stanno abusando del concetto di SOA e stanno provando a vendere i loro prodotti
• La SOA cresce in maniera incontrollata

Tuttavia, nulla definisce chiaramente le differenze architettoniche tra l'architettura orientata ai servizi (come concetto) e i microservizi (come concetto)

Secondo quello che ho capito, entrambi hanno:

• Fornitori di servizi, facendo solo una cosa
• Service Gateway / ESB esponendo tali servizi ai consumatori
• Consumatori di servizi, accesso ai servizi tramite ESB / Service Gateway

Domanda

Quindi, c'è qualcosa di diverso da rietichettare la SOA nei microservizi? è un vincolo tecnologico posto per impedire ai microservizi di diventare macro?

Nota: non sto cercando opinioni, solo fatti concreti, speriamo in punti elenco

Riferimenti

• Domande sull'ingegneria del software
• Sito di Martin Fowler (penso che lo odia alla grande)
• Informazioni sul mondo
• Sito Web di Michael Fethers
• Stack Overflow Questions

Aggiornare

Sembra che un simile dibattito si sia verificato in una domanda di overflow dello Stack , con opinioni divise tra microservizi o meno sono un'architettura orientata ai servizi sotto mentite spoglie.

Conclusione dalla domanda SO:

• La SM è un caso speciale di SOA
• Gli Stati Uniti approvano servizi di hosting di applicazioni di dimensioni inferiori
• La SM dipende dalla tecnologia (l'uso di HTTP piuttosto che di opzioni di protocollo aperto)
• Gli Stati membri si affidano alla tecnologia per applicare la disciplina (distribuzione automatica dei servizi)
• MS considera ESB (male), ma utilizza gateway API che IMHO è un tipo di ESB

Ciò conclude che la SM è SOA, se è vero quanto segue:

• La SM supporta la nozione di orchestrazione? Uno o più processi principali gestiscono i flussi di lavoro
• Esiste un livello di broker di messaggi in MS? Una serie di adattatori che traducono i formati dei messaggi dallo spazio dei messaggi dei produttori di servizi ai consumatori di servizi
• I microservizi possono leggere i dati dalle applicazioni monolitiche aziendali? Possono essere API di un'applicazione monolitica? o devono essere applicazioni autonome indipendenti, in grado di funzionare in modo indipendente?

Se la risposta all'ultima domanda fosse negativa, i microservizi non sarebbero in grado di gestire complessi sistemi di flusso di lavoro, ad esempio i sistemi di gestione delle carte di credito o i sistemi di riconciliazione

Fornitori di servizi, facendo solo una cosa

La differenza principale, che ha conseguenze diffuse sul progetto, è che con i microservizi questi fornitori di servizi sono implementabili e scalabili indipendentemente .

Questo è fantastico, perché puoi essere più agile. Se un servizio deve essere cambiato, basta cambiarlo, nessuno dei suoi parenti. Se si desidera provare un nuovo framework o lingua, è sufficiente effettuare una sostituzione drop-in per quel servizio. Se improvvisamente hai bisogno di una capacità di 100x, fai girare alcune nuove macchine con quel servizio per gestire quell'afflusso. Se vuoi eseguire la versione di una versione, esegui la versione senza toccare l' intera app. E rende le cose più facili da monitorare, strumentare, dividere tra i team, obsolete ...

Ma ha alcune implicazioni pesanti:

• Il processo di rilascio deve cambiare, poiché la distribuzione di alcuni servizi è molto diversa dalla distribuzione di alcune dozzine di servizi.
• Il processo di rilascio deve cambiare, poiché la distribuzione di un servizio su una macchina è molto diversa dalla distribuzione su alcune decine di macchine.
• La progettazione, l'utilizzo e la distribuzione del database devono cambiare perché è piuttosto insignificante distribuire un servizio se deve implementare questo grande database condiviso per funzionare (interrompendo tutti gli altri servizi).
• La progettazione e l'utilizzo delle librerie devono cambiare perché è piuttosto insignificante distribuire un servizio se è necessario aggiornare questa libreria condivisa (interrompendo tutti gli altri servizi).
• La vostra registrazione / autorizzazione / gestione delle sessioni / etc ha bisogno di cambiare perché è abbastanza facile da roba condivisione quando sei solo un servizio, ma diverso quando si dispone di una serie di servizi di piccoli indipendenti che compongono il prodotto - e stanno andando a voglio condividere cose. Oh, e tutte quelle cose condivise devono affrontare il potenziale essere su versioni diverse.
• La tua comunicazione deve cambiare. Con pochi servizi, puoi spezzare le cose lungo linee in cui la comunicazione non avviene spesso e / o potrebbe avvenire lentamente. Con i microservizi, si parleranno molto e l'alta latenza non lo taglierà.

Ecco la linea di fondo L'unica ovvia differenza tra SOA e Microservices è la nozione di

Smart Endpoint Dumb Pipes

A differenza della SOA , ciò farebbe affidamento su consumatori e produttori di servizi ignari, delegando la gestione del traffico, la traduzione del formato dei messaggi e l'orchestrazione dei servizi a sistemi esterni, ad esempio ESB, orchestratore dei servizi, broker di messaggi.