With the recent announcement that Azure Functions now has preview support for PowerShell, I will share some of my thoughts on automation of Azure operation tasks and compare using traditional runbooks with the Azure Functions using PowerShell. I have been kicking the tires since the preview was announced, and wanted to share some thoughts with this article. This article is not intended to be an Azure Automation overview. If you are not yet familiar with the services please see the overview pages on Microsoft’s site:
They key concepts that you need to understand for this article are:
- Azure Automation can be used to Build/Deploy/Configure resources, monitor changes, and automate governance activities
- Automation tasks can be scheduled, run manually, or triggered from an event or alert
- Automation accounts support Runbooks which are scripts that accomplish an automation task
My Use of Azure Automation
Much of my recent work with automation has been focused on a few areas:
- Deployment automation: Automated deployment of resources
- Responding to alerts: Budget alerts, system alerts
- Dev/Test Automation: Start and stop scripts, scale scripts, etc
- Governance Automation: Automatically applying or updating tags, locks, policies, etc
Like many, I started by developing a loose collection of PowerShell scripts and then took the step towards defining Runbooks in PowerShell. I mention this because despite my experience as a full stack dev with deep dotnet experience, PowerShell has been my primary language for the management of Azure and for my automation needs.
Runbooks can be run manually, scheduled, or called from an Action Group when an alert is triggered. The action groups include the capability to call an Azure Function, but prior to the recent update, the Function Apps did not support PowerShell. As I previously mentioned, PowerShell is my chosen language for these activities and I have a deep library of scripts that have already been written and tested.
Current Thoughts on Runbooks
The runbooks support storing, editing, and testing the scripts in the portal. The testing harness is good and it is fairly easy to make iterative changes as you build out your runbook. The included examples, provide a good overview of the general code flow, support for input parameters, and passing back the results or raising exceptions.
Please note, since these scripts are run unattended you can expect to put more time and effort into writing the logic and error handling to report appropriate results than you do for the scripts you run interactively in the console. Likewise, you need to sufficiently test the scripts to ensure that they are truly successful and that errors are not being suppressed.
My two main complaints about using the runbooks are:
- Defaults to the AzureRM module for all Azure commands. You can change it to support the Az module, but you cannot mix the use of both modules and it may cause conflicts with legacy scripts. For more details see: Az module support in Azure Automation
- Cannot author or test the scripts locally in a full IDE like Microsoft Code.
This still presents a great way to leverage legacy scripts and there are plenty of runbook examples available.
Current Thoughts on Azure Functions with PowerShell
I started working with Function Apps about three years ago and quickly found ways to leverage them within custom applications as well as to support application operational maintenance. The many virtues of serverless computing are beyond the scope of this article, but I am pretty excited about leveraging Function Apps to support my automation needs.
Some of the things I like about using Azure Functions (with PowerShell) to support automation:
- Defaults to Az module. You can change it to the AzureRM module if needed, but Az is the module being maintained and will continue to be developed and extended.
- Full, native support local development and testing with a full IDE such as Microsoft Code.
- Functions can be leverage both within automation scripts and other systems including MS Flow and Logic Apps.
While the experience of building Function Apps may be best suited for API developers, the tools are approachable enough for the modern administrator as well. When developing the PowerShell scripts within the Function Apps, I think the biggest adjustment will be thinking in terms of a web request and ensuring that you are passing back appropriate request status and message information. Again, not difficult, and there are many great examples, but it is an adjustment to the classic scripting patterns.
It is important to remember that the current support for PowerShell is officially in preview so the features and capabilities may evolve and things may break without notice. I would not recommend putting anything mission critical functions in there, but now would be a good time to start testing some scenarios that make sense for your environment.
I really like what I see so far. My plans are to continue to leverage my existing Runbooks where they exist. As I have a need for new automation, I will be looking first to move those into Function Apps especially for deployment related tasks.