The challenge: a GraphQL gateway that made every team depend on one team
UniGroup was migrating years of data off a legacy DB2 mainframe into modern microservices, and needed to retire the GraphQL gateway standing between those services and the outside world. That gateway had become a single point of dependency: any team touching it had to understand types and resolvers across domains that weren’t theirs, and a schema change in one domain could silently break another. In practice, every new integration routed through UniGroup’s platform team for hand-holding, which capped delivery speed for the whole engineering organization to the bandwidth of a handful of people.
UniGroup needed an API gateway that could enforce rate limiting and act as a configuration-driven proxy in front of downstream microservices, one that any engineering team could operate on its own, without becoming a GraphQL specialist first.
Choosing a self-serve API gateway: KrakenD over Tyk
UniGroup evaluated Tyk alongside KrakenD. Chad Ernst, Infrastructure Architect at UniGroup, led that comparison:
We looked at a bunch of different gateways, and it came down to KrakenD and Tyk. Tyk’s deployment model didn’t match well with us, and KrakenD had the flexibility and the ease of deployment, fairly lightweight. The other ones we looked at required a whole lot of components that we didn’t want to stand up, and didn’t really match how we wanted to use it. That’s why we landed on KrakenD.
Where Tyk’s model called for a Redis instance and a database-backed dashboard just to coordinate nodes and manage configuration, KrakenD needed neither. The team had KrakenD Community Edition running in their Kubernetes environment within days, testing both ConfigMap and volume-mounted configuration before settling on the model that fit their workflow.
Taking the platform team out of the critical path
Every new endpoint routes through one team
Each team configures and ships its own endpoints
With KrakenD in place, UniGroup was able to:
- Shift endpoint ownership to individual teams. Configuration-based routing means engineers add new endpoints and stand up new microservice integrations by following documentation, without opening a ticket with the platform team.
- Extend the API gateway to fit a non-standard auth model. UniGroup runs a customized Keycloak-based authorization flow. Where KrakenD’s default handling didn’t fit, the team wrote a Lua plugin to bridge the gap, keeping its existing identity architecture intact instead of re-engineering it around the gateway.
- Replace a tightly-coupled GraphQL layer with an interface any team can reason about, removing the risk that a change in one domain breaks another team’s service.
A lower-burden, self-serve platform, a year into the migration
UniGroup is a little over a year into running KrakenD in production. The migration off the legacy mainframe and GraphQL gateway is ongoing: production traffic is concentrated on third-party integrations and inbound webhooks today, while UniGroup’s engineering teams are onboarding onto the API gateway in stages as their microservices come online.
Even mid-migration, the operating model has already changed. Maintenance overhead is near zero, and teams that previously depended on the platform team for every GraphQL change now self-serve configuration changes directly. KrakenD’s plugin system also let UniGroup solve its Keycloak authorization requirement on its own timeline, without waiting on a vendor roadmap.
Blake Johnston, Engineering Manager for Enterprise Platform & Platform Services at UniGroup, sums up the trade-off in one line:
Wholesale, it is better than the GraphQL option, if only because the burden on the team is so much lower, and that time savings is a win in my opinion.
Ready to simplify your API management?
See how KrakenD can help your team achieve similar results.
