How does Tyk work with a service mesh?

Prefer to watch a video? 

TL;DW

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:

apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:

 name: tyk-gateway

 namespace: apps

spec:

 selector:

   istio: ingressgateway # use istio default controller

 servers:

 - port:

     number: 80

     name: http

     protocol: HTTP

   hosts:

   - "*"

---

apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

 name: tyk-gateway

 namespace: apps

spec:

 hosts:

 - "*"

 gateways:

 - tyk-gateway

 http:

 - match:

   - uri:

       prefix: /

   rewrite:

     uri: "/"

   route:

   - destination:

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

       port:

         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.