Triggering Actions with Webhooks in Azure

In this post, I will explain what a webhook is, in the context of Azure, and how we can use webhooks to trigger tasks inside of Azure from other Azure systems or even systems outside of Azure.
 

 

Background

I have heard the phrase “webhook” before but it sounded like one of those things that was just for developers. It did not seem relevant to what I was spending time on, so I ignored it. A few months ago, I was meeting a customer to have a chat about their Azure business and to give them an update on some new things. I brought up the subject of Azure Automation and how it might be useful for some of their customers. We can use Automation runbooks to schedule the shutdown and start-up of Auzre virtual machines. Therefore, this can reduce the per-minute-of-runtime charges. This particular customer did not really need an update because they stay on top of things. Their CTO responded with, “We already do that. Look, I can even start the runbooks using my phone.” That is when my facial expression changed to, “Whatchoo’ talkin’ ‘bout Willis?”
Since then, I have had other encounters with customers, where similar kinds of solutions might be useful. Recently, one customer requested a simple way for end users to start and stop the virtual machines that host a rarely used line of business application. Immediately, I thought of that solution, which was based on webhooks. So what are webhooks?

Azure Webhooks

Wikipedia describes a webhook as:

… a method of augmenting or altering the behavior of a web page, or web application, with custom callbacks

In the world of Azure, a webhook is a trigger. There are several systems in Azure that can be triggered, including:

• Runbooks in Azure Automation
• Webjobs in Web Apps or Service Fabric that allow a website to have a background task
• Functions, another Service Fabric feature but is a server-less method of running a task or small workflow

 
You are probably an IT pro, so let’s stick with the scenario that you will be most familiar with, runbooks in Azure Automation. Automation allows us to create a runbook, which will perform some task, such as powering up one or more virtual machines. That runbook can be triggered or started in many ways, including:

• A once-off or recurring schedule
• On demand
• By some other Azure system such as an Azure metric exceeding an alert threshold or an Azure Recovery Services recovery plan

An additional trigger method is a webhook. We can create a webhook in the Azure Portal or a runbook. This webhook generates a URI, a uniform resource identifier that looks like a URL. We can use this URI in any external system to start the runbook via a HTTP POST action. For example:

• A developer writes an application that is running in Azure or anywhere with Internet access and when something happens, the URI is posted. Azure Automation will respond by executing the associated runbook.
• We can create a Button with a HTTP POST action in Office 365 Flow.

Ah! That last option is interesting. In the Office 365 Portal, I can open the Flow service, create a button, and associate that button with a webhook for an Automation runbook that will start a set of virtual machines. I can then share that button with my colleagues. If one of my colleagues opens the Microsoft Flow app on their phone, a new button will appear. All they have to do now to start those virtual machines is to press the button. Hey presto, a minute or two later, Azure Automation has provisioned capacity (probably a Hyper-V container) to execute the runbook. This will start the virtual machines all without the user needing to sign into the Azure Portal.