Technology partners
Kong implementation and operations
Interkey implements and operates Kong for organisations in Saudi Arabia: the gateway deployed in the shape residency allows, the policies expressed as configuration, the ingress on Kubernetes where the workloads already are, and the platform run afterwards.
In short
What Interkey delivers with Kong
Kong is the API gateway platform Interkey implements when an organisation needs one layer in front of its services that enforces who may call them, how often, and in which version. Interkey’s work is the deployment, the policy design, the integration with the identity and observability platforms already in place, and the operation of the gateway after go-live — from Riyadh, in Arabic and English.
The gateway is the enforcement point of a broader practice. Deciding what goes through it, under which written rules, owned by whom, is API management, and that page argues the gateway is the third step rather than the first. This page assumes that argument has been had, and is about doing the platform well.
It is also about the honest scope of what a gateway does. It enforces access, limits, transformation and routing on traffic. It does not make an unsafe service safe, and it does not remove the need for the service behind it to be built properly. Proposals that present the gateway as a security programme in itself are describing a component as a strategy.
The first decision
Self-managed, hybrid, or on the cluster
Kong separates the plane that carries traffic from the plane that holds configuration, and the residency answer decides how those two are placed. Take the shape the classification of your data allows, and accept what each costs to operate.
| What decides it | Self-managed, in-Kingdom | Hybrid | Kubernetes ingress |
|---|---|---|---|
| Where traffic is inspected | Your infrastructure inside the Kingdom, both planes | Traffic plane in-Kingdom; configuration plane hosted by the vendor | Inside the cluster, in front of the workloads it serves |
| What has to be operated | Everything: gateway nodes, the control plane, its database, upgrades of both | The traffic plane only; configuration arrives as a service | The gateway as one more cluster workload, upgraded with the cluster’s discipline |
| When it is right | Payloads or configuration may not leave the Kingdom, and someone owns the platform for years | Payloads must stay; configuration metadata may leave; the operating team is small | The services are already on Kubernetes and north-south traffic is the problem to solve |
| What you give up | The vendor’s automation of the control plane: you are buying control with engineering effort | Some residency control over configuration, which is a classification question rather than a technical one | Nothing in itself; it composes with either of the other two for traffic from outside the cluster |
The delivery
From inventory to operated gateway
-
Inventory and policy
What exists, who consumes it, and the written rules the gateway will enforce. Done in the API practice; the gateway is configured from it rather than designed in its absence.
-
Deploy in the residency shape
The planes placed as the table above decides, sized for the traffic the inventory found, built as configuration so a second environment is a repeat rather than a redesign.
-
Policy as configuration
Authentication against the identity platform already in use, authorisation, rate limits per consumer, transformation and routing — declared, versioned and reviewed like code, never edited by hand on a node.
-
Move consumers, close back doors
Each consumer onboarded through the gateway and its direct route retired, one at a time, with the parallel run each needs. The measure is how many exceptions remain.
-
Operate
Per-consumer traffic, errors and latency into the observability platform, an upgrade cadence for the gateway itself, and a named operator — your team, or Interkey’s managed service.
Production readiness
What a production gateway has to be able to show
A gateway sees every request, so a review will ask for these whether or not anyone planned for them. Building them in is dramatically cheaper than retrofitting them after the first partner integration goes live.
- Every route, plugin and consumer defined in version-controlled configuration, and no change applied any other way
- Authentication delegated to the identity platform the organisation already runs, not a second credential store inside the gateway
- Rate limits per consumer, set from the inventory rather than from a default, and alerting when one is hit
- The gateway’s own upgrade path rehearsed, including rollback, with the traffic plane and configuration plane upgraded in the right order
- Per-consumer metrics and logs flowing to the observability platform, with payload logging decided by data classification rather than left on
- Secrets for upstream services held outside the configuration and rotated on a schedule that actually runs
- A deprecation calendar for versions, and the consumer notification that goes with it
Where it sits
Kong and the rest of the platform
A gateway is one component in a platform that already has an identity provider, a cluster, an observability stack and a delivery pipeline, and most of the implementation work is joining it to those correctly. On Kubernetes it is the ingress, upgraded with the cluster; in the observability platform it is a source of the per-consumer telemetry operations teams did not previously have; in the delivery pipeline its configuration is one more versioned artefact promoted through environments.
Interkey implements those neighbouring platforms too, which is the practical reason the gateway work is done by the same team: a gateway configured by people who also run the cluster and the monitoring is a gateway that was designed to be operated.
Migrating to it
Moving from another gateway, or from none
The routes migrate in a day; the policies are the project
Organisations arrive at Kong from an older gateway, from a cloud provider’s managed one, or from nothing but a load balancer and a convention. In every case the technical migration of routes is the small part. What takes the engagement is that the old arrangement encoded policies nobody wrote down — which consumer was quietly unlimited, which service accepted a credential everyone shared — and moving them means deciding, for the first time, whether they were ever intended.
So a migration runs as the flow above with one addition: every implicit policy found in the old gateway is written down and either adopted deliberately or retired deliberately, before it is recreated. A migration that reproduces the old gateway faithfully has bought new software and kept the old problems.
What this page is
A statement of capability, not of status
This page says what Interkey does with Kong: implementation and operation for organisations in Saudi Arabia, delivered from Riyadh. It makes no statement about any formal programme, tier or certification, because the site publishes relationship claims only where the evidence for the exact wording is on file, and for this technology it is the capability that is on file. Kong is a product of Kong Inc.; the descriptions of its deployment shapes above are general and current as of this page’s last update, and the vendor’s own documentation is the authority on the product itself.
Buyer questions
What buyers ask us
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
Is Kong an Interkey product?
No. Kong is a technology Interkey implements and operates, in the same way as Datadog, Couchbase and Docker on this site. Interkey’s own products are on the products page.
Can the whole platform run inside the Kingdom?
Yes: the self-managed shape in the table above places both the traffic plane and the configuration plane on infrastructure you operate in Saudi Arabia. The cost is operating both for years, which is a real cost and the reason the hybrid shape exists for organisations whose classification allows configuration metadata to leave.
Does Interkey operate the gateway after go-live?
Where wanted, on an agreed scope, through the managed service: upgrades, policy changes through a change process, consumer onboarding and per-consumer monitoring. Where your own team operates it, the implementation hands over the configuration repository and runbooks they will need.
We are on Kubernetes already. Is this just an ingress controller?
It can be exactly that, and for a cluster whose problem is north-south traffic that is the right scope. It becomes more when the same policies have to apply to services outside the cluster, or to partners calling in, at which point the gateway in front of the cluster and the ingress inside it are one configuration rather than two.
Read next
Explore related solutions
Next step
Discuss a gateway deployment
Say what sits behind the gateway today, who calls it, and where the data may live. The deployment shape follows from those three answers.
-
Policy as versioned configuration
Nothing edited by hand on a node
-
In-Kingdom data plane where required
Shape decided by data classification
-
Operated on the Saudi working week
Riyadh engineering, Sunday to Thursday