API management · Guide
Service mesh: when your services need one, and when a gateway is enough
A service mesh is a layer that secures, routes and measures the calls services make to each other, using a small proxy beside each service and a control plane that configures them all. It solves a real problem for platforms with many services, and it adds real operating cost. This guide explains in plain words when a service mesh is worth it, when an API gateway at the front door is enough, what mTLS and zero trust mean between services, and where Kong Mesh fits for organisations in Saudi Arabia.
Published 11 min read
In short, for executives
- What it is: a layer that encrypts, controls and measures traffic between your own services, without changing their code.
- When it is worth it: many services calling each other, a requirement to encrypt and authorise every internal call, or services spread across clusters and sites.
- When it is not: a handful of services, or a problem that is really about outside callers. An API gateway handles that.
- Where Kong fits: Kong Gateway at the front door; Kong Mesh, Kong's service mesh, between services where a mesh is justified.
At a glance
| Question | Answer |
|---|---|
| Traffic it governs | East-west: calls from one service to another inside your platform |
| How it works | A proxy beside each service carries its traffic; a control plane gives every proxy its rules |
| Typical policies | Mutual TLS, which service may call which, retries, timeouts, traffic splitting |
| What it does not replace | An API gateway for outside consumers, or authorisation inside each service |
| Main cost | One more platform to run: proxies on every workload, certificates, upgrades and skills |
| From Interkey | An honest needs check, then Kong Gateway, Kong Mesh or both, run with support from Riyadh |
What a service mesh does, in plain words
When an application is split into many services, most of its traffic stops coming from outside. A request from a mobile app may reach one service, which calls five others, each of which calls a database or another service. These internal calls are often sent in plain text, retried in different ways by each team and measured differently, or not at all.
Read more
Fixing that service by service means every team adds the same certificate handling, retry logic and metrics to its own code, in its own language, and keeps them current. A service mesh moves that work out of the code. A small proxy runs beside each service and handles its incoming and outgoing calls. A control plane holds the rules and sends them to every proxy. The teams write their service; the platform team sets how services talk to each other, once, for all of them.
Why the question comes up in Saudi organisations
Many organisations in the Kingdom are moving core systems onto containers and Kubernetes as part of digital programmes, often with dozens of services owned by several teams and vendors. Security reviews increasingly ask for encryption and access control between services, not only at the edge. The National Cybersecurity Authority (NCA) publishes the cybersecurity controls that many of these organisations are assessed against; which of them apply, and how, is a question for your own compliance team. A mesh is one way to meet requirements of that kind consistently. It is not the only way, and it is not required by itself.
Service mesh vs API gateway: when a mesh is needed, and when a gateway is enough
An API gateway governs north-south traffic, callers outside your platform reaching your APIs; a service mesh governs east-west traffic, your services calling each other. They are not rivals for one job, and many platforms on Kubernetes run both. Our glossary entry what is an API gateway compares gateway, load balancer and mesh side by side. The table below answers the next question: whether your platform needs the mesh. One row on the right is rarely a reason to adopt one; several together usually are.
| Situation | A gateway is usually enough | A mesh is usually worth it |
|---|---|---|
| Number of services | A few services, owned by one team | Dozens of services, owned by several teams or vendors |
| Where the risk is | Outside callers: partners, apps, the public | Internal calls: one compromised service could reach the others |
| Encryption requirement | TLS at the edge is accepted by your security review | Every call between services must be encrypted and both ends identified |
| Access rules | Who may call the API from outside | Which service may call which, enforced on every internal call |
| Where services run | One cluster or one set of servers | Several clusters, sites or a mix of Kubernetes and virtual machines |
| Releases | Whole releases, rolled back as a unit | Gradual releases that send a share of internal traffic to a new version |
| Platform team | No one to own another platform yet | A team that can own the mesh, its certificates and its upgrades |
If most of your answers sit in the middle column, start with the gateway and good service-level security. A mesh added before the platform needs it is a cost without a return.
Microservices security: mTLS and zero trust between services
Ordinary TLS lets a caller check the server it is talking to. Mutual TLS (mTLS) checks both ends: each service presents a certificate, so the receiving service knows which service is calling, and the traffic is encrypted on the way. Done by hand, mTLS means issuing, distributing and rotating certificates for every service. In a mesh, the control plane acts as or connects to a certificate authority and the proxies handle the exchange, so certificates are issued and rotated without the teams touching their code.
Read more
Zero trust, in this context, means that being inside the network is not a reason to be trusted. Every call carries an identity, and a written rule says whether that identity may make that call. A mesh makes this practical: with service identities from mTLS, the platform team can write rules such as "only the payments service may call the ledger service", and the proxies refuse everything else.
What mTLS does not cover
- Authorisation inside the service. The mesh knows which service is calling, not whether a given customer may see a given record. That check stays in the service.
- What is inside the payload. Encryption protects data on the wire. It does not stop a service returning more data than it should. Our API security page covers those gaps at the API level.
- Traffic that bypasses the mesh. Workloads outside the mesh, and databases or legacy systems it does not reach, need their own controls.
What a service mesh costs to run
The benefits above are real, and so is the cost. Before adopting a mesh, the platform team should be ready for each of these:
Read more
- Resources. A proxy runs beside every workload and uses CPU and memory there. On a large cluster that adds up.
- Latency. Each internal call passes through two proxies. The overhead is usually small, but it should be measured on your own traffic, especially on chains of many calls.
- Certificates. The mesh's certificate authority becomes a critical system. Its keys, its rotation and its recovery need an owner.
- Upgrades. The control plane and the proxies have their own release cycle, which has to be rehearsed alongside cluster upgrades.
- Debugging. When a call fails, the cause may now be a mesh rule. Teams need traces and logs from the proxies, and the training to read them. Our distributed tracing page explains how a call is followed across services.
Relateddistributed tracing page
A checklist before you adopt a service mesh
- You can list the services in scope, who owns each and which services each one calls.
- The requirement is written down: encryption between services, access rules between services, gradual releases, or several clusters.
- Outside consumers already pass an API gateway, so the mesh is not being asked to do the gateway's job.
- A platform team is named to own the mesh, its certificate authority and its upgrades.
- Proxy resource use and added latency have been measured on a test environment with your real call patterns.
- Workloads that cannot join the mesh, such as some databases and older systems, are known and have their own controls.
- Access rules between services start permissive and are tightened service by service, with logs read before each change.
- Mesh configuration is declared and version-controlled, and changes go through review.
- Traces, metrics and logs from the proxies reach your observability platform before production.
- A rollback path exists for each service that joins the mesh.
Where Kong Mesh fits, and where it does not
Kong is the API platform Interkey implements. Kong Gateway handles the front door; Kong describes Kong Mesh as "an enterprise-grade service mesh that helps you connect, manage, and secure workloads across environments", built on top of Kuma, an open-source project Kong started.
| Need | In Kong | What to know |
|---|---|---|
| Outside callers reaching your APIs | Kong Gateway | Consumers, keys, rate limits and validation at the front door |
| Traffic into a Kubernetes cluster | Kong Ingress Controller | Runs Kong Gateway as the cluster's ingress, configured through Kubernetes resources |
| Encryption and access rules between services | Kong Mesh | Kong states zero trust by default through authentication, authorisation and encryption; its documentation includes a mutual TLS policy |
| Services on Kubernetes and on virtual machines | Kong Mesh | Kong states it deploys on Kubernetes, in the cloud, on-premises, in containers or on virtual machines |
| Several clusters or sites | Kong Mesh | Kong describes cross-zone connectivity and routing that prefers nearby services across clusters |
| A few services owned by one team | Kong Gateway alone | A mesh is probably not needed yet |
Where it does not fit. A mesh does not decide what a customer may see, fix an unsafe service or replace the inventory and written rules that API management starts with. Kong also offers to install and manage Kong Mesh through Kong Konnect's Mesh Manager; whether hosted management suits your data classification is a decision we make with you, as we do for the gateway on our API gateway page. We confirm individual Kong Mesh policies, editions and licensing against Kong's current documentation before design, and run it with the same discipline our Kong implementation page describes for the gateway. Services that are not yet on containers come first: our Kubernetes page covers that move, and our planned Kubernetes ingress controller guide covers the cluster's front door.
What drives cost and timeline
We give no fixed figure before we have seen the platform. A small pilot on a few services in a test cluster is a matter of weeks; bringing every service into a mesh, with strict access rules, takes longer and is done in waves. What drives the effort: how many services and clusters are in scope, whether they already run on Kubernetes, how many teams own them, whether services run on virtual machines too, how strict the access rules must be, and whether observability already reaches the services.
Read more
Kong licences, where Kong Mesh or Kong Gateway Enterprise features are needed, are quoted at Kong's terms, on a separate line from Interkey's work.
Support from Riyadh. Interkey's engineers work from Riyadh in Arabic and English. The mesh's control plane and proxies can run on your servers or in a cloud region in the Kingdom, so service-to-service traffic and its certificates stay where your data residency rules require.
How Interkey helps with a service mesh
-
Map the calls.
Which services call which, from traces or configuration, and what each call carries.
-
Decide honestly.
Gateway alone, mesh, or both, from the decision table above and your written requirements.
-
Pilot.
A few services in a test cluster, with proxy cost and latency measured on your traffic.
-
Roll out in waves.
Encryption first, then access rules tightened service by service, configuration declared as code.
-
Operate.
Certificates, upgrades and proxy telemetry owned by your team or under a written managed services scope.
Questions buyers ask about a service mesh
At what point does a microservices platform start to need a service mesh?
There is no fixed number of services. The signal is a combination: many services owned by different teams, a written requirement to encrypt and authorise every internal call, and services spread across clusters or sites. With a few services owned by one team, a gateway and good service-level security are usually enough.
Can a service mesh take the place of our API gateway?
Not well. A mesh knows services; a gateway knows outside consumers, their keys, plans and limits. Some meshes can expose a gateway at their edge, but partner onboarding, per-consumer limits and request validation remain gateway work.
How much does the sidecar proxy slow each call down?
Every internal call passes through two proxies, so there is some overhead, usually small for a single call and more visible on long chains of calls. It depends on your traffic and the rules applied, so we measure it in a pilot before any commitment.
Can Kong Mesh run on our own servers in Saudi Arabia, including virtual machines?
Kong states that Kong Mesh deploys on Kubernetes, in the cloud, on-premises, in containers or on virtual machines. That lets the control plane and proxies run on your infrastructure or a cloud region in the Kingdom. Kong also offers hosted management through Konnect, which is a data classification decision.
How is Kong Mesh licensed, and what drives the cost of a mesh project in KSA?
Kong Mesh licences are quoted at Kong's terms, which we confirm with Kong for your scope. Interkey's part is quoted separately and follows the number of services, clusters and teams, whether virtual machines are included and how strict the access rules must be.
How long does it take to bring our services into a service mesh?
A pilot on a few services is a matter of weeks. Bringing every service in takes longer and is done in waves, because each team has to check its service under the mesh and access rules are tightened one service at a time. We give an estimate after mapping your service calls.
Next
Read next
Next step
Check whether your services need a mesh
Tell us how many services you run, where they run, who owns them and what your security review asks for between services. We will tell you whether a gateway is enough or a mesh is worth it, and how Kong would fit.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia