Seit heute gibt es am Kiosk das neue iX-Developer-Sonderheft über moderne Softwareentwicklung.
Darin enthalten ist ein Artikel von mir über das Entwickeln von Microservices auf Basis von Vert.x, Kotlin und dem OpenAPI Code-Generator.
Das Besondere an unseren Workstreams ist, dass Holistikönner*innen sie eigenverantwortlich ins Leben rufen, gestalten, verändern und unter Umständen auch wieder zu Grabe tragen. Je nachdem, ob sich die Crew und die im Laufe der Lebensdauer gesammelten Erfahrungen für oder gegen ein Thema aussprechen. Dadurch leben und verwirklichen wir die eigene Agilität. Nun hat sich ein neues Glanzlicht emporgehoben: Event-Driven Microservices.
Aber wir starten am Anfang….
Die Microservice-Architektur hält Einzug in die Unternehmens-IT und findet immer mehr Einsatz in internen Systemen. Sie beschränkt sich schon lange nicht mehr nur auf Internet-Systeme mit hohen Anforderungen an Skalierbarkeit und Ausfallsicherheit. Damit werden zunehmend komplexe Geschäftsabläufe in Unternehmens-Architekturen implementiert. Die monolithischen Prozessanwendungen müssen weichen und werden durch mehrere zusammenwirkende Microservices ersetzt. Dies ist positiv, stellt aber auch neue Herausforderungen an die Systeme.
Unsere fleißigen Kolleginnen und Kollegen sind viel auf Konferenzen unterwegs. Wir halten interessante Vorträge und Workshops. Wir richten Meetup- und User-Group-Treffen aus. So tragen wir unser Wissen weiter und engagieren uns in der Community.
Im Jahr 2018 sind bzw. waren wir u.a. vertreten auf der OOP in München, auf der JavaLand Konferenz in Bonn (siehe Foto), auf dem Global Scrum Gathering Minneapolis, USA und auf der SEACON in Hamburg.
Unser Themenspektrum ist vielfältig. Wir widmen uns Technologie-Themen wie beispielsweise Microservices, Continuous Integration/Delivery/Security, Web Performance und Cloud Computing.
Enterprise-Architektur-Themen wie zum Beispiel BPM und Prozessautomatisierung decken wir ebenso ab wie den agil-methodischen Bereich. Agile BPMN-Projekte, Anforderungserhebung und Liberating Structures sind hier nur einige unser Schwerpunkte.
Weiterhin gewinnt auch bei uns der Aspekt der Smart Data immer mehr an Bedeutung.
Für mehr Details zu unseren Veranstaltungen besucht einfach unsere Homepage: www.holisticon.de.
Oder stöbert durch die Kategorie Veranstaltung hier im Blog.
Foto: JavaLand Konferenz in Bonn von Jan Weinschenker – Lizenz: Creative Commons BY
Die Entwicklung des Frameworks TracEE schreitet mit großen Schritten voran, so dass wir (Daniel, Tobi und ich) bald die erste Version mit stabiler API herausbringen wollen. Was TracEE genau ist, hatten wir in einem vergangenen Blog-Beitrag bereits sehr ausführlich erwähnt. In wenigen Sätzen erklärt: TracEE erzeugt einen Invocation-Context im MDC und sorgt mit den Bindings dafür, dass dieser bei allen Aufrufen mitgegeben wird. Alle Log-Einträge enthalten diese Informationen und lassen sich so einfach nachvollziehen. Vor allem für das Monitoring von Microservice-Architekturen ist ein solcher MDC in den Log-Meldungen wünschenswert: Ein Frontend-Service empfängt einen Request und ein Filter erzeugt eine InvocationId. Dieser Service ruft zwei weitere Microservices auf, die getrennt deployed werden. Egal ob REST, SOAP oder etwas anderes: TracEE trägt den MDC des Logging-Frameworks weiter — es überträgt den MDC sogar im Response wieder zurück! Wir nennen diese Abbildung TPIC – TracEE Propagated Invocation Context.
In einer Aggregation der Log-Einträge (z.B. über Splunk oder einen ELK-Stack – ElasticSearch, Logstash, Kibana) werden die Zusammenhänge mittels invocationId und (pseudonymisierter) sessionId sichtbar:
Durch diese IDs wird überhaupt erst sichtbar, dass Alice auf einen Fehler im Programmablauf aufgelaufen ist — und nicht Bob. Da das Backend z.B. via REST angesprochen wurde, sind die aus Application-Servern bekannten Thread-IDs bei der Korrelation von Log-Meldungen nicht sehr hilfreich.
TracEE ist und bleibt weiterhin OpenSource und auf GitHub verfügbar. Da wir das Projekt aber nicht als alleiniges Holisticon-Projekt sehen und uns über jegliche Mithilfe, konstruktive Kritik und Code-Beiräge sehr freuen, haben wir das Repository in eine eigene GitHub-Organisation verschoben. Zudem haben wir die Context-Logger aus dem Hauptprojekt herausgelöst und in ein Tochter-Projekt überführt. Auch die Beispiele wurden in ein separates Repository verschoben und helfen dir bei der Integration in deine Projekte.
Apropos Integration: Uns erreichte die Kritik, dass die Dokumentation zwar die Zusammenhänge gut erklärt, die Integration mit den einzelnen Technologien aber überarbeitungswürdig ist. Diese Module heißen Bindings und übertragen z.B. den TPIC von einem Apache CXF-Client auf einen JaxWS-Server. Diese Dokumentation haben wir für sämtliche Bindings nachgepflegt und über die Hauptseite verlinkt. Auch die Unterseite der Bindings enthält die entsprechenden Links.
Des weiteren wurden viele Technologien abseits des JavaEE-Stacks als Binding integriert. Neu seit dem letzten Blog-Artikel sind folgende Integrationen:
Diese wurden in Teilen von den ersten early-adoptern implementiert und in Form von Pull-Requests an das TracEE-Projekt gegeben. Interessant an dieser Stelle sind die Quartz-Scheduler. Diese oft für die Batch-Verarbeitung genutzten Jobs werden zeitlich gesteuert und stellen somit eigentlich keinen echten Request dar. Trotzdem möchte man durch einen Job ausgeführte SOAP- oder REST-Anfragen auch diesem Job zuordnen können. Daher haben wir beschlossen, den Begriff RequestId durch das generellere Konzept einer InvocationId abzulösen.
Zuallererst: Du integrierst einfach mal TracEE in dein Projekt und berichtest uns und der Welt von den Vorzügen eines einheitlichen Contextes. Bei Fragen und Problemen freuen wir uns auf dein Feedback oder deine Beiträge auf Github. Für die schnelle Hilfe haben wir für TracEE einen Gitter-Kanal eingerichtet.
Außerdem arbeiten wir gerade an einer Integration in Spring WS und überarbeiten gerade die Context-Logger-Struktur. Falls Du noch immer nicht überzeugt sein solltest, kannst du auch auf unsere Blog-Serie warten. In dieser werden wir auf die Vorzüge eines zentralisierten Log-Systems eingehen und zeigen, wie TracEE und Context-Logging dir hilft, z.B. Bugs oder Abläufe über die Systemgrenzen besser nachzuvollziehen. Und irgendwann dann werden wir die 1.0 releasen.