# Rerouting the Stream: How Lyft Moved to the Apache Flink Operator

DevFeed: [Rerouting the Stream: How Lyft Moved to the Apache Flink Operator](<https://devfeed.tech/articles/rerouting-the-stream-how-lyft-moved-to-the-apache-flink-operator-1242.md>)

Original publisher: [Read original article](<https://eng.lyft.com/rerouting-the-stream-how-lyft-moved-to-the-apache-flink-operator-36f20246d250?source=rss----25cd379abb8---4>)

Author: Maheep Myneni

Published: 2026-08-31T19:08:16Z

Content type: article

Language: en

Sources: [Lyft Engineering - Medium](<https://devfeed.tech/sources/lyft-engineering-medium.md>)

Topics: [Apache Iceberg](<https://devfeed.tech/topics/apache-iceberg.md>), [Streaming](<https://devfeed.tech/topics/streaming.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [autoscaling](<https://devfeed.tech/topics/autoscaling.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>)

Tags: [apache](<https://devfeed.tech/tags/apache.md>), [apache-flink](<https://devfeed.tech/tags/apache-flink.md>), [autoscaling](<https://devfeed.tech/tags/autoscaling.md>), [data-platforms](<https://devfeed.tech/tags/data-platforms.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [lyft](<https://devfeed.tech/tags/lyft.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [production](<https://devfeed.tech/tags/production.md>), [streaming](<https://devfeed.tech/tags/streaming.md>), [streaming-data-processing](<https://devfeed.tech/tags/streaming-data-processing.md>), [tooling](<https://devfeed.tech/tags/tooling.md>)

## AI overview

Lyft describes its migration from an internally developed Flink Kubernetes operator to the open-source Apache Flink Kubernetes Operator. The move addressed maintenance burden, technical debt, feature gaps, outdated dependencies, and growing real-time streaming demands, while providing capabilities such as autoscaling, memory tuning, safer upgrades, and automatic rollbacks.

## Source excerpt

Written by Maheep Myneni, Arda Kuyumcu, and Prem Santosh Udaya Shankar at Lyft. Why We Migrated: Technical Debt Meets Modern Streaming Demands Over the past several quarters, Lyft's Streaming Compute team retired our internally developed Flink Kubernetes operator and moved our entire streaming fleet onto the open-source Apache Flink Kubernetes operator. This post is about why we made the switch, how we pulled it off incrementally without disrupting users, and the follow-on work it took to actually get the benefits we were after. Back in 2020, when we first architected the Lyft Flink Kubernetes Operator, it was exactly what we needed. At that time, the open-source community hadn't yet built a dedicated control plane, so we built our own to manage all streaming applications on Kubernetes. It worked well for our initial workloads, but as our real-time data needs increased and our engineers' scope of ownership grew in both breadth and complexity, the cracks started to show. First came the maintenance burden. Our operator had become a relic of Lyft's early Kubernetes days, kept alive by a growing pile of custom code. Every Flink version upgrade meant carefully picking through layers of accumulated technical debt and hoping nothing broke on the way through. Second came the feature gap. Streaming tooling kept moving, and our engineers kept asking for capabilities that had become table stakes elsewhere, such as autoscaling to right-size jobs, automatic rollbacks on failed deploys, and an end to hand-tuning CPU and memory. Each request left us with two options, neither of which was ideal. We could explain why we couldn't support it yet, or spend weeks rebuilding something the open-source community had already shipped. Third was the dependency problem. We were pinned to outdated libraries. That doesn't break anything today, but it almost always creates new issues down the line. Security patches lagged, modern Kubernetes features stayed out of reach, and every quarter we waite