3 Kommentare

CME Workbench: eine solide Basis für Microservice-Umgebungen

Die CME Workbench ist eine OpenSource-Umgebung, die Entwickler bei der Erstellung von Microservices abholt und Schritt für Schritt bis zum Monitoring in der Cloud leitet. Dabei werden auch viele Grundlagen bezügl. Dokumentation und Team-Kommunikation etabliert, die die Basis einer gesunden DevOps-Kultur darstellen.

Den Überblick behalten über Microservice-Projekte

Im Gegensatz zu monolithischen Anwendungen bildet eine Menge von Microservices die Code-Basis für eine fachliche Anwendung. Dabei können Microservices von mehreren Anwendungen verwendet werden: z. B. kann ein EMail-Notification-Microservice gleichzeitig von den Anwendungen „Online-Shop“ und „Service & Support“ genutzt werden.

Diesem Gedanken trägt die CME Workbench Rechnung, die die lokale Entwicklungsumgebung visualisiert und je nach Kunde selbst weiterentwickelt werden kann. Es handelt sich also nicht um ein Produkt, sondern um einen Grundstock von Funktionen, der je nach Kunde unterschiedlich ausgebaut und optimiert werden kann. Ein Beispiel dafür ist die Angular 4 Benutzeroberfläche:

Sie bildet eine Sicht auf ein Microservice-Projekt ab, in der folgende Parameter berücksichtigt werden:

  • Das Projekt an sich
  • Die Iteration (z. B. aktueller Sprint in Scrum)
  • Die Laufzeitumgebung (z. B. lokaler PC oder Integrationssystem)

In diesem Kontext kann man über das C4 Diagramm erkennen, welche Systeme und menschliche Benutzer bzw. IoT-Devices beteiligt sind. Das C4 Modell von Simon Brown beschreibt eine Code-getriebene Methodik der Systemdokumentation, die gut in Everything-as-Code-Umgebungen passt.

Ebenso wie die permanente Dokumentation, ist die Integration von Team-Kommunikation über Slack (oder andere Messenger) und das kontinuierliche Beschreiben von Änderungen über Jira (oder andere Requirement-Tools) eines der Hauptanliegen der CME Workbench.
Dabei kann jedes Projekt unterschiedliche Tools verwenden (z. B. da verschiedene Abteilungen/Standorte unterschiedliche Technologien verwenden). Über Adapter können die Systeme hinter der Oberfläche ausgetauscht werden: z. B. Projekt A mit Jira in der Cloud als Requirements/Ticket-System und Projekt B mit Microsoft TeamServices.

Microservices stellen andere Anforderungen an Entwickler

Viele Entwickler sind es gewohnt, in ihrem eigenen Bereich vor sich hin zu werkeln – die Probleme treten erst auf dem Integrationssystem auf. Die CME Workbench unterstützt Entwickler dabei, ständig die neuen Ergebnisse der Kollegen über Docker-Container zu integrieren und damit den Weg in die Produktion zu ebnen. Dabei werden ständig die Microservices der anderen Entwickler angezeigt:

Zu jedem Microservice werden Informationen aus Git (oder anderen Versionsverwaltungswerkzeugen) angezeigt, Abhängigkeiten zu anderen Microservices oder die Open API Dokumentation (Swagger).

Auch Laufzeitprobleme können frühzeitig identifiziert werden, indem Teile des Monitoring (KPIs, Profiling) bereits in der Entwicklung aktiv benutzt werden. Typischerweise rufen Microservices andere Microservices auf und/oder starten asynchrone Jobs über Message Queues.

Da typische Remote-Debugger im Cloud-Umfeld meist versagen, lernt man über die CME Workbench, wie man trotzdem zur gewohnten Profiling-Sicht kommt:

Das funktioniert auf allen Systemen gleich, so dass das Debugging in der Entwicklungsumgebung identisch mit dem in der Produktionsumgebung ist – und das technologieübergreifend von Java über NodeJS bis hin zu Python.

Microservices stellen andere Anforderungen an das Monitoring

Bereits in der Entwicklung werden virtuelle Maschinen und Applikations-Virtualisierung verwendet: jeder Microservice wird in einen Docker-Container verpackt. Die CME Workbench hilft dabei, den Bruch zwischen Entwicklungs- und Produktionssystem zu vermeiden, indem relevante Technologien durchgängig verwendet werden.

Beispielsweise werden virtuelle Maschinen bereits auf dem Entwicklerrechner überwacht im Sinne eines permanenten Monitorings:

Dabei ist nicht die Darstellung die Besonderheit, sondern das automatische Erkennen der Infrastruktur: in obigem Bild werden die drei virtuellen Maschinen nicht von einem Administrator konfiguriert, sondern aus einem Ansible-Script automatisch extrahiert. Das bedeutet, wenn sich die Systemkonfiguration ändern, passt sich das Monitoring automatisch innerhalb weniger Sekunden an!

Eine Produktionsumgebung enthält wesentlich mehr virtuelle Maschinen – jedoch bleibt das Prinzip das gleiche. Wenn man später in der Produktion mit Microservice-optimierten Ops-Tools wie z. B. Instana – Dynamic APM for Microservice Management seine private oder public Cloud überwacht, dann findet man die gleiche Art von Darstellung vor:

Im Gegensatz zu traditionellen Ops-Tools wie Nagios oder Icinga, wird Instana nicht konfiguriert sondern erkennt Veränderungen automatisch und trennt über Machine Learning-Algorithmen echte Fehler von unproblematischen Unregelmäßigkeiten.

Fazit: Visualisierung hilft Probleme schneller zu identifizieren

Egal ob ein neuer Mitarbeiter zum Team stößt oder ein Kollege in den USA am Sonntag Abend bei der Fehlersuche aushilft: ein gemeinsames Bild einer Lösung zu haben und dieses Bild mit jeder agilen Iteration aktuell und jederzeit zugreifbar zu halten, ist ein enormer Vorteil.

Die CME Workbench der Consort Group bildet mit top-aktuellen Technologien, wie z. B. Angular 4, Jira- und Slack-Integration sowie der Docker API eine wertvolle Basis, um die Entwicklung von Microservices von Beginn an richtig zu verstehen und darüber eine DevOps-Kultur auf- und auszubauen!

3 Kommentare

  1. Simlock Samsung

    Danke für den umfassenden Artikel.Ich mag Deine Webseite!

Schreibe einen Kommentar zu Simlock Samsung Antworten abbrechen

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