ZEE5 partnered with Wohlig Transformations to prepare its Google Cloud estate for live streaming of the FIFA World Cup 2026. Over June and July 2026, Wohlig delivered an architecture review of the production estate, reversible networking designs in Terraform for QA and production, an observability approach, and an SRE/DevOps agent built on Google’s Agent Development Kit, with 6 agent roles, 95 read-only tools and 27 runbooks. The agent runs as a pilot on ZEE5’s UAT environment.
Project Overview
ZEE5 is the multi-language streaming platform of Zee Entertainment Enterprises Ltd., serving movies, TV, originals and live sport on web, mobile and connected TV. A tournament such as the FIFA World Cup 2026 (11 June to 19 July 2026) puts live traffic into sudden, sharp spikes, so the platform’s Google Cloud estate has to be understood, observable and changeable under control.
Wohlig began work days before the opening match, with project-level read-only access to ZEE5’s Google Cloud estate and alongside ZEE5’s platform team and Google Cloud specialists. The work ran as four workstreams under one principle: read broadly, change only through review. Those workstreams were an architecture review, networking design, an observability approach, and an SRE/DevOps agent. Event-support readiness for the tournament window (scoped 12 June to 19 July 2026) ran alongside them.
The Challenge
1. A short runway for a high-stakes event. The engagement began days before kick-off, and live sport arrives in sudden spikes. Evidence had to be gathered quickly and had to be right.
2. A deep request path with limited visibility. Traffic passes through a CDN edge, load balancing, API management, GKE Autopilot clusters, a managed service mesh and private service connectivity. The managed mesh exposes few proxy-level metrics, and coarse histograms or summed restart counters can mislead. Teams risk acting on measurement artefacts rather than causes.
3. Locked-down, change-controlled production. Private cluster control planes, service perimeters, read-only access and a production change freeze across the tournament meant every fix had to be advisory, prepared as code and reversible.
4. Night-time operations need fast, safe evidence. Clusters, logs, metrics, traces, repositories and caches sit in different tools. Operators need one place that gathers evidence without being able to break anything.
Key Objectives
Understand the estate: map the production Google Cloud estate end to end, read-only.
Test with evidence: investigate latency questions with raw data rather than assumption.
Prepare reversible change: write networking changes as Terraform for QA and production, each with a one-variable rollback.
Read the data correctly: define an observability approach that avoids common metric pitfalls.
Gather evidence safely: build an agent that reads broadly and can change things only through reviewed pull requests.
Be ready for the event: prepare support and enablement for the tournament window.
The Solution: Evidence first, changes reversible
Architecture review
Wohlig mapped the production estate and delivered 6 documents: an architecture review, latency findings, recommendations, open questions resolved, verified references and an access-gaps note. The estate (reported) comprises 4 GKE Autopilot clusters (primary and restricted in Mumbai, two disaster-recovery clusters in Delhi), a Shared VPC, Private Service Connect between clusters, a managed Cloud Service Mesh, Apigee, and external HTTPS load balancing with Cloud Armor behind a CDN edge.
Hypothesis-driven investigation
The latency work is described here as a method. Wohlig framed hypotheses across the request path (edge and API layer, mesh gateway, private networking, workload health), queried raw data through read-only Cloud Monitoring and gcloud, compared client-side and server-side measurements, and had an independent verifier re-query live data for each hypothesis. Tail latency was read from raw histogram buckets, restart behaviour from per-pod changes, and cost from the billing export. The output was 11 numbered recommendations in 5 priority tiers (P0 to P4).
Recommendations delivered (themes)
Connection reuse on cross-cluster paths (P0); gateway CPU sizing, load distribution and pre-scaling before match windows (P1); health-checked private-connectivity endpoints (P2); mesh proxy metrics, tail-latency measurement and per-pod restart alerting (P3); address-space headroom, disaster-recovery version alignment and retry-policy scoping (P4). Each is a change to be sequenced through ZEE5’s change control; adoption by ZEE5 is to be confirmed.
Observability approach: 18 component groups
Wohlig read 18 production component groups through ZEE5’s existing telemetry: the primary and restricted clusters, disaster-recovery clusters, mesh ingress gateway, Private Service Connect attachments and endpoints, the Apigee-to-GKE path, Cloud NAT, edge load balancing and Cloud Armor, Apigee, Cloud DNS, authentication and entitlement services, playback and ad-tech services, two subscription services, plan management, a long-poll service, the web server-side rendering tier, the transactional database, and GKE billing. Wohlig did not create new dashboards or alert policies; it shared one PromQL panel query for connection counts. Two external data services are invisible from Google Cloud telemetry and were covered by advice only.
Networking design in Terraform (QA and production)
Two work-streams, each with isolated QA and production trees:
Hybrid NEG: replaces a bare Private Service Connect backend with a hybrid network endpoint group over several health-checked endpoints (2 in QA; 20 planned in production). A toggle, active_backend = psc | hybrid, switches traffic on the imported existing backend service.
Apigee to GKE over HA VPN: two VPN legs from one reusable module, route export over the service-networking peering, and two DNS records switched by dns_target = psc | vpn.
Each environment holds 19 resource blocks of 13 types (2 stacks and 1 module). QA ships teardown scripts so the apply, verify, cutover and rollback sequence can be replayed. In QA, work-stream 2 is reported complete and work-stream 1 was dry-run; production is prepared but not applied, pending ZEE5’s change window and inputs.
SRE/DevOps agent (pilot)
Built on Google ADK 2.3 with Gemini on Vertex AI, deployed as a pilot on a ZEE5 UAT bastion. 6 addressable roles (a coordinator and 5 specialists: GKE workload, observability, GitOps, application infrastructure and data, foundations and networking) plus 1 deterministic triage pipeline that runs three evidence branches in parallel and fuses them into one root-cause analysis. The agent holds 95 read-only tools across 8 systems: GKE 21, GitHub 19, Cloud Logging/Monitoring/Trace 13, Coralogix 16, Redis 11, Terraform docs 9, repository files 4 and gcloud 2. Its only write path is 6 pull-request tools whose output a human reviews and merges; Coralogix is a read-only source for logs, metrics and the service map.
Read-only is enforced in 4 layers: viewer-tier IAM on the agent’s own service account; an IAM Deny backstop (planned); read-only MCP surfaces with per-agent allowlists; and a default-deny guardrail plugin. Local tests re-run in October 2026 passed: 14 of 14 guardrail tests, 5 of 5 configuration tests, and a regression gate that allowed 32 read cases and blocked 33 mutation cases. 27 runbooks cover connecting, securing, deploying and operating the agent, and a single-file operator console provides streamed chat, a live tool timeline and per-query cost.
Key Benefits & Results
Diagnosis
Previous: latency questions on the cross-cluster path, with limited mesh-level visibility.
Our Solution: structured hypotheses, raw-data queries and independent verification.
Result: 6 review documents and 11 prioritised recommendations delivered (reported; adoption pending confirmation).
Network change
Previous: network-path changes could only be proposed under the production freeze.
Our Solution: Terraform for two work-streams, with one-variable cutover and rollback.
Result: QA trees complete (reported); production trees prepared, not applied (planned).
Operations
Previous: evidence scattered across clusters, logs, metrics, repositories and caches.
Our Solution: a read-only, pull-request-only agent with 95 tools and a triage pipeline.
Result: pilot on UAT with passing test gates (verified); 27 runbooks and a console shared with ZEE5’s platform team.
Platform-level outcome metrics are not part of this case study.
Technical Innovation
1. Reads direct, changes by pull request, enforced four ways. The agent cannot reach a mutating tool even if its model is manipulated: IAM, tool servers, per-agent allowlists and a default-deny plugin each block it independently, and start-up assertions fail the service if a write tool ever appears in a read set.
2. Deterministic triage. Parallel evidence branches and a single synthesiser replace free-form routing, so each analysis is reproducible and auditable.
3. Tooling that fits a locked-down estate. A self-hosted GKE MCP server reaches private control planes from the bastion; small in-process Redis and gcloud tools replaced upstream servers that did not work against the estate.
4. Reversible infrastructure-as-code under a freeze. Existing backend services are imported, every cutover is a one-variable change, and QA can be torn down and replayed.
5. Measurement discipline. Raw buckets for tail latency, per-pod deltas for restarts, and the billing export for cost.
Wohlig’s Approach
Map read-only: build the estate map from cloud APIs, with project-level read access.
Frame and test hypotheses: use raw data, with an independent verifier per hypothesis.
Design reversible change: write Terraform with a one-variable cutover and rollback, then dry-run in QA.
Build safe tooling: an ADK agent whose only writes are reviewed pull requests, gated by tests.
Prepare the event: run readiness sessions, a QA network test and a scoped night-window support model.
Hand over: deliver documents, Terraform trees, 27 runbooks and the operator console.
About ZEE5
ZEE5 is the streaming platform of Zee Entertainment Enterprises Ltd. (ZEEL), one of India’s largest media companies. It offers movies, TV, originals and live sports in multiple languages across web, mobile and connected TV.
About Wohlig Transformations Pvt. Ltd.
Wohlig Transformations is a Google Cloud Premier Partner and a CNCF partner, with 40+ GCP certifications. Founded in 2016, Wohlig has offices in Mumbai (HQ), Toronto, London, Bangalore and Delhi, and delivers GenAI, Cloud Migration and DevOps engagements for enterprises.
Detailed Case Study Presentation: