Los Costos Ocultos de Construir tu Propia Capa de Integración Batch-Streaming

Por Andrew Tan

Los costos ocultos de construir tu propia capa de integración de Batch-Streaming

Con la codificación asistida por IA, construir tus propios data pipelines parece más barato que nunca. Pero los costos reales no están en la construcción inicial, sino en el mantenimiento, las rotaciones de guardia y la complejidad acumulada que se complica con el tiempo.

Aquí hay una conversación que sigue ocurriendo:

Gerente de Ingeniería: "Necesitamos un nuevo data pipeline para el proyecto de análisis de clientes."

Ingeniero Senior: "Puedo construirlo. Con Cursor y Copilot, puedo tener la lógica central lista en un par de días."

GI: "¿Qué hay del mantenimiento?"

IS: "Es solo un script de Python con algo de orquestación de Airflow. ¿Qué tan difícil puede ser?"

Tres meses después, el ingeniero que lo construyó está de vacaciones, el pipeline está fallando silenciosamente y nadie puede averiguar por qué los conteos de segmentos de clientes no coinciden con el sistema fuente. El "simple script de Python" ha crecido a 2,400 líneas, toca tres bases de datos diferentes y no tiene ninguna documentación sobre lo que se supone que debe hacer la lógica de negocio.

La revolución de la codificación con IA ha hecho que la decisión de construir parezca casi gratuita. Lo que no ha cambiado es la decisión de poseer — y ahí es donde reside la mayor parte del costo.

La Contabilidad Honesta

Cuando los equipos estiman el costo de construir su propia capa de integración de datos, generalmente modelan algo como esto:

Así es como se ve realmente la hoja de cálculo después de doce meses:

La brecha no se debe a que los ingenieros sean malos estimando. Es porque la hoja de cálculo solo captura el trabajo que puedes ver de antemano. Los costos reales se acumulan de manera invisible: las alertas a las 2 AM, las "soluciones rápidas" que se vuelven permanentes, la sutil corrupción de datos que lleva días detectar.

El Problema de los Dos Pipelines

Existe un modo de fallo específico que afecta a los equipos que construyen su propia infraestructura de batch-streaming: el problema de la divergencia.

Comienzas con batch. Es sencillo. Escribes un trabajo que se ejecuta cada hora, extrae datos, los transforma, los carga en algún lugar. Funciona bien.

Luego, el negocio pide procesamiento en tiempo real. "¿Podemos obtener estos datos en segundos en lugar de horas?"

Entonces construyes un pipeline de streaming. Kafka, tal vez Flink o Spark Streaming. Consume los mismos datos de origen y los entrega al mismo destino. Pero la lógica de transformación es diferente: el streaming tiene diferentes restricciones, diferente gestión de estado, diferentes modos de fallo. No puedes simplemente portar el código batch.

Ahora tienes dos pipelines haciendo aproximadamente lo mismo. Producen resultados ligeramente diferentes porque el join batch es externo y el join streaming es interno, o porque el trabajo batch maneja los datos tardíos de manera diferente a la ventana de streaming. Cuando alguien pregunta por qué los números no coinciden, tienes que depurar ambos sistemas.

Seis meses después, tienes:

• Dos bases de código que mantener
• Dos conjuntos de infraestructura que monitorear
• Dos modos de fallo que entender
• Dos rotaciones de guardia (o una persona muy infeliz)
• Y una pregunta persistente: ¿por qué no podemos tener solo un pipeline?

La respuesta honesta: porque batch y streaming son paradigmas genuinamente diferentes, y la mayoría de las pilas DIY no están construidas para unificarlos.

Los Multiplicadores de Complejidad Oculta

Más allá de los costos evidentes, hay tres multiplicadores de complejidad que no aparecen en las estimaciones iniciales:

Evolución del Esquema

Tu sistema fuente cambia. Se renombra una columna. Se amplía un tipo. Aparece un nuevo campo nullable. En una plataforma gestionada, esto se maneja. En tu pipeline personalizado, es un cambio de código, un despliegue y una oración para que no hayas roto a los consumidores aguas abajo.

El costo real no es el cambio en sí. Es la coordinación: notificar a cada equipo que consume estos datos, actualizar sus esquemas, probar la integración, retroceder si algo sale mal. Un cambio de código de dos horas se convierte en un proyecto de dos semanas.

Manejo de Fallos a Escala

Un simple bucle de reintento es fácil. Retroceso exponencial, una cola de mensajes fallidos, algunas alertas: puedes construir eso en una tarde.

Pero el manejo de fallos en producción es fractal. ¿Qué pasa cuando el destino está inactivo durante una hora? ¿Qué pasa cuando un mensaje es demasiado grande? ¿Qué pasa cuando una discrepancia de esquema causa un fallo de análisis? ¿Qué pasa cuando el mismo evento se entrega dos veces? ¿Qué pasa cuando las particiones de red crean situaciones de cerebro dividido?

Cada caso límite necesita manejo. Cada manejador necesita pruebas. Cada prueba necesita mantenimiento. La "lógica de reintento simple" crece hasta convertirse en una preocupación de sistemas distribuidos en la que nadie del equipo tiene una experiencia profunda.

Brechas de Observabilidad

Necesitas saber: ¿Está funcionando el pipeline? ¿Está manteniéndose al día con la fuente? ¿Se están procesando o perdiendo eventos? ¿Cuál es la latencia? ¿Cuál es la tasa de error? ¿Cuál es el costo por millón de eventos?

Construir esta visibilidad no es solo agregar un endpoint de métricas. Es diseñar las métricas correctas, construir los paneles de control, establecer las alertas adecuadas (ni demasiado ruidosas, ni demasiado silenciosas) y entrenar al equipo para interpretarlas. Es otro sistema que construir, mantener y depurar.

Cuando Construir Realmente Tiene Sentido

Quiero ser justo. Hay situaciones en las que construir tu propia capa de integración es la decisión correcta:

Tienes requisitos extremadamente específicos que ningún proveedor maneja bien: formatos de datos inusuales, restricciones de seguridad personalizadas, entornos de implementación exóticos.

Tienes el equipo para ello — ingenieros de sistemas distribuidos que han operado Kafka a escala, que entienden la semántica de exactamente una vez, que han depurado problemas de backpressure a las 3 AM.

Es un verdadero diferenciador — la capa de procesamiento de datos es fundamental para tu producto, no solo infraestructura. No estás construyendo un Data Pipeline; estás construyendo una ventaja competitiva.

Estás a una escala donde los costos del proveedor superan los costos de construcción — aunque sé honesto sobre lo que incluye el "costo de construcción". La mayoría de los equipos subestiman por 2-3 veces.

Para todos los demás, el cálculo generalmente favorece la compra, si se tiene en cuenta el costo total de propiedad.

La Evaluación de Proveedores que Realmente Importa

Si estás comparando proveedores, la matriz de características no es el lugar adecuado para comenzar. La mayoría de las plataformas tienen capacidades similares en papel. Lo que importa es el modelo operativo:

¿Cómo manejan el problema de las 2 AM? Cuando algo falla en producción, ¿a quién se le notifica? ¿Es tu equipo depurando su infraestructura, o su equipo depurando tu Data Pipeline?

¿Cuál es la ruta de migración si decides irte? Los Data Pipelines son pegajosos. Comprende cuánto cuesta extraer tu lógica y moverla a otro lugar.

¿Unifican batch y streaming? ¿O terminarás con dos Data Pipelines de todos modos, solo que en la infraestructura de otra persona?

¿Cuál es el verdadero TCO? Incluye capacitación, tiempo de integración, el costo de esperar las características que necesitas y el costo de oportunidad del tiempo de ingeniería dedicado a gestionar la plataforma.

Dónde encaja layline.io

No pretenderé que esta es una opinión imparcial. En layline.io, construimos una plataforma específicamente para equipos que han hecho un análisis honesto y han decidido que construir no es la opción correcta.

La apuesta principal: el procesamiento por lotes y el streaming no deberían ser pipelines separados. Deberían ser los mismos Workflows, las mismas herramientas, el mismo equipo. Cuando necesitas procesamiento en tiempo real, no reconstruyes. Ajustas una configuración.

La carga operativa recae en nosotros. La evolución del esquema, el manejo de fallos, la observabilidad — ese es el trabajo de la plataforma, no el tuyo. Tu equipo se enfoca en la lógica de negocio, no en la infraestructura de sistemas distribuidos.

¿Es más barato que construir tu propia solución? Eso depende de cuán honestamente contabilices el costo de construcción. Si cuentas dos semanas de desarrollo y lo das por terminado, probablemente no. Si incluyes la rotación de guardia, la carga de mantenimiento, los incidentes de deriva de esquema y el costo de oportunidad de ingenieros que no están construyendo características del producto — entonces, generalmente, sí.

La Pregunta a Hacer

Antes de que tu equipo se comprometa a construir, pregunta esto:

"Si construimos esto nosotros mismos, ¿quién se encargará de la llamada a las 2 AM cuando falle dentro de seis meses? ¿Y saben a qué se están comprometiendo?"

Si la respuesta es clara y todos entienden el compromiso, adelante con la construcción. Si hay dudas, o si la respuesta es "lo resolveremos más tarde", haz un cálculo honesto. Los números podrían sorprenderte.

Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresariales que maneja cargas de trabajo tanto por lotes como en tiempo real a gran escala.