Christian S.

In meinem Team bin ich für die digitale Transformation bei unserem Kunden verantwortlich. Dabei liegt mein Fokus einerseits auf der Automatisierung von Prozessen in den Backendsystemen mittels cloudbasierter Anwendungen in Kubernetes, die eine Drools Rules Engine nutzen. Zudem arbeite ich an der vollständigen Migration des bestehenden Stacks auf die Kubernetes-Plattform. Als Leitender Entwickler habe ich die Architektur des Projekts in Abstimmung mit anderen Teams entworfen und verschiedene Technologien eingeführt.

Ein neu eingeführtes Prozess-Management-System (BSI CRM) wurde nahtlos in den Kubernetes-basierten Software-Stack integriert, der über eine auf CloudEvent basierende Event-Driven-Architektur eine äußerst stabile und nachvollziehbare Prozessautomatisierung ermöglichte. Das vorhandene Frontend, basierend auf React, wurde über RESTful APIs in den Stack integriert. Dabei wurden bei bestimmten sensiblen Schnittstellen der Prozesse Events mittels Kafka/Service Bus generiert und verarbeitet, um die garantierte Reihenfolge der Nachrichten für jeden Geschäftsvorfall (Gevo) zu gewährleisten. Die Integration erfolgte mithilfe von Graal Polyglot an unserem Kubernetes-Stack.

Externe Systeme wie SAP und andere Kernsysteme waren über eine Abstraktionsschicht (Datenzugriffsschicht) mittels GraphQL für Lesezugriffe zugänglich. Änderungen an den Entitäten der Kernsysteme bezüglich einer Order wurden ebenfalls als Events in den Stack übertragen, und die Daten wurden im zentralen Data-Store (einer relationalen PostgreSQL-/Azure SQL-Datenbank) zusammengeführt. Der Data-Store fungierte als zentraler Service zur Datenspeicherung im Stack, und verschiedene Funktionalitäten und Aktionen wurden als Services implementiert.

Die zentrale Geschäftslogik wurde mithilfe von Drools-Regeln verarbeitet, die als Artefakte in einem Nexus-Repository hinterlegt waren und vom Rules Execution Service geladen und evaluiert werden konnten. Die Geschäftslogik basierte auf den Daten im Data-Store, der basierend auf dem vorherigen und aktuellen Zustand das Change-Set erkannte und entsprechende Aktionen initiierte. Dadurch wurde die Geschäftslogik entkoppelt und konnte separat entwickelt und getestet werden.

Des Weiteren habe ich das gesamte Deployment neu aufgebaut, wobei die kontinuierliche Integration auf GitLab mit einem vollständigen GitFlow basierte. Die Container der Microservices, die auf Spring Boot 3.22 mit Webflux, Retry, Circuitbreaker, Open Telemetry, Spring Cloud Config, Spring Admin, OpenAPI und OIDC basierten, wurden mittels Unit-Tests und isolierten IT-Tests mit Wiremock überprüft, und die Code-Qualität wurde mittels SonarQube, Spotless und PMD validiert. Im Erfolgsfall wurde mittels Jib ein Container für das Branch- und Entwicklungs-Deployment erstellt. Die Spring-Konfiguration wurde in einem sicheren Git-Repository verwaltet, und im Falle eines Merges nach Master wurde mittels Semantic Release ein neuer Container als Java- und GraalVM-Multi-Arch-Binary-Image generiert. Für Entwicklungs- und Branch-Deployments wurden die Upstream-GitOps-Repositories für die Stacks mit den neu erstellten Images aktualisiert. Die versionierten Images aus dem Semantic Release wurden mittels Renovate erkannt und als Pull Requests für die Test-, Release- und Produktionsumgebungen aktualisiert. Nach dem manuellen Merge wurden die GitOps-Deployments direkt über ArgoCD bereitgestellt, wodurch ein kontinuierlicher Bereitstellungsprozess implementiert wurde. Die GitOps-Repositories basierten auf Kustomize mit Remote-Bases, und das Deployment wurde eigenständig über ArgoCD durchgeführt.

Durch die Verwendung von KEDA, Istio, Traefik und Application Gateway wurde der Kubernetes-Stack auf Basis von AKS mit einer vollständigen Implementierung von B2C AD Managed Identities, Autoscaling und Azure Vault zu einer selbstskalierenden Bereitstellung entwickelt. Diese wurde mittels EFK/Grafana überwacht, inklusive der Bereitstellung von Charts/Configs für Grafana/Kibana. Darüber hinaus wurden Kiali/Jaeger zur Analyse der Spannenverteilung im Stack eingeführt, um die Leistung, Verarbeitungsgeschwindigkeit und Prozesse des Stacks zu optimieren.

Abschließend habe ich verschiedene Automatisierungsanbindungen des Kernsystems über den neuen Stack mittels separater Automatisierungsstapel an UI Path angeschlossen, um manuelle Prozesse zu automatisieren. Zum Management des Stacks habe ich diverse Tools per NodeJs und Python zum Monitoren und Management des Stacks geschrieben.

Die gesamte Softwarelösung wurde vorab geplant und dokumentiert. Alle erstellten Software-Komponenten wurden per Markdown und PlantUml dokumentiert.

Technologien: Java(21), Graal VM native, SpringBoot 3.22, Webflux, Micrometer, Feign, Spring Retry, Spring Cloud, Spring Cloud Config, Spring Admin, CircuitBreaker, Open Telemetry, Kubernetes, AKS, Azure Functions, Kafka, Service Bus, Azure Vault, Terraform, Drools, BSI CRM, Polyglot, React, Cloud Events, Restful, PostgreSQL, CosmosDB / MongoDB, Azure SQL, UI Path, Gitlab, ArgoCD, Istio, Traeffik, Kustomize, Keda, Kiali, Jeger, Prometheus, Jib, Spotless, SonarQube, PMD, Semantic Release, NodeJS, Python3, Azure Ad, Oauth2, OPA

Die SDA ist ein Dienstleister für Versicherungen, um diese technologisch bei der Cloud Einführung zu unterstützen. Dabei wurden im Projekt sehr komplexe Systeme mit einem hohen Maß an Sicherheit und Stabilität geschaffen. So wurden ODS entwickelt und weiterentwickelt, welche in Pub/Sub und Kafka-Umfeld für die Apps der Kunden eine hoch performante Verfügbarkeit von nicht 24h Backendsystemen unterstützen sollen. Des Weiteren sind Transformationsprozesse sowie eine optimierte Deployment-Struktur in Kombination mit OIDC-Authentifikationsprozessen über Proxy-OIDC IDP, welche per Brokerage an die IDP des Kunden angeschlossen waren. Die Service Authentifizierung wurde per OIDC umgesetzt. Für die Umsetzung der Autorisierung wurde zum einen eine „Service Based Authorization“ genutzt, welche auf Basis der optionalen Scopes claims bereitstellten, die teilweise mit Daten aus den ODS angereichert waren und so eine sehr granulare Eingrenzung der User-Rechte ermöglichten. Diese Claims wurden dann per OPA (open policy agent) Sidecar mit den Policies dem Request gegenüber geprüft, um so die Nutzung von Endpoints auf Basis der Claims und Requests zu autorisieren.

Weiterhin wurden Service aus Basis von Dropwizard und Spring Boot geschaffen, um eine Lösung im EPA Umfeld zu schaffen. Dabei wurden hochperformante, skalierbare Services verwendet, welche per Kafka und Restful API ein Bindeglied zwischen EPA-Mobile-Apps und Versicherungs-Core Systemen bereitstellten. Dabei mussten Probleme wie Nichtverfügbarkeit und das Zwischenspeichern der Requests sowie Skalierbarkeit und das Übersetzen der Formate und der individuellen States gelöst werden. Die Persistierung wurde auf Basis von MongoDB umgesetzt. Da die Production unter DocumentDB laufen soll ( DocumentDB ist eine EmulationAPI für Amazon S3, die MongoDb kompatibel ist. Dabei werden allerdings nicht alle Aggregation und Projection Operatoren unterstützt). Um die atomaren Vorzüge der MongoDB / DocumentDB zu nutzen, musste unter hohem Aufwand eine native Implementierung über die MongoDb Client API umgesetzt werden, welche die atomare Speicherung mit der Nutzung von positional Operators unterstützt.

Für einen anderen Kunden wurden automatisierte Cluster und eine komplette Infrastruktur geschaffen. Zunächst mussten die Cluster auf Basis von Terraform einmalig bereitgestellt werden, welche komplette Environments mit Monitoring ( Jaeger / OpenTracing / Metrics per Prometheus und Grafana und Kibana) bereitstellten. Diese wurden dann einmalig mit Gitops-Repos gepaired und anschließend über eine eigens erstellte Services gemanaged. Dabei wurde der Enduser über eine Angular / Stencil WebUI ermöglicht, Services suchen und deployen zu lassen. Diese Service Deployments stellten eigenständige Use-Cases dar, welche automatisiert die Jeweiligen Kunden-Konfigurationen nutzen, um die Use-Cases mit den Kunden Backendsystemen zu konfigurieren. Der Austausch geschah auf Basis von Standard Cloud-Events. Somit konnten sehr komplexe Use-Cases mit vollständiger Automatisierung bereitgestellt werden, so das der Kunde diese Use-Cases in seinen Kunden bereitstellen konnte. Bestimmte komplexe Probleme wie Authentifizierung ( Kerberos, LDAP zu OIDC Mapping) mussten dabei gelöst werden. Die Deployment-Pipeline wurde auf Basis von Kustomize und ArgoCD wurde dabei komplett neu entwickelt und in der SDA neben der neuen OIDC-IDP Struktur und dem neuen Keycloak-Blueprint ausgerollt. Der Keycloak wurde auf Basis eines Brokerage aufgesetzt. Dabei wurden Custom-Flows erstellt, welche dem Kunden jegliche IDP erlaubten. So wurde Kerberos und LDAP sowie andere OIDC Provider angebunden. Das Setup war automatisiert und war im Fehlerfall binnen einer Minute wieder vollständig herstellbar. Es waren keine Backups notwendig, da alle relevanten Konfigurationen im GitOps Repo lagen und im Fehlerfall der Keycloak neu aufgesetzt werden konnte binnen sehr kurzer Zeit. Für den Endanwender war dies transparent und nicht zu sehen, da hier login flows zu bestehenden Systemen genutzt wurden, in welchen der Kunde noch über aktive Sessions verfügte. Weiterhin wurde jeweils über dedizierte Routen ein Dex IDP für die Authorizierung für den Devs und Devops hinzugefügt.

Ein weiteres Thema war die Istio-Nutzung und Einführung sowie die Service-To-Service Authorisierung. Dabei konnte innerhalb der opa-policies auf basis des Istio / Envoy header „x-forwarded-client-cert“ der aufrufende Service und der Namespace festgestellt werden. So konnte mit jedem Request ab diesem Zeitpunkt eine Eingrenzung erfolgen, welche Services einen Endpoint aufrufen dürfen und welche Namespaces. Die Konfiguration würde per Kustomize / gitops durchgeführt.

Des Weiteren wurden einige weiter Service Stacks auf Basis von Dropwizard oder Spring Boot wie beispielsweise ein Consent-Stack oder ein Submission-Stack entwickelt. Alle Services wurden im Unternehmen auf Basis von Restful Code first entwickelt. Zudem bestand im Team Produktionsverantwortung.

10/2019-05/2020

100%

Otto Group / Baumarkt Direkt

- Im Rahmen dieses Projektes wurde ein komplett neues ERP System entwickelt und eingeführt. Das Unternehmen hat drei Säulen des Geschäfts mit dem Streckengeschäft, dem Lagerverkauf und als letztes den Verkauf von selbstvermarkteter Importware. Da diese Prozesse gar nicht in die Otto Systemstruktur passen, wurde ein ERP System auf Basis OSS Odoo entwickelt, welches als Schnittstelle zum Lager und Otto dient. Über dieses ERP werden die Artikeldaten Bestelldaten, Bestände und Buchungen abgeglichen. Das Lager hat keine Schnittstelle an die Otto Systeme. Die Übersetzung der Lagerprozesse und Lagerdaten wurde über das ERP Odoo abgeglichen. Deshalb wurden zum einen interne Prozesse im ERP entwickelt und zum anderen die Schnittstellen an das Lager und zu Otto für Artikeldaten, Bestellungen und Buchungen entwickelt. Parallel dazu sind diverse Systeme wie ein Ersatzteilsystem an diese neu geschaffene Infrastruktur angeschlossen worden.

Technologisch basiert das System auf der Softwareplattform Odoo und zum anderen auf einem ESB. Über den ESB wurden via Camel diverse Quellen angesprochen und per Services oder XSLT übersetzt. Die Kommunikation geschah über SOAP, XML (Endpoint oder File), MQ (Kafka und ActiveMQ). An diesem Projekt haben drei Personen inklusive mir mitgewirkt.

Bislang gab es im Unternehmen keinerlei Virtualisierung abgesehen von VM’S als Hosts für die Legacy-Systeme. Wir haben daher eine komplett neue Infrastruktur auf Basis von Kubernetes eingeführt und alle Services und Schnittstellen in Container gefasst und diverse Schedules Container für getriggerte Aufgaben wie Artikelabgleiche und Backups entwickelt und aufgesetzt. Zudem habe ich eine komplette CI mit Tooling und Pipelines (Jenkins OSS) erstellt und die Möglichkeit zum automatisierten Release geschaffen. Da aus ökonomischen Gründen nur ein Cluster 3 Master/5 Nodes betrieben wurde, ist die Trennung vom Testing und Produktion auf Netzwerkebene Ebene über RBAC in Calico realisiert worden, um Testing und Produktion sauber zu trennen und keine zufälligen bzw. unbeabsichtigten Issues zu generieren.

- Bei Otto gibt es eine riesige Active Directory Lösung. Diese wird noch durch diverse andere Lösungen bei Subfirmen von Otto ergänzt. Ich habe bei Baumarkt Direkt die Applikation komplett in die Cloud gebracht. Das wurde auf Wunsch der Firma in einem On-Premise Cluster mit Kubernetes 1.14 dem eigenen AD und dem AD von Otto wurden dabei an KeyCloak angebunden. Der komplette Cluster mit allen Services auf Basis von Java, dem Kafka und die Clients wurden über Token per KeyCloak authentifiziert. Die User für die ERP Anwendung wurden ebenfalls über KeyCloak authentifiziert, was den Vorteil hatte, dass neben den Otto Usern auch technische User mit klarem Access verwendet werden konnten. Die Zugriffsstrukturen waren sehr Komplex wurden waren zum Teil auf Angezeigte Inhalte im ERP gestaffelt und begrenzt und wurden alle über KeyCloak gemanaged.

- Intern bei Otto ist Kafka nur als vorgeschaltete Lösung zu einem ESB in Verwendung. Wir haben einen eigenen Kafka-Cluster für den Eingang und die Verarbeitung, Persistierung der Bestell- und Produktdaten verwendet. Zudem wurde über Kafka und Spring ein Messaging / Notification-System implementiert. Dabei wurde zum einen der JMS Mechanismus, aber auch die Stream API Verwendet.

- Im kleineren Rahmen wurde Dropwizard oft für kleine, hoch-skalierte Services wie CloudFunctions eingesetzt, da dies bei den Projekten oft deutliche Kostenvorteile nach sich zog.

- Bei Otto habe ich ebenfalls als Anforderung der Rechtsabteilung den Kubernetes OnPremise Cluster unter RHEL aufgesetzt und konfiguriert in komplettem Zusammenspiel mit

KeyCloak. Die Hybrid-Cloud Lösung wurde mit OpenShift 4 umgesetzt und ich bin mit OpenShift Themen wie Beispielsweise dem Service Mesh mit Istio und Jaeger aber auch mit anderen Themen wie MultiCloud und Hybrid-Cloud vertraut. Zudem kenne ich unter Openshift die OpenShift Cloud Functions oder auch die Anbindung und Verwendung von Promenteus / Grafana oder der OpenShift CLI oder den CodeReady Containers.

Da es eine neue Richtlinie der Rechtsabteilung bei Otto gibt und Baumarkt direkt aktuell eingegliedert wird, dürfen Freelancer seit 12/2019 nicht mehr verlängert werden. Aus diesem Grund werde ich das Unternehmen verlassen.