Migration of an On-Premise Kubernetes Cluster to Azure Cloud
Initially, services were operated in an on-premise Kubernetes cluster. The goal of the project was to migrate all services to Azure Cloud. Additionally, technologies and cloud services were evaluated, utility classes and templates were created for future development, and a CI/CD pipeline was established.
- Selection of cloud services to be used in coordination with the architect
- Agreements on future autonomy of development teams
- Review of existing code and resulting best practices
- Documentation of the Transaction Outbox Pattern, idempotency, aggregates, and other useful microservice patterns
- Utility classes for sending and receiving Protobuf business events
- Creation of the CI part of the CI/CD pipeline
- Evaluation and implementation of Azure Serverless
- Setting up infrastructure using Infrastructure as Code (IaC)
- Liveness check / readiness check for services in Kubernetes
- Creation of cron jobs in Kubernetes
- Creation of C# templates for building new services
Claim Data for the Consumer Portal
Lowell's consumer portal is a central digital service platform for individuals with outstanding claims at the debt collection agency. Lowell consists of multiple companies that are separated both organizationally and technically. Several different debt collection software systems had to be mapped onto a single API.
- Onboarding new Lowell subsidiaries
- Adaptations and extensions of the interfaces
- Definition of the API with a focus on compatibility
- Testing the interface locally, in the CI build, and in production (partially semi-automated)
- Rolling out the API with zero downtime in a Kubernetes cluster
- Analysis and resolution of production errors
- Reduction of the number of services, as the microservices had been cut too small
- Fixing security vulnerabilities and hardening API interfaces after penetration tests
- Guiding the development team to sustainably avoid identified weaknesses
- Defending the system architecture against external security auditors
Schleupen.CS 3.0 – Architecture and Framework
The Schleupen.CS software solution is a distributed application with numerous functional and technical components, aimed at providing a standardized and configurable software solution for the energy and water sector across different market roles. The "Architecture and Framework" team works directly with the enterprise architect and handles all cross-cutting concerns of the backend. The team's tasks involve creating cross-team best practices, design patterns, and a framework for over 100 developers, so that the architecture is implemented as consistently as possible across the many different applications.
- Development and consolidation of the application architecture
- Reducing dependencies between teams through better modularization of the framework
- Development of SOAP services for platform components
- Analysis, design, and implementation of a new deployment solution based on Puppet
- Writing and automating CoffeeScript (a JavaScript dialect) unit tests
Persistence Problems
The newly introduced Continuous Delivery pipelines exposed non-reproducible persistence problems. Distributed transactions could not be completed under load. Since Schleupen.CS 3.0 has only a single database, no distributed transactions should have occurred at all. The task of the project was to analyze and resolve these problems.
- Analysis of log entries, error messages, and code to systematically narrow down the issue
- Analysis of NHibernate and its internal handling of transactions
- Concept and implementation of a clean but complex solution for new applications
- Concept and implementation of a quick but somewhat hacky solution for existing applications
- Documentation of both solutions
- Training sessions on the solutions
- Implementation of the clean solution in the platform components
Legacy Pub-Sub Solution
To comply with legal requirements for smart meters (intelligent electricity meters), it was necessary to establish a communication solution between Schleupen.CS 2.0 and 3.0. This had originally been excluded from the initial architecture but became necessary for business reasons.
- Concept for asynchronous communication between separate systems
- Mapping Pub/Sub queues in a database
- Implementation of generic receiver and sender solutions
Stabilization of Asynchronous Communication – Business Components
When distributed systems communicate asynchronously and messages are lost, it is very difficult to find out where they go missing. Since the previous project had shown that the errors were no longer in the platform components, the team's task was to provide solutions within the framework to support the business developers.
- Concept and implementation of the Transaction Outbox Pattern in the framework
- Documentation of the Transaction Outbox Pattern
- Training sessions on idempotency and the Transaction Outbox Pattern
Stabilization of Asynchronous Communication – Platform
When distributed systems communicate asynchronously and messages are lost, it is very difficult to find out where they go missing. The task of the project was to analyze the existing code and identify and fix weaknesses in the platform components. Solutions were also developed to increase the confidence of testers and developers in the platform components.
- Concept and implementation of the Test Message Pattern