Kong Consulting & Services for Enterprises

Gateway architecture including DB-backed versus DB-less and hybrid control plane design, plugin and authentication strategy, rate limiting design, Kong Ingress Controller deployment on Kubernetes, performance tuning, and migration from other API gateways. Every engagement is staffed by a named senior engineer.

DB-less with declarative configuration suits teams that already deploy through CI and want configuration reviewed like code — no database to run, and data planes come up with known state. DB-backed suits environments needing runtime configuration changes through the Admin API, dynamic consumer registration, or plugins that require the datastore. For most Kubernetes deployments we recommend declarative configuration managed with decK or the Ingress Controller.

Policy parity first. We inventory every policy on every proxy — quota, spike arrest, OAuth, transformations — and map each to a Kong plugin or a custom plugin where no equivalent exists. Consumer credentials are migrated so clients are not forced to re-onboard. Then we shift traffic per route with weighted routing and keep the old gateway available until each route has proven itself.

It depends on which Enterprise features you actually use. If you need the developer portal, RBAC on the admin interface, vendor support, or specific Enterprise-only plugins, the license buys something real. If you are paying for it and using OSS-equivalent functionality, we will say so. Our health check includes a feature-by-feature read on this — we are not a Kong reseller.

Yes. We deploy Kong Ingress Controller with Ingress or Gateway API resources, configure plugins through custom resources so gateway policy lives alongside application manifests, and set up the control plane and data plane split where hybrid mode fits. The recurring problem we fix is configuration drift between what is in the cluster and what teams think is deployed.

The local policy is fastest and least accurate — counters are per node, so your effective limit multiplies by node count. The cluster policy is accurate but adds datastore load on every request. Redis-backed counters are the usual middle ground for multi-node deployments needing real accuracy. We pick based on how strictly the limit must hold and how much latency budget the route has.