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 network security before one is in deep waters. 

There are limitations to API gateways in the app modernization journey when we consider Istio versus API gateways. However, this article will discuss different scenarios to implement Istio with your existing API gateway infrastructure.

Before we begin, if you prefer to watch a video about implementation, feel free to click on the link below.

Video: App Modernization With API Gateway and Istio

Scenario 1: API Gateway With Istio Ingress to Manage Multicloud Workloads

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 by 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

Use this architecture 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 the 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 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 types of software — the API gateway and Istio ingress.

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

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. Fewer 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 example, load balancer by cloud providers), then some effort is required.
   
   

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

The 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 multicluster 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 the growing complexity of networks along with the rise of security attacks on the other, force DevOps and architects to reimagine their network infrastructure.

Getting started with Istio service mesh will open doors for opportunities to make the hybrid cloud more agile and secure.