Lead DevOps / SRE.
I build the bridges between
systems that refuse to talk.

The foundation under every framework below. A curated, versioned Terraform module library covering networking, compute, data, security, and observability primitives across GCP, AWS, and OCI. Each module ships semver-pinned, terratest-covered, OPA-policied, tflint-clean, with auto-generated docs from variables and outputs. Deprecations follow a published window — never a surprise. Modules are the contract between the platform team and everyone who consumes the platform.

A multi-cloud Kubernetes substrate that every workload runs on. Cluster provisioning via the Terraform module library (GKE, EKS, OKE), with cluster-wide concerns standardized rather than re-invented per team: CNI (Cilium / native VPC CNI), the Kubernetes Gateway API for ingress and routing (deliberately moved off the older Ingress + NGINX pattern for cleaner platform / app-team separation), network policy and service mesh (Istio or Cilium) for mTLS and east-west traffic control. Autoscaling is tuned in two dimensions — Karpenter and cluster autoscaler for nodes, HPA + VPA for pods. External Secrets Operator pulls from cloud secret stores so no plaintext secrets live in Git. Velero handles backup and DR, with periodic restore drills (DR plans you haven't tested are wishes). Prometheus + Grafana for in-cluster metrics, recording rules for SLO math, remote-write into the broader observability stack. Pod Security Standards and namespace-scoped RBAC keep multi-tenancy honest. App delivery rides on top via Kustomize for env-specific manifests and Argo CD + Helm for GitOps. Cluster and node upgrades are scripted, zero-downtime, and routine — not events.

The GCP AI substrate: Vertex AI workbenches, model endpoints, training jobs, and Gemini access — provisioned through the Terraform module library. The interesting work isn't the model infrastructure itself; it's the developer access layer around it. Engineers building agents and AI workflows authenticate through short-lived service-account tokens with role assumption (the same pattern as Workload Identity Federation for CI), not long-lived API keys scattered across .env files and laptops. IAM scoping by team and project tier; access requests flow through the identity framework (PRJ-007), so manager approval is the gate, not Vertex AI console access. The result: AI engineering teams move fast without scattering keys, and security knows exactly who has access to what model.

The CI/CD parallel of the module library: a curated, versioned set of reusable GitHub Actions workflows and Concourse pipeline templates that every team calls into instead of copy-pasting YAML. Build, test, lint, scan, sign, publish, deploy — each step lives once, gets tested, and is versioned independently. Consumer repos reference the library with a single pinned line (uses: org/.github/.workflows/build.yml@v3.2.1). Composite actions handle the standard scaffolding: cloud auth via OIDC and Workload Identity Federation, secret rotation, OPA policy gating, SonarQube quality checks. The library is the contract for what "shipping software" looks like at the org — owned centrally, consumed everywhere, deprecated on a published window.

A self-service abstraction: devs write a small YAML or JSON file describing what they need (a service, a bucket, a vault, a queue). The framework validates against JSON Schema, applies OPA policy, picks the right Terraform module + version, and produces a fully planned change. Same input file works across GCP, AWS, and OCI — the headline pattern that the next three frameworks specialize.

An application-team specialization of the YAML framework targeting AWS workloads. Developers describe a service in a single file — runtime (Lambda, ECS task, EC2/ASG), networking, IAM, event sources, queues, buckets, databases, secrets — and the framework compiles it into a full Terraform stack with least-privilege IAM wired in by default. Same author writes lambda.fn.yaml on Monday and ecs.svc.yaml on Tuesday; the abstraction stays consistent.

A data-team specialization of the YAML framework. Analytics engineers and data engineers describe datasets, tables, views, materialized views, scheduled queries, routines, and Dataplex lakes / zones / assets in a single declarative file. The schema bakes in data classification (PII, restricted, public), access patterns, and lifecycle rules — the framework compiles it all to Terraform underneath. Data people ship their own infrastructure without ever opening an HCL file.

The framework pattern extended past infrastructure into identity. Access requests — Okta group membership, application assignment, GCP custom IAM roles & bindings, and other SaaS entitlements — flow through Jira. The requester's manager approves the ticket; the webhook pipeline validates the request against policy, then Terraform applies the change against Okta, GCP IAM, GCP Identity-Aware Proxy (IAP) bindings, and the relevant SaaS APIs. The manager never needs Okta admin rights. The requester never needs GCP project ownership. Approvers approve; the system grants. Audit lives in Jira and Git, not in a spreadsheet.

A serverless bridge between Jira and a Terraform monorepo. Jira fires a JSON webhook on ticket transition; a GitHub Actions workflow receives it, validates the payload against a JSON Schema, generates a YAML request from the ticket fields, opens a PR, runs terraform plan, and posts the plan back into the ticket as a comment. Ticket approval triggers the apply workflow, which authenticates to GCP, AWS, and OCI via Workload Identity Federation — no long-lived keys, no service-account JSON files, no static cloud credentials anywhere in CI.

An Atlassian Forge app that turns production deployment tickets in Jira into risk briefings. Every application repository ships a blast-radius.yaml declaring service information, owners, severity tier, and upstream / downstream dependencies. When a production deploy ticket is opened, the Forge app reads the YAML from the repo's main branch and renders a dynamic panel inside the issue view: what's changing, what depends on it, who owns each dependency, and the resulting blast radius. Approvers see the real risk profile before they click approve — not a hunch, not a wiki page someone last edited two years ago.

A queryable catalog of every resource running across GCP, AWS, and OCI. The inventory ingests from three sources of truth: Terraform state (for what the platform believes exists), provider APIs (for what actually exists — and therefore drift), and the per-repo blast-radius.yaml files (for ownership and dependency metadata). Resources are indexed by owner, cost center, environment, tier, region, and dependency graph edges. The catalog feeds cost attribution reports, drift detection, the Blast Radius Forge app, and the access framework's policy decisions.

Cost work that runs continuously, not quarterly. Attribution wired into every IaC tag (team, cost center, environment, tier) so the inventory produces showback / chargeback reports by ownership — not just a giant monthly bill. Infracost runs in CI on every Terraform PR and posts a dollar-delta comment before merge, so cost becomes a code-review concern instead of a billing-cycle surprise. Idle-resource sweeps from the inventory catch the long tail: orphan disks, unused public IPs, stale snapshots, dormant load balancers. Right-sizing recommendations from utilization data feed back into module defaults so the next deploy gets it right by default. For Kubernetes: spot / preemptible node pools and bin-packing through Karpenter (EKS) and cluster autoscaler (GKE / OKE). For data: BigQuery slot reservations vs. on-demand chosen by workload pattern. Commitments — CUDs on GCP, Savings Plans on AWS, RIs on OCI — sized from real consumption, not vendor sales-deck projections.

Designed and rolled out an OCI landing zone from scratch — compartment hierarchy, tag defaults, network architecture, identity domains, and logging baseline — to support the migration of production workloads from GCP and AWS into OCI. Built the IaC modules from scratch and wrapped them in the same YAML / JSON framework used elsewhere, so the application teams running the migrations shipped OCI infrastructure using a vocabulary they already knew. No second platform to learn, no second framework to maintain.