Types of Integration Runtimes in ADF

Azure Data Factory Leave a comment

Integration Runtime is the compute infrastructure for your ADF where pipelines/activities runs or gets dispatched from. This tells, what kind of hardware/machine is going to run your ADF workload, where the machine is physically located, whether it can access the data sources within cloud only or can reach out to your on-prem sources too and who owns/manages the machine for upgrades, patching or required data components. This is how it looks like in ADF:

There are three types of Integration Runtimes:

  1. Azure Integration Runtime
  2. Azure-SSIS Integration Runtime and
  3. Self-hosted Integration Runtime

Azure Integration Runtime:

  1. This is the compute infrastructure which is completely managed by Azure
  2. Microsoft takes care of any installation, maintenance, patching or scaling. You just pay for the time you use it
  3. This can access data stores located within cloud only
  4. Each ADF will have at least one Azure integration runtime and its region is set to auto-resolve as you can see in the snapshot at the top of this post, which means, Microsoft decides which region, this machine needs to be provisioned
  5. If you have a compliance requirement and want that your data is not moved from one region to another then you can create another Azure Integration Runtime in your region

Self-Hosted Integration Runtime

  1. If you want to manage the machine on your own for all installations, upgrades, patching and maintenance OR if you have a need to connect to on-premise side of data sources then this is the integration runtime you need to look for
  2. This is kind of gateway in the way that it allows you to connect to private networks

Azure-SSIS Integration Runtime

  1. This is a specialized integration runtime that you need to provision if you want to host SSIS packages on Azure. If you are not going to deal with SSIS packages then you don’t need this
  2. Behind the scenes, it provisions a cluster of managed VMs which have SSIS engine installed on them
  3. However, for SSIS packages too, you can go with self-hosted integration runtime but you will have to install the SSIS engine on your own which comes with SQL licensing. Additionally, you will have to manage the machine an other maintenance too. So, must be considered only when Azure-SSIS integration doesn’t fit your needs

While setting up IR, you see a screen like:

For a moment, if you gets surprised or worried that it is showing only two options then look at it carefully, the first option covers both Azure and Self-Hosted integration runtimes :). We will cover it in separate posts on how to setup each integration runtime exactly. I just wanted to highlight the first screen of setup wizard as it shows two IRs clubbed into a single option.

Conclusion

If you need to deal with data stores and services within Azure and don’t need to host SSIS packages then azure integration runtime serves your purpose. If you need to host SSIS packages then azure-ssis integration runtime is what you need to go with. If you need more control on the hardware and need to deal with on-premise sources then self-hosted integration comes to your rescue.

Leave a Reply