Diskussion:Microservices

Self Contained Systems

"Ebenso kann ein Team für mehrere fachlich zusammenhängende Microservices (Self-contained System)[3] verantwortlich sein."

Anmerkung dazu:

Mehrere fachlich zusammenhängende Mikroservices können innerhalb eines Self-contained Systems liegen, aber auch unabhängig davon sein. Ein Team kann beispielsweise für fünf Services Verantwortlich sein und mithilfe von Events einen gemeinsamen fachlichen Prozess bearbeiten, ohne das ein übergeordnetes Vertikal mit einer eigenen UI existiert. Andersrum kann auch ein SCS existieren ohne weitere feingranularere Microservices zu beinhalten. Quelle: http://scs-architecture.org (nicht signierter Beitrag von Olcay Tümce (Diskussion | Beiträge) 16:32, 29. Mär. 2017 (CEST))

Widersprüchlich

An einer Stelle heißt es "Datenbanken werden nicht von mehreren Services verwendet, sondern immer nur von einem einzigen Service." Zwei Zeilen später heißt es "Jeder Microservice kann eine andere ... Datenbank ... Stack nutzen." Beides kann offenbar nicht gleichzeitig gelten, insbesondere das IMMER im ersten Satz eine strenge Regel impliziert. --217.13.68.110 09:33, 22. Nov. 2017 (CET)

Das ist so richtig: Im ersten Fall ist die Instanz einer Datenbank gemeint, im zweiten Fall der Typ einer Datenbank. Das heißt z.B. zwei verschiedene Instanzen einer XY-Datenbank sind möglich.--Afroehlicher (Diskussion) 11:06, 20. Jun. 2018 (CEST)

Abgrenzung zu SOA

Kann mir bitte mal jemand erklären, was wirklich der Unterschied zwischen Mikroservices und SOA ist? In diesem Abschnitt kann ich nämlich nur Gemeinsamkeiten finden. Gibt es denn überhaupt einen Unterschied?

Mikroservices sind laut Einleitung dortselbst "ein Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus unabhängigen Prozessen komponiert wird".

Bei SOA dagegen (ebenfalls aus der Einleitung dazu) können "durch Zusammensetzen (Orchestrierung) von Services niedriger Abstraktionsebenen [...] Services höherer Abstraktionsebenen geschaffen werden". Was bitte ist der Unterschied zwischen der "komplexen Anwendungssoftware" des MS und der "Orchestrierung von Services" beim SOA? Bzw. den "Mikroservices" beim MS und den "Diensten" beim SOA?

Für mich klingt das fast so, als ob man darüber streite, was bei einem beidseitig leeren Blattes Papier nun Vorder- und was Rückseite sei. Sind da möglicherweise nur ein paar minderwertigkeitskomplexgetriebene Theorie-Fanatiker am Werk, die einfach nur ihre Viertelstunde in der Öffentlichkeit suchen? Sorry, wenn ich das so provokativ formuliere.

Nehmen wir z. B. etwas, das wir alle kennen, den Comupter. Ist das eine Mikroservice- oder eine SO-Architektur? Sind Dateisystem, Monitor, Tastatur usw. (inklusive deren Treiber) jetzt Mikroservice oder SOA-Dienste? Ist das Betriebssystem eine "Anwendungssoftware, komponiert aus unabhängigen Prozessen", oder eine "Orchestrierung von Services" gemäß SOA-Definition? Oder noch was anderes?

BTW.: Irgendwie sollten Wikipedia-Artikel eigentlich (u. a. auch) eine verständliche Erklärung und Einführung bieten für Leser, die kaum mehr als den Begriff kennen, und nicht nur für Leser geschrieben sein, die eigentlich schon alles darüber wissen. Leider verfehlen beide Artikel ("Mikroservices" und "Serviceorientierte Architektur") ersteres komplett (m.a.W. weiß ich selbst nach mehrmaligem Lesen beider Artikel immer noch weder, was ich mir unter dem einen, noch unter dem anderen konkret vorzustellen habe; vom Unterschied beider ganz zu schweigen. :-(( ). --Wowo20 (Diskussion) 09:48, 31. Aug. 2018 (CEST)

Historie

Wann sind mocriservices eigentlich aufgekommen? Ich glaube mich zu erinnern 2012 oder 2013 das erste Mal in der Praxis darüber gestolpert zu sein -- in einem Team mit dem im Artikel zitierten Eberhardt Wolff (nicht signierter Beitrag von 77.183.171.169 (Diskussion) 20:17, 4. Aug. 2020 (CEST))

Stichpunkt "Schnittstellen verstecken Implementierungsdetails" liest sich so als würde bei Microservices generelle Transaktionssicherheit versprochen

Im folgenden Absatz stimmt der dritte Satz nicht unbedingt: "Datenbanken werden nicht von mehreren Services verwendet, sondern immer nur von einem einzigen Service. Dies betrifft auch Zugriffe über Views und Stored Procedures. Andernfalls wird die Architektur über die Datenbank veröffentlicht und die Transaktionssicherheit, Datenintegrität und Versionierung können nicht sichergestellt werden.".

Die Transaktionssicherheit und Datenintegrität werden aber nicht unbedingt anhand der Microservice-Architektur sichergestellt, sondern durch andere Maßnahmen, z. B. auf Datenbankebene mit korrektem Einsatz von Locks, Serialisierung, Isolation Levels, sequentielle Primärschlüssel usw. Das mit der sichergestellten Transaktionssicherheit, sehe ich nur dann im Bezug auf die Isolierung der Microservices als zutreffend, wenn wir von jeweils einem Thread und einer Applikationsinstanz pro Microservice ausgehen, was aber gerade bei Microservices (welche zum horizontal Skalieren vorgesehen sind) unpraktisch und unpassend ist. Transaktionssicherheit und Datenintegrität aufgrund der Microservice-Architektur (bzw. aufgrund deren Isolation) in dieser Form zu versprechen, halte ich daher für falsch und irreführend. Gemeint ist hier vermutlich dass in einem bereits transaktionssicherem Umfeld, dieses Umfeld weiterhin geschützt bleiben sollte durch seine abgeschotteten "verstecken Implementierungsdetails", um Eingriffe von anderen Services zu vermeiden. Diese anderen Services könnten je nach Umsetzung die Transaktionssicherheit gefährden oder erschweren. Hier sehe ich aber als Grund die generellen Vorteile der Aufteilung einer Datenbank, welche Transaktionssicherheit vereinfachen kann, aber eben auch nicht sicherstellt. (nicht signierter Beitrag von 2A02:908:DF56:B580:BC07:24EC:BDF6:AE69 (Diskussion) 03:30, 28. Mai 2021 (CEST))

Ich hab den Satz jetzt einfach gestrichen. Die genannten Punkte sind auch meines Wissens nach nicht der (einzige) Grund für die Isolation der Datenbanken, sondern generelle architektonische Überlegungen, die nicht nur bei MS Gültigkeit haben. --Sebastian.Dietrich  ✉  09:09, 28. Mai 2021 (CEST)

subjektive geschönte Darstellung?

Der Artikel insb. die Ausführung zu den Nachteilen erscheinen Pro-MS gefärbt. Mehrere der Nachteile sind nicht nur benannt, sondern im gleichen Atemzug werden dieser relativiert - durch unsachgemässe Vergleiche mit anderen Architekturen. Die Vergleiche können sogar stimmen; das will ich nicht bewerten. Es sollten die Nachteile auch klar benannt werden und nicht aufgeweicht und lieber ein Abschnitt zur Gegenüberstellung mit anderen Architekturmustern aufgenommen werden. --Bastie (Diskussion) 10:29, 17. Apr. 2022 (CEST)

Hab jetzt bei den Vor- und Nachteilen etwas aufgeräumt. --Sebastian.Dietrich  ✉  19:25, 17. Apr. 2022 (CEST)