I build the platforms
data teams rely on.

The foundation

My career started where most serious infrastructure engineers begin — deep in Linux. Configuring kernels, hardening servers, tracing network packets at 2am. Over 10 years I developed the kind of systems intuition that doesn't come from tutorials: Red Hat, Ubuntu, Debian environments running production workloads that couldn't go down.

Networking wasn't just a subject — it was a discipline. Routing, switching, firewalls, load balancers. Understanding the full stack from physical layer to application made me a better engineer at every layer above it.

Moving to cloud & containers

As the industry shifted, I shifted with it. AWS became my cloud of choice — EC2, S3, IAM, VPC, all the way to managed services. Docker and Kubernetes followed naturally: the same systems thinking applied to container orchestration. I've designed and operated Kubernetes clusters for data workloads, managed CI/CD pipelines with GitOps patterns, and built the tooling for teams to ship faster with fewer incidents.

Data platform engineering

Today my focus is data infrastructure. I work across the full Apache ecosystem — Kafka for event streaming, Hadoop and HDFS for distributed storage, YARN for resource management, Apache Iceberg for the table format layer. On top of that: Cloudera for enterprise distribution management and Dremio as a query engine for the data lakehouse. Apache Superset for visualisation. I understand the difference between a data warehouse, a data lake, and a lakehouse — and when to use each.

Growing into ML platforms

The natural next layer above a solid data platform is ML infrastructure. I'm building knowledge in this space — MLflow for experiment tracking and model registry, Kubeflow for ML pipeline orchestration on Kubernetes, and AWS SageMaker for managed training and deployment. I approach ML platform engineering the same way I approach everything: with infrastructure-first thinking and a focus on reliability and observability.

How I think

Platform-first. Every tool I choose must be operable at 3am, observable under load, and boring in the best possible way. I prefer the right primitive over the clever abstraction. Documentation matters. Runbooks matter. A system that only its author understands is a liability.