Microservices zum Anfassen

Ein echter Microservice lässt sich über viele Schnittstellen anfassen. Dieser Artikel gibt einen Überblick, was heute Stand der Technik ist und was demnächst möglich sein könnte.

Im Gegensatz zu früheren (in sich geschlossenen) Applikationsserver leben Microservices in verschiedenen Container-Clustern, die von verschiedenen Herstellern kommen (Kubernetes, AWS ECS, Docker Swarm usw.) und sich nach Netz-Standards (http, REST, AMQ) anstatt nach Programmiersprachen-Standards (z. B. Java JSRs) richten.

Da sich die Container-Cluster-Technologie mit verschiedensten Monitoring-Tools kombinieren lässt – und das Monitoring außerdem in fachliche und technische Probemstellungen zerfällt – muss ein Microservice bezüglich folgender Aspekte „anfassbar“ sein:

Applikations-Schnittstellen

Wenn ein Microservice ein Teil einer Applikation ist (also den Teil den man in Deutschland als „Anwendungsprogrammierung“ bezeichnet), dann stellt er dazu REST APIs bereit oder sendet/empfängt Messages über eine Queue.

Der Entwickler kann diese Schnittstellen z. B. über POSTMAN oder ähnliche Tools anfassen und ausprobieren. Dazu muß nur der Http-Port bekannt sein, auf dem die REST API läuft.

Tool- und Monitoring-Schnittstellen

Da ein Microservice Teil einer Cloud-Infrastruktur ist, benötigt er Endpunkte über die Monitoring-Tools und andere automatisierte Prozesse Informationen abrufen können. Meist liegen diese „Stellschrauben“ (Actuator Endpoints) auf einem eigenen Http-Port.

Bekannte Beispiele sind z. B. Health-Endpoints, die ein Kubernetes Cluster benötigt:

  • Liveness (der klassische /health-Endpoint)
  • Readiness (gibt an, ab ob der Microservice seine Initialisierung abgeschlossen hat und auf Applikations-Schnittstellen Anfragen bearbeiten kann)

Je nach Reifegrad der Gesamtarchitektur, in der der Microservice lebt, können noch verschiedene andere Endpunkte existieren, z. B. für das Abgreifen von Business-Metriken/KPIs für Dashboards.

Nicht selten sind diese Endpunkte komplizierter als die eigentlichen Applikations-Schnittstellen, z. B. wenn es sich um Streams handelt.

UI-Schnittstellen

Während für einige Informationen, die von Tool-Schnittstellen kommen, bereits generische UIs existieren (wie z. B. Kibana für KPIs), gibt es momentan keine technische Spezifikation, wie verschiedene Microservices zusammen eine composite UI bilden könnten. Konzepte, wie die JSR-168 für Java Portlets sind mittlerweile nicht mehr aktuell.

Interessant wäre es, wenn ein Microservice Angular 5 Komponenten „emitten“ könnte, die dann von einer Angular-Web-App dynamisch eingebunden werden könnten.

Beispiel aus dem Bereich „Entwicklertooling“:

Eine Entwicklerin stellt ihren Kollegen einen Microservice zur Verfügung, über den in der lokalen Entwicklungsumgebung ständig Testdaten auf MQ-Ebene erzeugt werden. Diesen MQ-Datenstrom kann man über ein simples REST-API ein- und ausschalten. Damit lässt sich z. B. eine laufende IoT-Maschine simulieren.

Heute ist es für keinen Entwickler ein Problem im kleinen Rahmen „zu wissen“ wie so ein Testdatengenerator-Microservice funktioniert. Die Entwicklerin startet POSTMAN, verbindet sich auf den Tool-Port und ruft (nach Lektüre des Wiki-Artikels, der die Port-Nummer und die Methoden-Signaturen enthält) die Start- und Stop-Methode auf. Für das nächste Mal speichert der Entwickler die POSTs und GETs in POSTMAN, um sich das erneute Nachschauen im Wiki zu ersparen.

Aus diesem Beispielszenario kann man mit etwas Erfahrung den Schmerz von Entwicklern in umfangreichen Microservice-Umgebungen voraussehen:

  • bei 200 Microservices mit zugehörigen 50 Testdatengeneratoren wird die Sache unübersichtlich
  • Änderungen (sowohl bei den Microservices als auch z. B. neue Parameter für die Testdatengeneratoren) erfordern dauerndes Lesen im Wiki
  • die Zusammenhänge und Abhängigkeiten (z. B. Startreihenfolge der Services) muss man im Kopf nachvollziehen (auch als neue Mitarbeiterin im Projektteam)

Eine Beispiel-Lösung ist in der CME-Workbench implementiert:

  1. Das Entwickler-Tooling reagiert auf die Start/Stop-Events der Docker-API und bekommt so mit welche Microservices laufen bzw. überhaupt installiert sind
  2. Wenn ein Microservice gestartet wurde, fragt die Workbench über die Docker-API die Docker-Labels des Containers ab und erfährt hierüber, ob und wo eine UI für den Testservice existiert
  3. Anhand weiterer Metadaten, die ebenfalls in den Docker-Labels enthalten sind, platziert die Workbench die Angular-Komponente auf einer Cockpit-Seite
  4. Über die Tooling-API kann sich der Microservice über die von ihm selbst bereitgestellte UI steuern

Details über die technische Realisierung lesen Sie demnächst in einem Blog-Beitrag unseres Angular-Teams…

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.