Dos formas de armar un stack de datos
Cuando armás la arquitectura de un proyecto de datos, tenés dos caminos posibles.
El primero es elegir herramientas de propósito específico para cada función: una para extracción, otra para carga, otra para transformación, otra para orquestación. Cada pieza hace una cosa bien y se conecta con las demás a través de interfaces claras.
El segundo es usar una plataforma que te ofrece todo integrado: extracción, transformación, orquestación, catálogo, gobierno, todo en un mismo lugar.
Ninguno de los dos caminos es inherentemente mejor. Pero tienen implicancias distintas para el día que necesites cambiar algo.
El argumento del desacoplamiento
La idea detrás del stack modular es simple: si cada herramienta tiene un propósito específico, el día de mañana podés cambiar una sin tocar las demás.
Querés cambiar tu herramienta de extracción porque apareció algo mejor o porque la que usás dejó de mantenerse. Si tu extracción está desacoplada de tu transformación, podés hacer ese cambio sin rehacer todo el pipeline.
Lo mismo aplica para el motor de transformación, el orquestador, o cualquier otra pieza. Cada componente es reemplazable porque no está atado a los demás más allá de los datos que produce y consume.
Eso te da flexibilidad a largo plazo. No quedás casado con una decisión que tomaste hace tres años cuando el contexto era otro.
El argumento de la integración
Las plataformas integradas tienen su propio argumento: la conveniencia.
Cuando todo vive en el mismo lugar, no tenés que preocuparte por cómo conectar las piezas. El vendor ya resolvió eso. La extracción habla con la transformación, la transformación habla con el catálogo, el catálogo habla con el gobierno. Todo funciona junto porque fue diseñado para funcionar junto.
Eso reduce fricción operativa, especialmente en equipos chicos o en organizaciones donde la capacidad de ingeniería es limitada. No necesitás un equipo de plataforma dedicado a mantener la integración entre herramientas.
El costo es el acoplamiento. Si mañana querés cambiar una pieza, probablemente tengas que cambiar varias. O quedarte con lo que el vendor te ofrece, aunque no sea exactamente lo que necesitás.
Herramientas de ingesta como ejemplo
La ingesta es un buen ejemplo de cómo se manifiesta esta tensión.
Hay herramientas como dlt (data load tool) que se enfocan en resolver un problema específico: conectarte a un origen, extraer datos, y cargarlos en un destino. La herramienta te resuelve los conectores y el manejo de esquemas. Vos te ocupás de la lógica del medio.
La ventaja es que concentrás el problema de "cómo me conecto y cómo vuelco" en una sola pieza. Si mañana aparece algo mejor, podés cambiar esa pieza sin tocar el resto del pipeline.
La contra es que dependés de conectores mantenidos por terceros. Si el conector que necesitás no existe o está abandonado, tenés que escribirlo vos o buscar otra solución. En proyectos open source, eso se mitiga porque en el peor de los casos podés hacer un fork y mantenerlo vos. Pero no es trivial.
Herramientas visuales vs código versionado
Otra dimensión de esta tensión es la interfaz: visual vs código.
Las herramientas visuales aceleran la configuración inicial. Conectar un origen a un destino con clicks es más rápido que escribir código. Para conexiones puntuales o exploratorias, eso tiene valor.
Pero las herramientas visuales suelen sacrificar propiedades que en código son naturales. La más obvia es el versionado. Si tu extracción está definida en código, podés versionarla en Git, hacer code review, ver el historial de cambios, hacer rollback si algo sale mal.
Si tu extracción está definida en una UI, esas propiedades no vienen gratis. Algunas herramientas las ofrecen, pero no es lo mismo que tenerlas como parte natural del flujo de trabajo.
No es que código sea bueno y visual sea malo. Es qué atributos de ingeniería priorizás. Si el versionado y la auditabilidad son importantes para tu contexto, el código te los da de forma más natural.
Cómo evaluar la decisión
La pregunta no es "qué es mejor" sino "qué necesito".
Si tu equipo es chico, tu volumen es moderado, y valorás la conveniencia de tener todo integrado, una plataforma puede tener sentido. El costo del acoplamiento se compensa con la reducción de fricción operativa.
Si tu contexto es más complejo, si anticipás que vas a necesitar cambiar piezas, o si tenés capacidad de ingeniería para mantener la integración entre herramientas, el stack modular te da más flexibilidad.
También importa el horizonte temporal. Las decisiones de arquitectura que tomás hoy las vas a cargar por años. Si elegís una plataforma integrada, estás apostando a que ese vendor va a seguir siendo la mejor opción para vos durante ese tiempo. Si elegís un stack modular, estás apostando a que vas a tener la capacidad de mantener la integración.
En resumen
Un stack de herramientas de propósito específico te permite reemplazar piezas sin rehacer todo. Cada componente hace una cosa bien y se conecta con los demás a través de los datos que produce y consume.
Las plataformas integradas ofrecen conveniencia a cambio de acoplamiento. Todo funciona junto porque fue diseñado para funcionar junto, pero cambiar una pieza puede implicar cambiar varias.
La decisión depende de tu contexto: tamaño del equipo, complejidad del proyecto, horizonte temporal, y qué atributos de ingeniería priorizás. No hay respuesta universal, pero sí hay consecuencias distintas para cada camino.