Kestra 2.0 flips unmatched worker routing from waiting to failing by default

The outbound stream is what makes the topology possible. In Kestra 2.0 the worker opens a gRPC stream out to the control plane, user code runs in the data plane, and that plane can sit in another region, another cloud, or a network with no inbound path ^[4]. Because the worker dials, the control plane needs no route into the network holding the data ^[15]. If a firewall review is what has been blocking a central orchestration service, read that line of the release notes before the feature list.

The same notes set out the migration. Several constructs are removed or changed, the upgrade has to pass through 1.3.x, and unmatched worker routing now fails by default where it used to wait ^[5]. That last default is the one that shows up on upgrade day. A task pointed at a worker group nobody has connected used to sit in a queue until someone noticed; now it errors. That is better behaviour, and it will surface every stale worker-group label in the repository.

Prefect's announcement runs the other way. Prefect said in July that it is acquiring Dagster Labs, and the announcement has Dagster keeping its name, its support and its open-source license, with no migration required for customers ^[1][2]. A post on dev.to that reads both events together allows that the deal "creates legitimate questions about long-term product direction" ^[13].

Five items go to the platform team in that post's proposed boundary: control plane, identity and secrets, worker environments, deployment path, shared monitoring. Five go to the data teams: workflow definitions, transformation code, data-quality rules, schedules and dependencies, domain runbooks ^[8][14]. The line falls between the worker environment and the code that runs inside it. "If every data team needs the platform team to install a Python dependency, self-service is mostly a logo," the post says ^[9]. Push the other way and workflow authors run arbitrary code with shared production credentials, at which point, the post says, "self-service has gone too far in the other direction" ^[10].

Task-versus-asset gets the same treatment. A task model asks what should run next; an asset model asks what data should exist and what it depends on; neither is universally better ^[11]. The test offered is which sentence your incidents actually use, "this job did not run" or "the customer dimension is missing yesterday's partition" ^[12].

The evidence that orchestrator selection has become an ownership question is one argument and one Reddit thread. Its answers were stay with Dagster, use Airflow because it is established, buy managed, or go smaller for a lean team. A few vendors turned up to recommend their own products, "because some laws of distributed systems are social" ^[6][7]. For the split-plane topology to be worth a two-hop upgrade, two things have to hold in your shop: data that cannot leave the network it lives in, and a platform team that can own worker images without becoming a ticket queue ^[4][9].