proof of work

Work that shipped.

Key engagements delivered as embedded lead within LiSEC Austria's Cloud Operations & Observability function — each as challenge, approach and outcome — followed by three personal builds that prove the patterns out end-to-end.

6 named engagements
3 personal builds
Azure + AWS same design, two clouds

engagements

Challenge → approach → outcome.

Enterprise Observability Modernization — OpenTelemetry & Datadog

  • OpenTelemetry
  • Datadog
  • AKS
  • on-prem

challenge

Fragmented, agent-based monitoring across on-prem Java and .NET systems and AKS made incident diagnosis slow and created vendor dependency.

approach

Directed OpenTelemetry rollout across on-prem and AKS environments, redesigned Datadog tagging architecture, and ran internal enablement through training sessions and tech talks.

outcome

Standardized telemetry collection org-wide and reduced reliance on legacy monitoring agents.

AKS Ingress Modernization — NGINX App-Routing to Istio/Traefik

  • AKS
  • Istio
  • Traefik
  • ADR

challenge

Microsoft's planned end-of-life of the AKS NGINX App-Routing extension put production ingress at risk across multi-region clusters.

approach

Led a proof-of-concept evaluating Traefik and Istio, authored an architecture decision record, and defined the migration path.

outcome

Delivered a documented ingress replacement strategy ahead of the platform's EOL deadline.

Datadog & Azure Cost Optimization (FinOps)

  • FinOps
  • Datadog
  • Azure

challenge

Uncontrolled growth in Datadog APM hosts and licenses, alongside unattributed Azure spend across a multi-customer analytics platform.

approach

Led an APM Enterprise host cost reduction initiative and built an Azure cost attribution model across the customer base.

outcome

Eliminated redundant Datadog spend and created cost visibility that hadn't previously existed for stakeholders.

Messaging Infrastructure Security — ActiveMQ TLS/AMQPS Rollout

  • ActiveMQ Artemis
  • TLS
  • security

challenge

ActiveMQ (Artemis) brokers were running without transport encryption across on-prem and analytics environments.

approach

Designed and rolled out amqps/TLS across broker infrastructure, coordinating directly with customer-site stakeholders.

outcome

Closed a security gap across production messaging infrastructure with no service disruption.

Least-Privilege Azure RBAC Design

  • Azure
  • RBAC
  • governance

challenge

The SRE support team lacked a scoped access model for the production Azure subscription, risking over-permissioning.

approach

Designed a custom least-privilege Azure RBAC role tailored specifically to SRE support operations.

outcome

Delivered a governance-aligned access model balancing operational need against security exposure.

CI/CD Pipeline Security Hardening

  • CI/CD
  • Trivy
  • CycloneDX
  • SBOM

challenge

CI pipelines for the NG platform lacked vulnerability scanning and software bill-of-materials (SBOM) generation.

approach

Integrated Trivy scanning and CycloneDX SBOM generation into shared CI templates for .NET and npm builds.

outcome

Improved supply-chain security posture across the pipeline template used organization-wide.

personal projects

Infrastructure, observability and a live app — built on my own time.

The same infrastructure design implemented on both Azure and AWS, plus a full OTel observability stack running on-prem and across both clouds — and a calorie-tracking app with real users, built and run end to end.

app.live

A calorie tracker that reads your plate — from idea to live users in days.

  • live beta
  • next.js · supabase · vercel
  • claude vision
  • otel → openobserve
  • Photo to calories, reviewed before it counts Snap a meal or type "2 rotis and a katori of dal": Claude returns schema-validated JSON with each dish, its grams (or a count, for rotis and idlis) and nutrition per 100 g. Nothing is logged until the user checks it, photos are never stored, and a per-user daily cap keeps API cost bounded.
  • Secure by default, verified not assumed Row-level security on every Postgres table, proven by a live test that signs in as a second user and must get nothing back. The server recomputes calorie plans and nutrition instead of trusting numbers from the browser.
  • Run like production, priced like a hobby Free tiers end to end. Throttled email alerts for errors, sign-ups and AI credit running out; a daily summary job that also keeps the free database from pausing; Playwright tests on phone and desktop before every deploy.
  • Observed end to end, on my own hardware, at zero cost OpenTelemetry traces and logs leave Vercel through a Cloudflare Tunnel to a gateway collector — bearer auth, redaction of URLs and emails, span-derived RED metrics, tail sampling that keeps every error — into self-hosted OpenObserve on WSL2. One photo estimate reads as a single trace: auth, three database calls, the Claude call with tokens and cost. First finding: ~650 ms per database round trip from Vercel's US region to a Seoul database.

otel.pipeline

Agent, gateway, backend — on-prem and in two clusters.

  • traces tempo
  • logs loki
  • metrics prometheus + grafana
  • Tail sampling, not head sampling Deciding per-trace before you know if it errored means you can throw away exactly the traces worth keeping. The gateway waits, sees the whole trace, always keeps errors.
  • The multi-replica bug this creates Two gateway replicas for availability means one trace's spans can land on different pods — neither sees the whole trace. Fixed with a load-balancing exporter that hashes by trace ID, so every span of one trace reaches the same replica.
  • Same design, two clusters The AKS and EKS manifests are identical except for one environment variable identifying which cluster the telemetry came from — verified with a diff, not just claimed.

infra.tf

One network interface, two clouds.

  • personal project
  • terraform · terragrunt · github actions
  • oidc auth, no stored credentials
  • Subnet model Azure spreads a subnet across availability zones automatically; AWS needs one subnet per AZ. The shared interface takes one CIDR per role either way — the AWS module carves it into per-AZ blocks internally.
  • Workload identity AKS auto-exposes an OIDC issuer the moment workload identity is enabled. EKS exposes one too, but AWS doesn't register it as a trusted identity provider automatically — that's a separate resource and a live certificate-thumbprint fetch.
  • Registry pull scope ACR pull access is a role assignment scoped to one registry. ECR pull comes from a managed policy already on the node role — free, but broader than it needs to be. Flagged in the ADR rather than quietly fixed.

contact

Have a similar problem?

Observability, FinOps, or AKS platform work — happy to talk it through.