Why deploying Hybrid Runbook Workers on Azure makes sense

A “Hybrid Runbook Worker” is basically an extension the the MMA (Microsoft Management Agent), meant to execute Azure Automation Runbooks on premises. For a general introduction I’m referring to the following documentation:

https://docs.microsoft.com/en-us/azure/automation/automation-hybrid-runbook-worker

I really like the concept to have a single point of control for either Cloud- Hybrid- or on-premises automation. Additionally Azure Automation, as it’s a Cloud Service, it has more features, more frequent updates and enhancements that the on premises System Center Suite.

So while I was thinking about the Hybrid Worker scenarios and some requirements I have in ongoing projects, I though about deploying Azure VMs as Hybrid Runbook Workers instead of using the “shared” ones could be a solution for some of them.

But Wait... Deploying Azure VMs and use them as Azure Automation Hybrid Runbook Workers? Is he nuts?

So here’s why..

Fair share principle of Azure Workers

Runbook jobs running more than 3 hours, will be suspended/resumed or restarted from scratch, depending on  the type of the runbook. After 3 subsequent events like this they are kind of “discarded”.
See here for more information about “fair share” in Azure Automation.

Scalability

If you have thousands of jobs executed each day, performance of the shared workers in azure can become an issue, especially if you use a lot of nested Workflow based runbooks. Hybrid Workers are added to Hybrid Worker Groups and follow the same “static random” queuing mechanism, as SMA workers do. Scaling up your workers (memory / CPU / IOPs) is only possible with Hybrid Workers.

Outbound Network Connections / Special Binaries

You can’t install anything on a Azure Runbook Worker, neither can you connect from a runbook executed on a AA Worker to external networks or into a virtual machine running in one of your network security groups. Another reason are Modules, PowerShell SnapIns or even custom management consoles you might need to deploy for automation purposes. You can only import PowerShell Modules into your Azure Automation account which follow the requirements documented here.

When to use the default Cloud bases Workers?

If those three use cases do not apply for you, I’d recommend to use the Azure Workers for the following reasons:

• No additional cost for the workers running as Azure VMs
• Any imported custom modules are automatically distributed, which is not the case for Hybrid Workers at the time writing
• Less complexity