{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Mikroservices: Was sind sie, warum sind sie wichtig und wann sollten sie eingef\u00fchrt werden?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ich wollte schon lange einen Artikel \u00fcber mikroservicearchitektur schreiben, doch zwei Fragen hielten mich immer wieder zur\u00fcck: Je tiefer ich in das Thema eintauchte, desto mehr schien mir das, was ich wei\u00df, offensichtlich, w\u00e4hrend das, was ich nicht wei\u00df, noch zu lernen bleibt. Anderseits bin ich der Meinung, dass es bereits gen\u00fcgend Diskussionsstoff f\u00fcr ein breites Publikum gibt. Alternativen Meinungen sind daher herzlich willkommen.
\n<\/a><\/noindex><\/p>\n

Conway's Gesetz und der Zusammenhang zwischen Gesch\u00e4ft, Organisation und Informationssystem<\/h2>\n

\nIch nehme mir erneut die Freiheit zu zitieren:<\/p>\n

\u201eJede Organisation, die ein System (im weitesten Sinne) entwirft, erh\u00e4lt ein Design, dessen Struktur die Struktur der Teams in dieser Organisation widerspiegelt.\u201c
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

Meiner Meinung nach bezieht sich dieses Gesetz eher auf die Zweckm\u00e4\u00dfigkeit der Gesch\u00e4ftsorganisation als direkt auf das Informationssystem. Lassen Sie mich ein Beispiel geben. Angenommen, wir haben eine ausreichend stabile Gesch\u00e4ftsm\u00f6glichkeit mit einem Lebenszyklus, der lang genug ist, um ein Unternehmen zu gr\u00fcnden (das ist kein Tippfehler; ich finde diesen Begriff, den ich entlehnt habe, sehr interessant). Nat\u00fcrlich wird das unterst\u00fctzende System dieses Gesch\u00e4fts organisatorisch und prozessual auf dieses Gesch\u00e4ft abgestimmt sein.<\/p>\n

Gesch\u00e4ftsorientierung von Informationssystemen<\/h2>\n

\n\"Mikroservices:
\n
\nLassen Sie mich ein Beispiel geben. Angenommen, es gibt die Gesch\u00e4ftsm\u00f6glichkeit, ein Unternehmen zum Verkauf von Pizzen zu gr\u00fcnden. In Version 1 (nennen wir sie vor-informativ) stellte das Unternehmen eine Pizzeria, eine Kasse und einen Lieferservice dar. Diese Version war langlebig in einer Umgebung mit geringer Ver\u00e4nderung. Dann kam Version 2 \u2014 fortschrittlicher und in der Lage, ein Informationssystem als Grundlage f\u00fcr ein Unternehmen mit monolithischer Architektur zu nutzen. Und hier denke ich, entsteht einfach eine furchtbare Ungerechtigkeit gegen\u00fcber den Monolithen \u2014 Die angeblich monolithische Architektur entspricht nicht dem Gesch\u00e4ftsmodell der Domain.<\/b>W\u00e4re dem so, k\u00f6nnte das System \u00fcberhaupt nicht funktionieren \u2013 was im Widerspruch zum Conway\u2019schen Gesetz und zu gesundem Menschenverstand steht. Nein, die monolithische Architektur entspricht vollkommen dem Gesch\u00e4ftsmodell in dieser Phase der Unternehmensentwicklung \u2013 ich spreche hierbei von der Phase, in der das System bereits erstellt und in Betrieb genommen wurde. Es ist eine bemerkenswerte Tatsache, dass unabh\u00e4ngig vom architektonischen Ansatz sowohl die serviceorientierte Architektur Version 3 als auch die Microservices-Architektur Version N gleicherma\u00dfen gut funktionieren werden. Wo liegt der Haken?<\/p>\n

Alles flie\u00dft, alles ver\u00e4ndert sich \u2013 oder sind Microservices ein Mittel zur Bek\u00e4mpfung von Komplexit\u00e4t?<\/h2>\n

\n Bevor wir fortfahren, lassen Sie uns einige Missverst\u00e4ndnisse bez\u00fcglich der Microservices-Architektur betrachten.<\/p>\n

Bef\u00fcrworter des mikroservices-Ansatzes behaupten oft, dass die Aufspaltung eines Monolithen in Mikrodienste die Entwicklung erleichtert, indem sie die Codebasis der einzelnen Dienste verringert. Meiner Meinung nach ist diese Aussage v\u00f6lliger Unsinn. Im Ernst, ist die offensichtliche Interaktion innerhalb eines Monolithen und homogenen Codes wirklich so kompliziert? W\u00e4re das der Fall, w\u00fcrden alle Projekte von Anfang an als Mikrodienste konzipiert werden. Die Praxis zeigt jedoch, dass die Migration von einem Monolithen zu Mikrodiensten weitaus verbreiteter ist. Die Komplexit\u00e4t verschwindet nicht, sie wechselt lediglich von einzelnen Modulen zu Schnittstellen (sei es Datenbusse, RPC, APIs und andere Protokolle) und orchestrierenden Systemen. Und das ist \u2013 kompliziert! <\/p>\n

Der Vorteil der Nutzung eines heterogenen Stacks ist ebenfalls fraglich. Ich will nicht sagen, dass dies nicht m\u00f6glich ist, aber in der Realit\u00e4t kommt es selten vor (Um es vorwegzunehmen \u2013 es sollte vorkommen, jedoch eher als Folge denn als Vorteil).<\/p>\n

Produktlebenszyklus und Servicelebenszyklus<\/h2>\n

\nSchauen Sie sich das Diagramm oben noch einmal an. Ich habe nicht zuf\u00e4llig den verk\u00fcrzten Lebenszyklus einer einzelnen Gesch\u00e4ftsversion hervorgehoben \u2013 in der heutigen Zeit ist die Beschleunigung des \u00dcbergangs zwischen den Versionen f\u00fcr den Erfolg entscheidend. Der Erfolg eines Produkts h\u00e4ngt von der Geschwindigkeit ab, mit der die Gesch\u00e4fts-Hypothesen darin \u00fcberpr\u00fcft werden.<\/b>. Hier liegt meiner Meinung nach der Schl\u00fcsselvorteil der mikroservicebasierten Architektur. Doch lassen Sie uns der Reihe nach vorgehen. <\/p>\n

Lassen Sie uns zur n\u00e4chsten Evolutionsstufe der Informationssysteme \u00fcbergehen \u2013 zur serviceorientierten Architektur (SOA). In einem bestimmten Moment haben wir in unserem Produkt langfristige Dienste<\/b> definiert \u2013 langfristig insofern, als dass beim \u00dcbergang zwischen den Produktversionen die Chance besteht, dass der Lebenszyklus des Dienstes l\u00e4nger ist als der Lebenszyklus der n\u00e4chsten Produktversion. Es w\u00e4re logisch, sie \u00fcberhaupt nicht zu \u00e4ndern \u2013 denn wir ben\u00f6tigen insbesondere die Geschwindigkeit des \u00dcbergangs zur n\u00e4chsten Version<\/b>. Doch bedauerlicherweise sind wir gezwungen, st\u00e4ndige \u00c4nderungen an den Diensten vorzunehmen \u2013 und hier kommen uns alle M\u00f6glichkeiten zugute, sei es DevOps-Praxis, Containerisierung und alles, was uns in den Sinn kommt. Aber das sind noch keine Mikroservices! <\/p>\n

Mikrodienste als Mittel zur Bew\u00e4ltigung von Komplexit\u00e4t\u2026 Konfigurationsmanagement<\/h2>\n

\n Hier k\u00f6nnen wir endlich zur entscheidenden Rolle der Mikrodienste \u00fcbergehen \u2013 es handelt sich um einen Ansatz, der das Management der Produktkonfiguration vereinfacht. Genauer gesagt beschreibt die Funktion jedes Mikrodienstes genau die Gesch\u00e4fts- funktion innerhalb des Produkts gem\u00e4\u00df dem Dom\u00e4nenmodell \u2013 und das sind bereits Dinge, die nicht in einer kurzlebigen Version leben, sondern in einer langlebigen Gesch\u00e4ftsm\u00f6glichkeit. Der \u00dcbergang zur n\u00e4chsten Produktversion geschieht quasi unmerklich \u2013 Sie \u00e4ndern oder f\u00fcgen einen Mikrodienst hinzu, oder m\u00f6glicherweise nur das Schema seiner Interaktionen, und schon befinden Sie sich in der Zukunft, w\u00e4hrend Ihre weinenden Konkurrenten weiterhin zwischen den Versionen ihrer Monolithen springen. Stellen Sie sich nun vor, dass es eine ausreichend gro\u00dfe Anzahl an Mikrodiensten mit bereits definierten Schnittstellen und Gesch\u00e4ftsm\u00f6glichkeiten gibt. Sie kommen und bauen die Struktur Ihres Produkts aus diesen bestehenden Mikrodiensten \u2013 einfach indem Sie beispielsweise ein Diagramm zeichnen. Herzlichen Gl\u00fcckwunsch \u2013 Sie haben eine Plattform geschaffen \u2013 und jetzt k\u00f6nnen Sie sich Ihr Gesch\u00e4ft zusammenklicken. Tr\u00e4ume, Tr\u00e4ume. <\/p>\n

Fazit<\/h2>\n

<\/p>\n