{"id":31761,"date":"2019-10-31T21:42:55","date_gmt":"2019-10-31T18:42:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes\/"},"modified":"2019-10-31T21:42:55","modified_gmt":"2019-10-31T18:42:55","slug":"mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes","title":{"rendered":"Mikroservices: Gr\u00f6\u00dfe ist wichtig, selbst mit Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

19. September in Moskau statt<\/a><\/noindex> das erste thematische Meetup HUG (Highload++ User Group), das den Microservices gewidmet war. Darin wurde der Vortrag \u201eBetrieb von Microservices: Gr\u00f6\u00dfe spielt eine Rolle, auch wenn Sie Kubernetes nutzen\u201c gehalten, in dem wir umfangreiche Erfahrungen des Unternehmens \u201eFlant\u201c im Betrieb von Projekten mit mikroservice-basierter Architektur teilten. Er ist in erster Linie f\u00fcr alle Entwickler von Interesse, die \u00fcber den Einsatz dieses Ansatzes in ihrem aktuellen oder zuk\u00fcnftigen Projekt nachdenken.<\/p>\n

\"Mikroservices:
\n
\nWir pr\u00e4sentieren das Video mit dem Vortrag<\/b><\/a><\/noindex> (50 Minuten, deutlich informativer als der Artikel), sowie eine umfassende schriftliche Zusammenfassung.<\/p>\n

NB: Video und Pr\u00e4sentation sind auch am Ende dieses Beitrags verf\u00fcgbar.<\/i><\/a><\/noindex><\/p>\n

Einf\u00fchrung<\/h2>\n

\nGew\u00f6hnlich hat eine gute Geschichte einen Anfang, einen Hauptplot und ein Ende. Dieser Vortrag \u00e4hnelt eher einem Anfang, und zwar einem tragischen. Au\u00dferdem ist es wichtig zu erw\u00e4hnen, dass darin eine Perspektive auf Microservices aus der Sicht der Betriebsf\u00fchrung<\/i>.<\/p>\n

Ich beginne mit einem solchen Diagramm, dessen Autor (im Jahr 2015) wurde<\/a><\/noindex> Martin Fowler ist:<\/p>\n

\"Mikroservices:
\n
\nHier sieht man, dass bei einer monolithischen Anwendung, die eine bestimmte Gr\u00f6\u00dfe erreicht, die Produktivit\u00e4t zu sinken beginnt. Mikrodienste hingegen haben von Anfang an eine niedrigere Produktivit\u00e4t, jedoch ist die Effizienzdegradation bei zunehmender Komplexit\u00e4t weniger auff\u00e4llig.<\/p>\n

Ich erg\u00e4nze dieses Diagramm f\u00fcr den Fall der Verwendung von Kubernetes:<\/p>\n

\"Mikroservices:
\n
\nWarum hat die Anwendung mit Mikrodiensten profitiert? Weil eine solche Architektur strenge Anforderungen an das Design stellt, die durch die M\u00f6glichkeiten von Kubernetes hervorragend erf\u00fcllt werden. Andererseits wird ein Teil dieser Funktionalit\u00e4t auch f\u00fcr Monolithen n\u00fctzlich sein, besonders weil ein typischer Monolith heutzutage nicht wirklich ein Monolith ist (Details folgen sp\u00e4ter im Bericht).<\/p>\n

Wie zu sehen ist, unterscheidet sich das endg\u00fcltige Diagramm (sowohl f\u00fcr monolithische als auch f\u00fcr mikrodienstbasierte Anwendungen in einer Kubernetes-Infrastruktur) nicht wesentlich von dem urspr\u00fcnglichen. Im Folgenden werden wir \u00fcber Anwendungen sprechen, die unter Verwendung von Kubernetes betrieben werden.<\/p>\n

N\u00fctzliche und sch\u00e4dliche Mikrodienste<\/h2>\n

\nUnd hier ist der Hauptgedanke:<\/p>\n

\"Mikroservices:
\n
\nWas ist also normal?<\/b> Mikroservice-Architektur? Sie sollte Ihnen echten Nutzen bieten und die Effizienz steigern. Hier ist der entsprechende Verlauf:<\/p>\n

\"Mikroservices:
\n
\nWenn man sie n\u00fctzlich nennt,<\/b>gibt es auf der anderen Seite des Verlaufs sch\u00e4dliche<\/b> Mikroservice-Zusammensetzung (beeintr\u00e4chtigt die Arbeit):<\/p>\n

\"Mikroservices:
\n
\nZur\u00fcck zur 'Hauptfrage': Sollte ich meinem Erlebnis \u00fcberhaupt Vertrauen schenken? Seit Anfang dieses Jahres habe ich 85 Projekte<\/b>. Nicht alle davon hatten eine mikroservicebasierte Architektur (etwa ein Drittel bis die H\u00e4lfte), aber es ist trotzdem eine gro\u00dfe Anzahl. Wir bei Flandt als Outsourcing-Partner haben die M\u00f6glichkeit, eine breite Palette an Anwendungen zu beobachten, die sowohl in kleinen Unternehmen (mit 5 Entwicklern) als auch in gro\u00dfen (~500 Entwicklern) entwickelt werden. Ein weiterer Vorteil ist, dass wir sehen, wie sich diese Anwendungen \u00fcber viele Jahre entwickeln und leben.<\/p>\n

Warum Mikroservices?<\/h2>\n

\nDie Frage nach dem Nutzen von Mikroservices hat eine sehr konkrete Antwort<\/a><\/noindex> von dem bereits erw\u00e4hnten Martin Fowler:<\/p>\n

    \n
  1. klare Modulegrenzen;<\/li>\n
  2. unabh\u00e4ngiges Deployment;<\/li>\n
  3. Freiheit in der Technologienwahl.<\/li>\n<\/ol>\n

    \nIch habe viel mit Architekten und Softwareentwicklern gesprochen und gefragt, warum sie Mikrodienste ben\u00f6tigen. Dabei habe ich eine Liste ihrer Erwartungen erstellt. Hier ist das Ergebnis:<\/p>\n

    \"Mikroservices:
    \n
    \nWenn ich einige dieser Punkte \u201egef\u00fchlsm\u00e4\u00dfig\u201c beschreiben w\u00fcrde, dann:<\/p>\n