Home on Arian Svirsky | DevOps Engineering

A Multi-Cloud Identity Platform

Mon, 01 Jan 0001 00:00:00 +0000

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.

Migrating a Security Product to Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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.

The Linux Foundation

Mon, 01 Jan 0001 00:00:00 +0000

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.

About

Mon, 01 Jan 0001 00:00:00 +0000

Staff-level DevOps / Infrastructure Engineer with 10+ years of hands-on experience. Specialized in Kubernetes, multi-cloud platforms, and production systems at scale. I’ve led infrastructure design at two very different companies — a unicorn identity startup and an enterprise security product — and taken both from “it works” to “it scales, it’s observable, and it doesn’t wake anyone up.”

Started in tech support in 2014. Moved to Linux administration, then hosting infrastructure, then eCommerce platforms, then Docker, then Kubernetes, then owning multi-cloud platforms end-to-end. Each step was a deliberate climb toward harder problems and more ownership.

ariansvi.com — Cloud-Native on a Budget

Mon, 01 Jan 0001 00:00:00 +0000

A personal website that runs on the same infrastructure patterns I use in production — but tuned to cost less than a coffee per month instead of a small car.

How it works

 git push → GitHub Actions → Artifact Registry → Cloud Run
 (lint, test, build) (Docker images) (serverless, scales to zero)

Push code → GitHub Actions lints + tests + builds Docker images → pushes to Google Artifact Registry → deploys both services to Cloud Run via gcloud run deploy. End-to-end in a few minutes. Auth to GCP is keyless (Workload Identity Federation).

Live Stats

Mon, 01 Jan 0001 00:00:00 +0000

Tools & Technologies

Mon, 01 Jan 0001 00:00:00 +0000

Not a checklist — these are things I actually use in production and have opinions about.

Kubernetes

EKS, GKE — I’ve run clusters on both. Helm for packages, Kustomize for overlays, ArgoCD for GitOps. Opinions: Autopilot is great until you need node-level access. Managed node groups are the sweet spot for most teams.

Infrastructure as Code

Terraform for cloud resources (modules, remote state, workspaces). Pulumi when the team prefers real programming languages over HCL. I’ve used both in production and can argue for either depending on the context.