La primera vez que me pidieron conectar Azure Data Factory con un SQL Server on-premises detrás de un firewall corporativo, entendí de golpe por qué existe el Integration Runtime. No es un detalle menor de configuración: es la infraestructura de cómputo que hace posible (o imposible) que un pipeline llegue hasta tus datos, estén donde estén.
Qué es un Integration Runtime
El Integration Runtime (IR) es el motor de cómputo que Azure Data Factory usa para proporcionar las capacidades de integración de datos: mover datos entre almacenes, ejecutar Data Flows, o despachar y monitorizar actividades de transformación contra otros servicios de cómputo. Cada activity de un pipeline necesita, en algún momento, apoyarse en un IR para ejecutarse de verdad; el pipeline define el «qué» y el IR resuelve el «dónde y con qué recursos».
Existen tres tipos, pensados para tres escenarios de red distintos.
Totalmente gestionado y serverless, sin infraestructura que aprovisionar. Mueve datos entre almacenes en la nube, ejecuta Data Flows y despacha actividades de transformación contra servicios con endpoint público (Databricks, HDInsight, Azure Functions). Escala de forma elástica según Data Integration Units (DIU) y se paga por uso.
Se instala en una máquina Windows on-premises o en una VM dentro de una red privada, y solo abre conexiones salientes hacia internet. Es la pieza necesaria para copiar datos entre la nube y almacenes que viven detrás de un firewall corporativo, o para usar drivers propios con orígenes como SAP HANA. Requiere tener un Java Runtime Environment instalado y admite alta disponibilidad asociando varias máquinas a la misma instancia lógica.
Un clúster de VMs totalmente gestionado pensado para ejecutar de forma nativa paquetes SSIS (SQL Server Integration Services), es decir, para migrar («lift and shift») cargas ETL existentes a Azure sin reescribirlas. Necesita una base de datos SSISDB en Azure SQL Database o SQL Managed Instance, y permite escalar tanto el tamaño del nodo como el número de nodos.
Cuándo usar cada uno
La elección casi siempre viene marcada por dónde vive el dato. Si origen y destino están en la nube y son accesibles públicamente, el Azure IR gestionado por Microsoft es suficiente y no exige mantenimiento. Si alguno de los dos extremos está on-premises o en una red privada sin salida directa a internet (por ejemplo, una base de datos de un ERP interno de una empresa), necesitas un Self-Hosted IR instalado dentro de esa red. Y si lo que tienes es un catálogo de paquetes SSIS heredados que no quieres reescribir desde cero, el Azure-SSIS IR te permite ejecutarlos tal cual en Azure.
Un matiz importante para copias entre dos almacenes privados: si tanto el origen como el destino están detrás de un firewall, ambos extremos deben usar la misma instancia de Self-Hosted IR, porque es la única pieza con visibilidad de red hacia los dos lados.
Consideraciones de red
El Self-Hosted IR es el único de los tres que exige instalar y mantener algo tú mismo: un nodo (o varios, en alta disponibilidad) dentro de la red donde vive el dato. Ese nodo solo necesita salida HTTP hacia internet, nunca puertos de entrada abiertos, lo que facilita bastante la conversación con el equipo de seguridad. El Azure IR, en cambio, puede reforzarse con una red virtual gestionada y Private Link cuando no quieres exponer el tráfico a internet público. El Azure-SSIS IR puede desplegarse dentro de una red virtual conectada a on-premises, y conviene ubicarlo en la misma región que su base SSISDB para minimizar latencia y coste de tráfico entre regiones.
| Tipo | Dónde se ejecuta | Acceso on-premises |
|---|---|---|
| Azure IR | Gestionado por Microsoft, serverless | No |
| Self-Hosted IR | Máquina Windows instalada por ti | Sí |
| Azure-SSIS IR | Clúster de VMs gestionado | Sí, vía VNet |
- No sobredimensiones: si todo tu dato ya está en la nube, no necesitas instalar ningún Self-Hosted IR.
- El nodo Self-Hosted solo abre tráfico saliente; no hace falta abrir puertos de entrada en el firewall.
- Configura alta disponibilidad en el Self-Hosted IR asociando al menos dos máquinas a la misma instancia lógica.
- Ubica el Azure-SSIS IR en la misma región que su base SSISDB para reducir latencia y coste.
- En entornos con CI/CD, mantén el mismo nombre y tipo de Integration Runtime en todas las etapas de despliegue.
El Integration Runtime resuelve el «dónde se ejecuta», pero ¿qué hay del resto del pipeline: activities, triggers y orquestación completa?
Leer el artículo sobre pipelines, activities y triggers en Azure Data Factory