What this microservices customer was asking for, why it's different from what GKG does today, and what the gap actually is.
Based on the Apr 2026 customer conversation: 4,000+ services, Helm charts, Jenkins, API gateway.
4,000+ services across three business layers. GKG sees every line of code in every repo — but the connections between services live somewhere else entirely.
In a monolith, service A calls service B through a code import. You can trace that. In microservices, service A calls service B over HTTP — there is no import. The dependency information has to live somewhere, but it's no longer in the code.
Service calls are code imports. GKG reads these directly. The graph is in the code itself.
// PaymentController.java import com.example.order.OrderService; import com.example.notify.NotificationService; // GKG sees these imports. // It knows: PaymentController // depends on OrderService // and NotificationService.
GKG traces these imports across repos, builds the graph, answers: "what would break if I change OrderService?"
Services communicate over HTTP/gRPC. Each service lives in its own repo. There is no import to read.
// PaymentService.java // No imports of other services. // The URL of order-service is set at // deploy time via environment variable. String orderUrl = System.getenv("ORDER_SERVICE_URL"); // Where does ORDER_SERVICE_URL come from? // A Helm chart. Which lives in a // separate repo. Which GKG can't read.
The dependency is encoded in a Helm chart values file in a different repo, in YAML format. GKG doesn't index YAML.
In a mature microservices system, the information "service A talks to service B" is encoded across three separate systems — none of which are the application code.
Each service has a corresponding Helm chart repo (e.g., helm_prod_payment). The values file lists every environment variable the service gets at runtime — including the URLs of downstream services. This is the primary place service-to-service dependencies are declared.
# helm_prod_payment/values-prod.yaml env: ORDER_SERVICE_URL: http://order-service:8080 NOTIFY_SERVICE_URL: http://notification:8080 MONGO_URI: mongodb://mongo:27017/payments API_GATEWAY_HOST: https://api.example.com # This file = the inbound/outbound map for payment-service. # GKG cannot read YAML. This is invisible to it.
Jenkins pipelines reference Helm chart URLs explicitly. This creates an additional map: service repo → Helm chart repo. GKG only indexes GitLab CI/CD pipelines — Jenkins is external and not ingested at all.
// Jenkinsfile for payment-service pipeline { environment { HELM_CHART = 'helm_prod_payment' HELM_CHART_URL = 'https://charts.internal/payment' DOWNSTREAM = 'order-service,notification-service' } stages { stage('Deploy') { steps { helmDeploy(env.HELM_CHART) } } } } // GKG doesn't read Jenkins. This mapping is lost.
The API gateway is the single entry point for all external traffic. Its routing configuration is the ground truth for "what services exist and what paths they handle." This typically lives as YAML or JSON config — sometimes in a separate repo, sometimes in Kubernetes ConfigMaps. Neither is indexed by GKG.
# kong-routes.yaml (API Gateway config) services: - name: payment-service url: http://payment:8080 routes: - paths: ["/api/v1/payments"] - name: order-service url: http://order:8080 routes: - paths: ["/api/v1/orders"] # This is the full inventory of services + their routes. # Lives in YAML. GKG can't read it.
This is the actual scenario from the customer call. The payment service has code in GitLab — but its full dependency picture requires reading three other systems that GKG can't see today.
Honest breakdown. The customer's questions range from code-level (GKG can help) to topology-level (GKG is blind today).
Prioritized by impact to this specific use case. P1 items are blockers — without them, GKG gives partial value only.
Helm charts are YAML. The entire service-to-service dependency map this customer cares about lives in YAML values files. Without YAML indexing, GKG is permanently blind to the topology layer. This is the single biggest product gap for infrastructure-heavy enterprise accounts.
This customer is on-prem. GKG is not available for self-managed deployments until Q2 FY27. This is a hard blocker — they can't trial any of GKG's capabilities regardless of what else is built. Every enterprise microservices customer we're talking to runs self-managed.
The customer links services to Helm charts via naming convention: payment-service maps to helm_prod_payment. GKG today doesn't infer cross-repo relationships from naming patterns. Supporting this would mean letting customers define naming rules as explicit relationships in the graph — or inferring them automatically.
This customer runs Jenkins, not GitLab CI. GKG only indexes GitLab-native pipelines. Supporting Jenkins would require either a webhook integration (Jenkins pushes events to GKG) or a one-time import of Jenkinsfile metadata. The service-to-chart linkage encoded in Jenkinsfiles would become queryable.
The customer asked directly: "100K nodes — can GKG handle that?" We don't have a benchmark answer. Before pitching to any hyperscaler or financial services account running thousands of services, we need a tested, citable performance number for query speed and graph traversal at that scale.