I design infrastructure that keeps running when parts of it don't.
Infrastructure engineer working across on-prem datacenters and public cloud. Each project shows the architecture, the trade-offs, and what happens when things fail.
From traditional VMs to production scale
6 stagesOne product, told as it grows up: a startup that launches on two servers, raises its first round, and scales into Kubernetes, then a real production estate brought under code. Each stage is the infrastructure I built at that point.
First servers on a startup budget
Two founders have an app that only runs on their laptops, and every investor demo means carrying a MacBook to the meeting. It needs to go live on AWS with no platform team and no money to spare.
~$32/mo savedThree environments and a pipeline that guards production
The product has users now, so changes need a path to production that cannot skip a check. Dev, staging and prod on AWS, a tag-only release pipeline with no static keys, and the monitoring that caught a $5,000-a-month mistake before the invoice did.
$111.52/mo savedAn immutable AWS platform for the product
The startup has raised a Series A, the team is doubling, and the CTO wants every environment reproducible from code instead of console clicks. Three environments in Terraform behind Atlantis, CIS-hardened golden AMIs scored before release, app versions pinned in SSM, and fleets that switch off outside office hours.
0 hand-edited serversContainers, and images six times smaller
The company is now a household name. Traffic spikes by orders of magnitude when the app goes viral, and the backend has grown into fourteen services, so shipping fourteen AMIs no longer scales.
137 → 23.1 MBGitOps on Kubernetes, ready for scale
The company is chasing a billion-dollar valuation, and the servers themselves have become the bottleneck. The product runs on Amazon EKS and every change reaches the cluster through git.
Git-only changesBringing a hand-built production estate under Terraform
The real thing. A regulated company runs production on cloud infrastructure that was clicked together over years, and nobody can rebuild it.
Zero-downtime imports
Previous work
3 case studies3 projects shown
SAS Viya 3.5 platform with an N-node database cluster and Kafka ingestion
A multi-machine SAS Viya 3.5 deployment with no single point of failure: one writable PostgreSQL primary with N hot standbys behind pgpool-II, an odd-N Consul quorum, and Kafka topics loaded into CAS through SAS Event Stream Processing, so any single tier can fail without losing records.
Self-hosted Kubernetes for local development, shareable on demand
A three-node kubeadm cluster on arm64 that runs my local development work on a VMware host-only network, with real names and TLS. Nothing outside my machine can reach or discover it. Egress goes through a separate NAT interface, and any service can be shared publicly on demand through a Cloudflare tunnel that dials out over that NAT. Every component ships as plain, digest-pinned manifests with a functional verification gate.
Five-node Proxmox and Ceph cluster on mixed Dell and HPE hardware
The first version of this lab cluster kept one copy of its data and lost it when a single node was corrupted. I rebuilt it on two Dell and three HPE servers so any one node can fail while VMs keep running and storage keeps serving. Hardware alerts catch failing parts early, fencing makes failover safe, and drifted nodes return to the CIS Level 1 baseline without anyone logging in.
Skills by environment
Production experienceOn-prem
- Proxmox
- VMware
- Ceph
- MinIO
- HAProxy
- keepalived
- Ansible
Cloud
- AWS
- Terraform
- EKS
- Route 53
- S3
- CloudWatch
Shared
- Kubernetes
- Postgres
- GitLab CI
- Prometheus
- Grafana