In der Enterpriseumgebung des Kunden (> 100 Microservices) ist es unabdingbar ein Live Monitoring der kritischen Geschäftsprozesse zu implementieren. Hierfür wurde der klassische Stack Prometheus und Grafana neben AppDynamics und Azure Monitoring gewählt.

Über ein Whitebox- sowie Blackbox-Testing wurden die Metriken ermittelt und nach Prometheus exportiert.
Meine Aufgabe war die Implementierung von Blackboxtests mit Playwright, Einweisung der Teams für ein strukturiertes anliefern der Metriken via Prometheus API und die Unterstützung im CI/CD Prozess für das automatische Deployment von Grafana Dashboards.

Im Rahmen des Umbaus der Softwaresysteme von einer Legacy Architektur auf Microservices in Quarkus ergibt sich ein hoher Schulungsbedarf. Mit der gleichzeitigen Einführung von Camunda, Kafka, OpenShift, Docker, Programmierung mit dem Apache Camel sowie die konsequente Nutzung von Quarkus für die Microservices braucht es einige PoC Implementierungen sowie Trainingsunterlagen und Aufgabenstellungen.

Meine Aufgabe war es diverse PoC durchzuführen, in Eigenleistung oder einem kleinen Team. Die Erstellung von Schulungsszenarien, sowie die Schulung der Mitarbeiter war eine weitere Aufgabe von mir.

API Design mit REST

• Grundlagen von Rest (Rest Prinzipien, Architekturstil)
• Rest vs SOAP
• HTTP Methoden (GET,POST, PUT, PATCH, DELETE, Header)
• Ressourcen und URIs (Aufbau und Best Practices)
• JSON, XML, Media Types,
• Hypermedia und HATEOAS
• API Design (Versionierung, Ressourcenmodellierung und Hierarchie)
• Sicherheit und Authentifizierung (Basic Auth, OAuth 2.0)

Quarkus

• Nativer Code-Kompilierung (Startzeit und Speicherbedarf)
• MicroProfile- und Java EE-Unterstützung 
• Reactive Programming (Eclipse Vert.x-Framework, async und eventbasiert)
• Dev-Mode (Entwicklungsmodus) 
• Konfigurationsverwaltung 
• Dependency Injection (CDI-Spezifikation (Contexts and Dependency Injection))
• Testing-Framework 
• Datenbankzugriff (JPA, Hibernate, Panache) 
• Metriken und Monitoring (Integration Prometheus und Grafana)
  

Docker

• Docker-Architektur (Container vs VMs, Docker Deamon, Images, Container, Registries)
• Installation von Docker und Image Erstellung (Dockerfile)
• Aktionen mit Containern 
• Docker Volumes und Persistenz (mount)
• Docker Netzwerke und Kommunikation
• Docker Swarm (Orchestrierung, Swarm Cluster)
• Überwachung und Fehlerbehebung
• Best Practices und Sicherheit
• Anwendung von Docker in verschiedenen Szenarien

Microservices Workshop

• Spring Boot Services
• Kafka als Event Bus
• Performance Tests, locust.io 
• ELK Stack - Elasticsearch, Logstash, Kibana
• Monitoring mit Prometheus und Grafana
• Service Discovery mit Consul
• Hystrix für Circuit Breaker, Timeouts, Bulkheads, Steady State, Fail Fast

Active MQ / Artemis Schulung

• Message Oriented Middleware (MOM, Publish/Subscribe, Point-to-Point, Producer, Consumer, Queue)
  
• ActiveMQ Architektur (Broker, Connector, Adresse und Queue)
• ActiveMQ/Artemis vs. Kafka
• Installation, Konfiguration und Betrieb
• Topics und Persistenzmodelle
• Routing, Transaktionen und Atomarität
• Clustering und Load Balancing/Skalierung/Replikation/Failover
• Überwachung und Management (JMX)
• Sicherheit (SSL/TLS)
• ActiveMQ und JMS

Apache Kafka Schulung

• Producer und Consumer
• Arbeiten mit dem Offset
• Performanz und wesentliche Paramter
• Serialisierung
• Arbeiten mit Topics
• Partitioning
• Transaktionen mit Kafka
• Clustering, Failover
• Header und Timestamps
• Konfigurationen
• Security und Monitoring
• Zookeeper Konsole

Teilnehmer der Schulung sind in der Lage einen clusterfähigen Kafka zu installieren, konfigurieren und fortlaufend zu kontrollieren. Darüber hinaus können die Teilnehmer ganze Teams/oder Serviceteams einweisen und denen die Arbeit mit Kafka erklären. Teilnehmer der Schulung haben selbst in Ihren Konzernen und Unternehmen Kafka installiert oder auch nach der Schulung angepasst. Die Teilnehmer stammen aus den Branchen:

• Handel allgemein
• Versicherung und Banken
• Textilbetrieb
• Lebensmittelhandel
• Druckerzeugnisse

Spring Boot 

• Actuator
• Rest mit Spring Web
• Deployment mit Docker nach Kubernetes/Openshift
• Deployment in eine Cloud Umgebung (Azure, AWS, Google Cloud, Digital Ocean)
• Domain Driven Design (DDD)
• Test Driven Development (TDD)
• Spring Data - Anbindung von postgres, Mongo DB, Redis Cache

Kubernetes

• Installation eines ausfallsicheren Clusters (Controller, Worker, etcd, kubelet, kubeadm, kubectl)
• Metrics Server für Monitoring und Autoscaling mit HPA Horizontal Pod Autoscaler
• Definition, Deployment, Betrieb, Änderungen von Pods, Deployments, Services, Ingresses, Daemon Sets, Stateful Sets, Jobs, Cron Jobs
• Konfiguration von Network, Firewall und Traffic Limits
• Kubernetes API 
• Rechtemanagement mit Serviceaccounts und RBAC Policies
• Konfiguration mit ConfigMaps und Secrets
• Überwachung mit Readiness und Liveness Probes

Der Kunde des Projekts kaufte für diverse Bereiche (Vertragsverwaltung, Partnerverwaltung, Kundenbuchhaltung) Standardsoftware dazu. Die Aufgabe bestand darin, die Verträge einer neuen Sparte in das neue Vertragsverwaltungssystem zu integrieren und Bestandsdaten zu migrieren.

Ich war dafür zuständig, die Unternehmensarchitektur aus diversen Softwarebestandteilen (Kernsystem Cobol, Java Module, Fremdsoftware) zu analysieren, die bestehenden Interaktionen fachlich zu verstehen und in die Integration der neuen Software anzupassen.
Die Modellierung der neuen Schnittstellen über Apache Kafka, Rest, SOAP sollten exakt vorgenommen werden, damit die Softwareentwicklung außer Haus sowie die internen Entwickler genaue Vorgaben haben.

• Für einen großen Bankdienstleister gibt es die Herausforderung, von einer zentralen Architektur auf eine dezentrale Architektur zu migrieren. Hierbei wurden mehrere Projekte installiert, die zum einen unterschiedliche Messaging Stacks mit Kafka vergleichen aber auch eine Streamverarbeitung für fachliche Use Cases analysieren.
• 
  
• Meine Aufgabe in diesem Projekt war es, die Mitarbeiter hinsichtlich der Apache Kafka Funktionalitäten zu schulen und zu coachen. Hierbei gab es unterschiedliche Fragestellungen zu klären - unter anderem das Mengengerüst der zukünftigen Events und die benötigten Ressourcen, die Performance von unterschiedlichen Stacks (Confluent) und deren Funktionsvielfalt sowie Logging als auch Monitoring.
• 
  
• Weiter wurde zur Umsatzabfrage eine Performance Messung mit Hilfe einer Streamverarbeitung implementiert. Diese wurde dann mit einem Spring Boot Microservice gemessen und Timestamps in einen Elastic (ELK) Stack weitergegeben. Hier wurde die Zeitmessung dargestellt und den Stakeholdern präsentiert.

Zur Erweiterung der Core Banking Software wurde der Aufbau des Integration Layers definiert. Dieser besteht aus dem  Messaging System Apache Kafka, Spring Boot Services, die in einem OpenShift Cluster betrieben werden. Meine Beteiligung in dem Projekt war neben der Beratung die Implementierung und Umsetzung von Aufgaben:

Basis Stack:

• Open Shift
• Spring Boot Services und teilw. Go Services
• Avaloq
• Jenkins
• Prometheus
• Elasticsearch, Logstash, Kibana
• Apache Kafka

Operationstasks

• Prometheus Überwachung von Services im Detail Readiness Probe während des Einleseprozesses von Apache Kafka
• Aufbaue einer Schnittstelle für alle Services um readiness Probe zur Verfügung zu stellen
• Analyse bei Operationbugs - z.B. Default Timeouts bei Kommunikation mit dem Banking Core Avaloq

Development

• Entwickeln eines Basis Microservices mit Spring Boot für neue Spring Boot Services
• Mitarbeit im Projekt Omnium / Kreditberatung
• Debugging und Bugfixing in diversen Fachprojekten
• Architektur und Struktur von Daten in Microservices NoSql und PostgresDB
• Rest Interfaces Design
• Anbindungen für Mobile Apps Zak

Für die Anbindung des Integration Layers war es notwendig tiefgehendes Wissen mit der Arbeit von Kafka zu haben. Hier wurden Mitarbeiter/Teams geschult und Wissen an diese weitergegeben. Darüber hinaus war es notwendig bei der Entscheidung der Kafka Topics zu helfen. In folgendes Fragen erfolgt die Beratung und auch die Umsetzung:

• Anzahl der Partitions pro Topic
• Eventstrukturen und deren Versionierung auf einem Topic
• Performance auf dem Client mit den Parametern linger.ms und batch.Size
• Clusterbetrieb und Failover

Für die Entkopplung der Microservices von dem ERP System war es notwendig einen Kafka zu implementieren. Dabei bestand die Aufgabe darin den Kafka in einer geeigneten und angepassten Installation auf dem Kubernetes Cluster zu installieren.

Die folgenden Entscheidungen wurden getroffen.

• Volumes pro Broker und deren Größe
• Retention Policy eingestellt
• Clients aufgrund der linger.ms und batch.size angepasst
• Eventgröße und Struktur
• Topics und deren Partitionen
• Anzahl der Cluster für das Staging
• Header Informationen und Protokoll
• Anzahl Zookeeper und Broker
• Monitoring mit Confluent Control Center und Grafana und weitere Detailentscheidungen.

Daraufhin wurde ein Kafka Adapter gebaut, der Event abhängig aufgerufen wird und dadurch Änderungen an den Artikel, Preisen, Bildern oder auch Kunden auf die entsprechenden Topics pushed.

Erstellen einer REST basierten Import Möglichkeit für:

• Kunden
• Orderdaten in das ERP-System JTL Wawi.

Die Orderdaten die aus dem Drittsystem abgerufen wurden sollten in das JTL Wawi importiert werden. Hierzu wurde ein Import Tool (Ameise.exe) via Java gewrappt und der Import sowie Command Line ausgaben via Rest zurück gegeben.

• Über JOOR sollte das B2B Orderhandling realisiert werden. Den Einkauf sowie die Bearbeitung der Orders sollte in der ERP Software JTL vorgenommen werden. Die Stammdaten wurden im ERP System gehalten.
• Die Aufgabe bestand darin, die erforderlichen Stammdaten via REST die Daten aus dem JOOR System abzugleichen. Auch einen vollständigen Sync sollte die Schnittstelle unterstützen.
• Weiter sollten aus den abgeglichenen Artikeln Linesheets erstellt werden, die dem Sales Agent die Arbeit mit Katalogen sowie App Order, Excel Order vereinfachen.
• Technik auf der Gegenseite: Python, Django
  

Erstellen der REST Schnittstelle um Daten an Drittsysteme ausliefern zu können.

• Stammdaten
• Kategorien
• Bilddaten

Die Herausforderung war es, die Daten systemspezifisch auszuliefern. So sollten Kategorien in einem rekursiven Baum dargestellt werden, Bilddaten je nach Bedarf resized werden sowie Attribute zu Artikel und Styles gesteuert werden.

Um die gewünschte Performance bei der Auslieferung zu erreichen, wurde ein Redis Cache vor die Schnittstellen geschaltet, der große Requests sehr schnell beantwortet.

• Beim Umbau der IT Infrastruktur wurde SAP und Microsoft Dynamics sowie Office CRM eingeführt. Prozesse, die über ERP Systeme bzw. CRM System hinweg abgebildet werden mussten, erfolgten über ein Mediation Layer.
• Der Mediation Layer bestand aus einzelnen Microservices, welches den Datenaustausch zwischen den System übernommen hatte bzw. Daten angereichert oder auch ganze Funktionen abgebildet hat.
  So wurde im Medation Layer das komplette CardProcessing abgebildet, da im SAP System die Performance nicht ausgereicht hat. Auch war es nicht möglich Open- to- Buy, sowie Limitstrukturen hierarchisch zu speichern. Diese Anforderung bestand, da ein Company Account Kreditkartenlimits auf unterschiedlichen Ebenen hat.
• Als Austausch für die Services diente ein Apache Kafka. Es war erforderlich, sowohl im Betrieb, als auch bei der Integration der Services Schulungen anzubieten und Unterstützung zu leisten. Auch dieser Aufgabenbereich lag in meinem Verantwortungsbereich.
  

Die Aufgabe in diesem Projekt bestand darin, die ideale Infrastruktur für eine TV Ausstrahlung mit einer gleichzeitigen Besucherzahl von mindestens 100.000 gleichzeitigen Benutzern zur Verfügung zu stellen.

Meine Aufgaben waren:
- die Optimierung der bestehenden Webseitenrequests auf ein Minimum
- die Umsetzung einer Cachingstrategie für die hohe Besucherzahl
- das Sicherstellen der ERP Auftragseingänge und die Bearbeitung dieser

Das Modestratup MOROTAI GmbH expandiert sehr stark. In diesem Zusammenhang musste ein ERP-Software eingeführt werden, die den Anforderungen von MOROTAI entspricht. Im Rahmen dieses Projekt wurde für die Auswahl eines Anbieters eine Geschäftsprozessanalyse gemacht. Diese mündeten in einer Short/Longlist für die Anbieter Kommunikation.

Im Rahmen eines Pitches hat man die passende Software ausgesucht.

In der Einführung mussten technische Anpassungen durchgeführt werden. So musste der Import der Produktdaten, Kundendaten, bisherige Bestelldaten organisiert und ausgeführt werden. Darüberhinaus musste der Logistik Prozess im Versand definiert und implementiert werden.

Aufbau einer Webpräsenz mit angeschlossenem E-Commerce WebShop auf Basis der Vision der Gründer.
Die Anforderungen waren Designvorgaben und funktionale Vorgaben, die speziell dafür angepasst werden mussten.

Hierfür wurde als Basis eine WooCommerce Installation genommen und erweitert. Eine Versionierung mit Git wurde eingeführt, die in Echtzeit über Änderungen in Slack informiert.

Funktionale Anpassungen waren für schaltende Kampagnen notwendig.
Beispiel: Ab einem Warenkorbwert von x werden Produkte automatisch hinzugefügt.

Die technische Verantwortung bestand darin, die komplette Seite von einem klassischen Hosting auf Amazon Web Services zu bringen. Angebunden waren ein Cloud ERP-System, Zahlungsanbieter. Aus den Produktdaten mussten für die Produktion Exports generiert werden.

Im Rahmen der Weiterentwicklung des Kundenverkaufsportals sind Änderungen in der bestehenden Architektur notwendig. Ziel beim Umbau ist Nutzung der bestehenden Funktionalität auf mobilen Geräten.

In einer Bankanwendung müssen gesetzliche Anforderungen umgesetzt werden. Hierbei geht es im Speziellen um die Anpassung des Kreditprozesses. Verbundpartner, die ebenfalls an den Kreditprozess angebunden sind, müssen neue Daten bekommen. Die Erweiterung einschließlich der E2E Tests wurden übernommen. Weiter ist es notwendig viele Teilprozesse technisch anzupassen wie z.B. Kreditentscheidungsprüfung, Modellrechnung, Kreditsicherheiten. Bei der Erweiterung von Services mussten entsprechend Modelle angepasst und Klassen generiert werden.

Aufbau einer Behaviour Driven Testing Implementierungs- und Ausführungsumgebung für einen neuen Teilbereich des Portals. Unterstützung und Beratung des Quality Assurance Teams für Performance- , SEO- sowie Tracking Testing. Dabei wurde die Analyse von passenden Werkzeugen sowie Prozessen evaluiert und eingeführt.

Die Aufgabe innerhalb dieses Teilprojekts waren die Planung der Kapazitäten im Team, einfordern von Ressourcen, Planung der Meilensteine und Demands für diverse Anforderungen aus der Betriebsorganisation und den Fachabteilungen. Weiter bestand die Aufgabe in der Abnahme der implementierten Funktionen und Weitergabe in das Testcenter, Report und Statusmeldung an die Großprojektleitung sowie die Budgetplanung und das Einfordern von Budgettöpfen. Die Planung für die Release Einführung den außerordentlichen Einsatz der Teammitglieder war ebenso die Aufgabe des Teilprojektleiters.

Das Kundenportal des großen Versicherungskonzerns bietet dem Kunden die Möglichkeit Verträge zu verwalten, persönliche Daten einzustellen, Schadenmeldungen vorzunehmen und viele weitere Funktionen auszuführen. Die Komplexität liegt vor allem in der herausfordernden Systemlandschaft des Konzerns. Dem Kunden ein einheitliches und durchgängiges Interface zu bieten bedarf vieler Anpassungen und Abstimmungen der Schnittstellen.

PROVI/PDB ist ein System in dem alle Versicherungsprodukte einer Sparte abgebildet werden. Aufgrund der Produktvielfalt ergibt sich eine sehr komplexe Datenbasis. Diese ist häufig Strukturänderungen unterworfen, die eine Anpassung der Weboberfläche erfordern. Darüber hinaus werden aus der Datenbank denormalisiert Daten als Container abgezogen. Diese dienen den nachgelagerten Systemen als hoch performanter Zugriff auf die Produktbasis.

Um eine neu entwickelte Zwischenschicht zu einem Rechenkern zu testen wurde das Quality Gate entwickelt. Dieses dient dazu fachliche Tests über die Zwischenschicht an den Rechenkern zu schicken und die Ergebnisse auszuwerten. Das Quality Gate hat eine Testverwaltung, eine Benutzerverwaltung sowie eine Verwaltung der auszuführenden Tests. Die Ergebnisse des Tests können in Echtzeit über eine Weboberfläche eingesehen werden.

Bei der Entwicklung/Test und Abnahme von Steuergeräten werden diverse Dokumente erstellt. Diese Dokumente enthalten Schaltpläne, Testergebnisse und Architekturinformationen. Diese werden werden im EEB dem Dokumentenmanagement System abgelegt und verwaltet. Dieses Dokumentenmanagement System bietet diverse Schnittstellen zu angrenzenden System und passt sich ideal in die IT-Landschaft des Automobilherstellers an.

Für die ?metatrader? Plattform wurde ein Plug in sowie Auswertungskomponente entwickelt. Das Plug- In lieferte zum Ende eines Trading-Tages alle gehandelten Daten an einen zentralen Server. Die Auswertungskomponente hat die Daten aufbereitet und ansprechend dargestellt.

Im Rahmen der Entwicklung von Systemen mit Hardware in the Loop und Software in the Loop Methoden wurden Dokumente erstellt die in DoRIS archiviert wurden. DoRIS besteht aus einer C# Oberfläche und einem Java Backend. Versionsverwaltung, hierarchische Dokumentenstruktur sowie Versionsstandvergleich sind einige der Use Case's von DoRIS.