- What decides it
- Where traffic is inspected
- Self-managed, in-Kingdom
- Your infrastructure inside the Kingdom, both planes
- Hybrid
- Traffic plane in-Kingdom; configuration plane hosted by the vendor
- Kubernetes ingress
- Inside the cluster, in front of the workloads it serves
Technology we implement
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.
Read more
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 real 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
- What has to be operated
- Self-managed, in-Kingdom
- Everything: gateway nodes, the control plane, its database, upgrades of both
- Hybrid
- The traffic plane only; configuration arrives as a service
- Kubernetes ingress
- The gateway as one more cluster workload, upgraded with the cluster’s discipline
- What decides it
- When it is right
- Self-managed, in-Kingdom
- Payloads or configuration may not leave the Kingdom, and someone owns the platform for years
- Hybrid
- Payloads must stay; configuration metadata may leave; the operating team is small
- Kubernetes ingress
- The services are already on Kubernetes and north-south traffic is the problem to solve
- What decides it
- What you give up
- Self-managed, in-Kingdom
- The vendor’s automation of the control plane: you are buying control with engineering effort
- Hybrid
- Some residency control over configuration, which is a classification question rather than a technical one
- Kubernetes ingress
- 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.
Read more
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.
Scope of this page
Interkey implements and operates Kong for organisations in Saudi Arabia, from Riyadh, and integrates it with the environment you already run. Kong is a product of Kong Inc.; licensing and the implementation scope are set out in the proposal, and the vendor’s documentation is the authority on the product itself.
Working together
How work with Kong begins
Kong is a technology partner: the gateway is Kong’s, and the inventory, policy, deployment and operation are done by Interkey’s own team in Riyadh. Work begins with the interface inventory — what is exposed today, to whom, under which policies — and the deployment shape that residency and the existing cluster allow. That first conversation is short and decides most of what follows.
The implementation is scoped as a fixed piece of work from inventory to operated gateway, and operation afterwards is a written scope under managed services; Kong licensing, where the enterprise edition is needed, is quoted at the vendor’s terms beside it. The practice that this gateway work belongs to is API management, and the interfaces behind the gateway are usually system integration work.
Relatedsystem integration
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.
Relatedproducts 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.
Relatedmanaged service
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
Practice
API management in Saudi Arabia
Technology
Docker and Kubernetes implementation and operations
Practice
The observability practice
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
-
Same team as the cluster and the monitoring
Kubernetes, observability and delivery pipelines