El Costo Oculto de los Pipelines Basados en Scripts
¡Hola Devs! Todos hemos estado ahí: empiezas con un transform_pedidos.py bien limpio. Seis meses después tienes transform_pedidos_v2.py, transform_pedidos_fix.py, transform_pedidos_final_USA_ESTE.py. La lógica de transformación está duplicada en una docena de workflows, y cualquier cambio en una regla de negocio se convierte en una semana de refactor. 😵
Ese es exactamente el cuello de botella que resuelve la composición guiada por especificación. En lugar de enterrar la intención del workflow en código imperativo, declaras qué debe producir el pipeline en una especificación estructurada (JSON o YAML), y un composer arma el cómo a partir de capacidades reutilizables y versionadas.
Este patrón brilla en entornos regulados — salud, finanzas, ciencias de la vida — donde la gobernanza exige que usuarios de negocio escriban la intención sin tocar el código de ejecución, y donde las pistas de auditoría deben ser explícitas y versionadas.
El insight central: intención del workflow y lógica de procesamiento son cosas distintas. Mezclarlas es lo que te mata al escalar.
Si antes quieres entender cómo escalar cargas Python en cluster, checa nuestro tutorial práctico de Ray en AWS.
La Arquitectura en Tres Capas
La composición guiada por especificación organiza el workflow en tres capas:
- Capa de intención — Especificaciones definen el comportamiento de forma declarativa.
- Capa de composición — El composer valida specs y arma pipelines.
- Capa de procesamiento — Procesadores de capacidad ejecutan las transformaciones.
La Especificación
Una especificación es un documento JSON/YAML declarativo que describe datasets, mapeos y transformaciones. Sin lógica de procesamiento — solo intención.
{
"source": ["pedidos_crudos"],
"target": ["pedidos_limpios"],
"mappings": [
{
"source_field": "fecha_pedido",
"target_field": "fecha_pedido_iso",
"capability": "formatear_fecha@1.2.0"
},
{
"source_field": "monto",
"target_field": "monto_mxn",
"capability": "normalizar_moneda@2.0.1"
}
]
}
Fíjate en las versiones fijadas (@1.2.0). Eso es lo que garantiza reproducibilidad — nunca tomas silenciosamente un breaking change en una transformación.
El Composer
El composer es el cerebro. No transforma datos. Él:
- Valida la especificación contra un schema
- Consulta el registro de capacidades (vía Amazon OpenSearch Service) para resolver ARNs y metadatos
- Compila la spec en una definición ASL (Amazon States Language)
- Arranca una state machine de AWS Step Functions
# Lambda composer — esqueleto simplificado
import json, boto3
sfn = boto3.client("stepfunctions")
def lambda_handler(event, context):
spec = json.loads(event["spec_body"])
validar_schema(spec) # lanza excepción si es inválido
states = {}
for i, mapping in enumerate(spec["mappings"]):
cap = resolver_capacidad(mapping["capability"]) # lookup en OpenSearch
states[f"step_{i}"] = {
"Type": "Task",
"Resource": cap["arn"],
"Next": f"step_{i+1}" if i + 1 < len(spec["mappings"]) else "Fin"
}
states["Fin"] = {"Type": "Succeed"}
asl = {"StartAt": "step_0", "States": states}
sfn.create_state_machine(name=spec["id"], definition=json.dumps(asl),
roleArn="arn:aws:iam::123456789012:role/sfn-exec")
return {"status": "compuesto", "pasos": len(spec["mappings"])}
El Registro de Capacidades
Trata el registro como un artefacto gobernado, no como una tabla de lookup. Las definiciones viven en control de versiones. Tu pipeline CI/CD valida metadatos y corre tests antes de publicar.
El Pipeline de Capacidades
Ya armado, Step Functions invoca cada Lambda de capacidad en secuencia. Cada procesador recibe solo los campos que su mapeo referencia — una frontera natural de mínimo privilegio. Los traces van a CloudWatch Logs.
Dónde Este Patrón se Rompe (Y Dónde Brilla)
⚠️ Limitaciones Que Debes Aceptar
Es overkill para pipelines chicos. Si tienes menos de tres a cinco workflows, composer + registro + schema son puro overhead. Un script bien testeado le gana a una arquitectura distribuida siempre.
El registro se vuelve cuello de botella sin gobernanza. Sin validación en CI y version pinning, cambias scripts duplicados por un registro duplicado — misma enfermedad, síntoma distinto.
La complejidad del composer es real. Escribir validador de schema, resolvedor de capacidades y compilador ASL no es trivial. Presupuesta para ello.
🔐 Notas de Seguridad
- Usa SSE-KMS con clave gestionada por el cliente en los buckets de spec y datos.
- Fuerza HTTPS vía bucket policy (
aws:SecureTransport). - Activa node-to-node encryption en OpenSearch.
- Marca campos sensibles en la spec (
"sensitivity": "PHI") y deriva la sensibilidad del target a partir del source + comportamiento de la capacidad.
📊 Cómo Medir Éxito
Sigue tres métricas:
| Métrica | Antes | Meta |
|---|---|---|
| LOC duplicado en transformaciones | Alto | Cerca de cero |
| Tiempo de onboarding de dataset | Semanas | Días |
| Nuevos workflows sin tocar código | 0 | Creciendo |
Si esos números no se mueven, el patrón no se está pagando solo.
Cómo Empezar Esta Semana
No reescribas todo. Toma un pipeline existente que tenga tres o más variantes (reportes financieros mensuales de fuentes distintas son ideales). Luego:
- Descríbelo como una especificación en JSON.
- Implementa 3–5 capacidades reutilizables como Lambdas.
- Conecta uploads en S3 a una Lambda composer.
- Mide el tiempo de onboarding de la siguiente variante.
Si la segunda variante toma días en vez de semanas, validaste el patrón. 🎯
Próximos Pasos
- Wiring event-driven: la guía de arquitecturas event-driven de AWS Lambda muestra cómo conectar uploads S3 al composer.
- Orquestación: la guía de integración Step Functions + Lambda cubre la invocación de los procesadores.
- Observabilidad: publica métricas customizadas en CloudWatch para tasa de composición y latencia por paso.
Lectura Relacionada
- Alerta de Seguridad en React Server Components — CVE-2025-55184 — si tus pipelines sirven un frontend web, vale la pena checarlo.
La victoria real no es la arquitectura. Es que usuarios de dominio ahora escriben workflows en un lenguaje que entienden, y los ingenieros dejan de ser compiladores humanos entre intención de negocio y ejecución.
Fuente: AWS Architecture Blog — Specification-driven composition for flexible data workflows