We’re excited to announce the latest release for both Kuma and Kong Mesh. This cycle, we focused on simplifying enterprise-wide mesh deployments.

We strongly suggest upgrading, in order to take advantage of the latest and greatest when it comes to service mesh.

## **Notable Releases in Kuma 1.7.0 **

• - **🚀 Streamlined cross-mesh communication through Kuma's builtin gateway**. There's a bit to unpack here - details are in the following section.
• - **🚀 Support for ARM-based Linux and MacOS environments**. You can continue to connect services across your environment with Kuma as you modernize onto microservices with ARM architectures.
• - **🚀 Observability implementation in one command**. You can instrument metrics, traces, and logs with a single [observability] command line tool.
• - **🚀 Simplified application metrics collection**. You can now enable metrics collection from your services without deploying Prometheus inside the mesh.
• - **🚀 Graceful Data Plane Proxy shutdowns.** You won't see occasional data plane proxy error metrics from your services and DPPs as they spin down.
• - 🚀 Ability to **p****atch**** injected containers** (both sidecar and init) which enables advanced customization.
• - **🚀 Multiple Helm refinements. **You can now use Helm charts to customize image tags, expose the control plane's metrics for self-deployed Prometheus scraping, and more.

For more details, reference the [Kuma Changelog](https://github.com/kumahq/kuma/blob/master/CHANGELOG.md)Kuma Changelog.

## **Notable Releases in Kong Mesh 1.8.0**

• - **🚀 cert-manager.io support **for X.509 certificate management with Kubernetes.
• - **🚀 **Everything in Kuma 1.7.0, with our industry leading enterprise support and SLAs.

For more details, reference the [Kong Mesh Changelong](https://docs.konghq.com/mesh/changelog?_ga=2.22654011.1487246945.1653492382-1823038313.1653492382)Kong Mesh Changelong.

### **Builtin Gateway Cross-Mesh Communication**

We see many application teams deploy a service mesh for each of their applications to act as a logical boundary - each service mesh ensures only the services within the mesh can communicate with each other.

Traditionally, these teams deployed a [Delegated Gateway](https://kuma.io/docs/latest/explore/gateway/#delegated)Delegated Gateway in their mesh to facilitate cross-mesh communication and authentication. Most chose Kong Gateway, but any API Gateway can work.

The challenge with this approach is that each team must operate an API Gateway and configure it to securely connect to their mesh. And, while API Gateways are critical for connectivity at the edge of any environment, their full capabilities are not needed for connectivity between service meshes within an enterprise environment.

Today's release of the Builtin Gateway's [cross-mesh](https://kuma.io/docs/latest/explore/gateway/#cross-mesh)cross-mesh capability lets teams expose their meshes to other meshes, while keeping all traffic secured through the data plane using mTLS. And, configure all of their listeners and routes directly using Kuma policies.

Here’s a simple visualization of how Builtin Gateway cross-mesh can be deployed across two team’s service meshes:

And, their deployment using Delegated Gateway:

For more information on the ways you can deploy Kong Mesh and Kuma, reference our [How Zones and Meshes Fit Into Your Service Mesh Deployment](https://konghq.com/blog/zones-meshes)How Zones and Meshes Fit Into Your Service Mesh Deployment blog.