On August 29th 8AM CET it’s time for Serverless Morning hosted by Azure User Group Norway.
Together with two experienced Microsoft MVPS, Jan-Egil Ring and Anders Eide we will try to cover as much as possible on Microsoft’s serverless offerings.
I’m really looking forward to speak in this user group. This event is for everyone who’s interested in automation technology. CEO, Marketing, Dev or Ops you’re all welcome
In part two we will integrate Azure Functions using Powershell triggered by Event Grid to complete the circle in our application infrastructure. If you havent read the previous parts in this blog series, i recommend you start with the introducution.
Azure’s serverless flagship probably don’t need any introduction at this stage, but in short. Azure Functions allows you to run code or scripts on demand triggered via various sources. Timer triggers, event, webhooks, http post, gets etc. The most common way to run your stuff is by consumption where your code run on spare compute in azure at a very low-cost. If you demand more power, you can also opt in for the app service plan.
Read more about functions and how to get started here.
FYI; the same type of service from AWS is called Lambda and Google offers similar with Cloud Functions
Powershell support in Azure Functions is still in preview, but I have used it many times, without issues. It is slower that all the other languages supported, but that doesent matter in this case. But be aware that azure functions Powershell run in v4. If you want to run C# or Java feel free to do so.
Let’s start by adding a new function app. Things to notice is that the name of your function app, is also the DNS name. App insights is on by default, and I have no idea why you would want to chose OS type. This wasn’t here before…
without wasting too much of your time reading a lot of fill text, lets just create a new function. Remember to enable ‘experimental language support’ this will magically allow Powershell support (among others). Chose the HTTP trigger Powershell.
I am naming my first function “incoming-pizza-order” which we will add the code to and connect to Event Grid.
After creation you will have a function that supports GET and POST request with your name as the input. A “hello world” type of example. Let’s see if we can trigger this from Event Grid. As we did in the previous post. Create a new Event Grid subscription.
Failure, right? Let’s take a look.
Azure event grid accepts all incoming events and will pass them on to any subscribers. To add a layer of security you will have to validate the subscription upon creation. So all subscribers, weather it’s your own incoming webhook solution on premises or in a another cloud, will have to sort of handshake before it creates the subscription. As you see, the error message in Azure isn’t very good, and I searched quite a long time before I reached out to Ling Toh via Twitter. Luckily she pointed me in the right direction.
Upon creation event grid sends a validation request to the subscriber, which looks something like this:
[{
"id": "2d1781af-3a4c-4d7c-bd0c-e34b19da4e66",
"topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"subject": "",
"data": {
"validationCode": "512d38b6-c7b8-40c8-89fe-f46f9e9622b6",
"validationUrl": "https://rp-eastus2.eventgrid.azure.net:553/eventsubscriptions/estest/validate?id=B2E34264-7D71-453A-B5FB-B62D0FDC85EE&t=2018-04-26T20:30:54.4538837Z&apiVersion=2018-05-01-preview&token=1BNqCxBBSSE9OnNSfZM4%2b5H9zDegKMY6uJ%2fO2DFRkwQ%3d"
},
"eventType": "Microsoft.EventGrid.SubscriptionValidationEvent",
"eventTime": "2018-01-25T22:12:19.4556811Z",
"metadataVersion": "1",
"dataVersion": "1"
}]
We will have to return a successful HTTP response (HTTP 200 OK) with the validation code under the property, “validationResponse”
{
"validationResponse": "512d38b6-c7b8-40c8-89fe-f46f9e9622b6"
}
All this is described in Microsofts documentation, but how do we do this in a Powershell function? Here’s my modified version of the “hello world/name” example. As you see it grabs the post requests and if it is a validation event from Event Grid it will return an http 200 and the validation response. Copy the entire script in to your function and re-create the subscription in event grid.
Hopefully the subscription registered successfully. Time to play!
Grab the code example from part 1 and fire off an event, in the matter of seconds your function will fire. You can confirm that it’s working by looking at the log and output.
How cool isn’t this? I love that we can use our Ops skills and create true serverless, modern application infrastructure.
In my next post, I will share a few more code examples with multiple Azure Functions, sending events through event grid, from the introduction you know that these are the steps:
PS: I would like to create a simple GUI at some point, what tools should I use? I’m thinking either Powershell Universal Dashboard by Adam Driscoll or PowerApps. If you have other suggestions, let me know.
This is part one of my blog series describing how you can create a serverless application infrastructure using PowerShell. The scope and history behind, covered in the introduction post. If you haven’t read that I recommend doing so.
In my serverless infrastructure design, I have chosen to use Azure Event Grid as a hub for the other components in play. The other components will write and subscribe to events/messages in Event Grid and perform their given task as ‘their’ event arrives. Event grid fit’s the concept perfectly as you act on state changes. You can publish as many events you like, but you don’t need to subscribe to every one. A lot of Azures PaaS offerings are already fully integrated which makes it easy to get started.
Other event based offerings in Azure are Service Bus and Event Hub. You can read a little on the differences here
I am sure you are able to create resources in Azure so here’s a quick one. Feel free to use what ever you want for deployment, but for the purpose of screenshots, I’m using the portal. Just remember that the name you chose will be the url of your endpoint as well.
After the custom topic is successfully deployed, you are given the option to subscribe to events. Before doing that we are taking a break. Besides a graph showing incoming events you have no good way to see your events as they arrive. This makes it way more difficult to debug why stuff isn’t working. While writing this post I researched for a good way to solve this and stumbled across this blog post by David Barkol. He created a web app that lets you view events as they arrive. You can deploy it directly from GitHub using ARM. Do this while your coffee is brewing. And come back here in 10 minutes 🙂
Welcome back… If you have deployed the web app you can follow and create a subscription subscribing to all events. In a production scenario, it’s likely to have scoped your subscribers, but in order for Event grid viewer to function i’ll subscribe to everything.
Once deployed your overview page will look something like this. Showing all subscriptions within your topic and their corresponding metrics. Now lets try to send a custom event using powershell.
Basically, event grid accepts post request to an API endpoint, which is the name of your topic plus a suffix and the API version. your full URI looks something like this; https://adatumblogdemo.northeurope-1.eventgrid.azure.net/api/events?api-version=2018-01-01
To authenticate we will pass an ‘aeg-sas-key’ within our request header. You will find the keys for authentication in the keys pane. Further event grid events has a schema you willl need to follow, meaning that all post requests will need to have some properties defined and your custom event data will be in a data property. The basics of it all looks like this
[
{
"topic": string,
"subject": string,
"id": string,
"eventType": string,
"eventTime": string,
"data":{
"custom": "data"
},
"dataVersion": string,
"metadataVersion": string
}
]
More details on the schema can be found on Msft Docs
If we combine everything we know this far, we can use the script below to post messages to event grid. Please add your own url and access key. Everything else should work.
Assuming no error messages, jump in to your event grid viewer to view the raw content like this;
A corresponding graph in the Azure portal could look something like this. Here you will see incoming events and how many matches your subscriptions in the same graph. You can also see individual metrics per subscription.
In this part of my blog series on how to create a serverless application infrastructure using PowerShell. We have walked through how to set up a custom Event Grid topic and how to post messages or event to it using standard PowerShell commandlets. We also deployed a custom web application capable of reading our incoming events in real time.
In the next part: For part two we are going to create an Azure Function running PowertShell that subscribes and send Event Grid messages. This is key to build up our infrastructure wich consists of multiple Azure Functions in order to work.
Welcome, fellow IT pro. You have found the blog series describing how you can create a serverless application infrastructure with Powershell.
If you consider your self being a ‘modern it pro’, you frequently solve complex tasks and automate your work using code. You know what Git is and have heard people talk about continuous integration. If you can relate, let’s label you a ‘modern it pro’.
When I develop solutions that challenge my knowledge, I often seek advice from our developers. (You know, those who are employed to ‘GIT commit’?) Usually they can share some light on the issue and point me in the right direction.
By developing our own solutions, we have a working proof-of-concept to handover to our developers when things grow too big or complex.
The challenge or scope for my POC was to streamline creation of Azure tenants for our customers. We required to create a tenant, assign subscriptions and do some configuration within Azure AD. Many of these steps was already solved with various scripts, but it is time to consolidate and automate the automation. We decided that we wanted to learn more around the integration and ‘serverless’ PAAS offerings available in Azure.
For the purpose of this blog series we are going to build a new application using the same techniques, in a smaller scale. To create our serverless application infrastructure, we make use of the following Azure offerings:
I bet you have worked a fair amount of overtime in your career, therefore eaten a lot of pizza as well. Let’s try to build a simple pizza order and delivery process using Event Grid as integration layer and multiple Azure Functions to process the order.
We will break the pizza order and delivery process in to the following steps:
Windows Admin Center (WAC) (formerly Project Honolulu) is the new, modern tool for managing servers, Hyper-V, clusters and even Windows 10 clients. Other than being fully HTML 5 driven it can integrate with third-party software via an Extension manager. All components within WAC is an extension, this means you can install, update, and delete individual components without re-installing the whole application.
As announced WAC SDK is now in public preview, meaning you and everyone else can build integrations with WAC. Luckily I have tested one integration already, and I have to say that the future looks promising.
I’ve been fortunate to be able to work closely with the team over at SquaredUp for many years now. At some point early 2018 they reached out and asked if I had looked in to Microsoft’s new server management tool, project Honolulu. SquaredUp told me they where working closely with the Windows Server team to make an integration with SCOM/SquaredUp and Honolulu.
Working for a large service provider in Norway we have many tools to provide management for our clients and a big priority is to integrate them to provide better visibility. I was immediately interested to integrate SCOM with Windows Admin Center. After installing the extension through extension manager you can access monitoring and historic performance data directly within server manager.
Top 3 for integrating SCOM and Windows Admin Center
Sign up for the integration with SquaredUp and Windows Admin Center and install the extension via Extension Manager.
This is another good reason to drop interactive logons and get Windows Admin Center and I expect more to come over the next couple of days. If rumors are true we have some cool extensions showcased in this Microsoft Build 2018 session.
PS:
One way integration is cool, but I don’t see any reason for not to integrate WAC in other applications. If you feel the same way, please add your vote over at UserVoice to make that happen