Por Andrew Tan
Los gastos que nadie incluye en el presupuesto de migración — y por qué el verdadero precio de pasar a tiempo real no tiene nada que ver con las licencias de software
El presupuesto que no sobrevivió al primer contacto
Un VP de Ingeniería que conozco presupuestó $180,000 para la migración de su equipo de batch a streaming. Eso fue hace doce meses. La última vez que hablamos, el proyecto había consumido $640,000 y aún estaban a seis semanas de producción.
¿Qué pasó? No fue fraude. No fue un aumento del alcance en el sentido tradicional. Simplemente no lograron tener en cuenta los costos que no aparecen en las cotizaciones de los proveedores: el retraso de seis semanas mientras contrataban a un ingeniero de Kafka que entendía la semántica de exactamente una vez. Los tres meses que pasaron ejecutando batch y streaming en paralelo porque nadie confiaba aún en el nuevo pipeline. La consultoría de emergencia cuando su agregación en streaming produjo números diferentes al informe batch y el CFO lo notó.
El software en sí era barato. Los costos ocultos los devoraron.
He visto este patrón repetirse en empresas de todos los tamaños. Los equipos presupuestan para infraestructura y licencias. No presupuestan para la incertidumbre, el retrabajo y el impuesto operativo de mantener dos sistemas mientras uno reemplaza al otro. Para cuando se dan cuenta de lo que está sucediendo, el proyecto está o bien sobre el presupuesto o bien no cumple con lo prometido — a veces ambos.
Esto es lo que realmente cuesta dinero cuando te mueves de batch a streaming.
Costo #1: El talento que aún no tienes
La ingeniería de batch y la ingeniería de stream están relacionadas de la misma manera que la carpintería y la fabricación de muebles. Mismo material, oficio completamente diferente.
Tu equipo actual conoce los cron schedules, los escaneos de tablas y la reconfortante finalidad de un trabajo que comienza, se ejecuta y termina. Streaming les pide que piensen en tiempo de evento, gestionen un estado ilimitado y depuren sistemas que nunca dejan de funcionar. Algunos de tus ingenieros se adaptarán rápidamente. Otros no — no porque sean malos ingenieros, sino porque el procesamiento de streams distribuidos es genuinamente difícil y no todos quieren especializarse en ello.
Esto crea un costo oculto en tres formas:
Contratación: Un ingeniero senior de procesamiento de streams en Londres o Nueva York cuesta entre $160,000 y $220,000 de salario base en este momento, además del tiempo promedio de contratación de cuatro meses para esa especialidad. Si necesitas dos de ellos, eso es casi medio millón en salario antes de que hayan escrito una línea de código de producción.
Capacitación: Tus ingenieros actuales necesitan aprender nuevos conceptos: watermarking, consumer lag, partition skew, operadores con estado, al menos una vez versus exactamente una vez. Estos no son temas para un taller de una tarde. Son meses de aprendizaje práctico donde la productividad es más baja de lo normal y los errores son más costosos de lo habitual.
Rotación: Algunos de tus mejores ingenieros de batch se irán durante la migración — no porque no puedan aprender streaming, sino porque no se inscribieron para convertirse en especialistas en sistemas distribuidos. Les gustaba el trabajo de datos. Irán a algún lugar que todavía lo haga de la manera que disfrutan.
La partida presupuestaria para "talento" en la mayoría de los planes de migración cubre la capacitación. Rara vez cubre los retrasos en la contratación, la pérdida de productividad o la rotación inesperada.
Costo #2: El período de operación paralela
Nadie habla lo suficiente de esto. No puedes simplemente apagar batch y encender streaming. No si valoras tu trabajo.
Durante algún período — típicamente de tres a seis meses, ocasionalmente más — ejecutarás ambos sistemas. El pipeline de batch sigue produciendo los informes en los que todos confían. El pipeline de streaming corre junto a él, produciendo resultados que teóricamente deberían coincidir pero que a menudo no lo hacen, al menos no al principio.
Esto significa el doble de infraestructura. El doble de monitoreo. El doble de alertas. Y un equipo de ingenieros pasando sus días reconciliando dos conjuntos de números en lugar de construir nuevas funciones.
Una empresa de comercio electrónico con la que trabajé ejecutó sistemas paralelos durante ocho meses. Su stack de batch costaba aproximadamente $4,200 por mes en computación en la nube. Su stack de streaming costaba $7,800 por mes. Durante ocho meses, pagaron ambos. Eso es $96,000 solo en infraestructura — sin contar el tiempo de ingeniería dedicado a investigar por qué el conteo en streaming de los pedidos del martes estaba 347 por debajo del conteo batch.
El período paralelo no es opcional. Es un seguro. Pero como todo seguro, es caro, y la mayoría de los equipos subestiman la prima.
Costo #3: La arqueología de datos
Tus pipelines de batch contienen años de lógica de negocio acumulada. En algún lugar de un script de Python de 400 líneas que se ejecuta a las 2 AM hay una condición de join que existe debido a una excepción de precios de 2019. Nadie documentó por qué está ahí. La persona que lo escribió se fue en 2021. Pero si lo eliminas, los números de ingresos cambian un 0.3% y finanzas envía correos electrónicos enojados.
Migrar a streaming significa entender cada uno de estos artefactos. No puedes simplemente portar el código. La lógica necesita ser reimplementada para el procesamiento continuo de eventos, lo que significa que primero debes entender qué hace y por qué. Esto es arqueología de datos — tedioso, lento e imposible de estimar con precisión porque no sabes qué encontrarás hasta que comiences a cavar.
Una firma de servicios financieros que asesoré pasó cinco semanas en un solo pipeline. La implementación en streaming tomó tres días. Entender por qué la versión batch producía un resultado específico en un caso extremo tomó los otros treinta y dos días. La lógica de negocio estaba codificada en un procedimiento almacenado escrito por tres personas diferentes durante cuatro años, con comentarios como "arreglo para error de Q2" y sin más explicación.
Costo #4: El impuesto de complejidad operativa
Los pipelines de batch fallan de manera visible. Un trabajo se bloquea. Recibes una alerta. Lo arreglas. Lo vuelves a ejecutar. Todos entienden lo que pasó.
Los pipelines de streaming fallan sutilmente. El consumer lag se acumula durante horas. Las tiendas de estado crecen hasta que alcanzan los límites de memoria. Los watermarks se desvían y de repente tus agregaciones en ventanas están dejando caer eventos tardíos. Para cuando te das cuenta, has estado produciendo resultados ligeramente incorrectos durante medio día.
Las herramientas operativas también son diferentes. No solo estás monitoreando si un trabajo terminó. Estás monitoreando distribuciones de latencia, pendientes de throughput, señales de backpressure y tamaños de tiendas de estado. Tus runbooks existentes no aplican. Tus alertas existentes no detectan los nuevos modos de falla.
Construir esta madurez operativa lleva tiempo y errores. La primera vez que tu pipeline de streaming deja caer silenciosamente el 2% de los eventos durante seis horas, invertirás mucho en una mejor observabilidad. Ese es un costo necesario. Pero casi nunca está en el presupuesto inicial.
Costo #5: El costo de oportunidad que nadie mide
Mientras tus mejores ingenieros están depurando el reequilibrio de particiones y reconciliando salidas de batch versus streaming, no están haciendo otro trabajo. Las solicitudes de funciones se acumulan. La deuda técnica se acumula. Los competidores lanzan cosas que tu equipo habría construido si no estuvieran hasta el cuello en la migración.
Este es el costo más difícil de cuantificar y el más fácil de ignorar. No hay una factura por ello. Pero es real.
Una empresa SaaS pausó todo el desarrollo de nuevos productos de datos durante nueve meses durante su migración a streaming. Cuando terminaron, habían construido un pipeline en tiempo real técnicamente impresionante — pero su principal competidor había lanzado tres funciones de análisis en el mismo período y ganado cuota de mercado. La migración fue un éxito técnico y un retraso estratégico.
Por qué seguimos subestimando
Parte del problema es el mensaje de los proveedores. Las plataformas de streaming venden el destino: insights en tiempo real, reacciones instantáneas, ventaja competitiva. No anuncian el viaje: la contratación, los sistemas paralelos, la arqueología, la curva de aprendizaje operativa.
Otra parte es el sesgo de optimismo. Cada equipo de ingeniería cree que serán la excepción. Su código es más limpio. Su equipo es más inteligente. Sus requisitos son más simples. A veces eso es cierto. Usualmente no lo es.
El resultado es una brecha persistente entre el costo presupuestado y el costo real. He visto ratios de 2:1, 3:1, incluso 5:1. No porque alguien fuera deshonesto — porque los costos reales son invisibles hasta que ya te has comprometido.
Cómo presupuestar honestamente
No puedes eliminar estos costos, pero puedes tenerlos en cuenta. Así es como aconsejo a los equipos que lo piensen:
Agrega un buffer del 40% a las estimaciones de infraestructura. El período paralelo, los entornos de prueba, los despliegues en sombra — todos agregan computación y almacenamiento que no predecirás con precisión.
Presupuesta un mínimo de seis meses de operación dual. Si terminas antes, celebra. Si no, no estarás explicando sobrecostos a tu CFO.
Contrata o contrata a un especialista en streaming antes de comenzar, no después de que te atasques. El costo de traerlos temprano es alto. El costo de traerlos después de tres meses de falsos comienzos es mayor.
Acepta que algunos pipelines deben permanecer en batch. No todo se beneficia del tiempo real. Informes diarios, análisis históricos, pipelines de entrenamiento de ML — estos son a menudo cargas de trabajo apropiadas para batch que no justifican el costo de la migración. Sé explícito sobre lo que no estás migrando.
Una forma diferente de pensar en la transición
Los equipos que manejan esto bien comparten un rasgo: no lo ven como una migración. Lo ven como agregar una capacidad.
En lugar de "estamos pasando de batch a streaming", dicen "estamos agregando streaming donde crea valor, y manteniendo batch donde aún funciona". Esto suena como semántica, pero cambia la economía completamente. Ya no estás comprometido a mover todo. Puedes evaluar cada pipeline por sus propios méritos: requisitos de latencia, complejidad, valor de negocio, costo de migración.
Algunos pipelines se mueven. Algunos no. Los que se mueven justifican su propia inversión. Los que se quedan no generan costos innecesarios.
Aquí es donde una plataforma unificada importa. Si estás ejecutando herramientas separadas para batch y streaming, cada pipeline enfrenta presión para migrar porque mantener dos plataformas es caro. Si puedes ejecutar ambos modelos en la misma plataforma — mismos workflows, mismo equipo, mismo enfoque operativo — la presión desaparece. Agregas real-time streaming donde se gana su lugar y dejas batch donde ya está funcionando.
Esa es la aproximación que construimos en layline.io. No porque batch sea malo — a menudo es exactamente correcto — sino porque forzar a los equipos a elegir un enfoque y abandonar el otro crea costos y riesgos artificiales. Los equipos que duermen bien por la noche son los que no intentaron hervir el océano.
La conclusión
El costo oculto de cambiar de batch a streaming no es el software. Es todo lo demás: las personas que necesitas contratar, los sistemas que necesitas ejecutar en paralelo, la lógica heredada que necesitas excavar, la madurez operativa que necesitas construir, y la oportunidad que pierdes mientras te enfocas en infraestructura en lugar de producto.
Presupuesta para ello. Tenlo en cuenta. Sé honesto sobre qué pipelines realmente necesitan moverse y cuáles no.
El objetivo no es estar en tiempo real en todas partes. El objetivo es estar en tiempo real donde importa, sin arruinarte en el proceso.
Qué sigue
Si estás planeando una migración de batch a streaming, comienza con una auditoría honesta. Enumera tus diez principales pipelines. Para cada uno, pregunta: ¿cuál es el costo real de la latencia? ¿Cuál es el esfuerzo estimado de migración? ¿Cuál es el aumento de complejidad operativa?
Si los números no justifican el movimiento para un pipeline dado, déjalo en paz. Enfoca tu energía en los dos o tres donde el tiempo real crea un valor de negocio medible.
Para los equipos que evalúan plataformas, la Community Edition de layline.io es gratuita para explorar. Puedes prototipar un pipeline de streaming junto a tu workflow de batch existente y ver cómo es la realidad operativa antes de comprometer el presupuesto.
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 en batch como en tiempo real a escala.
