Webservices vs Microservices

Schuriko

Bekanntes Mitglied
Ich beschäftige mich gerad mit Webservices und Microservices. Ich bin nur noch nicht so ganz dahinter gestiegen was konkret der unterschied zwischen Webservices und Microservice ist. Ich hoffe mir kann hier jemand etwas weiterhelfen und den Unterschied aufdecken helfen.
 

LimDul

Top Contributor
Webservice bedeutet im Allgemeinen Service, der über Web-Protokolle wie http/https verfügbar ist.

Microservice bedeutet eine Anwendung, deren Aufgabe nur darin besteht einen kleinen und sehr klar abgegrenzten Service bereitzustellen. Das kann ein Webservice sein, aber auch eine beliebige andere Technologie wie RMI oder ähnlichem.
 

Barista

Top Contributor
Der Name Microservice ist relativ irreführend, dahinter kann ein grosses Team stehen, empfohlen werden max 10 Leute.

Es geht um einen fachlich abgegrenzten Applikations-Bereich (Domain-Driven-Design bounded context).

Von Eberhard Wolff (keine Garantie, dass ich den Namen richtig geschrieben habe) gibt es im Netz kostenlose Bücher zum Thema Microservices.
 

Thallius

Top Contributor
Microservice ist nur mal wieder so eine schöner neu ausgedachter Name für Dinge die man eh schon seit Jahrzehnten so macht.
 

LimDul

Top Contributor
Passt schon. Mittlerweile rät aber auch er davon ab Microservices als (neuere) Lösung für alles zu verwenden.
Das ist ja oft so, das es neuen, heißen Scheiß gibt der als Heilsbringer für alle Probleme in der IT gilt und man ihn für alles anwendet. Und am Ende stellt man fest - die alten Probleme sind weg, dafür hat man neue Probleme die manchmal sogar größer sind als die alten.
 

Barista

Top Contributor
Welche zentralen Konzepte davon nutzt man denn schon immer?
Ich war mal in einem Projekt mit IBM-Grossrechner.

Ein alter Herr erzählte mir, dass früher bereits verschiedene Programme als Bausteine verbunden wurden.

Im Java-Bereich seit etwa 2000 stand der Application-Server im Mittelpunkt.

Module waren EJB oder so.

Microservices gehen da weiter, weil jeder Service eine eigene Technologie nutzen kann.

Ausserdem ist die Idee, dass unabhängig deployt (asgeliefert) werden kann.

Es gibt auch serviceorientierte Archtitektur, da stand ein Enterprise-Service-Bus im Mittelpunkt.

Ich habe mal gehört, dass zum Beispiel die Post Vorreiter bei SOA war, es dann aber gescheitert ist.

Eine große deutsche Behörde, bei der ich mal im Projekt war, nutzt es wahrscheinlich immer noch.

SAP hat in den einstelligen 2000er-Jahren SOA als Architektur ausgegeben, war aber eher nur was innerhalb einer SAP-Landschaft.

Auch Oracle hat sowas gemacht.
 

Schuriko

Bekanntes Mitglied
Danke für eure Klarstellung. Also habe ich es doch richtig gesehen:

  • Webservices laufen über HTTP - Protokol
  • Microservices beihalten auch Services über RMI / RMI-IIOP
  • Webservices ist nur ein Teil von Microservices
 

LimDul

Top Contributor
Danke für eure Klarstellung. Also habe ich es doch richtig gesehen:

  • Webservices laufen über HTTP - Protokol
Ja

  • Microservices beihalten auch Services über RMI / RMI-IIOP
Ja, aber eigentlich für die Definition irrelevant. In der Regel sind es Webservices

  • Webservices ist nur ein Teil von Microservices
Definitiv nein. Webservices sind ein eigenständiges Konzept.
Das eine sind Äpfel das andere ist ein Steak.

Webservices ist eine Technologie
Microservcies ist eine Architektur.

Das sind grundlegende unterschiedliche Konzepte.
 

LimDul

Top Contributor
Wobei Technologie eigentlich zu eng gefasst ist, Webservices sind ja eigentlich noch eine Ebene über der Architektur und völlig Technologieunabhängig (bis auf „Internet“)
Hm, stimmt im Prinzip - aber mir fällt kein passender Begriff ein. Es kennzeichnet auf "technischer" bzw "Transport"-Ebene eine Eigenschaft einer einzelnen Schnittstelle.

Microservice kennzeichnet die Architektur einer Anwendung in einer Anwendungslandschaft.
 

Oneixee5

Top Contributor
Microservices sind in sich gekapselt, teilen sich also nicht direkt Daten oder Informationen mit anderen Anwendungen oder Microservices, z.B.: Database per Service Pattern (Keep each microservice’s persistent data private to that service and accessible only via its API. A service’s transactions only involve its database.).
 

Schuriko

Bekanntes Mitglied
Microservices sind in sich gekapselt, teilen sich also nicht direkt Daten oder Informationen mit anderen Anwendungen oder Microservices, z.B.: Database per Service Pattern (Keep each microservice’s persistent data private to that service and accessible only via its API. A service’s transactions only involve its database.).
Also soweit ich es verstanden habe bisher kann sich der Microservice die Daten einer Datenquelle teilen oder kann auf andere Microservices zugreifen um sich Daten zu ermitteln.
 

LimDul

Top Contributor
Nein, nicht teilen. Wenn Datenbank, dann exklusiv für den Microservice. Klar kann er Daten über eine API von woanders lesen - aber seine interne Datenhaltung ist exklusiv und nicht geteilt.
 

kneitzel

Top Contributor
Also irgendwie werden hier Definition ("Was ist ein Microservice") und Best Practices durcheinander geworfen.

Nein, nicht teilen. Wenn Datenbank, dann exklusiv für den Microservice.
Das ist ein Best Practice. Aber das muss so nicht sein. Die Datenbank kann natürlich auch geteilt sein. Wenn ich eine Datenbank extra für den Microservice erstelle, dann sollte das eine exklusive Datenbank sein. Aber die Datenbank kann man auch als etwas externes ansehen. Dann ist es wie jede andere Kommunikationsschnittstelle und es interessiert mich nicht, wer da noch drauf zugreift. Ob der Zugriff auf die externe Datenquelle per http, jdbc oder sonst irgendwas erfolgt, ändert ja nichts daran, dass es ein Microservice ist.

Daher ist es ein Best Practice oder wie @Oneixee5 gesagt hat: Ein Pattern.

Daher finde ich auch die Aussage von @Barista gut in #3: Es kann - aber es wird empfohlen.
 

Schuriko

Bekanntes Mitglied
Nein, nicht teilen. Wenn Datenbank, dann exklusiv für den Microservice. Klar kann er Daten über eine API von woanders lesen - aber seine interne Datenhaltung ist exklusiv und nicht geteilt.
Korrekt so hatte ich es auch geschrieben. Mehrere Microservices könnten sich auf eine Datenquelle drauf zugreifen. Vorausetzung ist, dass die Datenquelle gespiegelt ist und der eine Microservice nicht auf die eine Datenquelle aus technischem Grund nicht zugreifen kann. Oder habe ich es falsch Verstanden?
 

Oneixee5

Top Contributor
Ich meinte das schon Ernst - Microservices sind in sich gekapselt, teilen sich nur Daten über ihre API. Das Shared Database Anti-Pattern hat weitreichende Konsequenzen und ein Service sollte nicht als Microservice bezeichnet werden, wenn das Database per Service Pattern nicht erfüllt wird.
Kopplung der Entwicklungszeit - ein Entwickler, muss Schemaänderungen mit den Entwicklern anderer Dienste koordinieren, die auf dieselben Tabellen zugreifen. Diese Kopplung und zusätzliche Koordination verlangsamen die Entwicklung. Der Zugriff über API's ist versioniert und kann auf Anforderung aktualisiert werden.
Laufzeitkopplung - da alle Dienste auf dieselbe Datenbank zugreifen, können sie sich gegenseitig stören. Wenn z. B. eine lange laufende Transaktion eine Sperre für eine Tabelle hält, wird der Service blockiert.
Eine einzige Datenbank erfüllt möglicherweise nicht die Anforderungen aller Dienste an die Datenspeicherung und den Datenzugriff, RDBMS, NoSQL, usw..
Die automatische horizontale Skalierung der Microservices und ihrer DB's wird mit dem Shared Database Anti-Pattern so gut wie unmöglich.
 

kneitzel

Top Contributor
Dem Pattern widerspreche ich keiner Weise. Nur eben entspricht das "ein Service sollte nicht als Microservice bezeichnet werden, wenn das Database per Service Pattern nicht erfüllt wird." keiner Definition, die ich bisher zu Microservice gehört habe.

Wird auch relativ schwer, das alles zu spezifizieren. Einfach ein Service, den ich kenne, mal aufgezeigt:
- Der Service kommt prinzipiell ohne Datenbank aus.
- Teil einer Schnittstelle ist aber eine Oracle Datenbank, die gelesen und geschrieben wird. (Ist halt eine "Schnittstelle", die von Oracle Datenbank Experten erstellt wurde und auf das u.a. ein Oracle Cluster zugreift um von dort Jobs auszuwerten)

Ich halte es für schwer, das zu spezifizieren. Das kann man als Außenschnittstelle betrachten. Aber der "State" liegt nun einmal in dieser Außenschnittstelle. Es gibt keine Entitäten, die woanders abgelegt werden.

Und so einem Microservice willst Du ernsthaft die Bezeichnung Microservice wegnehmen? Und wenn Entitäten noch in einer eigenen Datenbank gesichert worden wäre mit entsprechenden Synchronisierungsjobs, dann wäre es wieder ein Microservice, weil das diese Datenbank als klare Aussenschnittstelle abstempelt oder würde das auch nicht reichen und man müsste separat noch einen CRUD Webservice bauen oder so?

Ich freue mich schon jetzt auf Argumente und Begriffsdefinitionen.
 

Oneixee5

Top Contributor
Dem Pattern widerspreche ich keiner Weise. Nur eben entspricht das "ein Service sollte nicht als Microservice bezeichnet werden, wenn das Database per Service Pattern nicht erfüllt wird." keiner Definition, die ich bisher zu Microservice gehört habe.

Wird auch relativ schwer, das alles zu spezifizieren. Einfach ein Service, den ich kenne, mal aufgezeigt:
- Der Service kommt prinzipiell ohne Datenbank aus.
- Teil einer Schnittstelle ist aber eine Oracle Datenbank, die gelesen und geschrieben wird. (Ist halt eine "Schnittstelle", die von Oracle Datenbank Experten erstellt wurde und auf das u.a. ein Oracle Cluster zugreift um von dort Jobs auszuwerten)

Ich halte es für schwer, das zu spezifizieren. Das kann man als Außenschnittstelle betrachten. Aber der "State" liegt nun einmal in dieser Außenschnittstelle. Es gibt keine Entitäten, die woanders abgelegt werden.

Und so einem Microservice willst Du ernsthaft die Bezeichnung Microservice wegnehmen? Und wenn Entitäten noch in einer eigenen Datenbank gesichert worden wäre mit entsprechenden Synchronisierungsjobs, dann wäre es wieder ein Microservice, weil das diese Datenbank als klare Aussenschnittstelle abstempelt oder würde das auch nicht reichen und man müsste separat noch einen CRUD Webservice bauen oder so?

Ich freue mich schon jetzt auf Argumente und Begriffsdefinitionen.
Ein Microservice ohne eigen DB ist natürlich auch ein Microservice. Ein Microservice kann natürlich auch API's fremder Services benutzen, oder RPI usw.. Die Schnittstelle zu oder die Nutzung von externen Services soll aber nicht Teil einer Transaktion sein.
 

Schuriko

Bekanntes Mitglied
Okay. Aber was ich dann noch nicht so ganz verstanden habe, wie willst du Vorgehen wenn z.B. eine Datenbank-Server ausfällt - aus was für technische Gründe auch immer.
 

kneitzel

Top Contributor
Ein Ausfall ist ein Ausfall und zieht sich dann durch. Also das bedeutet dann, dass der Service, der die Datenbank nutzt, ebenfalls (teilweise) ausfällt.
Alles, was den Service nutzt, fällt dann ebenfalls (teilweise) aus.

Muss man sich ja nur vorstellen: Du hast einen Service, der die Autorisierung übernimmt. Wenn da die Datenbank ausfällt, dann geht keine Anmeldung mehr. Alle Dienste, die diesen Service zur Anmeldung benötigen, können dann auch nicht mehr benutzt werden.

Daher wird dann halt redundant gearbeitet. Du hast nicht einen Service für Anmeldungen sondern mehrere. Dann kann einer ausfallen und alles funktioniert weiter. Der Vorteil ist hier halt, dass Du diese Microservices meist virtuell laufen lässt. Du startest die also nicht direkt auf einem Rechner sondern in einer VM / einem Container. Und da hast Du dann Systeme, die diese auf physischen System hin und her schieben können ohne Unterbrechung. Und der Start ist extrem schnell - Du musst halt nicht ein ganzes Betriebssystem mit allem drum und dran starten.

Da sind wir aber dann nicht mehr direkt beim Thema Microservices sondern sind in einem mehr Administrativen Gebiet.
 

Ebi

Neues Mitglied
Die Datenbank kann natürlich auch geteilt sein.
Bei Microservices geht es vor allem darum, dass du die Services unabhängig voneinander entwickeln und deployen kannst. Auf REST Ebene ist dies machbar, weil du bei einem größeren Umbau in der Regel Code schreiben kannst, der für den anderen Sevice eine kompatible Schnittstelle anbietet. Daneben gibt es dann eine neue Schnittstelle auf die der andere Service umsteigen solll. Nach dem Umstieg kann man dann den alten Code wegwerfen.

Wenn sich 2 Microservices die Datenbank teilen, dann wird man das Problem haben, dass wenn ein Service die Struktur ändert, auch der andere Service geändert und zeitgleich deployed werden muss.

Damit schaffst du dir etwas, das man Deployment Monolith nennt. Heißt dass du zwar zur Compilezeit nur Microservices hast und nicht einen fetten Monolithen. Wenn du deployst, dann musst du alles zur gleichen Zeit machen. Dies macht dir dann continuous integration/continuous Deployment schwierig bis unmöglich.

Ich bin der Meinung, dass man Microservices nur dann machen sollte, wenn man wirklich die Vorteile braucht und dann auch konsequent umsetzt, wie keine gesharten Datenbanken oder gesharter Code. Nur weil man Dimge gut aufteilen und daraus fachliche Teile schneiden kann, muss man daraus nicht Services machen, die einzeln deployed werden können und über Rest reden. Microservices adressiert ein organisatorisches und Prozess Problem, kein fachliches oder Clean Code Thema.
 

mihe7

Top Contributor
Ich freue mich schon jetzt auf Argumente und Begriffsdefinitionen.
Zuerst sollte man mal zwischen Microservice und Microservice-Architektur unterscheiden. In Anlehnung an den von Balzert verwendeten Architekturbegriff bezeichnet Microservice-Architektur die Softwarearchitektur eines verteilten Systems dessen Architekturbausteine Microservices sind.

Beim Microservice gibt es dagegen so viele Betrachtungsweisen, dass es nicht möglich ist, eine explizite, geschlossene Definition anzugeben. Der kleinste gemeinsame Nenner wurde m. E. von Dragoni et al. beschrieben, wonach es sich bei Microservices um unabhängige, kohäsive Prozesse handelt, die über Nachrichten interagieren. Dabei würde ich allerdings noch das Netzwerk als zusätzliches Charakteristikum anführen, um sich von z. B. Unix-Tools abzugrenzen, außerdem darf man den Prozessbegriff nicht zu eng auslegen. Vielmehr muss hierunter fallweise auch die Anwendung verstanden werden, während der Betriebssystemprozess dann eine konkrete Instanz des Microservices wäre.

Das Interessante an diesem Kriterium ist, dass es auf der einen Seite sehr allgemein gehalten ist, andererseits eine Beschreibung liefert, die präzise genug ist, um ableiten zu können, worauf es im Wesentlichen ankommt. Insbesondere wird die Größe implizit über die Kohäsion nach oben und unten bereits eingeschränkt.

Auswirkungen sind die hier bereits genannten:

Bei Übertragung auf DDD liefert der bounded context, wie von @Barista bereits geschrieben, die Grenze nach oben. Das Aggregate als transaktionale Einheit würde dagegen das absolute Minimum darstellen, was von einem Microservice abgedeckt werden kann.

Die Unabhängigkeitsforderung liefert mit Blick auf die DB, dass jeder Microservice seine eigene Daten hält. Außerdem muss er alle Abhängigkeiten mitbringen, um ausgeführt werden zu können. Daraus ergeben sich im Zusammenhang mit Conway's Law dann auch die von @Ebi bechriebenen Konsequenzen.

So viele Vorteile Microservices auch haben mögen, so sehr muss man sich der Komplexität bewusst werden. Eine verteilte Anwendung ist nun einmal eine ganz andere Hausnummer als ein Monolith. Man muss zusätzlichen Aufwand in die Kommunikation stecken und das CAP-Theorem schlägt gnadenlos zu. ACID vs. BASE. Hurra.

Daher: Microservices so viel als nötig, so wenig wie möglich. Ohne fundierte Gründe keine Microservice-Architektur, wobei es sehr viele Gründe geben kann, die auch über die Strukturen im Betrieb etc. hinausreichen.
 

Ähnliche Java Themen


Oben