Lyft retired its in-house Flink operator, citing maintenance on every Flink upgrade and gaps in autoscaling and rollbacks.
Lyft has moved hundreds of production Apache Flink jobs from a homegrown Kubernetes operator to the Apache Flink Kubernetes Operator. In a Lyft Engineering post published on 31 August, streaming engineers Maheep Myneni, Arda Kuyumcu and Prem Santosh Udaya Shankar reported that the move unlocked last-state upgrades, in-place autoscaling and resource autotuning across the fleet.
Lyft built the in-house operator in 2020, when, as the team put it, the open-source community had not yet built a dedicated control plane for Flink on Kubernetes. Dual-deployment upgrades started a second cluster, took a savepoint, cancelled the old job, and restored from that savepoint. The legacy operator's own BlueGreen mode kept both clusters running until engineers switched traffic by hand.
The savepoint trigger had no retry logic and no idempotency. A timeout on a large-state job could cause the deploy to fail or restart the job with no state at all if no recent checkpoint was available. Non-JVM memory reservation sat behind one systemMemoryFraction knob, a guess at the overhead that Apache Beam Python harnesses needed. If they set it too low, TaskManagers were OOM-killed. If they set it too high, the fleet wasted memory.
The Apache operator treats last-state as a first-class upgrade mode, restoring from high-availability metadata or the latest checkpoint even when the JobManager is unhealthy. Rather than rewriting Jsonnet templates, Lyft's deploy API translated legacy FlinkApplication specs to FlinkDeployment resources at the boundary. The layer mapped jarName to jarURI, lifted node selectors into PodTemplateSpec objects, injected legacy environment variables, and defaulted upgrades to last-state.
The Apache operator starts JobManagers first to manage TaskManager lifecycles. Moving off the legacy operator also replaced dual deployments with stop-then-start deploys. That produced 3 to 6 minutes of downtime on a typical deploy, and about 20 minutes on the largest jobs. Lyft adopted FlinkBlueGreenDeployment, a CRD that was still under development when Lyft began testing it and shipped in operator 1.14.0 on 15 February 2026, so new versions run alongside old ones before cutover. After hitting a configuration-rename bug tracked as FLINK-38548, Lyft contributed the upstream fix. Myneni, Kuyumcu and Udaya Shankar wrote, "When we noticed the BlueGreen bug, we filed an issue and a fix landed upstream within days."
Lyft upgraded to Flink 1.19 to autoscale. Version 1.17 required a restart to change parallelism, which the jobs that needed scaling most could not afford. The operator documents in-place scaling from Flink 1.18 onwards. Upgrading to 1.19 also unblocked the independently released KinesisStreamsSource, which arrived in flink-connector-aws 5.0.0 in November 2024 and requires Flink 1.19 or later. It emits record backlog metrics for Kinesis streams the way the Kafka source does, giving the autoscaler a signal it previously lacked on Kinesis-bound jobs. Autotuning then reclaimed JVM overhead that Beam Python processes still used, OOM-killing the Beam fleet until Lyft moved the harness to a dedicated sidecar with its own limits.
Because autotuning resizes container memory and requires pod restarts, it conflicts with in-place autoscaling. Lyft split features by criticality: pricing and routing jobs use in-place autoscaling without autotuning, while less critical workloads accept restarts to tune resources. When restart-based autoscaling moved pods, a custom most-allocated scheduler packed them densely, letting Lyft shed underutilised nodes, while Karpenter provisioned EC2 capacity on demand.
Spotify's Flink operator, forked from Google's now-deprecated operator, documents running the Beam Python SDK harness as sidecar containers alongside Flink TaskManagers, the same arrangement Lyft arrived at after the autotuning OOMs. Amazon Managed Service for Apache Flink manages checkpoints and eliminates operator maintenance, though it lacks pod-level sidecar customisation.
By contrast, Netflix is running both its in-house and the open-source Flink Autoscaler while converging on the latter rather than adopting the Kubernetes Operator. Netflix runs more than 30,000 Flink jobs, against Lyft's hundreds. Lyft's Streaming Compute team next wants faster marketplace pricing loops and autonomous-vehicle telemetry. Myneni, Kuyumcu and Udaya Shankar wrote that "the autoscaler is doing what we had hoped, which is right-sizing a fleet that had been overprovisioned by a few million dollars per year."