How does Tyk work with a service mesh?

Prefer to watch a video



Tyk works by running inside your service mesh as the sole ingress. This allows us to put APIM as a higher-level abstraction in front of all the network-level stuff that the service mesh will do “invisibly”.

Let’s use Istio as our service mesh for the following example.

We run Tyk in a namespace with Istio injection configured and then forward all ingress towards Tyk:


kind: Gateway


 name: tyk-gateway

 namespace: apps



   istio: ingressgateway # use istio default controller


 - port:

     number: 80

     name: http

     protocol: HTTP


   - "*"



kind: VirtualService


 name: tyk-gateway

 namespace: apps



 - "*"


 - tyk-gateway


 - match:

   - uri:

       prefix: /


     uri: "/"


   - destination:

       host: gateway-svc-tyk-pro.tyk.svc.cluster.local


         number: 8080    

You can see that we are forwarding all ingress traffic from Istio to Tyk.  

Now – Our Gateway is in front of our services, doing all the APIM stuff we discuss here, but we can still leverage Istio on the backend for all our inter-service communication.

Here’s a screenshot from Istio Kialo. What does it show?

  • Tyk as ingress into the service mesh
  • Tyk forwarding requests to the product page service, where Istio manages multiple versions of the service, as well as where east-west weighted round-robin load balancing is happening:

Note – as far as Tyk is concerned, we’re forwarding traffic to a single service, the product page. Everything else that happens is east-west as defined by the services and the Istio routes.

And here’s us using Tyk’s Universal Data Graph to stitch together multiple services running in my Istio service mesh as a single GraphQL Facade:

Even though we made a single GraphQL query in the above request, the data above came from 3 different services running in my Istio service mesh, all orchestrated by Tyk UDG:

Hopefully, we’ve illustrated that APIM and service mesh are solving two very different problems. Full lifecycle API management can be described as solving “people” problems; documenting, discovering, productising, publishing, monitoring, APIs, and more, whereas service mesh is designed for network-level problems.