Architect / Area Owner

Das Projekt zielt darauf ab, die Produktivität von fachlichen Entwicklern einer Meldewesenplattform zu erhöhen, indem es die Entwicklungsplattform optimiert. Dabei wird GIT als Basis für die Speicherung und den Zugriff auf fachliche Codeartifakte genutzt und zahlreiche Ineffizienzen der bestehenden Plattform behoben

Java, Git, Json, Kubernetes, Micro Services

Lead Architect / Area Owner / Developer

Das Projekt entwickelt eine Datenzugriffsschicht, die die physische Datenhaltung abstrahiert und die Performance und Skalierbarkeit für Batch- und Onlineoperationen verbessert. Die Lösung nutzt Microservices, GraphQL, ClickHouse und Calcite, um die Anforderungen an die Datenarchitektur zu erfüllen.

Neben den funktionalen Anforderung diente das Projekt auch der nachhaltigen Weiterentwicklung der bestehenden Software. Im Zuge dessen wurde von mir eine cloudfähige Zielarchitektur und ein Migrationspfad für die bestehende Anwendung definiert. Dies umfasste auch eine cloudbasierte DevOps Infrastruktur und Anpassungen des Technologiestacks im Sinne einer nachhaltigen Wartbarkeit und darauf basierendem Testframework für Unit und Integrationstests.

Testautomatisierung über die gesamte Testpyramide hinweg, inkl. Performance Test für kritische Operationen waren wichtiger Bestandteil der Qualitätssicherung. Dabei laufen die Tests elastisch in der Cloud und belegen Resourcen nur solange benötigt.

Java, SQL, Spring Boot, ClickHouse, Calcite, Oracle, GraphQL, REST, Kubernetes, GKE, Micro Services, JUnit, TestContainers, Apache Kafka, (Apache Cassandra evaluiert),, VisualVM, Postman, DevOps, CI/CD, Agile (Kanban), Relational Algebra Optimization

Lead Developer

Analyse eines Memory Leaks bei der Ausführung einer komplexen und verteilten Batch Verarbeitung mittels Apache Spark. Die Herausforderung bestand darin, dass die Speicherallokation durch die Java Prozesse selber - also der Java Heap - in Ordnung schien. Nach weiterer Analyse stellte sich heraus, dass auch kein Problem mit der Allokation von Off-Heap Memory in Java erkennbar war. Im weiteren Verlauf konnte ein Problem der nativ eingebunden zlib Library Version identifiziert werden, die in der Kundenkonfiguration zum Schreiben der Parquet Files verwendet wurde. Dies war beim Test durch den Softwarehersteller nicht aufgefallen, weil dort standardmäßig nur die Snappy Kompression getestet wurde.

Apache Spark, Java, VisualVM, pmap

Java, ClickHouse, Calcite, Oracle, GraphQL, Kubernetes, GKE, Micro Services, VisualVM