Fachvorträge rund um das Thema Microservices @ JAX 2020
- von Azmir Abdi
JAX 2020: 5 spannende Tage voller Vorträge, Begegnungen und interessanter Gespräche und wir mittendrin. Als Teilnehmer mit eigenem Stand und zwei Fachvorträgen rund um das Thema Microservices.
Ein Bericht von Azmir Abdi, IT-Architekt und Teamleiter bei sidion
Das Microservices Paradigma als IT-Architektur ist immer öfter ein Thema bei unseren Kunden. So haben wir bereits in einigen Projekten monolithische Anwendungen teil- oder vollständig in die Microservices Architektur migriert. Bereits im Vorfeld ist es bei diesem Ansatz klar, dass die IT-Komplexität um vielfaches zunehmen wird. Daher ist es wichtig, den Microservices-Ansatz nur da einzusetzen, wo auch die Vorteile gegenüber den Nachteilen überwiegen. Es kam auch bereits vor, dass die durch den Microservices-Ansatz erhoffte Time-To-Market Verbesserung vom Business als notwendig eingestuft wurde, da die Existenz des Geschäfts durch die gewachsene IT-Trägheit bedroht wurde. So konnten wir mit der Migration auf die fachlich geschnittene Microservices Architektur unter dem Einsatz der Microservices Technologien auch die Agilität einführen. Dabei mussten wir am Anfang einige begleitende Anforderungen wie Infrastruktur, CI/CD-Tools, technisches Monitoring, Testing und auch fachliches Monitoring angehen und ebenfalls lösen. Über die zwei Lösungen haben wir an der diesjährigen JAX Konferenz in Mainz Vorträge gehalten.
Architektur der Integrationstests in der Ära der Microservices
Im ersten Vortrag, den ich zusammen mit meinen Kollegen Oliver Flegler gehalten habe, ging es um die Umsetzung der Integrationstests in einer Microservices Umgebung [1]. Bei den Microservices nimmt die Bedeutung der Integrationstests zu. Da die Implementierung im Vergleich zum klassischen Vorgehen verteilt ist, ist es wichtiger, das Zusammenspiel der Microservices auch zu testen. Man kann hierfür Consumer-Driven-Contracts (CDC) einsetzen, wie mein Kollege im Java Magazin sehr lesenswert beschrieben hat – siehe [2]. Es ist sicherlich möglich mit dem CDC Ansatz Abbildung der gesamten Integrationstests umzusetzen, jedoch sind diese Tests API fokussiert und legen Wert auf die Kompatibilität der Schnittstellen und nicht auf die fachlichen Anforderungen. Doch wann sind die Integrationstests vollständig? Mit Behaviour Driven Development (BDD) steht uns ein ebenfalls sehr interessanter Ansatz zur Verfügung. Beim BDD Ansatz werden die fachlichen Anforderungen unter dem Einsatz der natürlich-fachlichen Gherkin-Sprache nach Given-When-Then Notation spezifiziert. Diese Spezifikation erfolgt separat je Funktion (Feature) und pro unterschiedlichen Ablauf (Szenario). Ziel ist es, die benötigte oder vorhandene Fachlichkeit in Features und Szeanrien in Gherkin zu beschreiben und diese mit dem eigenentwickelten Testing-Code zu verknüpfen. Damit und durch die spezifizierten Beispieldaten dient so eine Spezifikation bereits als Integrationstest, da sie automatisiert ausführbar ist. Sobald die Fachlichkeit voll über die Gherkin Spezifikationen abgedeckt ist, ist auch die Abdeckung der Integrationstests vollständig. Daher ist Einsatz von BDD neben CDC ebenfalls sehr interessant und empfehlenswert.
Ein Problem bei dem BDD Ansatz ist die über die Integrationstests erzwungene Abhängigkeit zwischen zwei unabhängigen Microservices Projekten. Wie gesagt, Microservices werden eingesetzt um die Agilität zu erreichen. Dabei gilt es, die Querschnittabhängigkeiten zu vermeiden. Thema unseres JAX Vortrages [1] war wie man diese Querschnittabhängigkeiten beim BDD Ansatz minimieren kann. Durch eine bedachte Architektur ist es möglich, die einzelne Test-Schritte aus den fachlich geschnittenen Microservices mit einander zu integrieren indem die bereits implementierte Schritte wiederverwendet werden. Sprecht uns an bei Interesse hierzu.
Microservices und BPM – liebe IT, denkst Du noch an das Geschäft?
Der zweite Vortrag [3] von uns hat ebenso einen „Nachteil“ der Microservices Architektur behandelt, nämlich Business Monitoring. Durch Aufteilung der Implementierung auf den fachlich unabhängigen Bereich ist ein querschnittlich laufender Prozess gestückelt und ohne weiteres nicht mehr verfolgbar. Der Einsatz eines orchestrierenden Services oder gar einer Business Process Engine widerspricht dem Microservices-Paradigma. Wieso und wie man trotz konsequenter Einhaltung des Microservices-Ansatzes Business Prozess Management betreiben kann, habe ich bereits in meinem Artikel erschienen in Business Technology Magazin (siehe [4]) beschrieben und nochmal mit meiner Kollegin, die Geschäftsprozessmanagement an der Hochschule Heilbronn unterrichtet, Stefani Poßner ebenfalls in dem Vortrag thematisiert. In einem kleinen Ratespiel wurden die Konferenzteilnehmer sowohl mit den Begriffen der Microservices Technologie als auch den Begriffen aus der Betriebswirtschaft vertraut gemacht. Unter dem Titel: „Liebe IT, denkst Du noch an das Geschäft“ wurde an die IT appelliert, trotz des Microservices-Hypes das Geschäft nicht aus dem Auge zu verlieren und der Reverse Business Process Management (rBPM) Ansatz vorgestellt. Es ist nämlich möglich, eine saubere Microservices Architektur ohne den Einsatz einer querschnittlichen Business Process Engine oder eines orchestrierenden Services aufzubauen und trotzdem alle Business Process Management Anforderungen umzusetzen. Falls der Artikel [4] als auch der Vortrag [3] nicht ausreichend Klarheit schaffen, sprecht uns an.
Unter dem Strich können der Microservices-Ansatz und die damit verbundene Agilität für einen Unterschied auf dem Markt und für den Erfolg sorgen. Wir beraten und begleiten unsere Kunden bei der Einführung und denken daran, alle Facetten der IT und des Unternehmens auf diese Reise mitzunehmen, so dass die Migration auch gelingen kann.
Links
[2] https://www.sidion.de/275/consumer-driven-contracts-mit-spring.html
[3] https://jax.de/microservices/microservices-und-bpm-liebe-it-denkst-du-noch-an-das-geschaeft/
[4] https://www.sidion.de/275/bpm-und-microservices-die-ordnung-ueber-den-haufen-werfen.html
