Suche
Interview mit Peter Eijgermans, Entwickler bei Ordina Netherlands

„Microservices? Gerne, aber bitte keine Spaghetti-Struktur!“

Gabriela Motroc

© Shutterstock.com / Mauro Pezzotta

Microservices sind in aller Munde, Monolithen gelten als überholt. Aber stimmt das so grundsätzlich? Gibt es nicht Anwendungsfälle, in denen Monolithen doch die bessere Wahl sind? Und welche Probleme und Fehler können bei der Entwicklung und Anwendung von Microservices auftreten? Peter Eijgermans gibt Antworten.

JAXenter: Welche Unterschiede zwischen einem Monolithen und Microservices gibt es, die allgemein nicht so bekannt sind?

Peter Eijgermans: Microservices haben ein viel komplexeres Ökosystem als monolithische Anwendungen, manchmal ist die Komplexität des Systems als Ganzes viel größer als eine monolithische Anwendung. Denken Sie zum Beispiel an das Container-Management, verteilte Werkzeuge wie Rancher, Mesos, etc… Auch das Testen und das Deployment in die Produktion sind wesentlich komplexer. Die Organisation muss auf die Herstellung von Microservices ausgerichtet sein. Mit anderen Worten, ein Monolith ist oft viel einfacher.

  • Microservices kommunizieren – vorzugsweise – asynchron über einen Message Bus anstelle von synchronen Calls in einem Monolithen. Das macht das Debuggen und so weiter viel komplexer.
  • Monitoring ist in einer Microservices-Architektur unerlässlich, wird aber oft vergessen oder nicht gut eingerichtet.

JAXenter: Was sind die Vor- und Nachteile des jeweiligen Ansatzes?

Peter Eijgermans: Im Vergleich zum monolithischen Modell hat ein Microservice folgende Vor- und Nachteile:

  • Wenn Sie einen Microservices-basierten Ansatz verfolgen, haben Sie eine stärkere Entkopplung und Trennung von Problemen, da Sie Ihre Anwendung buchstäblich in separate Services aufteilen. Ein Service ist eine modulare Komponente, die nur über einen eigenen Vertrag zugänglich ist und daher weniger anfällig ist, sich in einen „Big Ball of Mud“ zu verwandeln.
  • Code in einem Microservice ist auf eine Funktion des Unternehmens beschränkt und somit leichter verständlich. IDEs können die kleine Code-Basis sehr einfach laden und die Entwickler produktiv halten. Dabei spielt es keine Rolle, welche Sprache, welches Framework oder welche Datenbank verwendet wird, solange sie für die jeweilige Aufgabe am besten geeignet sind.
  • Dank kürzerer Build-, Test- und Deployment-Zyklen können Sie neue Versionen eines Services flexibler veröffentlichen. Das bedeutet auch geringe Ausfallzeiten während des Roll-outs. Andererseits ist das Deployment mehrerer Services aber auch komplexer: Es gibt viel mehr bewegliche Teile, die konfiguriert, bereitgestellt, skaliert und überwacht werden müssen.
  • Da die verschiedenen Services klein sind und separat bereitgestellt werden, ist es natürlich einfacher, sie zu skalieren, mit dem Vorteil, dass Sie bestimmte Services Ihrer Anwendung skalieren können.

Aber es gibt auch viele Nachteile:

  • Das Testen einer Microservices-Anwendung ist viel komplexer. Beispiel: Eine Testklasse für einen Service müsste diesen Service und alle Services, von denen er abhängt, starten – oder zumindest Stubs für diese Dienste konfigurieren. Auch die Implementierung von Änderungen, die sich über mehrere Services erstrecken, oder die Aktualisierung mehrerer Datenbanken, die verschiedenen Services gehören, ist sehr schwierig.
  • Schließlich ändert sich das API eines Services im Laufe der Zeit: In einer monolithischen Anwendung ist es in der Regel einfach, das API zu ändern und alle Caller zu aktualisieren. In einer Microservices-basierten Anwendung ist es viel schwieriger, selbst wenn alle Konsumenten Ihres APIs andere Services in derselben Anwendung sind. Sie können in der Regel nicht alle Clients dazu zwingen, mit dem Service ein Upgrade durchzuführen. Außerdem werden Sie wahrscheinlich schrittweise neue Versionen eines Services bereitstellen, sodass sowohl alte als auch neue Versionen eines Services gleichzeitig ausgeführt werden.

JAXenter: In welchen Fällen sollte man Microservices nutzen?

Peter Eijgermans: Die Frage ist: Für welche Art von Systemen müssen Sie Microservices nutzen und für welche nicht?

  • Konkurrierende Websites, die schnell an Marktveränderungen angepasst werden müssen wie Webshops, Banken, Zeitungen, Suchmaschinen, etc.
  • Anwendungen, in denen viele Daten verarbeitet werden.

JAXenter: Welche Tools verwendest du bei der Verwaltung von Microservices?

Peter Eijgermans: Das sind die Werkzeuge, die ich am häufigsten benutze:

  • Belastbarkeit (Resilience): Netflix OSS Tools, Hystrix, Ribbon
  • Plattform: Kubernetes, Zookeeper, Mesos, Marathon, Rancher, Puppet, Chef, Ansible, OpenStack, Netflix Eureka
  • Software Delivery: GITLab, Bamboo, TeamCity, GoCD, Jenkins, Docker, rkt (Rocket)
  • Logging / Metriken: Prometheus, GrayLog, LogStash, Kibana, Grafana, ElasticSearch
  • Messaging: Kafka, RabbitMQ
  • Verteilte Datenbanken: MongoDB, CouchDB, Cassandra, MySQL, Postgres

JAXenter: Was machen die meisten Menschen oder Unternehmen bei Microservices falsch?

Peter Eijgermans: Die Menschen wissen oft nicht, dass Microservices wirklich unabhängig sein müssen.

Zum Beispiel sieht man oft, dass alle Arten von Services ausgeführt werden, aber dass eine einzige Datenbank gemeinsam genutzt wird. Ein weiteres Problem ist, dass die Leute programmieren, was sie von Monolithen gewohnt sind, wodurch die Kette der synchronen Calls zwischen den Services – über das Netzwerk – viel zu lang wird.

Ebenso wenig wird auf die Spaghetti-Struktur geachtet, die aus allen Arten von Services entstehen kann, die sich gegenseitig nutzen und eng miteinander verschlungen sind. Die Infrastruktur für Monitoring, automatische Tests und Deployments ist oft nicht vollständig eingerichtet, sondern nur für 50 bis 75 Prozent, sodass die Vorteile von Microservices nicht genutzt werden können, aber die Nachteile entstehen.

JAXenter: Vielen Dank!

MicroservicesPeter Eijgermans is a software craftsman at Ordina Netherlands. Peter is an experienced Java Developer with the focus on new technologies and frameworks. He has worked on various projects since 1992, as a developer, teacher and coach. He loves to share his experience by speaking at conferences and writing for the Dutch Java magazine and DZone.

Verwandte Themen:

Geschrieben von
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare
  1. S. Waldmann2018-04-12 10:54:40

    Zoowärter, Puppe, Koch, Bambus - bei den häufig genutzen Werkzeugen hat wohl ungewollt ein Übersetzungsprogramm zugeschlagen... ;-)

  2. Dominik Mohilo2018-04-12 11:01:40

    Hallo S.,

    vielen Dank für den Hinweis, ist korrigiert!

    Wobei wir natürlich nicht ausschließen können, dass es diese Tools nicht tatsächlich doch gibt ;-)

    Liebe Grüße,
    Dominik

  3. Heinrich2018-04-12 13:37:39

    Ja DeepL ist schon ein guter Übersetzer

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.