Wat is Kong API Gateway?
Kong API Gateway gebruik ik als centrale toegangspoort tussen clients en backend-services. In plaats van dat iedere service zelf verantwoordelijk wordt voor zaken zoals authenticatie, routing, security en toegangscontrole, leg je die verantwoordelijkheden op één duidelijke plek neer.
Voor mij zit de waarde van Kong vooral in die scheiding. Een backend-service moet zich voornamelijk bezighouden met domeinlogica. Alles wat gaat over hoe verkeer binnenkomt, wie toegang krijgt en naar welke service een request moet, wil ik zoveel mogelijk buiten die domeinlogica houden.
Dat houdt services eenvoudiger en de architectuur beter beheersbaar.
Belangrijke dingen om te weten
Een API Gateway kan veel verantwoordelijkheid krijgen. Dat maakt Kong krachtig, maar betekent ook dat je bewust moet blijven nadenken over wat je er wel en niet in stopt.
Ik gebruik Kong onder andere voor:
Routing naar verschillende backend-services
Authenticatie en autorisatie rondom API's
Centraal afdwingen van securityregels
Afzonderen van interne services van externe consumers
Consistente configuratie van inkomend verkeer
Schaalbare toegang tot een landschap van meerdere services
Mijn uitgangspunt is daarbij simpel: Kong ondersteunt de architectuur, maar wordt niet de architectuur.
Businesslogica hoort wat mij betreft niet thuis in een API Gateway. Zodra te veel beslissingen in de gateway terechtkomen, creëer je opnieuw centrale complexiteit op een plek waar je die juist probeerde weg te halen.
Waar heb ik Kong API Gateway gebruikt?
Mijn meest recente ervaring met Kong komt uit het Car Platform van ANWB.
Daar werkte ik aan een backend-platform gebouwd met onder andere Kotlin, Spring, Redis en AWS. Binnen dat platform heb ik Kong API Gateway ingericht om veilige en schaalbare toegang tot onze backend-services mogelijk te maken.
Dat sloot aan op een bredere architecturale verandering die ik binnen het platform heb doorgevoerd. Het systeem bewoog van een sterk gekoppelde opzet richting een duidelijker gescheiden en event-driven architectuur.
Juist wanneer een landschap uit meerdere services bestaat, vind ik het belangrijk dat ook aan de buitenkant een duidelijke structuur aanwezig is. Kong vormde daar de grens tussen consumers en de interne backend.
Veelgestelde vragen die ik krijg over Kong API Gateway
Waarom Kong en niet alles rechtstreeks vanuit de backend regelen?
Omdat ik verantwoordelijkheden graag gescheiden houd. Een service moet vooral goed zijn in zijn domeinlogica. Routing, toegangscontrole en generieke API-verantwoordelijkheden kunnen beter centraal worden opgelost.
Stop je alle security in Kong?
Nee. Kong is een belangrijke securitylaag, maar niet de enige. Autorisatie die afhankelijk is van domeinkennis hoort nog steeds in de applicatie zelf thuis.
Is een API Gateway altijd nodig bij microservices?
Nee. Als je maar een paar interne services hebt, kan een gateway extra complexiteit toevoegen zonder voldoende voordeel. Ik voeg infrastructuur alleen toe als daar een concreet probleem tegenover staat.
Kan Kong een bottleneck worden?
Ja, als je hem verkeerd inzet. Daarom houd ik configuratie bewust eenvoudig en voorkom ik dat businesslogica of onnodig complexe flows in de gateway terechtkomen.
Wat vind je het belangrijkste bij het inrichten van Kong?
Eerst begrijpen welke grens je probeert te bewaken. Daarna pas routes en plugins configureren. Een gateway zonder duidelijke verantwoordelijkheden wordt anders heel snel een centrale plek waar alle uitzonderingen terechtkomen.