Implementation Architecture of Istio and API gateway

With the advent of microservices, cloud, and containers, architects and the DevOps team need to reimagine and rethink how to simplify the network complexity and achieve zero trust security before one is in deep waters. 

In the previous blog, we mentioned the limitation of the API gateway in the app modernization journey. This blog will discuss different scenarios to implement Istio with your existing API gateway infrastructure.  

In case you want to watch the video about the implementation, then please watch the below:

Watch the video on App modernization with API gateway and Istio

Scenario 1: API gateway with Istio ingress to manage multicloud workloads

In our previous blog, we discussed that the application and people need to open multiple ports when they use a network or application load balancer because the cluster does not allow traffic to the cluster. But using Istio ingress inside a cluster, we can open required ports such as 80 or 443. All the traffic from the API gateway enters the cluster through the ingress port. Istio ingress can then divert the traffic to any services. 

When to use this architecture:

1. When API gateway implementation handles a large amount of traffic and the DevOps team wants to implement a service mesh. The scenario-1 architecture is implemented in phase-1 of Istio implementation.

Pros:

1. Service-to-service (S2S) communication can now be easily managed from the central plane of Istio.
2. With Envoy proxies, S2S communication can also be secured with mTLS in just seconds.
3. Traffic management functionalities can be distributed- let API gateway perform advanced traffic management (API management, billing, etc) and Istio ingress performs L7 routing. 
4. Istio ingress supports Kubernetes natively and also supports VMs (refer to Fig A).
5. Being an open source, Istio supports integration with almost all API gateways.

Cons:

1. Edge-to-cluster traffic is not secure.
2. Adds network hops as all the traffic from clients to respective services has to go through two software- API gateway and Istio ingress.

Fig A: API gateway and Istio ingress implementation

Scenario 2: API gateway without Istio ingress to manage multicloud workloads

To overcome the problem of scenario-1, architects can choose to deploy the API gateway in one of the clusters where all the services are placed. Such an implementation will save the network hops. 

When to use this architecture:

1. If multiple services are in one cluster, then the API gateway can be implemented into the same cluster. All the traffic rules in the API gateway have to be redeployed. 

Pros:

1. All the benefits of scenario-1 plus, 
2. Less network hops without an Istio ingress gateway.

Cons:

1. Edge-to-cluster traffic is still not secure
2. If your API gateway does not natively support Kubernetes (for e.g. load balancer by cloud providers), then some effort is required. 

Fig B: Istio with API gateway without ingress gateway

Scenario 3: API gateway with Envoy proxy to manage multicloud workloads

To overcome the problem of scenario-2, an Envoy proxy can be attached to the API gateway. The idea is that the API gateway receives the traffic and processes it, but when the traffic goes out from API gateway and into the cluster services, it goes through an Envoy proxy attached to it. 

With the sidecar proxy, all the traffic from the edge to the services can be secured with authentication and authorization policies in Istio. 

When to use this architecture:

1. Envoy proxy can be attached to the API gateway in phase-2 of Istio implementation. 

Pros:

1. All the benefits of scenario-2 plus, 
2. All the east-west and north-south traffic can be managed and secured easily from Istio.
3. End-to-end observability in a single plane

Cons:

1. Configuration can be very tricky. 

In the above scenarios, you can observe that Istio can be used to inject sidecars to all services inside a cluster and apply security and network logic selectively from the central plane. We can set up Istio to also get mutlicluster visibility in terms of access logs, tracing, and  performance metrics of each service.  

In the coming weeks, we will also discuss using an Istio gateway (based on Gateway API) instead of an API gateway. And that new reimagination can be way more potent in increasing security features and simplifying a network of cloud-native applications. 

Conclusion

With the advent of the internet, our network requirement has also evolved. At first, a load balancer was enough, but then an API gateway was used to handle traffic at the edge. With more and more microservices and cloud adoption on one side, and growing complexity of networks along with the rise of security attacks on another side force DevOps and architects to reimagine their network infrastructure. Starting with the Istio service mesh will open doors for opportunities to make the hybrid cloud more agile and secure.