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:
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.