Overview
This is a typical-engagement scenario, not a delivered customer story. A platform team runs Kong Gateway in front of its services and is considering Envoy Gateway because the organisation is standardising on the Kubernetes Gateway API. The question is how much of the current Kong behaviour can be expressed as Gateway API resources, how much needs a policy resource or another layer, and how much has to be rewritten.
Challenge
Routes and services are easy to list. The behaviour hides in plugins: authentication on some routes and not others, rate limits per consumer, request transformations written in custom Lua, and ordering rules that only matter in production. Consumers hold keys and secrets that cannot simply be copied. The team also needs to know whether the licence terms for the Kong version it runs are a reason to move at all.
Environment
Kong Gateway on Kubernetes or virtual machines with either a database or a DB-less declarative file, fronting internal and partner-facing APIs, with a target cluster running a Gateway API controller.
Approach
We start from the exported configuration, whether a database dump or the declarative file, and build one table: every service, route, plugin instance, consumer and credential, with its scope and order. Each row is classified as a direct Gateway API mapping, a policy resource, a different layer such as an identity proxy, or a rewrite. We then run a small set of representative routes through the target gateway on mirrored traffic to test matching, timeouts, retries and error responses before any estimate is fixed.
Solution
- Inventory of services, routes, plugins by scope and order, consumers, credentials, upstreams, health checks and certificates
- Version and licence check for each Kong environment, recorded for the client to confirm with Kong
- Row-by-row mapping to HTTPRoute, backend references, policy resources, another layer or a rewrite
- Secret and credential rotation plan for consumers rather than a copy of keys
- Mirrored-traffic pilot of representative routes, comparing status codes and latency per route
- Route-by-route cutover order with rollback, and a comparison against staying on Kong with independent support
- Written findings with an effort estimate per plugin class
Outcome
The team receives a complete inventory and mapping, a list of plugins with no direct replacement and what to do about each, a pilot method and a sequenced plan. It can then compare migration against staying on Kong, with independent support if needed. The engagement stops at the written plan unless the team asks AceMQ to continue.
Technologies
Kong
KubernetesEnvoy Gateway
PostgreSQL
Docker
NGINX
Redis
dbt
Kafka
