---
title: Mixer Adapter for Knative
subtitle: Demonstrates a Mixer out-of-process adapter which implements the Knative scale-from-zero logic
description: Demonstrates a Mixer out-of-process adapter which implements the Knative scale-from-zero logic.
publishdate: 2019-09-18
attribution: Idan Zach (IBM)
keywords: [mixer,adapter,knative,scale-from-zero]
target_release: 1.3
---

This post demonstrates how you can use [Mixer](/faq/mixer/) to push application logic
into Istio. It describes a Mixer adapter which implements the [Knative](https://knative.dev/) scale-from-zero logic
with simple code and similar performance to the original implementation.

## Knative serving

[Knative Serving](https://knative.dev/docs/serving/) builds on [Kubernetes](https://kubernetes.io/) to support deploying
and serving of serverless applications. A core capability of serverless platforms is scale-to-zero
functionality which reduces resource usage and cost of inactive workloads.
A new mechanism is required to scale from zero when an idle application receives a new request.

The following diagram represents the current Knative architecture for scale-from-zero.

{{< image width="60%" link="knative-activator.png" caption="Knative scale-from-zero" >}}

The traffic for an idle application is redirected to **Activator** component by programming Istio with `VirtualServices`
and `DestinationRules`. When **Activator** receives a new request, it:

1. buffers incoming requests
1. triggers the **Autoscaler**
1. redirects requests to the application after it has been scaled up, including retries and load-balancing (if needed)

Once the application is up and running again, Knative restores the routing from **Activator** to the running application.

## Mixer adapter

[Mixer](/faq/mixer/) provides a rich intermediation layer between the Istio components and infrastructure backends.
It is designed as a stand-alone component, separate from [Envoy](https://www.envoyproxy.io/), and has a simple extensibility model
to enable Istio to interoperate with a wide breadth of backends. Mixer is inherently easier to extend
than Envoy is.

Mixer is an attribute processing engine that uses operator-supplied configuration to map request attributes from the Istio proxy into calls
to the infrastructure backends systems via a pluggable set of adapters. Adapters enable **Mixer** to expose a single consistent API, independent of the
infrastructure backends in use. The exact set of adapters used at runtime is determined through operator configuration and can easily
be extended to target new or custom infrastructure backends.

In order to achieve Knative scale-from-zero, we use a Mixer [out-of-process adapter](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide)
to call the Autoscaler. Out-of-process adapters for Mixer allow developers to use any
programming language and to build and maintain your extension as a stand-alone program
without the need to build the Istio proxy.

The following diagram represents the Knative design using the **Mixer** adapter.

{{< image width="60%" link="knative-mixer-adapter.png" caption="Knative scale-from-zero" >}}

In this design, there is no need to change the routing from/to **Activator** for an idle application as in the original Knative setup.
When the Istio proxy represented by the ingress gateway component receives a new request for an idle application, it informs **Mixer**, including all the
relevant metadata information.
**Mixer** then calls your adapter which triggers the Knative **Autoscaler** using the original Knative protocol.

{{< idea >}}
By using this design you do not need to deal with buffering, retries and load-balancing because it is already handled by the Istio proxy.
{{< /idea >}}

Istio's use of Mixer adapters makes it possible to replace otherwise complex networking-based application logic with a more
straightforward implementation, as demonstrated in the [Knative adapter](https://github.com/zachidan/istio-kactivator).

When the adapter receives a message from **Mixer**, it sends a `StatMessage` directly to **Autoscaler**
component using the Knative protocol.
The metadata information (`namespace` and `service name`) required by **Autoscaler** are transferred by Istio proxy to
**Mixer** and from there to the adapter.

## Summary

I compared the cold-start time of the original Knative reference architecture to the new Istio Mixer adapter reference architecture.
The results show similar cold-start times.
The implementation using the Mixer adapter has greater simplicity. It is not necessary to handle low-level network-based mechanisms as these are handled by Envoy.

The next step is converting this Mixer adapter into an Envoy-specific filter running inside an ingress gateway.
This will allow to further improve the latency overhead (no more calls to **Mixer** and the adapter) and
to remove the dependency on the Istio Mixer.
