Am 10. Juni 2026 traf sich die Java User Group Münster zu ihrem Vortragsabend bei der LVM Versicherung am Kolde-Ring.
Auf der Agenda stand das Thema Agentic AI, vorgetragen von Lars Röwekamp.
Die trion GmbH gehört zu den Hauptsponsoren der User Group und unterstützt damit den fachlichen Austausch in der Region.
Den Abend organisierte und moderierte Thomas Kruse.
Agentic AI hat deutlich über 100 Teilnehmer angezogen, was die Relevanz unterstreicht.
Large Language Models sind längst kein Forschungsthema mehr – sie landen in Produktivanwendungen.
Spring AI bringt die gewohnte Spring-Philosophie in die KI-Integration: einheitliche Abstraktionen über verschiedene Anbieter, automatische Konfiguration per Spring Boot und typsichere APIs.
Dieser Beitrag zeigt, wie man in wenigen Schritten einen ChatClient aufbaut, Prompts parametrisiert und strukturierte Java-Objekte aus Sprachmodell-Antworten gewinnt.
Wenn Systeme miteinander kommunizieren, stellt sich immer die Frage: Wie weist sich ein System gegenüber einem anderen aus?
Ein Microservice, der nachts einen Batchjob ausführt, ein CI/CD-System, das Deployments anstößt, oder ein Backend, das im Hintergrund auf eine API zugreift – all diese Szenarien brauchen eine Systemidentität.
Die klassischen Lösungen für dieses Problem – API-Keys, technische Benutzerkonten oder Shared Secrets – haben alle ihre Schwächen.
Keycloak bietet mit Service Accounts eine deutlich bessere Alternative, die auf dem bewährten OAuth 2.0 Standard aufbaut.
Wie geht es meiner Anwendung eigentlich?
Wer hierauf eine präzise Antwort haben möchte, muss die richtigen Daten sammeln.
Tut man es nicht, ist man blind unterwegs und kann bei Problemen erst spät reagieren.
In diesem Artikel beschreibe ich daher, wie man einfach und standardisiert Observability-Daten seiner Spring-Boot-Anwendung sammelt.
Sensoren, Kameras und industrielle Geräte erzeugen kontinuierlich Daten, die zunehmend direkt durch AI analysiert werden, oft in Echtzeit und möglichst nahe an der Datenquelle.
AI übernimmt mehr und mehr Aufgaben wie Vorhersage, Muster erkennung, Entscheidungsfindung und Ausführung sowie Datenmanagement. Literature Review on AI in IoT Systems
Damit solche Systeme zuverlässig funktionieren, benötigen sie eine Kommunikationsschicht, die leichtgewichtig, skalierbar und eventbasiert ist.
Genau hier kommt MQTT ins Spiel.
Das Publish-Subscribe-Protokoll wurde ursprünglich für ressourcenbeschränkte Geräte und instabile Netzwerke entwickelt, hat sich jedoch schnell zu einem zentralen Baustein moderner IIoT-Architekturen entwickelt.
Durch seinen geringen Overhead und die lose Kopplung zwischen Komponenten und Systemen eignet sich MQTT besonders gut, um Datenströme zwischen Geräten, AI-Systeme und Backend-Systemen zu orchestrieren.
In diesem Artikel werfen wir einen Blick darauf, warum MQTT eine ideale Grundlage für die Kommunikation von Agenten und Model Context Protocol (MCP) Systemen darstellt.
Geschrieben von Jonas Winkelmann am 23. Februar 2026
Wer seine Anwendungen sicher und flexibel in Bezug auf Authentifizierung und Autorisierung gestalten möchte,
findet im Open Source Identity Provider Keycloak häufig die passende Softwarelösung.
Beim Login über Keycloak werden Nutzer auf dessen Anmeldeseite weitergeleitet.
Wer jedoch bereits mit Keycloak gearbeitet hat, weiß,
dass das standardmäßige Styling der Login-Maske oft nicht zur visuellen Identität der eigenen Anwendung oder Website passt.
In den folgenden Abschnitten werfen wir einen genaueren Blick auf die verschiedenen Ansätze,
mit denen sich das Erscheinungsbild der Keycloak-Seiten anpassen lässt.
Dabei unterscheiden sich die Möglichkeiten nicht nur im Funktionsumfang,
sondern auch im Grad der Flexibilität und im benötigten Implementierungsaufwand.
Ab und zu kommen Wünsche, die sich extrem einfach mit Kubernetes umsetzen lassen würde, aber …
Kubernetes ist viel zu komplex!
Wir haben kein Kubernetes!
Es ist doch nur ein Server (aber Ausfallsicherheit brauchen wir schon) …
Wie könnte also ein unterbrechungsfreies Deployment aussehen, wenn lediglich Docker und Docker Compose zur Wahl stehen, und was sind die Tradeoffs, die damit einher gehen?
Schauen wir es uns an einem praktischen Beispiel an.
GitLab hat mit GitLab CI eine angenehme Integration von Builds in die Repositoryverwaltung.
Damit lassen sich Pipelines umsetzen, die schnelles Feedback liefern und damit helfen, die Software- und Systemqualität zu verbessern.
Die GitLab CI Runner helfen dabei, den Build zu skalieren, damit es auch hier nicht zu unnötigen Verzögerungen kommt.
Doch was, wenn der Wunsch besteht, dass genau das passiert?
Es soll bis zu einem gewissen Zeitpunkt verzögert werden, da die bisherige Anwendung noch Session-basiert ist, und zu einem Zeitpunkt mit der geringsten Wahrscheinlichkeit für Störungen das Deployment erfolgen soll.
etcd spielt in Kubernetes Clustern typischerweise eine essentielle Rolle, denn hier wird der gesamte Zustand des Clusters gehalten.
Die einzelnen Kubernetes API Server Instanzen selbst sind zustandslos.
etcd ist ein verteilter Key-Value-Store, der mit Multi-Version-Concurrency-Control arbeitet und darüber Change-Notification and Zugriff auf ältere Versionen ermöglicht.
Die Implementierung verwendet dazu einen Revisions-Zähler.
Werden Daten gelöscht, hinzugefügt oder überschrieben, so werden diese Operationen stets zu einer neuen Revision assoziiert.
Die vorheigen Zustände bleiben zunächst gespeichert, auch wenn sie überholt sind.
Damit diese quasi unendliche Geschichte nicht dazu führt, dass die Festplatte volläuft, müssen regelmäßig Wartungsaufgaben erfüllt werden.
Kubernetes speichert sämtliche Konfigurationsdaten des Clusters in einer Datenbank, typischerweise etcd.
etcd ist ein verteilter Key-Value-Store, durch mehrere Instanzen kann die Verfügbarkeit und Datensicherheit gewährleistet werden.
Damit keine Daten verloren gehen, signalisiert etcd dem Betriebssystem per fsync()-Aufruf, dass ein sofortiges Schreiben auf Festplatte erfolgen soll.
Doch etcd kann auch zum Flaschenhals werden:
Wenn keine Schreiboperationen möglich sind, ist auch die Clusteradministration blockiert.
Ein weiterer Aspekt ist, dass selbst in einem relativ stabilen Cluster kontinuierliche Aktualisierungen diverser Kubernetes-Objekte erfolgen, wie z.B. zur Leader-Election.
Das führt zu recht hoher I/O-Last und kann bei günstigen SSDs/NVMe Speichern zu schneller Alterung führen.