When Would You Use Azure Automation Instead of Orchestrator?

In a previous post, I described how to configure Azure Automation to bridge in to your on-premises environment by using Hybrid Runbook Workers (“HRWs”). Being able to run automation runbooks against on-premises systems starts to encroach on the turf that has traditionally been held by System Center Orchestrator. But when would you consider using one versus the other? I’ll explain when leveraging Azure Automation can make sense, even if Microsoft’s own Orchestrator vs. Azure Automation comparison chart doesn’t list the capability for Azure Automation to use HRWs to touch on-premises systems.

The first area I like to focus when comparing solutions are the differences in available functionality. Right now, Orchestrator is probably the easier tool to work with, due to the large amount of integration packs and the library of runbooks out there for easy re-use. Meanwhile, Azure Automation is just beginning to come in to its own, in terms of the active user base and the amount of reusable content available. The library of runbooks available for Azure Automation is growing quickly, and it relies heavily on the use of PowerShell workflows to get things done.  It’s not quite as “modular” as Orchestrator can be for common automation tasks, especially if you’re in a primarily Microsoft environment. There is a conversion tool, however, that will convert some integration packs (namely, those created with the Orchestrator Integration Toolkit) in to integration modules that can be leveraged by Azure Automation, and this might be very helpful to anyone who has put significant effort in to developing content for Orchestrator. I think the key thing to keep in mind regarding functionality is this: Azure Automation is the new product on the scene, and it will likely grow to fill in those functionality gaps. Even Microsoft’s documentation reflects it’s “under active development” status.

If functionality does not rule out one product or the other, the next major consideration is cost. The only way to get access to Orchestrator currently is by purchasing the System Center Standard or Datacenter MLs for servers, or the Client Management Suite Client ML or Enterprise CAL for desktops. For the purposes of this post, I’ll focus largely on servers, since very few people are purchasing Orchestrator licenses for their client systems. And because most organizations are trending towards more and more virtualized environments, I’ll consider a heavily virtualized scenario where the environment is covered by the Datacenter ML:

  • Each VM costs $250/year to license (assumes 12 VMs/host and $3,000/year for the Datacenter ML)
  • Our sample organization leverages 4 of the 8 System Center products the Datacenter ML covers, and if we assign cost equally and assume Orchestrator is one of those 4, that’s $62/VM/year for Orchestrator.
  • Azure Automation minutes cost $.002 each – so for the $62 it costs to license each VM for Orchestrator, you could buy about 31,000 Azure Automation minutes per year, or about 43 hours per month of automation time per VM.

At least from a naive perspective, that makes the question of “which is more cost effective” pretty cut and dry.  If you’re going to use more than ~43 hours of automation time (on average) per VM per month, then it’s cheaper to go with Orchestrator via the Datacenter ML than it is to meet those automation needs with per-minute Azure Automation costs. And you can slide the numbers around, depending on what value you put on the Orchestrator licensing – in an extreme case, Orchestrator might be the only piece of the System Center Suite you’re interested in, which means you need to use even more Azure Automation time per VM before the on-premises Orchestrator licensing represents a savings. In either case, before you can assess which model is best, you have to look at how you use (or plan to use) your automation environment.

The worst use case for a “pay by the minute” model are automation needs where the runbooks “spin” – meaning they are always running and always watching for new things to do or changes in something’s status, but probably are sitting idle the majority of the time. A common example of runbooks that spin are those that check for new Service Manager incidents or for new computer and user accounts in the “default” containers rather than the proper OUs and performs a task when those things are found. Could those runbooks be “fixed” so they’re not running all the time? Look at the need to get updated information or the results of the automation and find out if you can schedule it to occur at intervals rather than real-time. The runbooks you use most in your environment will determine which pricing model is least expensive.

Aside from potentially lower cost, there are a few other less quantifiable advantages to the Azure Automation environment:

  • Reduced footprint to manage: Hybrid Runbook Workers have less software to maintain and lower hardware requirements than a full Orchestrator environment. There are no on-premises database requirements like with Orchestrator.
  • Coverage flexibility: You can use automation minutes whenever you want, against whichever machine you want, all without worrying about having coverage by the ML – across both servers and workstations. No need to lock in to perpetual licensing or limited coverage via an Enterprise Agreement licensing model.
  • Webhooks: Azure Automation runbooks can be kicked off from an HTTP call – meaning not just from a webpage, but from anything that can make an HTTP call, including PowerShell. This gives users easy ways to invoke runbooks to automate common tasks. There are ways to do this in Orchestrator, but they require integration with Service Manager (not exactly a lightweight install in and of itself) or a 3rd party or self authored console.

All of that said, there’s nothing keeping you from having the best of both worlds. You don’t have to throw away your on-premises Orchestrator environment to be able to use Azure Automation, and thanks to the webhooks, you can even use an Orchestrator runbook to call out to an Azure Automation runbook. There are definite opportunities to use Azure Automation to reach out to parts of your environment that aren’t covered by full Orchestrator licensing, and do to so on a cost effective per-minute basis, and only as often as you need. Which tool (or tools) will work best in your environment?

1 Comment

  • Dan Sukoneck September 10, 2015 12:30 pm

    Andrew, great job on this. This is a very straightforward and digestible comparison – bookmarked for reference!

Your email address will not be published. Required fields are marked *

Phone: 312-602-4000
Email: marketing@westmonroepartners.com
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons