Descope — identity and authentication infrastructure

Part of the platform team behind an auth product that processes millions of requests per day across 4 global regions. My remit is the boring but load-bearing part: the infra stays up, the deploys stay boring, and production never surprises us.

Scale & surface area

• 25+ microservices in one platform, running simultaneously on AWS (primary) and GCP
• 4 regions, each a fully independent production environment
• Millions of auth requests/day across customer workloads
• TypeScript + Pulumi as the IaC substrate — every cluster, every service, every env

What I own and drive

Reliability & observability — Full Datadog footprint (APM, structured logs, dashboards, SLOs) across every region. I build and maintain the dashboards on-call actually uses, set the SLO targets for services I own, and drive the runbook standard for infra-level incidents. When latency creeps in Singapore, we see it before customers do.

Deployment pipeline — Automated Sandbox → RC → Production promotion. RC ships twice a week, production weekly, hands-off unless something actually breaks. I contribute to the pipeline design and own the infrastructure changes that flow through it.

Platform IaC patterns — Module design, environment promotion, guardrails. I write the Pulumi modules other teams consume and review cross-service infrastructure changes.

Supporting systems — Temporal (workflows), RabbitMQ (messaging), Elasticsearch (search), Redis (caching), Cloudflare (CDN + WAF). I’m the operational owner on the pieces that don’t have a product team behind them.

Why it’s interesting

This isn’t one cluster with some apps on it — it’s a small-ish SaaS platform that happens to run in two clouds at the same time, with enterprise customers expecting five-nines behavior. The problems that matter aren’t “how do I deploy to Kubernetes”; they’re “how do I evolve the platform without freezing a release train” and “how do I know a regional provider issue from a regression we shipped.”

Palo Alto Networks (Cortex XSOAR, formerly Demisto) — 6 years

Joined Demisto as a DevOps Engineer, stayed through the Palo Alto Networks acquisition, left as Principal DevOps Engineer. Led infrastructure architecture and mentored a growing DevOps team through a startup-to-enterprise transition.

The hard problem: Docker-in-Docker on Kubernetes

Cortex XSOAR is a SOAR product — it runs customer automation playbooks inside Docker containers. When we moved from EC2 to Kubernetes, I led the design of how to securely run Docker-in-Docker inside Kubernetes pods.

This isn’t a “just add privileged mode” situation. This is a security product. Customers run untrusted integration code. Container escapes aren’t theoretical — they’re the threat model.

I drove the solution end-to-end:

• Designed a custom container runtime configuration to eliminate the privileged requirement
• Authored network policies for strict workload isolation
• Set resource limits that hold under dynamic scheduling
• Owned the security review process and got sign-off from the PANW security org

The migration shipped and became the standard deployment for enterprise customers.

Ownership across 6 years

• CI/CD architecture — Led the migration from Jenkins to GitLab CI; defined shared-library patterns used across the R&D org
• AWS infrastructure — Terraformed all of AWS (VPC, EKS, RDS, S3, IAM, Route53); owned cost, security posture, and DR strategy
• Observability transformation — Drove migration from Nagios to Prometheus + Grafana; defined the SLO and alerting standard
• Post-acquisition integration — Led integration of Demisto infrastructure into the Palo Alto Networks ecosystem (IAM, networking, compliance)
• Principal responsibilities — Made architecture decisions, mentored engineers, and represented infrastructure in cross-org technical reviews

2014–2018 — inManage, Interhost Networks, Calanit

Before Kubernetes existed in my vocabulary, I was managing Linux servers, configuring DNS zones, hardening firewalls, and writing Bash scripts that are probably still running somewhere.

Interhost Networks was web hosting infrastructure — hundreds of customer sites, shared servers, the kind of environment where you learn DNS, SSL, and Apache configuration by necessity. When something broke at 2am, there was no Kubernetes self-healing. You SSH’d in and fixed it.

inManage was eCommerce — this is where I first started containerizing things with Docker and realized that infrastructure could be version-controlled, reproducible, and not terrifying.

The early years gave me the foundation that everything else is built on: Linux, networking, troubleshooting under pressure, and the conviction that automation isn’t optional.