Work

Production platform work for employers. Each case study gives the context, the decisions I made with the alternatives I turned down, and what was measured afterwards.

Data PlatformDatenna B.V. · Jan 2025 - Jan 2026

Multi-Region Azure Databricks Platform

Context

Data-intensive analytics company processing intelligence data across multiple regions, requiring a modern data platform to handle 50TB+ daily data with strict governance requirements.

Problem

The existing data infrastructure couldn't scale to meet growing data volumes. Manual cluster management led to inefficient resource utilization, and lack of standardized pipelines created inconsistency across data teams. Cost visibility was poor, making optimization difficult.

Approach

Designed a multi-region Databricks platform with Infrastructure as Code at its core, implementing medallion architecture for data organization and self-service capabilities for data teams.

Infrastructure
Pulumi + Crossplane for declarative infrastructure, enabling GitOps workflows and environment consistency
Over: Terraform + OpenTofu
Why: Programming language expressiveness for complex multi-region logic; accepted smaller module ecosystem and steeper onboarding curve
Data Architecture
Medallion architecture (Bronze/Silver/Gold) with Delta Lake for ACID transactions and time travel
Over: Snowflake as a standalone warehouse
Why: ACID transactions and time travel without a separate vendor; accepted tighter coupling to the Databricks ecosystem
Cost Control
Auto-scaling clusters with spot instances, job clusters for batch workloads, interactive clusters with auto-termination
Over: Reserved instances with fixed capacity
Why: 60-70% compute savings on batch workloads; accepted cold start latency and occasional spot evictions requiring retry logic
CI/CD
Azure DevOps + ArgoCD for infrastructure, Databricks Asset Bundles for notebook/job deployments
Over: GitHub Actions + Terraform Cloud
Why: Enterprise constraint mandated Azure DevOps; ArgoCD adds drift detection and self-healing that Terraform Cloud lacks natively

My role

Led platform architecture and implementation. Designed the IaC structure, implemented auto-scaling policies, and built the CI/CD pipelines. Collaborated with data engineering teams to define self-service patterns.

Cost Reduction
35% (~€420K/year)
Processing Speed
3x faster
Deployment Automation
100%
Time to New Environment
< 30 minutes
AzureDatabricksPulumiCrossplaneDelta LakeAzure DevOpsArgoCDPython
Core PlatformPVH Europe · 2022 - 2024

Kubernetes Platform Modernization and Observability Migration

Context

Global fashion retailer (Calvin Klein, Tommy Hilfiger) running 200+ microservices on legacy VM infrastructure, facing scaling challenges and slow deployment velocity.

Problem

Weekly deployments were the norm, with each taking 2+ hours. Teams waited days for infrastructure provisioning. Observability was fragmented across tools, making incident response slow. The VM-based infrastructure couldn't efficiently handle traffic spikes.

Approach

Built a Kubernetes-native platform with self-service capabilities, comprehensive observability, and GitOps-driven deployments. Migrated services incrementally with feature flags to minimize risk.

Platform
AWS EKS with managed node groups, Karpenter for intelligent autoscaling based on workload requirements
Over: Self-managed Kubernetes or ECS Fargate
Why: Managed control plane reduces operational burden; Karpenter provides pod-level resource bin-packing that Fargate and Cluster Autoscaler cannot match
Deployment
ArgoCD for GitOps, progressive rollouts with Argo Rollouts, standardized Helm charts as golden paths
Over: Spinnaker
Why: Git-native declarative model with lower operational overhead; accepted less mature multi-cloud support compared to Spinnaker
Observability
Prometheus + Grafana for metrics; logs migrated from a self-managed ELK stack to AWS Managed OpenSearch with UltraWarm and cold tiers, automated index lifecycle policies, and Terraform modules so teams provision their own index patterns and dashboards
Over: Datadog, or self-managed OpenSearch on Kubernetes
Why: Avoids per-host pricing at 200+ services and the upgrade and patching burden of self-managed search; accepted less granular tiering control and a higher per-node cost
Migration Strategy
Strangler fig pattern - new services on K8s, gradual migration of existing services with parallel running
Over: Big-bang cutover
Why: Near-zero risk for revenue-critical e-commerce services; accepted a longer migration timeline and cost of running parallel environments

My role

Led the platform team through the migration. Designed the target architecture, built the observability stack and led the ELK to OpenSearch migration, created migration runbooks, and mentored teams on Kubernetes adoption. Personally migrated critical checkout services.

Annual Savings
€500K+
Deployment Time
2 hours → 15 min (85% faster)
Deployment Frequency
Weekly → 50+/day
Self-Service Adoption
85% of teams
Log Licence Costs
60%+ lower (ELK → OpenSearch)
Log Query Latency
40% faster
Golden Path Coverage
90%+ services
AWSEKSTerraformArgoCDPrometheusGrafanaAWS OpenSearchFluent BitHelmKarpenter
AI InfrastructuremyTomorrows · Feb 2026 - Present

Matching API Platform for Healthcare SaaS

Context

Healthcare SaaS needing a secure, EU-compliant platform for an LLM-powered clinical trial matching API. B2B API product processing de-identified medical records through multi-model LLM inference.

Problem

No existing infrastructure for the new Matching API product. Needed isolation appropriate for medical data, LLM calls to EU-resident model endpoints, SQS-driven async processing with autoscaling workers, and security controls appropriate for a regulated healthcare environment.

Approach

Delivered the product on the shared EKS cluster with its own namespace, a dedicated Karpenter node pool and per-service IAM, LLM calls through a shared LLM gateway, CloudFront VPC Origins for zero-exposure production APIs, and KEDA-driven autoscaling for async batch LLM processing.

Cluster Strategy
Shared EKS cluster over a dedicated cluster. My first ADR chose a dedicated cluster; I reversed it before production. My reading of GDPR Article 32 is that it is risk-based and does not demand cluster-level separation, while a dedicated cluster meant about two weeks of setup and seven duplicated add-ons to run
Over: Dedicated EKS cluster per product
Why: Faster delivery and one platform to operate; accepted a shared control plane, mitigated with a dedicated node pool, its own namespace and per-service IAM
LLM Access
Model calls through a shared LLM gateway rather than direct provider SDK calls
Over: Direct calls to the model provider APIs
Why: One place for EU data residency and provider fallback; accepted a shared dependency whose timeouts had to be tuned for long LLM calls
Production Ingress
CloudFront + VPC Origins + internal ALB over internet-facing ALB or API Gateway - ALB has no public IP, Shield Standard DDoS, EU geo-restriction at edge
Over: Internet-facing ALB or API Gateway
Why: ALB has no public IP, Shield Standard DDoS, EU geo-restriction at edge; accepted debugging complexity across CloudFront + ALB logs
Worker Scaling
KEDA with SQS triggers over HPA with CPU metrics - queue-depth-driven scaling matches async batch workload
Over: HPA with CPU-based metrics
Why: Queue-depth-driven scaling matches async batch workload; custom scaleOnInFlight=false and 7200s cooldown for long-running LLM tasks

My role

Owned the infrastructure end to end: wrote the architecture ADR (and the later decision to move to the shared cluster), provisioned the AWS resources, configured CloudFront VPC Origins for production, built the observability stack (Grafana dashboard with 18 panels, 8 alert rules), ran the ingress load tests, and handed over to the product team.

Production Handover
March 2026
Edge Security
No public ALB; CloudFront + WAF (6 rules)
Autoscaling
Queue-driven workers scale 1→3 in 30s (KEDA)
AWS EKSTerraformTerragruntKEDAKarpenterCloudFrontWAFv2LiteLLMSQSRDS PostgreSQLGrafanaPrometheus