One gateway topology instead of four teams' worth of entry points

Overview

Kong is usually adopted one team at a time, and the result is several independently configured gateways with incompatible auth, inconsistent logging, and no shared view of what is exposed. Consolidating them is an architecture problem before it is a Kong problem.

Challenge

Four business units had each stood up their own gateway. Authentication varied between API keys, JWT, and mutual TLS with no common consumer model. Configuration was applied by hand in some environments and by declarative config in others, so promotion between environments was not reproducible. Nobody could produce a definitive list of externally reachable routes.

Environment

Kong across on-premises data centers and a managed Kubernetes cluster, fronting a mix of legacy SOAP services and newer REST APIs.

Approach

AceMQ designed a hybrid control plane and data plane topology with a single declarative source of truth for gateway configuration, held in version control and promoted through environments. Auth was standardized on a common consumer and credential model, with per-service exceptions documented rather than improvised.

Solution

• Designed a hybrid control plane / data plane topology with data planes close to their workloads
• Standardized configuration as declarative files in version control with an environment promotion pipeline
• Defined a single consumer and credential model, with documented exceptions for legacy services
• Established a shared plugin baseline for logging, tracing, request size limits, and rate limiting
• Planned staged migration of each business unit's routes with parallel-run and rollback per service
• Produced an authoritative inventory of externally reachable routes and their auth posture

Outcome

Technologies