Umzug eines On-Premise Kubernetes Clusters in die Azure Cloud
Zunächst wurden die Services in einem On-Premise Kubernetes Cluster betrieben. Ziel des Projekts war, alle Services auf die Azure Cloud umziehen. Außerdem wurden Techniken und Cloudservice evaluiert, Hilfsklassen und Template für die zukünftige Entwicklung und eine CI/CD Pipeline erstellt.
- Auswahl der zu nutzenden Cloud-Services in Absprache mit dem Architekten
- Absprachen über zukünftige Autonomie der Entwicklerteams
- Review bestehenden Code und daraus resultierender Best-Practices
- Dokumentation des Transaction Outbox Pattern und Idempotenz, Aggregaten und anderen nützlichen Microservice Pattern
- Hilfsklassen für die Zustellung und Empfang von Protobuf Business Events
- Erstellung des CI-Teils der CI/CD Pipeline
- Evaluierung und Implementierung von Azure Serverless
- Aufsetzen der Infrastruktur unter Anwendung von InfrastructureAsCode (IaC)
- Liveness-Check / Readiness-Check für Services in Kubernetes
- Erstellung von Cronjobs in Kubernetes
- Erstellung von C# Templates für die Erstellung neuer Services
Forderungsdaten für das Konsumentenportal
Das Konsumentenportal von Lowell ist eine zentrale, digitale Service-Plattform für Personen, die offene Forderungen bei dem Inkassodienstleister haben. Lowell besteht aus mehreren Unternehmen, die sowohl organisatorisch als auch technisch voneinander getrennt sind. Dabei mussten mehrere verschiedene Inkassosoftware-Systemen auf eine API abgebildet werden.
- Anbinden neuer Subunternehmen von Lowell
- Anpassungen und Erweiterungen der Schnittstellen
- Definition der API mit Fokus auf Kompatibilität
- Testen der Schnittstelle lokal, im CI Build als auch in Produktion (teils nur halbautomatisiert)
- Ausrollen der API mit Zero Downtime in einem Kubernetes Cluster
- Analyse und Beheben von Fehlern in der Produktion
- Reduzierung der Anzahl der Services, da die Microservices zu klein geschnitten waren
- Behebung von Sicherheitslücken und Härtung der API-Schnittstellen nach Penetrationstests
- Anleitung des Entwicklerteams um erkannte Schwachstellen nachhaltig zu vermeiden
- Verteidigung der Systemarchitektur gegenüber externen Security-Auditoren
Schleupen.CS 3.0 – Architektur und Framework
Die Schleupen.CS-Softwarelösung ist eine verteilte Software mit zahlreichen sowohl fachlichen als auch technischen Bausteinen mit dem Ziel, eine standardisierte sowie konfigurierbare Softwarelösung für die Energie- und Wasserwirtschaft für unterschiedliche Marktrollen bereit zu stellen. Das Team „Architektur und Framework" arbeitet dabei direkt mit dem Enterprise Architekten zusammen und kümmert sich um alle Querschnittsthemen des Backend. Die Aufgaben bestehen darin, für die über 100 Entwickler teamübergreifende Best-Practices, Design Patterns als auch ein Framework zu schaffen, so dass die Architektur möglichst einheitlich umgesetzt wird, trotz der vielen verschiedenen Applikationen.
- Entwicklung sowie Konsolidierung der Anwendungsarchitektur
- Reduzierung der Abhängigkeiten zwischen den Teams durch besseres Schneiden des Frameworks
- Entwicklung von SOAP-Services für Plattform-Komponenten
- Analyse, Entwurf und Programmierung einer neuen Deployment-Lösung auf Basis von Puppet
- Schreiben und Automatisieren von CoffeeScript (Javascript-Dialekt) Unit-Tests
Persistenz-Probleme
Die neu eingeführten Continuous-Delivery Pipelines deckten nicht reproduzierbare Persistenz-Probleme auf. Verteilte Transaktionen konnten unter Last nicht abgeschlossen werden. Da Schleupen.CS 3.0 nur eine Datenbank hat, hätten überhaupt keine verteilten Transaktionen auftreten dürfen. Die Aufgabe des Projekts war es, die Probleme zu analysieren und zu beheben.
- Analyse von Logeinträgen, Fehlermeldungen und Code um den Fehler systematisch einzugrenzen
- Analysieren von NHibernate und dessen internem Umgang mit Transaktionen
- Konzept und Implementierung einer sauberen, aber aufwändigen Lösung für neue Applikationen
- Konzept und Implementierung einer schnellen, aber etwas getricksten Lösung für bestehende Applikationen
- Dokumentation beider Lösungen
- Schulungen in den Lösungen
- Implementierung der sauberen Lösung in den Plattform-Komponenten
Legacy-Pub-Sub-Lösung
Um die gesetzlichen Vorgaben zu Smart Meter (intelligente Stromzähler) einzuhalten, war es notwendig eine Kommunikationslösung zwischen Schleupen.CS 2.0 und 3.0 herzustellen. Diese war in der initialen Architektur eigentlich ausgeschlossen worden, wurde aber fachlich notwendig.
- Konzept einer asynchronen Kommunikation zwischen getrennten Systemen
- Abbildung von Pub/Sub-Queues in einer Datenbank
- Implementierung generischer Empfänger und Senderlösungen
Stabilisierung der asynchronen Kommunikation – Fachkomponenten
Wenn verteilte Systeme asynchron kommunizieren und dabei Nachrichten verloren gehen, ist es sehr schwer herauszufinden wo sie verloren gehen. Da das vorherige Projekt gezeigt hat, dass die Fehler nun nicht mehr in den Plattform-Komponenten lagen, war die Aufgabe des Teams, im Framework Lösungen bereitzustellen, um die Fachentwickler zu unterstützen.
- Konzept und Implementierung des Transaction Outbox Pattern im Framework
- Dokumentation des Transaction Outbox Pattern
- Schulungen zu Idempotenz und Transaction Outbox Pattern
Stabilisierung der asynchronen Kommunikation – Plattform
Wenn verteilte Systeme asynchron kommunizieren und dabei Nachrichten verloren gehen, ist es sehr schwer herauszufinden wo sie verloren gehen. Die Aufgabe des Projekts war es, den bestehenden Code zu analysieren und dabei Schwachstellen in den Plattform-Komponenten zu entdecken und zu beheben. Außerdem wurden Lösungen entwickelt, um das Vertrauen der Tester und Entwickler in die Plattform-Komponenten zu erhöhen.
- Konzept und Implementierung des Test Message Pattern