El concepto cabe en una servilleta
A nivel conceptual, orquestar es directo: tenés etapas, definís dependencias entre ellas, y en lo posible paralelizás lo que no depende entre sí. Eso es todo.
Podés dibujar un pipeline en una servilleta: extracción, transformación, carga. Flechas que indican qué va primero. Quizás algunas ramas que corren en paralelo. El modelo mental es simple.
Y esa simplicidad conceptual es real. No hay nada misterioso en decir "primero extraigo, después transformo, después cargo". El tema es cuando eso tiene que funcionar todos los días, a escala, sin intervención manual.
Lo que no ves en los tutoriales
Levantar un orquestador en Docker y correr un DAG de ejemplo toma una tarde. Pero eso no es operarlo en producción.
En producción aparecen otras cosas:
Colas que se acumulan: si las tareas tardan más de lo esperado o hay picos de carga, empiezan a encolarse ejecuciones. Y cuando hay muchas cosas encoladas, el sistema se vuelve lento y difícil de diagnosticar.
Reintentos parciales: cuando un pipeline de 90 tareas falla en la tarea 88, necesitás poder retomar desde ahí. Si no tenés esa capacidad, cada fallo implica volver a correr todo desde el principio. Con pipelines cortos no importa. Con pipelines de horas, es un problema operativo serio.
Componentes que interactúan: un orquestador como Airflow no es un proceso único. Tiene scheduler, workers, base de datos de metadata, webserver. Cada componente puede fallar de formas distintas, y diagnosticar dónde está el problema requiere entender cómo interactúan.
Base de metadata que crece: toda la información de ejecuciones, estados, logs, se guarda en una base de datos. Con el tiempo, esa base crece. Si no la mantenés, el sistema se degrada.
La distancia entre el concepto y la operación
El concepto de orquestación es simple. La operación de un orquestador a escala no lo es.
Esto no significa que sea imposible ni que requiera un equipo dedicado. Significa que hay una curva de aprendizaje entre "tengo un DAG que corre" y "tengo un sistema de orquestación que funciona de manera confiable".
Esa curva incluye entender:
- Cómo dimensionar los workers según la carga.
- Cómo configurar políticas de retry que tengan sentido.
- Cómo limpiar la base de metadata sin perder información útil.
- Cómo diagnosticar cuando algo se traba en la cola.
- Cómo hacer backfills sin saturar el sistema.
Nada de esto es ciencia espacial, pero tampoco viene gratis con la instalación.
Por qué existen las ofertas managed
Hay ofertas de orquestadores managed (servicios donde alguien más gestiona la infraestructura) por una razón: gestionar un orquestador a escala es trabajo.
No es que sea imposible hacerlo uno mismo. Pero si tu objetivo es procesar datos y no convertirte en experto en operación de Airflow, tiene sentido evaluar si el costo de un servicio managed se justifica contra el tiempo que vas a invertir en operación.
Esto no es una recomendación de compra. Es reconocer que la complejidad operativa existe y que hay formas de delegarla.
Cuándo la complejidad se justifica
Un script de Python que encadena tres pasos ya es un orquestador. Si tu pipeline es simple y corre una vez por día sin dramas, quizás no necesitás más que eso.
La complejidad de un orquestador dedicado se justifica cuando:
- Tenés muchos pipelines que necesitan coordinarse.
- Necesitás visibilidad centralizada de qué corrió, cuándo, con qué resultado.
- Los reintentos y backfills son frecuentes y manuales es insostenible.
- Hay múltiples personas trabajando en pipelines y necesitás un lugar común.
Si ninguna de estas condiciones aplica, quizás la solución más simple sea suficiente. No hay mérito en adoptar complejidad que no necesitás.
En resumen
Orquestar, como concepto, es simple: etapas, dependencias, paralelismo. Pero operar un orquestador en producción tiene complejidades que no aparecen en el tutorial.
Colas, reintentos parciales, componentes que interactúan, base de metadata que crece. Todo eso es parte del trabajo de mantener un sistema de orquestación funcionando.
Antes de adoptar un orquestador, vale la pena preguntarse si la complejidad se justifica. Y si se justifica, vale la pena saber que hay una curva entre el primer DAG y un sistema confiable.