Re-Submit binärer Deadletter Queue Nachrichten für den Azure ServiceBus
Für den Azure ServiceBus existieren zwei Oberflächen. Die eine Oberfläche ist eine Windowsapplikation namens ServiceBusExplorer, die ursprünglich für den Windows ServiceBus entwickelt wurde. Die andere Oberfläche ist der Azure ServiceBusExplorer, eine Weboberfläche in Azure Devops, die dem ursprünglichen ServiceBusExplorer nachempfunden wurde. Beide der Oberflächen erlauben es einzelne Nachrichten in einer Deadletter Queue neu zu versenden. Ist die Nachricht dabei binär (z.B. durch Protobuf) kodiert, so wird die Nachricht als Text interpretiert und damit unbrauchbar. Aufgabe des Projekts war es, beide Oberflächen so zu erweitern, dass das erneute Senden einzelner Nachrichten möglich war.
- Reproduktion des Problems in einem einfachen Beispiel
- Erstellung des Feature Request für Azure ServiceBusExplorer
- Erstellen und Diskussion des Issues für ServiceBusExplorer
- Implementierung einer Lösung für den ServiceBusExplorer
Self-Service Payment Portal
Lowell hatte bereits eine Onlinezahlungsmöglichkeit über das Konsumentenportal realisiert. Da der Registrierungsprozess für das Portal aber aufwändig ist und den Versand eines Briefes vorsah, wollte das Management unkomplizierte Lösungen Forderungen direkt online zu bezahlen. Im Rahmen des Projektes wurden mehrere Möglichkeiten entwickelt und umgesetzt.
- Konzept der Lösungen mit dem Geschäftsführer
- Umsetzung von drei Konzepten (Self-Service Payment Portal mit Postleitzahl, Zahlungslinkversand in dem Begrüssungsschreiben, Ad-hoc Zahlungslink an Anrufer)
- Monitoring der eingenommenen Zahlungen
- Datenschutzkonforme Gestaltung des Self-Service Payment Portals
cLean – Inkassosoftware
Lowell verfolgte mit dem Projekt cLean den Aufbau einer einheitlichen Inkassosoftware für alle Unternehmen. Dabei sollten alle Forderungen der DACH-Organisation in einem hochverfügbaren System möglichst automatisiert verarbeitet werden. Ein Hauptaugenmerk war dabei die mögliche Skalierung des Systems zu bestimmen Zeiten, in denen viele Forderungen importiert werden mussten. C# war die primäre Programmiersprache aber einzelne Services wurden mit Kotlin und Go umgesetzt.
- Architektur des Microservices-Systems
- Schneiden der Services nach den Domänen der Fachlichkeit (DDD)
- Schneiden der Daten in Aggregate
- Konzept und Entwurf eines sowohl menschen- als auch computerlesbaren Aktenzeichens
- Konzept einer unveränderbaren Buchhaltung mit Event Sourcing
- Konzept und Implementierung der Buchhaltungskomponente unter Einhaltung der fachlichen Regeln
- Recherche der Verrechnungslogik in Deutschland und Österreich
- Implementierung der Fachlogik
- Realisierung von Suchanfragen über verteilte Systeme (separater Service mittels CQRS)
- Teamübergreifendes Coaching, Schulungen und Hilfestellungen
API-First
Lowell verfolgt eine API-First Strategie. Ziel war es, die API auch außenstehenden Prozessen zur Verfügung zu stellen. Deswegen wurde eine zentrale API vollautomatisch bereitgestellt und von allen Services genutzt. Die API unterliegt strengen Richtlinien an Design und Abwärts- und/oder Aufwärtskompatibilität je nach Anwendungsfall.
- Konzept und Erstellung eines zentralen API-First-Repositories auf Basis von Protobuf
- Automatisierte Erzeugung von Release und Pre-Release Versionen für mehrere Programmiersprachen für die Optimierung der Entwicklungsgeschwindigkeit
- Konzept einer API-Versionierung
- Erstellen von APIs
- Dokumentation der API
- Review von APIs mit primärem Fokus auf Verständlichkeit, Dokumentation und Breaking Changes
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