Solutions Architect at Tigera, the company behind Project Calico
I make enterprise Kubernetes security land in real customer environments.
That means designing the architecture, proving it in a PoC on the customer's own
platform, and building the tooling that makes the next one faster.
Ten years in networking, from trackside transit systems to multi-cloud container
platforms.
Fair warning: I will over-engineer a demo until it feels like a magic trick.
A pre-sales architect role on paper. In practice it splits three ways, and the
third one is where I spend the time nobody asks me to.
Architecture & proof
Design the target state, then prove it on the customer's own platform rather than
a slide. Microsegmentation, egress control, observability, runtime threat detection,
mapped to PCI, NIST and ISO 27001 obligations.
Platform automation
Repeatable environments instead of hand-built ones. Terraform, Packer, cloud-init
and a pluggable provisioner contract so a new Kubernetes distribution is a module,
not a rewrite.
AI-augmented delivery
I build the agent tooling my own role runs on: diagnostics, meeting intelligence,
issue triage, document generation. Not experiments. Daily-driver tools with
real workflows behind them.
02
Selected work
Five things worth showing. One is live and public, three are systems I built end to
end, and one is a body of published enablement material.
A set of interactive web pages that explain a container security platform to
prospects and internal teams. Not diagrams in a deck. Clickable component
architecture with OSS, Enterprise and Cloud editions, step-through "how it works"
walkthroughs, and a wizard that assembles a reference architecture for your
industry and priorities.
Each page is a single self-contained HTML file: inline CSS and JS,
embedded images, no build step, no dependencies. Light and dark themes, deep-linkable
state, hosted on GitHub Pages. Built solo and iterated through two rounds of UX
review with a designer and a principal architect panel.
Why it was hard
The architecture had to stay technically exact while being legible to a
non-specialist buyer, and it had to degrade gracefully across editions so one
page could serve three different products without lying about any of them.
Outcome
Shipped to production as a page on tigera.io, and handed to the web team with an
integration guide covering the embed, what is editable, and how copy changes are
made.
Type a slash command in Slack, pick a platform and a size, and a headless agent
provisions a real Kubernetes cluster on AWS, tags every resource with your name,
and reports back in the thread. A web console shows every live cluster, who owns
it, and lets you or your manager tear it down.
Built to replace a dated AWX and Ansible setup for an internal team doing support
reproduction, SRE debugging and pre-sales demos. The design bet is a
pluggable provisioner contract: every platform implements the same
plan, create, status and destroy interface, so adding a distribution is a new module
rather than a fork. Currently five platforms: EC2 kubeadm, EKS, AKS, RKE2 and OpenShift.
Architecture
Slack Socket Mode bot as the front door · Fargate job runner for long provisions ·
Packer golden AMI so cluster software is baked once, not installed per node ·
Terraform-enforced IAM tagging so untagged resources cannot be created ·
Secrets Manager for all credentials · a cost reaper that finds and reclaims
orphaned infrastructure · read-only Lambda behind a static console.
What I am most pleased with
Forced attribution. Every resource carries its owner from the moment it exists,
which turned "who left this cluster running" from an archaeology exercise into
a dashboard column.
Architecture pattern, drawn generically. Platform names and internal identifiers
omitted: this is a private project.
Private work. Happy to walk through the design and the decisions behind it in
conversation.
CatScan
prototypeCrewAI · MCP2026
Agentic diagnostics for support bundles · Python / FastAPI / React
Upload a customer diagnostic bundle, get triage back. A multi-agent pipeline reads
the archive, works out which components are actually unhealthy, gathers only the
evidence that bears on the problem, and writes up what it found. Built as a
FastAPI service with a React front end and a five-stage crew:
read, triage, gather evidence, validate, report.
The domain knowledge lives in code rather than in a prompt. A component map covers
the whole stack, apiserver through typha, kube-controllers, manager, log storage and
its several aliases, compliance, intrusion detection, guardian and monitoring, and a
health model reasons over available, progressing and degraded rather than
pattern-matching log lines.
The hard part was token economics, not diagnosis
A diagnostic bundle runs to hundreds of megabytes and a model can see a fraction
of one percent of it, so which fraction is the entire problem. I gave it a
per-file size cap, a fixed evidence budget, tail-line limits, and seed globs so the
highest-value files, cluster version and node state, get read before anything else
competes for the context.
The model does not get the last word
A deterministic validator grades every answer before it is returned. It has to cite
real file paths out of the bundle and show its evidence in fenced blocks, and if it
fails either check the response comes back with the gaps called out rather than
reading like a clean finding. Rules rather than a second model on purpose: the
check needs to be cheap, repeatable and explainable to whoever reads the output.
Where it led
It talks to a hosted documentation MCP server over SSE and adapts that server's
tool schemas into the model's own function-calling format. That experiment is the
direct ancestor of the Calico MCP server now wired into my daily workflow, which
is the part of this project I got the most out of.
Built on Gemini 2.0 Flash at the time. A working prototype rather than a shipped
product, and the reason I knew what the production version needed to be.
Record a call and get a diarized transcript, minutes with owned action items, and
drafted follow-ups. Capture, transcription and diarization run
entirely on the laptop and the audio never leaves it. The
reasoning steps call a model only when you invoke them. Roughly what Gong or Otter
or Granola do, without shipping customer conversations to a third party.
Deliberately manual rather than scheduled, which sidesteps macOS background
permission fragility and keeps behaviour predictable. Layered as a local core, an
optional connector tier for Gmail, Drive, Atlassian and Slack, and a plugin tier
where each opinionated workflow is a drop-in skill.
Why local-first mattered
The useful version of this tool listens to regulated-industry customer calls.
A cloud transcription vendor was never going to clear that bar, so the
constraint drove the architecture instead of being bolted on afterwards.
Making the demo experience worth watching
many reposmarketing & field enablement2025
Guided PoC blueprints and demo kits
I have written a lot of these: hands-on repositories that take an operator from an
empty cloud account to a secured, observable microservices application, built for
marketing campaigns and for global SA and partner enablement.
The interesting part was not the Kubernetes. It was realising that a demo repository
is a performance, not a manual. A wall of a hundred kubectl commands
teaches nothing, because the person running it has no idea what just happened or why
it mattered.
So I gamified the run
Every script narrates itself. Echoed cues set up what is about to happen and what
to watch for, then confirm what changed. The flow is paced in beats: establish the
working baseline, break something on purpose, show the blast radius, apply the
control, prove the blast radius shrank. Checkpoints between beats so nobody
proceeds on a broken cluster. Validation scripts that assert the expected outcome
rather than trusting it. Teardown that actually removes everything, because the
demo you cannot cleanly delete is the demo nobody runs twice.
Why it mattered
It turned a wall of commands into a story an SA could narrate live to a customer
without rehearsing, and made the repos usable by partners who had never touched
the product. Adopted across global SA and partner enablement teams.
Built for specific campaigns and cycles rather than as long-lived software. Listed as
authored work, not active projects.
03
Experience
Networking first, then cloud native. The transit years are why I am comfortable when
a Kubernetes problem turns out to be a routing problem.
Jan 2025 to present · Vancouver, BC
Solutions Architect, Pre-Sales
Tigera Inc. (Project Calico)
Led 15+ proofs of concept (PoCs) across Amazon EKS, GKE, AKS, OpenShift and ROSA, and VMware VKS, on SaaS and on-premises deployments and across iptables and eBPF dataplanes
Delivered 45+ technical demos and workshops covering microsegmentation, egress control and observability, mapping controls to PCI, NIST and ISO 27001 and Kubernetes workloads to Zero Trust principles
Diagnosed production incidents from diagnostic bundles and packet captures, and authored the customer-facing root cause analyses
Owned CVE and vulnerability disposition plus upgrade-path guidance for enterprise accounts, including cross-version compatibility statements
Authored public enablement repositories and demo tooling adopted by global SA and partner teams
Presented at partner webinars and Red Hat Summit Connect, and fed field findings back into product and engineering
Dec 2023 to Jan 2025 · Edmonton, AB
Lead, Systems & Network Engineering
Wabtec Transportation Canada
Led light rail transit communication deployments across North America, owning scope, budget and stakeholder alignment
Architected end-to-end transit networks on Cisco, Siemens, MOXA and OTN Systems hardware
Managed vendors and resource planning for multimillion-dollar deliverables, and defined the risk and reporting frameworks
Standardized configuration schemas and trained support teams for Tier 1 and Tier 2 operations
Jul 2022 to Dec 2023 · Toronto, ON
Senior Systems & Network Engineer
Wabtec Transportation Canada
Delivered transit communication networks across North America and APAC
Architected resilient IP schemas and integrated multi-vendor hardware
Scoped and executed upgrades with minimal service downtime
Jul 2019 to Jul 2022 · Woodbury, MN
Network Engineer
Wabtec Corporation
Designed enterprise network infrastructure and deployed monitoring for light rail systems
Wrote network policy, disaster recovery plans, and supported cross-team integration testing
Education
MS, Telecommunication Systems Management
Northeastern University, Boston · 2019
BE, Telecommunication Engineering · Visvesvaraya Technological University, India · 2016
04
Writing
Published under Tigera's masthead, which means each piece went through editorial and
technical review before it shipped. I write the explainer I wanted to find when I
first hit the problem.
Secure & Scale VMware VKS with Calico Kubernetes Networking
tigera.io/blogMar 2026
The reference architecture for running vSphere Kubernetes Service with an eBPF
dataplane, Zero Trust policy and enterprise observability. Written out of the
VKS platform work I did with a partner engineering team.
The three egress designs that actually matter, and how to pick between them. Most
teams discover they need stable source IPs the week a partner asks them to sit on
an allowlist, so this is the piece I send ahead of that conversation.
What changes about ingress, egress and lateral movement when the workload is a
model-serving stack, and which controls in Kubernetes actually address it rather
than just logging it.
The ingress-nginx wind-down and what it means in practice: the Gateway API
migration path, what breaks, and how to sequence it without a maintenance window
you cannot get approved.
The part of the job I did not inherit. Over one quarter I ran roughly
1,800 agent sessions
across cluster builds, packet-level forensics, vulnerability disposition and
customer-facing writing, and built permanent tooling out of whatever repeated.
Prove it, don't pitch it
A PoC on the customer's own platform beats any demo environment. Most of my repos
exist because I needed the same environment twice and refused to build it by hand
the second time.
Automate the second occurrence
The first time something is manual it is work. The second time it is a signal.
margay exists because provisioning demo clusters was the single biggest tax on
delivery speed for an entire team.
Agents as instruments, not oracles
The tooling I run on is tooling I wrote: four Claude Code skills for issue filing,
meeting analysis and document generation, a multi-agent diagnostic service for
support bundles, a local-first meeting stack, and two MCP servers wired into the
daily workflow, one of them talking to live clusters. Model output gets verified
against the cluster or the flow logs before it reaches a customer, never trusted on
its own.
Adversarial review before it ships
Customer-facing root cause analyses get reviewed from the other side of the table
first: once as the skeptical principal architect whose name is on the accuracy,
once as the customer engineer who has to defend it to their leadership. Errors are
much cheaper to find that way.
Write it down where the team can find it
Architecture decision records, provisioner contracts, runbooks, upgrade and CVE
delta documents. If the knowledge only lives with me, I have not finished the task.
