We are happy to announce the first release for both Kong Mesh and Kuma in 2022, which is packed with features and improvements, including substantial performance improvements when running at scale.

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

## Notable improvements in Kong Mesh 1.6.0

• - 🚀 Everything in Kuma 1.5.0, including the **Zone Egress**, the new **builtin gateway mode**, the **90% memory performance improvements** and 15+ overall new features (as described below).
• - 🚀 A new native **ECS controller** that allows to run Kong Mesh on ECS with both ECS Fargate and ECS EC2, and that automates the provisioning of the data plane proxy tokens by leveraging AWS secrets.
• - 🚀 Official support for **Red Hat Universal Base Image (UBI)**. Combined with the pre-existing **FIPS-140-2** compliant encryption, these new images accelerate the service mesh adoption in both enterprise and federal environments.
• - Upgraded the bundled OPA agent to v0.37.2.

The full Kong Mesh changelog is available [here](https://docs.konghq.com/mesh/changelog)here.

## Notable improvements in Kuma 1.5.0

• - 🚀 A new **Zone Egress** resource to create a single egress point from a Zone, that goes in hand with the pre-existing Kuma Ingress. This new features has been added in addition to the pre-existing egress behavior, which means that Kuma now allows to configure two egress modes: centralized via Zone Egress, or decentralized from the sidecars.
• - 🚀 A new **builtin gateway mode** in addition to “delegated” mode. Kuma now ships with an Envoy-based gateway implementation to expose services from within the service mesh to the outside world – or to other meshes – using an Envoy based ingress
• - 🚀 This new version ships with a **90% decrease** in memory consumption when running Kuma at scale, as part of our ongoing effort to make Kuma the fastest service mesh in the world.
• - New troubleshooting tooling in the CLI and GUI to help identify issues faster.
• - A new Mesh membership capability that determines, top-down, what DPPs should be part of a “Mesh” (in addition to the bottom-up membership mode that is already supported, where a DPP can choose what “Mesh” it belongs to).
• - Helm chart improvements to provide custom “imagePullSecrets”.
• - Updated Envoy proxy to v1.21.1.

The full Kuma changelog is available [here](https://github.com/kumahq/kuma/blob/master/CHANGELOG.md)here.

*Kuma 1.5.0 and Kong Mesh 1.6.0 ship with new troubleshooting capabilities in the GUI and CLI.*

## Zone Egress

Kong Mesh – built on top of Kuma – is a multi-zone service mesh and since the beginning it supported the concept of `Zone Ingress` to allow traffic generated from a zone to enter another zone through a centralized ingress resource. Traffic that is coming outside of Kuma can enter the `Mesh` via `Gateway` data plane proxies.

With Kong Mesh 1.6 and Kuma 1.5, we have finally introduced a new Zone Egress resource, to channel traffic exiting a zone through a centralized egress component. Prior to this capability, the only egress functionality that Kuma supported was for egress traffic to exit the zone directly from the data plane proxies (which is **still supported** if we prefer the operational simplicity of not having to manage an additional component).

This gives us plenty of options when it comes to managing our ingress and egress traffic from within our Kong Mesh zones.

## Built-in Envoy-based gateway (technical preview)

This release of Kong Mesh introduces a new **builtin Gateway** data plane proxy (technical preview), that can be used to expose mesh services to the outside world via an Envoy proxy. The new `builtin` gateway works across Kubernetes and VMs (like every other feature of Kong Mesh). Before we release this feature as GA in the next release, this new gateway will also natively support the new **Kubernetes Gateway API** specification, the successor of the older `Ingress`.

This also means that starting from today, Kong Mesh supports two gateway modes:

• - [Delegated(opens new window)](https://kuma.io/docs/1.5.x/documentation/gateway/#delegated)Delegated(opens new window)
• - [Builtin(opens new window)](https://kuma.io/docs/1.5.x/documentation/gateway/#builtin)Builtin(opens new window)

Delegated gateways have been supported for a long time, and they can be used to expose services to the outside world by delegating the capability to a 3rd party API Gateway, like Kong Gateway. This gives us plenty of options when it comes to exposing our services from within a `Mesh`:

• - To expose our services via a mature API Management solution, we can still use the `delegated` gateway mode.
• - If we don’t need an APIM solution, but simply a pure Envoy-based ingress for our services, we can use the new `builtin` mode, which has the benefit of not requiring a 3rd party solution.

The builtin gateway is currently experimental and is enabled with the kuma-cp flag `--experimental-meshgateway` or the environment variable `KUMA_EXPERIMENTAL_MESHGATEWAY`.

## Performance Improvements

We always put lots of effort into improving the performance of Kong Mesh and Kuma to better sustain large service mesh deployments. On this release, we have significantly refactored our memory management capabilities and – by doing so – decreased memory consumption by 90%.

Below, you can observe the differences in memory consumption between Kuma 1.4.1 and the new 1.5.0, when new services are being added. These benefits are inherited by Kong Mesh 1.6.0.

Performance is a key focus area of Kong Mesh and Kuma, and this is one of many performance improvements that we have shipped into the project over the past few months, in order to make Kong Mesh easier than ever to scale in production environments.

## Learn more

[Get in touch with Kong](https://konghq.com/request-demo-kong-mesh)Get in touch with Kong to learn more about Kong Mesh and how to build an enterprise service mesh. You can also [download Kong Mesh](https://docs.konghq.com/mesh/1.6.x/install)download Kong Mesh and get started for free.