{"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 spielt eine Rolle, selbst wenn Sie Kubernetes haben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

19. September in Moskau hat stattgefunden<\/a><\/noindex> das erste thematische Meetup der HUG (Highload++ User Group), das den Mikroservices gewidmet war. Auf diesem wurde der Vortrag \"Betrieb von Mikroservices: Die Gr\u00f6\u00dfe spielt eine Rolle, selbst wenn Sie Kubernetes haben\" gehalten, in dem wir umfangreiche Erfahrungen der Firma \"Flant\" im Bereich des Betriebs von Projekten mit mikroservicebasierter Architektur geteilt haben. Insbesondere wird es allen Entwicklern n\u00fctzlich sein, die dar\u00fcber nachdenken, diesen Ansatz in ihrem aktuellen oder zuk\u00fcnftigen Projekt anzuwenden.<\/p>\n

\"Mikroservices:
\n
\nWir pr\u00e4sentieren das Video des Vortrags<\/b><\/a><\/noindex> (50 Minuten, deutlich informativer als der Artikel), sowie die Hauptinhalte in Textform.<\/p>\n

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

Einf\u00fchrung<\/h2>\n

\nNormalerweise hat eine gute Geschichte einen Anfang, einen Hauptplot und ein Ende. Dieser Vortrag \u00e4hnelt eher einem Anfang, und zwar einem tragischen. Es ist auch wichtig zu beachten, dass er einen Blick auf Mikroservices aus der Perspektive von der Ausnutzung<\/i>.<\/p>\n

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

\"Mikroservices:
\n
\nMan sieht, dass in einem monolithischen Anwendungsszenario, das eine bestimmte Gr\u00f6\u00dfe erreicht hat, die Produktivit\u00e4t zu sinken beginnt. Mikroservices unterscheiden sich darin, dass die anf\u00e4ngliche Produktivit\u00e4t damit niedriger ist, aber mit zunehmender Komplexit\u00e4t weniger auff\u00e4llig ist die Effizienzdegradation.<\/p>\n

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

\"Mikroservices:
\n
\nWarum ist es einer Anwendung mit Mikroservices besser geworden? Weil eine solche Architektur ernsthafte Anforderungen an die Architektur stellt, die ihrerseits hervorragend durch die M\u00f6glichkeiten von Kubernetes erf\u00fcllt werden. Auf der anderen Seite wird ein Teil dieser Funktionalit\u00e4t auch f\u00fcr Monolithen n\u00fctzlich sein, insbesondere aus dem Grund, dass ein typischer Monolith heutzutage kein echter Monolith ist (Details werden sp\u00e4ter im Vortrag behandelt).<\/p>\n

Wie man sieht, unterscheidet sich das endg\u00fcltige Diagramm (wenn sowohl monolithische als auch mikroservicebasierte Anwendungen in einer Infrastruktur mit Kubernetes betrieben werden) nicht wesentlich von dem urspr\u00fcnglichen. Im Folgenden wird es um Anwendungen gehen, die mit Kubernetes betrieben werden.<\/p>\n

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

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

\"Mikroservices:
\n
\nWas ist eigentlich eine normale<\/b> Mikroservicearchitektur? Sie sollte Ihnen einen echten Nutzen bringen, indem sie die Effizienz Ihrer Arbeit erh\u00f6ht. Wenn man zum Diagramm zur\u00fcckkehrt, dann sieht man das hier:<\/p>\n

\"Mikroservices:
\n
\nWenn man sie n\u00fctzlich<\/b>nennt, dann wird auf der anderen Seite des Diagramms sch\u00e4dliche<\/b> Mikroservicestruktur (behindert die Arbeit):<\/p>\n

\"Mikroservices:
\n
\nZur\u00fcck zur \u201eHauptidee\u201c: Kann man meiner Erfahrung \u00fcberhaupt vertrauen? Seit Beginn dieses Jahres habe ich 85 Projekte<\/b>gesehen. Nicht alle waren mikroservices (diese Architektur hatten ungef\u00e4hr ein Drittel bis die H\u00e4lfte davon), aber es ist dennoch eine gro\u00dfe Zahl. Uns (der Firma \u201eFlant\u201c) als Outsourcern gelingt es, eine gro\u00dfe Vielfalt an Anwendungen zu sehen, die sowohl in kleinen Unternehmen (mit 5 Entwicklern) als auch in gro\u00dfen (~500 Entwicklern) entwickelt werden. Ein zus\u00e4tzlicher Vorteil ist, dass wir sehen, wie diese Anwendungen \u00fcber viele Jahre leben und sich entwickeln.<\/p>\n

Warum Mikroservices?<\/h2>\n

\nAuf die Frage nach dem Nutzen von Mikroservices gibt es eine ziemlich konkrete Antwort<\/a><\/noindex> von dem bereits erw\u00e4hnten Martin Fowler:<\/p>\n

    \n
  1. klare Modulgrenzen;<\/li>\n
  2. unabh\u00e4ngiges Deployment;<\/li>\n
  3. Freiheit bei der Technologiewahl.<\/li>\n<\/ol>\n

    \nIch habe viel mit Architekten und Softwareentwicklern gesprochen und gefragt, warum sie Mikroservices ben\u00f6tigen. Und habe meine eigene Liste ihrer Erwartungen zusammengestellt. Das ist das Ergebnis:<\/p>\n

    \"Mikroservices:
    \n
    \nWenn ich einige Punkte \u201egef\u00fchlsm\u00e4\u00dfig\u201c beschreiben sollte:<\/p>\n