Mesh to the Rescue of API Gateways for Cross-Cloud Connectivity

Many organizations struggle with managing API gateways across multiple cloud environments. In this blog post, we'll explore how Kong Mesh can solve these challenges and enable seamless cross-cloud connectivity.

The challenge of multi-cloud API gateways

Many large companies operate API gateways in multiple regions or cloud service providers. This may be a strategic decision or dictated by regional regulations (GDPR, Open Banking, etc.)

Additionally, the API gateway sprawl may stem from various business reasons like API visibility for different audiences (public, partners, corporate, export control, etc.), or be organizationally led. Companies frequently implement a public API gateway complemented by a Developer Portal to foster innovation based on existing APIs. Conversely, private API gateways are utilized for internal purposes, cross-domain sharing, or to keep dark IT away.

The spread of API gateways across clouds raises new connectivity challenges. Is it best to rely on a particular cloud provider networking infrastructure or to leverage telcos' private backbones? What’s the most secure? What are your encryption standards for cross-datacenter connectivity? 

Zero-trust and service mesh in the cloud native era

In the era of cloud-native technologies, you have undoubtedly heard of zero-trust networking and service mesh platforms — two buzzwords that echo the trend in cloud connectivity. While ZTN (zero-trust networking) encompasses a wide range of technologies and approaches, service mesh is a subset of zero-trust that is scoped to east-west traffic control for your applications. 

Service mesh technologies are often considered complex to use, operate, and scale because of the adoption gap and learning curve. That said, there are proven paths to success in their adoption. One common approach is to first onboard the (API) gateways in the mesh — just them, not your upstream APIs or technical services. It's an easy, riskless step with two advantages: your platform administrators start learning from this new technology, and you can complement your API gateway features with the ones of the mesh if any are missing (for instance, anything telemetry or resiliency).

There's more: having your API gateways in the mesh opens up new possibilities in terms of connectivity, at least with modern service mesh platforms like Kong Mesh, which were designed with multi-cluster in mind.

Kong Mesh is a service mesh platform built on top of OSS Kuma, facilitating cross-platform connectivity and global routing across your services. One of its building blocks, called “Zone Ingress” represents a special kind of gateway for east-west traffic. These Zone Ingresses are transparent to end-users. The point is they are automatically configured by the mesh when two services running on different platforms have to communicate with each other. Since the connection is secured over mTLS tunnels, it's fine to use public networking infrastructure like the internet (just like a standard VPN). 

Now, on the developer side, it's also important to facilitate the naming of services deployed elsewhere so that they can be easily consumed. Again, this is where Kuma shines because of its federated architecture.

All the services that are part of the mesh become routable with auto-generated mesh-side hostnames. As to how the routing is done with additional security and resiliency mechanisms, it's just Envoy magic!

Setting the scene

To demonstrate the value of having API gateways part of the mesh, here's an example with a fake company, acme.corp, that operates Kubernetes clusters on both Azure and Google Cloud.

The catalog API only runs on Google Cloud but is addressable from both API gateways running on each cluster.

The two gateways are tagged as regular workloads in the mesh:

To allow for both external and internal connectivity, the gateway running on Google Cloud is exposing a wildcard certificate that works for various sub-domains:

The way the catalog API is configured in the gateway that runs in Azure is with a virtual domain name provided by the mesh:

Since the gateway on Azure is also part of the mesh, the outbound requests can be routed to the other gateway on Google Cloud:

In order to assign a virtual domain name to the Kong Gateway from the Azure perspective, we use the HostnameGenerator CRD as shown below:

We can imagine more connectivity patterns for all kinds of workloads that are part or not part of the mesh:

In this last diagram, another client running in Azure can also consume the `catalog` API running in Azure through the Kong Gateways.

This setup outlines the power of modern service mesh platforms like Kong Mesh for cross-cloud connectivity. With the help of its great primitives like MeshTLS, HostnameGenerator, and Zone Ingress, your APIs have never been so close to each other!

If this kind of architecture resonates with your actual multi-cloud architecture or if you want to know more about multi-mesh platforms or Kong Mesh as an enterprise-ready service mesh platform, let's chat! Our team would love to discuss how Kong Mesh can streamline your multi-cloud strategy and enhance your API connectivity.