Software-Engineer

2/2023 – 5/2026

Im Konzern der REWE Group war das Produktteam „Authentication & Authorization Platform“ (kurz AAP) die zentrale Anlaufstelle für alle Authentifizierungsanfragen. Je nach Authentifizierungsart unterscheiden sich die Anbindungen und Authentifizierungsflow grundlegend (einige Beispiele: Benutzername und Passwort, Chip Authentifizierung an Kassensystemen, NFC-Chips, Yubikeys, Authenticator Apps, uvm.).
Um die Vielzahl der Anfragen (200 Millionen pro Woche) zu verarbeiten, sind mehrere Keycloak Instanzen in einem Kubernetes Cluster innerhalb der Google Cloud Platform bereitgestellt. Diese Keycloak Instanzen sind mit selbst entwickelten Erweiterungen bestückt, um die teils individuellen Authentifizierungsprozesse abbilden zu können.
Eine von vielen Erweiterungen kümmert sich um Audit Events, die neben in ein Kafka Topic geschrieben werden. Diese Events werden von diversen Backends konsumiert und Folgeaktionen durchgeführt.
Eine weitere zentrale Erweiterung war für die Synchronisation von Benutzerdaten aus unterschiedlichen Quellsystemen verantwortlich. Hierbei wurden Userinformationen aus diversen Datenquellen wie LDAP-Verzeichnissen, REST-basierten Services sowie der Entra Graph API aggregiert und konsolidiert. Die aufbereiteten Attribute wurden anschließend im Keycloak persistiert und den angebundenen Anwendungen im Rahmen der Autorisierung über Json Web Tokens (JWT) zur Verfügung gestellt, um eine feingranulare und konsistente Zugriffskontrolle über Systemgrenzen hinweg zu ermöglichen.
Des Weiteren werden für den Keycloak diverse Spring Boot Backends im selben Cluster mit PostgreSQL Datenbanken bereitgestellt, die Entitäten für den Keycloak verarbeiten.
Da die zentrale Anwendung höchste Verfügbarkeit aufweisen muss, stehen neben üblichen JUnit und Integrationstests auch End-to-End Tests mittels Cypress zur Verfügung, die vor und nach Änderungen Funktionen mittels GitLab Pipeline sicherstellen. Im Entwicklungsalltag wurde zusätzlich gezielt Prompt Engineering eingesetzt, um KI-gestützte Tools wie GitHub Copilot und Claude Opus effektiv in den Entwicklungsprozess zu integrieren. Durch präzise formulierte und iterativ verfeinerte Prompts konnten komplexe Anforderungen effizient in Code für Keycloak-Erweiterungen, Spring-Boot-Services sowie Testfälle überführt werden, was sowohl die Entwicklungsgeschwindigkeit als auch die Codequalität nachhaltig verbesserte. Um zusätzliche Sicherheit und Verfügbarkeit zu gewährleisten, existieren weitere Keycloak Instanzen in Systemkritischen Einrichtungen wie zum Beispiel den Lägern der REWE. Hier wird mittels selbst implementiertem Backend per REST Ressourcen des zentralen Keycloaks in die dezentralen Keycloak dupliziert. Diese dezentralen Keycloaks stellen auch in einem Offlinefall die Möglichkeit sich in den Lägern anmelden zu können.
Darüber hinaus umfasste der Aufgabenbereich auch umfangreiche DevOps-Tätigkeiten. Dazu zählte die Konzeption, Pflege und Weiterentwicklung von CI/CD-Pipelines, um die eingesetzten Keycloak-Instanzen regelmäßig und sicher auf aktuelle Versionen zu aktualisieren. Aufgrund der hohen Verfügbarkeitsanforderungen wurde ein Blue-Green-Deployment-Ansatz umgesetzt, bei dem neue Keycloak-Versionen parallel ausgerollt und der produktive Traffic kontrolliert über Kubernetes-Ingress-Ressourcen umgeschaltet wurde. Auf diese Weise konnten Updates und Konfigurationsänderungen ohne Downtime durchgeführt und Risiken beim Rollout minimiert werden. Die Google Cloud Platform wird mittels Terraform (Infrastructure as Code) verwaltet und erweitert.
Gearbeitet wird im agilen Kontext nach Scrum. Wobei diverse DevOps Tätigkeiten in Kanban Boards festgehalten wurden. Zum Team gehörten 6 Backend Entwickler, 3 Frontend Entwickler, 1 Testentwickler, 1 Requirement Engineer, 1 Solution Architect, 1 Product Owner und 1 Scrum Master.

Software Architecture, Softwareentwickler

12/2022 – 1/2023

In einem Greenfield wurde das Projekt Alley gestartet. Alley ist eine App, die Patienten bei Knie- und Hüftarthrose unterstützen soll. Patienten können von Ihrem Hausarzt einen Freischaltcode verschrieben bekommen, der den Zugang zu der App gewährleistet. In der App bekommt der Patient Tipps rund um die Behandlung, Präventionsmaßnahmen, wissenschaftlichen Artikeln und Fitnessübungen.
Da die App in der Medizinbranche eingesetzt wird, ist diese großen Qualitätsstandards unterlegt, die in regelmäßigen Abständen in Audits überprüft wurden. Eine genaue Entwicklerdokumentation, sowie diverse UML-Diagramme gehörten somit zur Bearbeitung von Tickets dazu.
Gearbeitet wurde agil nach Scrum. Zum Team gehörten vier Backend Entwickler, ein Scrum Master und ein Product Owner Team.
Das Frontend der App ist mit Angular entwickelt und vom Backend gekapselt. Das Backend ist microserviceorientiert und besteht aus rund acht Services. Jeder dieser Spring Boot (Version 2.7) Applikation ist in einer eigenen Dockerinstanz gebaut und in einem Kubernetes Cluster deployt. Die Kommunikation zwischen den Endpunkten wurde mit REST realisiert.
Es wurde mit der Versionsverwaltung GitLab gearbeitet. Für die Entwicklerdokumentation stand der Atlassian Stack zur Verfügung.
Um die hohen Qualitätsstandards der Medizinbranche und den Audits gerecht zu werden, wurden neben den Dokumentationen ein hoher Wert auf die Testabdeckung gelegt. Die Tests wurden größtenteils in JUnit und Cucumber geschrieben und deckten einzelne Methoden aber auch REST-Schnittstellen und Integrationstests ab. Diese wurden in der Pipeline mittels Sonarqube automatisch ausgewertet.
Als Identity Provider wurde Keycloak verwendet. Dieser wurde konfiguriert im Cluster deployt und diente zur Authentifizierung und Authorisierung aller Services.

Softwareentwickler, Software Architecture

12/2021 – 12/2022

In einem Greenfield wurde das Projekt Secure Service Hub gestartet. Ziel dieser Webanwendung ist es, Produktionsmaschinen über eigeninstallierte Hardware zu vernetzen und die hochgeladenen Informationen Maschinenherstellern und/oder Kunden zur Verfügung zu stellen.
Der USP der Webanwendung war es über das Frontend 3rd Party Applications auf die EdgeDevices zu installieren, die an den Maschinen gekoppelt waren. Dabei wurden mittels Serverless Functions in der AzureCloud Manifeste und Webhooks an ein IoTHub übergeben und auf den gewünschten EdgeDevices die darin erhaltenen Docker Containern deployt. Der Status der Installationen wurde wiederrum über ein ChangeRequest vom IoTHub an eine weitere Serverless Function übergeben, in eine MongoDB geschrieben und im Frontend zur Laufzeit angezeigt.
Die Webanwendung selbst ist als Docker Container in einem Kubernetes Cluster deployt und wurde mit Typescript und React entwickelt. Im Backend stehen rund 25 weitere Microservices im Cluster bereit, die mit Java Spring Boot 2.7 entwickelt wurden. Für die
Kommunikation zwischen den Services und dem Frontend wurde ein Gateway Service (Apollo Client) bereitgestellt, der die Föderation des GraphQL Schemas verwaltet.
Über den Standard OPC UA kommunizieren die Produktionsmaschinen mit Hilfe der vor Ort installierten Hardware. Auf der Hardware können über die entwickelten Webanwendungen Apps deployt werden, die in Docker Containern auf einem Linux System installiert werden.
Für die Qualitätssicherung wurden neben den JUnit / Jest Tests auch Integrationstest mittels Cucumber und E2E Tests mittels Cypress geschrieben.
Neben den genannten Services stehen auch viele weitere Ressourcen über die Azure Cloud zur Verfügung. Zum Beispiel: Azure SQL DB oder MongoDB für Backend Services, Kafka zur asynchronen Kommunikation, Blobstorages für die Dateiablage, das Azure Cluster mit allen notwendigen Keys und Routing Konfigurationen, Azure Functions als Serverless Service, IoTHub, Azure AD und AD B2C für die Benutzerverwaltung, Elastic für Monitoring und Logging, Azure Pipelines für ein automatisiertes Continuous Integration und Continuous Delivery, Azure DevOps für alle notwendigen Entwicklertools, App Registrations für die Verwaltung von außenstehenden Azure AD’s und viele weitere Ressourcen.
Um die Infrastruktur im Azure Portal sicherzustellen, wurden alle Ressourcen mit Terraform versioniert und angewandt. Dafür gab es für jede Umgebung der vier Systemlandschaften ein eigenes Directory im Azure Portal.
Gearbeitet wurde im agilen Umfeld mit 14-tägigen Sprints, einem Scrum Master, einem Product Owner und rund zehn Entwickler pro Team. Die Reviews fanden vor internationalen Stakeholdern auf Englisch statt.

Softwareentwickler, Software Architecture