Por Andrew Tan
La demostración que no aterrizó
Llevábamos dieciocho meses construyendo layline.io cuando conseguimos nuestro primer prospecto empresarial serio. Una empresa de logística de la lista Fortune 500. Su equipo de datos había revisado nuestra arquitectura, les gustó el enfoque de batch-plus-streaming, y programaron un taller de un día completo para profundizar.
Nos preparamos durante semanas. Construimos una demostración que mostraba todo: procesamiento de eventos complejos, manejo automático de backpressure, evolución de esquemas. Era, según todas las definiciones de libro de texto, una arquitectura de mejores prácticas. Distribuida. Tolerante a fallos. Construida para escalar horizontalmente. El tipo de sistema que dibujarías en una pizarra durante una charla en una conferencia.
El taller fue bien. Los ingenieros hicieron buenas preguntas. Luego, en los últimos treinta minutos, el arquitecto senior se recostó y dijo algo que nunca olvidaré: "Esto es impresionante. Pero ejecutamos todo en un solo servidor con trabajos cron, y funciona. ¿Qué ganaríamos realmente con toda esta complejidad?"
Tenía cien respuestas preparadas. Escalabilidad. Resiliencia. Preparación para el futuro. Pero podía ver en su cara que no estaba pidiendo una comparación tecnológica. Me estaba pidiendo que justificara por qué su realidad actual — aburrida, simple, funcional — era insuficiente.
No pude. No honestamente.
La arquitectura que eliminé
Tres meses después, estaba en una sala diferente con un cliente diferente. Este era una fintech de tamaño medio. Habían estado ejecutando un Data Pipeline basado en Kafka durante dos años. Se caía constantemente. Habían contratado consultores, actualizado hardware, reescrito su lógica de consumidor dos veces. El sistema era "correcto" según todos los libros de texto de sistemas distribuidos. También era una pesadilla de operar.
En la reunión, su ingeniero principal me mostró el diagrama de arquitectura. Era hermoso. Doce microservicios, tres capas de persistencia diferentes, un almacén de datos operativos personalizado para la gestión de estados. Habían seguido todos los patrones del blog de Confluent y el libro de Martin Kleppmann.
"¿Qué pasaría," pregunté, "si simplemente escribieran los eventos en un archivo y los procesaran en lotes?"
Me miró fijamente. "Eso... no es streaming."
"No," estuve de acuerdo. "Pero estás procesando eventos cada hora de todos modos porque tu sistema downstream no puede manejar actualizaciones en tiempo real. Estás pagando el costo operativo de una arquitectura de streaming para lograr semánticas de batch."
No compraron layline.io ese día. Pero seis semanas después, recibí un correo electrónico. Habían eliminado toda la arquitectura. La reemplazaron con un solo proceso que leía archivos y escribía en una base de datos. Básicamente, un trabajo cron. Su latencia p99 pasó de 200ms a cinco minutos — lo cual no importaba porque su proceso de negocio era diario. Sus incidentes operativos pasaron de tres por semana a cero. Su equipo de ingeniería pasó de apagar incendios a lanzar características.
La arquitectura "incorrecta" era mejor porque se ajustaba a sus restricciones reales, no a las aspiracionales.
La trampa de las mejores prácticas
Esto es lo que he aprendido de 25 años construyendo y vendiendo infraestructura de datos: las mejores prácticas son contextuales por definición, pero se comercializan como verdades universales.
La arquitectura de streaming-first que Netflix necesita no es la arquitectura que necesita una empresa SaaS de 50 personas. El enfoque de microservicios que permite a Amazon desplegar 10,000 veces al día no es lo que tu equipo de cuatro ingenieros necesita. El marco de agentes de IA que recaudó $50 millones en financiamiento de VC no es lo que tu ETL basado en cron necesita.
Pero no lo sabrías al leer contenido de la industria. Cada publicación de blog de proveedores, cada charla de conferencia, cada plano de arquitectura muestra la misma progresión: comienza simple, luego "gradúa" a la complejidad a medida que creces. La implicación es clara: lo simple es para principiantes. La complejidad es para practicantes serios.
Esto está al revés. La complejidad es una responsabilidad que debería añadirse con reticencia, no una insignia de honor que debería buscarse con entusiasmo.
Cómo se ve realmente "lo que funciona para nosotros"
He comenzado a hacer a los clientes una pregunta diferente en las conversaciones iniciales: "¿Cuál es la cosa más simple que podría funcionar para tu carga de trabajo real?" No tu carga de trabajo proyectada en tres años. No tu caso de uso aspiracional en tiempo real que el CEO mencionó una vez. Tu carga de trabajo real, hoy.
Las respuestas son consistentemente sorprendentes:
- Una empresa de salud que procesa un millón de registros de pacientes por día lo hace con un script de Python de un solo hilo que se ejecuta durante cuatro horas cada noche. Ha estado funcionando durante seis años sin modificaciones. ¿Por qué? Porque los registros llegan vía FTP a las 2 AM, y los médicos no miran los paneles hasta las 8 AM.
- Una empresa minorista que procesa datos de punto de venta de 2,000 tiendas utiliza un clúster de Kafka de tres nodos. No porque necesiten el throughput — podrían caber los eventos de un día en un solo archivo — sino porque su equipo existente conocía Kafka y no tenía tiempo para aprender algo nuevo durante su temporada más ocupada.
- Una empresa de logística que rastrea barcos contenedores en tiempo real usa... una hoja de cálculo. El equipo de operaciones la actualiza manualmente. Intentaron construir un Data Pipeline automatizado dos veces. Ambas veces, el sistema automatizado falló de maneras que eran más difíciles de depurar que la hoja de cálculo. La hoja de cálculo es "incorrecta" en una docena de maneras, pero es inspectablemente incorrecta. Puedes ver los errores.
Ninguna de estas son "mejores prácticas". Todas son correctas para su contexto.
El ciclo de exageración del agente de IA
Si quieres ver la trampa de las mejores prácticas en su forma más agresiva, observa cómo la industria de ingeniería de datos está respondiendo actualmente a los agentes de IA.
Cada blog de competidores que leo últimamente — Airbyte, Confluent, Kestra — está posicionando su producto como "listo para agentes de IA". Hay inmersiones profundas en el Protocolo de Contexto de Modelo, ontologías para agentes, gestión de ventanas de contexto. El mensaje implícito: si no estás arquitecturando para agentes de IA ahora mismo, estás quedándote atrás.
Le pregunté a un cliente la semana pasada si estaban considerando agentes de IA para sus Data Pipelines. "Pasamos seis meses tratando de que un LLM generara SQL," dijo. "Era 70% preciso en consultas simples y 30% preciso en las complejas. El 30% era lo suficientemente sutil como para que no lo detectáramos hasta que el CEO vio un número incorrecto en una presentación de la junta. Hemos vuelto a que los ingenieros escriban SQL."
Esto no es un argumento en contra de la IA. Es un argumento en contra de predeterminar la IA porque es la práctica actual. Los equipos que se benefician de los agentes de IA hoy tienen características específicas: altos volúmenes de consultas, esquemas relativamente simples, tolerancia a errores ocasionales, y recursos de ingeniería para validar resultados. Si eso no describe tu situación, los agentes de IA no son tu solución todavía — sin importar cuántas publicaciones de blog de proveedores sugieran lo contrario.
Cómo evaluar realmente la tecnología
Entonces, si "mejor práctica" no es una guía confiable, ¿qué lo es?
Aquí está el marco que uso ahora, tanto para mis propias decisiones arquitectónicas como cuando asesoro a clientes:
Comienza con tus restricciones reales. ¿Cuánta data? ¿Qué patrones de llegada? ¿Qué requisitos de latencia? ¿Qué tamaño de equipo y experiencia? ¿Qué presupuesto para operaciones? Las respuestas a estas preguntas eliminan el 90% de las arquitecturas "estándar de la industria" inmediatamente.
Optimiza para la depuración, no para la elegancia. La arquitectura que produce diagramas limpios es a menudo la que es más difícil de depurar a las 2 AM. Prefiere sistemas donde puedas rastrear un solo registro desde la fuente hasta el destino sin cruzar tres capas de abstracción diferentes.
Mide el costo operativo en atención del equipo, no solo en dólares de infraestructura. Un sistema distribuido que se ejecuta solo pero requiere que un ingeniero senior esté de guardia es más caro que un solo servidor que necesita reinicios ocasionales pero puede ser gestionado por un contratado junior.
Planifica para la migración que realmente harás, no la migración que deberías hacer. Cada equipo tiene sistemas heredados que nunca retirarán. Diseña para una coexistencia armoniosa con la tecnología antigua en lugar de un reemplazo revolucionario de la misma.
Cuando tengas dudas, comienza aburrido. Siempre puedes añadir complejidad. Eliminarla es mucho más difícil. Los equipos que veo teniendo éxito son aquellos que añaden tecnología con reticencia, con evidencia clara de que los enfoques más simples han sido agotados.
El contraargumento que no estoy haciendo
Quiero ser claro sobre lo que no estoy diciendo. No estoy argumentando a favor del conservadurismo técnico o en contra de probar cosas nuevas. Algunos problemas genuinamente requieren arquitecturas complejas, distribuidas y en tiempo real. Si estás procesando pagos a gran escala, necesitas semánticas de exactamente una vez. Si estás sirviendo características de ML con latencia sub-100ms, necesitas streaming. Si eres Netflix, necesitas lo que Netflix necesita.
Pero la mayoría de las empresas no son Netflix. La mayoría de los Data Pipelines no necesitan manejar 10,000 eventos por segundo. La mayoría de los equipos no tienen un grupo de ingeniería de plataforma para gestionar la carga operativa de la infraestructura de datos "moderna".
La incómoda verdad es que la industria ha confundido "lo que hacen las empresas tecnológicas exitosas" con "lo que deberías hacer". Las empresas tecnológicas exitosas tienen recursos de ingeniería interminables, alta tolerancia al dolor operativo, y modelos de negocio que requieren todo en tiempo real. Probablemente tu empresa no. Tu arquitectura no debería pretender lo contrario.
Dónde encaja layline.io (y dónde no)
Concluiré con algo que podría sorprenderte: layline.io no es la elección correcta para cada problema de Data Integration.
Si tienes algunos trabajos por lotes que se ejecutan de manera confiable en un horario, y tu equipo está cómodo con tu configuración actual, probablemente no nos necesites. En serio. La carga operativa de aprender una nueva plataforma no vale la pena si tu realidad actual es estable y entendida.
Donde añadimos valor es cuando has superado los enfoques simples pero quieres evitar el impuesto de complejidad de juntar múltiples herramientas especializadas. Cuando necesitas tanto batch como streaming en el mismo sistema. Cuando tu equipo está cansado de mantener capas separadas de orquestación, transformación y monitoreo. Cuando quieres consolidarte alrededor de un modelo en lugar de gestionar una costura de coordinación entre tres herramientas diferentes.
Incluso entonces, preferiría que comenzaras con una prueba de concepto que procese los datos de un solo día en lugar de un plan de migración ambicioso. Demuestra que el enfoque más simple funciona para tu carga de trabajo real antes de comprometerte con el complejo.
La mejor práctica es la que funciona para ti. Todo lo demás es solo marketing.
Si estás evaluando infraestructura de datos y quieres una evaluación honesta de qué complejidad realmente vale la pena añadir para tu situación específica, ponte en contacto. Te diremos si nos necesitas o si deberías mantener tus trabajos cron.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresariales que maneja tanto cargas de trabajo por lotes como en tiempo real a escala.
