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.
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?
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:
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:
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:
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.