Por Andrew Tan
La pila de orquestación típica de un equipo de datos evoluciona en pasos razonables. Comienzas con Airflow. Está bien. El equipo lo conoce. Los DAGs se ejecutan según lo programado. Cinco años después, Airflow está ejecutando 300 DAGs y todos tienen miedo de tocar la imagen base.
Entonces necesitas algo moderno. Una nueva contratación apuesta por Prefect: es nativo de Python, la experiencia del desarrollador es mejor y la interfaz de usuario es más limpia. Así que comienzas nuevos proyectos en Prefect y dejas los antiguos en Airflow.
Luego aparece un equipo de ML. Quieren Dagster porque el pensamiento centrado en Assets y el seguimiento de linaje se ajustan a su trabajo de almacén de características. Razonable. Añades Dagster.
Nadie tomó una mala decisión. Cada herramienta fue la elección correcta en su contexto. Pero ahora el equipo está pagando por tres planificadores, tres conjuntos de trabajadores, tres paneles de monitoreo y tres modelos mentales. Cuando los datos fluyen de Airflow a Dagster antes de ir a una llamada de API orquestada por Prefect, el linaje se rompe. Puedes ver cada paso de forma aislada. No puedes ver la cadena completa.
Este es el impuesto de orquestación. Y es casi universal en las empresas que han estado construyendo infraestructura de datos por más de dos años.
Cómo se manifiesta el impuesto
La factura oculta aparece en tres lugares que la mayoría de los equipos no miden.
La costura de coordinación. Cuando el Pipeline A (Airflow) necesita activar el Pipeline B (Dagster), ¿cómo lo hace? Usualmente: una caída de archivo, una bandera en la base de datos, una llamada de API o, lo más común, un mensaje de Slack entre los humanos que poseen cada sistema. Esa "integración" ahora es fundamental. Cuando se rompe, falla silenciosamente. Te enteras tres horas después cuando el pipeline de Dagster se ejecutó con los datos de ayer.
Algunos equipos terminan con un ingeniero dedicado a mantener lo que internamente llaman "la capa de pegamento". Ese es un rol a tiempo completo escribiendo scripts en Python para hacer que tres herramientas de orquestación finjan ser una sola.
El laberinto de depuración. Un problema de calidad de datos surge en la herramienta de BI. El número es incorrecto. ¿Dónde se equivocó? Comienzas en los registros de Airflow. El DAG tuvo éxito. Verificas Prefect: el flujo de eventos tuvo éxito. Verificas Dagster: los Assets se materializaron. En algún lugar en la transferencia entre sistemas, algo salió mal, y no hay una vista unificada de lo que sucedió.
El MTTR (tiempo medio de resolución) para fallos entre sistemas es consistentemente 3-5 veces mayor que los fallos en un solo sistema en los equipos que rastrean esto. El costo de depuración es la pieza oculta más grande.
El peaje del cambio de contexto. El planificador de Airflow piensa en expresiones cron y dependencias de tareas. Dagster piensa en Assets y políticas de frescura. Prefect piensa en flujos y despliegues. Cada uno tiene su propio modelo de autenticación, su propia gestión de secretos, su propia forma de manejar reintentos. Los ingenieros se vuelven fluidos en los tres, lo que significa que no son expertos en ninguno de ellos, y cada transición de herramienta cuesta un esfuerzo cognitivo que no aparece en ningún rastreador de sprints.
La situación de Kestra
Por eso el marketing de Kestra resuena. Su propuesta — "puedes ejecutar Airflow, Spark, dbt y scripts personalizados, todo desde un solo orquestador" — aborda directamente la frustración de múltiples herramientas.
Pero hay una diferencia entre un único panel de control y una única fuente de verdad. Kestra puede envolver tus herramientas existentes. Eso es útil. No reduce realmente el problema de coordinación distribuida. Has añadido otra herramienta encima de tres herramientas.
La proliferación de orquestación no es un problema de interfaz de usuario. Es un problema de propiedad del flujo de datos. ¿Quién posee el evento que activa la cadena? ¿Quién posee el esquema de los datos que pasan entre sistemas? ¿Quién es responsable cuando la transferencia entre el paso 2 y el paso 3 falla?
Una nueva capa de orquestación en la parte superior no responde a esas preguntas. Solo añade un sistema más para revisar cuando estás depurando a las 2 AM.
Lo que realmente ayuda
Seamos directos sobre lo que funciona frente a lo que solo desplaza el problema.
Funciona: consolidarse alrededor de un modelo, agresivamente. Elige la herramienta que maneja bien el 80% de tu carga de trabajo actual, migra todo lo que puedas y vive con la fricción de mover trabajos heredados. Es doloroso durante seis meses. Después de eso, tienes un modelo de programación, un conjunto de trabajadores, un lugar para mirar cuando las cosas fallan. Los equipos que hacen esto consistentemente reportan una reducción del 40-60% en el tiempo de respuesta a incidentes en un año.
Funciona: tratar las transferencias entre sistemas como datos de primera clase. Si tienes que ejecutar múltiples herramientas por razones legítimas (por ejemplo, los pipelines de ML realmente se benefician del modelo de Assets de Dagster), haz que cada transferencia sea un traspaso de datos explícito y monitoreado. No una caída de archivo. No una bandera en la base de datos que alguien añadió a una tabla hace cuatro años. Un esquema definido, con observabilidad, con reintentos, con alertas. El pegamento se convierte en parte de tu diseño de sistema en lugar de un accidente del mismo.
No funciona: añadir observabilidad sobre la fragmentación. Otro panel que muestra el estado de los tres sistemas no soluciona el problema de coordinación, solo hace que el fallo distribuido sea visible en más lugares. Necesitas menos cosas que observar, no mejores herramientas para observar más cosas.
No funciona: teatro de migración. "Estamos migrando a Dagster en los próximos 18 meses" no es un plan. Es una declaración de que el dolor no es lo suficientemente malo aún como para hacer el trabajo real. Hasta que realmente retires la herramienta antigua, solo estás añadiendo superficie de integración mientras planeas.
La pieza de batch/streaming
Una razón real por la que los equipos ejecutan múltiples herramientas de orquestación es que batch y streaming realmente tienen diferentes requisitos. Airflow programa trabajos. Kafka procesa flujos. Diferentes paradigmas, diferentes herramientas, y si estás tratando de servir a ambos en la misma plataforma de datos, terminas con dos sistemas de gestión de workflows separados.
Esto vale la pena nombrarlo directamente: una plataforma que maneja tanto batch como streaming dentro del mismo modelo de despliegue, la misma definición de workflow y las mismas herramientas de operaciones significa que el mismo equipo que ejecuta el ETL nocturno puede encargarse del procesamiento de eventos en tiempo real. No porque alguien esté reinventando Airflow o Kafka, sino porque la división entre "programado" y "basado en eventos" no debería requerir dos especialidades de ingeniería separadas y dos sistemas de monitoreo separados.
El objetivo no es reemplazar todo lo que tienes. Es dejar de pagar el impuesto.
La pregunta real
La conversación generalmente gira en torno a la misma pregunta: "¿Es este realmente un problema que vale la pena resolver, o simplemente la naturaleza de construir sistemas de datos?"
Justo. Cada empresa tiene deuda técnica. No todas las deudas valen la pena pagarlas.
Aquí hay una forma simple de pensarlo: si tu rotación de guardia incluye "revisar los tres planificadores" como un paso en cada manual de operaciones, estás pagando el impuesto de orquestación cada semana. Si un nuevo ingeniero de datos necesita un mes para ser productivo porque tiene que aprender los modelos mentales de múltiples herramientas, lo estás pagando en cada contratación. Si tu proceso de depuración requiere cruzar referencias de tres sistemas de registros diferentes, lo estás pagando en cada incidente.
Suma eso. Luego decide.
Si estás lidiando con la proliferación de orquestación y quieres entender cómo podría ser un camino hacia la consolidación, especialmente cuando manejas cargas de trabajo tanto batch como en tiempo real, ponte en contacto. Podemos revisar tu configuración específica y darte una imagen honesta de lo que vale la pena cambiar y lo que no.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresarial que maneja cargas de trabajo tanto batch como en tiempo real a escala.
