Volkswagen Group
99.9% availability, by design
Multi-AZ AWS infrastructure defined as code, ensuring 99.9% availability for the GENWIN web platform.
- AWS
- Multi-AZ
- Infrastructure as code
- Clean Architecture
Services
Cloud platform engineering on AWS and GCP
I design highly available platforms on AWS and GCP and the delivery pipeline to run them: multi-AZ architecture defined as code, Kubernetes, GitOps and CI/CD that your teams operate without me. Recent work includes a multi-AZ platform ensuring 99.9% availability for Volkswagen Group and a software factory for 12 teams at Inserm.
What platform engineering means here
Teams lose time to infrastructure built by hand and to pipelines that every project configures differently. Platform engineering replaces that with a shared, versioned foundation: infrastructure defined as code, environments that can be rebuilt, and delivery pipelines that enforce the same quality gates everywhere.
High availability is a design decision, not a setting. A multi-AZ layout keeps the platform serving when one availability zone fails; how far to go beyond that depends on the availability target and what it costs.
Text description of the diagram
Users reach the platform through load balancing across availability zones. Inside one AWS region, application instances run in more than one availability zone, which is what a multi-AZ design provides: the platform keeps serving when a single zone is unavailable. The infrastructure is provisioned as code (IaC), and the architecture ensured 99.9% availability.
What gets designed
-
Multi-AZ architecture
Application instances spread across availability zones behind load balancing, with the whole environment provisioned as code so that it can be rebuilt.
-
Infrastructure as code
Terraform for environments on AWS and GCP, reviewed and versioned like application code.
-
Kubernetes and GitOps
Kubernetes platforms operated through GitOps (Argo CD or Flux), so the desired state lives in Git.
-
CI/CD and quality gates
Standardised pipelines with GitLab, Nexus and SonarQube, scaled from one team to a company-wide software factory.
-
Migration and documentation
Guidance for moving legacy applications to microservices, with architecture documents (DAT) and decision records that your teams keep.
Typical deliverables
- Multi-AZ architecture and infrastructure as code (Terraform)
- Kubernetes, GitOps and CI/CD standardisation, up to a company-wide software factory
- Observability and quality gates
- Legacy-to-microservices migration guidance
- Architecture documentation (DAT, ADRs)
Who this is for
- Platform and engineering leaders who want consistent delivery across many teams.
- Organisations that need a web platform to stay available when a zone fails, and to be rebuilt from code.
- Teams modernising a legacy application toward microservices on AWS or GCP.
How it works
How an engagement runs
Four steps, each with something you can hold in your hands.
-
Talk
A 30-minute call. You describe what you are building and what is blocking it. I tell you honestly whether I can help.
-
Map
I review what exists and design the target: a reference architecture and decision records that your team can challenge.
-
Build
I work inside your team on the hard parts: the gateway, retrieval, agent actions, the pipelines. You get code, not slides.
-
Hand over
Evaluation gates, runbooks and dashboards, so your team can run the platform and change it without me.
Related work
Case studies
Inserm
One software factory for 12 teams
40+ projects on automated CI/CD and 50% fewer manual interventions, on HDS-compliant infrastructure.
- GitLab Enterprise
- Nexus
- SonarQube
- Kubernetes
SNCF
A data marketplace with 90,000 users
Spring Boot microservices on managed GCP services, with observability built in from the start.
- Spring Boot
- Microservices
- Google Cloud Platform
- Managed services
Guides
Enterprise AI platform architecture: a reference guide to the five layers
A reference architecture for an enterprise AI platform: AI gateway, retrieval, agent actions, evaluation and identity, and the order to build them in.
Common questions
What is multi-AZ and when is it enough?
Multi-AZ spreads a workload across several availability zones in one cloud region, so the platform keeps serving when one zone is unavailable. A multi-region design also protects against a regional failure, at higher cost and complexity. The availability target decides which one you need.
What is a software factory?
A software factory is a standard delivery platform that every team uses: the same CI/CD pipelines, artifact repository, code-quality checks and deployment rules. At Inserm I built one for 12 teams on HDS-compliant infrastructure.
Do you work on AWS or GCP?
Both. The Volkswagen Group platform is on AWS and the SNCF data platform runs on managed GCP services.
Can you help migrate a legacy application?
Yes. I led the technical side of a migration from Struts on Java 8 to Spring Boot microservices on Java 21 at RATP.
Last updated:
Need a platform that stays up?
Describe your platform and its availability target. After one call you will know whether I can help and what I would do first.
+33 6 02 73 49 22 me@osmanrami.fr