A self-service developer platform on GKE Autopilot. One modular Helm chart deploys a Go and a Ruby service together — and one request through both of them produces a single connected trace.
Illustrative — the real thing is one screenshot away, see “Proof it runs” below.
overview
One chart, two languages, one trace
BidFlow deploys a polyglot pair of bidding services from a single Helm chart: a Go service validates and forwards each bid, a Ruby service owns the write to Redis. Because one request genuinely crosses that language boundary, OpenTelemetry can trace it end to end — not two services that happen to sit near each other, but one connected call.
Terraform provisions GKE Autopilot, Artifact Registry, and a GCS backup bucket. GitHub Actions builds, immutably tags, and deploys both services with no downloaded credential anywhere in the pipeline — GCP trusts GitHub's own signed tokens instead.
architecture
How a bid moves through the platform
Dotted boundary is the cluster. Both services export spans to Jaeger over OTLP; Redis is snapshotted to Cloud Storage every six hours via GKE Workload Identity — no static key anywhere in that path.
proof it runs
Not just a diagram
Screenshots and a short walkthrough from an actual deploy, captured on my own GCP project.
◔
Cross-language trace
Screenshot — Jaeger UI, one trace ID showing both go-bidder and ruby-bidder spans
◔
HPA scaling under load
Screenshot or GIF — `kubectl get hpa -w` with replica count climbing
◔
CI/CD pipeline run
Screenshot — GitHub Actions run: build → push → helm upgrade, all green
▷
60-second walkthrough
Video — a bid going in through curl and the matching trace appearing in Jaeger
what this demonstrates
From resume line to running code
Modular Helm charts, Ruby/Go polyglot
one Deployment template, ranged over values.services