From COBOL Mainframe to Cloud-Native Microservices: Building the Unified DevOps Platform for SIXT Leasing SE

The challenge

Most cloud migrations move enterprise applications, such as databases, web services and APIs, to cloud infrastructure. COBOL mainframe modernisation is a different and harder class of legacy transformation. COBOL systems, usually running on IBM Z mainframes, are the systems of record for critical business processes in financial services, insurance, leasing, automotive and retail. They were built for reliability at scale, and they deliver it: a 2022 survey for Micro Focus estimated that 775 to 850 billion lines of COBOL are still in daily use.

The problem is that mainframes become harder and harder to change. The pool of COBOL developers keeps shrinking, proprietary hardware makes scaling expensive, mainframes connect poorly to modern cloud services and APIs, and decades of tightly coupled business logic can’t be safely extracted without understanding systems whose original authors may be gone.

Decoupling a COBOL monolith into microservices is as much an infrastructure, platform and DevOps problem as a software rewrite. The extracted microservices need somewhere to run: a cloud platform built for independent deployment, scaling and operation of many services at once. Without a production-grade Kubernetes platform, a standard CI/CD mechanism, monitoring and security architecture already in place, the microservices have nowhere safe to land.

For a leasing business like Sixt Leasing SE, where product features, pricing models and regulatory requirements change all the time, the ability to deploy changes in hours instead of quarters was a competitive necessity. Finance leasing in Germany is also a licensed financial service supervised by BaFin, so security had to be part of the platform from the start.

My task: build the cloud platform, the delivery pipeline, the monitoring and the security that the new microservices would run on, and lead the DevOps team that ran them.

How do companies move away from a COBOL mainframe?

Few companies rewrite a mainframe in one go, because a big-bang rewrite of decades of business logic is very risky. The common approach is step by step. In the strangler fig pattern, named by Martin Fowler and described in AWS’s own guidance, a routing layer sits in front of the old system and sends each request either to the monolith or to a new microservice. Features move out one by one while the old and new systems run side by side, until the monolith can be switched off. This only works when the new services have a stable place to land from the first day: somewhere to run, a standard way to deploy, and monitoring and security that cover every new service.

What I did

1. Built one Kubernetes platform on AWS for all projects: Kops first, then AWS EKS

   I designed and implemented a single Kubernetes cluster as the runtime platform for all Sixt Leasing SE projects. The first cluster was built with Kops on AWS, which gave us fast initial capability. As the platform matured and the operational requirements became clearer, I led the migration to AWS EKS, the managed Kubernetes service, to improve reliability, reduce operational overhead and align with AWS-native operations. One shared cluster for all projects replaced fragmented per-team infrastructure and removed the duplicated operational work that had built up across separately managed environments.

   Technical details

   • Why Kops first: control and flexibility for the first cluster design and a quick start.
   • Why AWS EKS later: AWS runs the Kubernetes control plane, which reduces operational work once the platform is stable and the priority moves from flexibility to reliability. The move was made without disrupting running workloads.
   • Multi-tenancy: each project ran in its own namespace in the shared cluster.
   • Service mesh: Istio for the traffic between microservices in the cluster.
   • Deployments: services were packaged and deployed to Kubernetes with Helm.

2. Standardised CI/CD for all teams on Jenkins with dynamic build agents

   I designed and implemented a unified CI/CD solution based on a Jenkins server with dynamic Jenkins agents, which gave elastic build capacity that grew and shrank with demand. This single platform replaced several inconsistent delivery pipelines across the development teams and gave every project the same path to production. Build resources were created on demand and released after use, which removed the cost and maintenance of permanent build servers.

   Technical details

   • Tools: Jenkins with pipelines written in Groovy, SonarQube for code quality checks, and Helm to deploy services to Kubernetes on AWS.

3. Set up monitoring and reporting for every project on the shared platform

   I designed and implemented a monitoring and reporting solution for all projects on the shared platform. When many teams share one Kubernetes cluster, visibility becomes both more important and more complex: metrics, logs and alerts have to be separated by project and still add up to one view of platform health. The solution gave each team its own operational view and gave the platform and security teams a view of the whole company.

4. Designed the security architecture and took part in internal penetration tests

   I owned the security architecture of the whole platform: network security, access control, secrets management, and the security of the Kubernetes cluster and the CI/CD pipeline. I also took part in internal penetration testing, to check the security controls in practice as well as on paper. In leasing and financial services, security architecture is a regulatory requirement, and it has to be built into the platform from the start instead of being added after incidents show the gaps.

5. Advised Team Leads and executives, and led the DevOps team

   I took part in discussions with Team Leads and Executive managers about the future direction of IT at Sixt Leasing SE, and represented the infrastructure and DevOps view in strategic architecture decisions. At the same time I managed a team of five DevOps engineers and was responsible for their direction, delivery and professional growth. Holding both roles in the same engagement kept the platform work consistent from the architecture forum down to implementation.

Results

Over 2 years and 3 months, the work delivered:

• One Kubernetes platform on AWS for all Sixt Leasing SE projects, moved from Kops to AWS EKS without disrupting running workloads.
• One CI/CD platform for all development teams, with build capacity on demand.
• Monitoring and reporting for every project on the shared platform, with a view of the whole platform.
• A security architecture checked in internal penetration testing.
• A ready place for the microservices extracted from the COBOL monolith to land, with less duplicated work than the earlier per-team setups. Today this kind of shared platform for many teams is often called platform engineering.
• The infrastructure and DevOps view represented in executive architecture decisions.

What I learned

Mainframe modernisation fails at the infrastructure layer more often than at the application layer.

Organisations invest heavily in deciding which parts of the COBOL monolith to extract, how to split business logic into service boundaries and how to move data out of mainframe storage. These are hard problems, but they can’t be solved if the platform where the microservices land doesn’t exist, or exists as different per-team setups that are more complex to run than the mainframe they replace. That is why standardisation across teams has to come before the monolith is split. If every team builds its own Kubernetes cluster and its own CI/CD pipeline while it moves components, the organisation ends up with fragmented microservices on top of fragmented infrastructure, which is harder to operate than the original monolith.

Evidence and further reading

• Related projectReplacing Akamai with AWS and leading a 4-continent SRE teamAnother monolith, SAP Hybris, tested for a move to microservices, with DevOps and SRE teams around it.
• Related projectBuilding a Cloud Center of Excellence from zeroOne set of cloud standards for a whole company: the same idea at a larger scale.
• Service · this siteCloud migration consultingHow I plan and lead migrations to the cloud.

Sixt Leasing SE has been called Allane SE since August 2021.

Skills and technologies

• COBOL mainframe modernisation
• Monolith to microservices
• AWS
• Kubernetes
• AWS EKS
• Kops
• Helm
• Istio service mesh
• Platform engineering
• Jenkins
• Groovy
• SonarQube
• CI/CD standardisation
• Monitoring and reporting
• Security architecture
• Penetration testing
• Secrets management
• Executive architecture advice
• DevOps team leadership

← All projects