Azure Functions – Time Trigger (CRON) Cheat Sheet

This is a cheat sheet for CRON expressions that are used in the time triggers for Azure functions. They define how often a trigger/the Azure function should be executed (daily, hourly, every 3 months, …).

The basic format of the CRON expressions in Azure is:
{second} {minute} {hour} {day} {month} {day of the week}
e.g. 0 * * * * * (=every minute)

The following values are allowed for the different placeholders:

Value Allowed Values Description
{second} 0-59; * {second} when the trigger will be fired
{minute} 0-59; * {minute} when the trigger will be fired
{hour} 1-23; * {hour} when the trigger will be fired
{day} 1-31; * {day} when the trigger will be fired
{month} 1-12; * {month} when the trigger will be fired
{day of the week} 0-6; MON-SUN; * {day of the week} when the trigger will be fired

e.g. 3 5 * * * * defines a trigger that runs every time when the clock is at second 3 and minute 5 (e.g. at 09:05:03, 10:05:03, 11:05:03, …).

The trigger executes at UTC timezone. So for Vienna (UTC+1), a trigger at 18:00 (UTC) executes at 19:00 Vienna time (UTC+1).

Read more

Use the Azure Billing API and calculate the costs

The last days, I created a .net library that allows to read data from the Azure Billing REST APIs. You can use it to read data from the usage API, the ratecard API and it also gives you the combination of the data and does a cost calculation. The library is available as NuGet package (https://www.nuget.org/packages/CodeHollow.AzureBillingApi/) and the code is published on GitHub: https://github.com/codehollow/AzureBillingApi.
But before I jump into a short description of the library, I want to write a bit about the Azure Billing APIs:

Introduction

The Azure billing API allows to get data of your usage and the money that you have to pay for your resources. There are currently two types of the billing API:

The billing API for EA customers already returns the costs – so it’s much simpler. The REST (generic) billing API returns more data. It returns the usage of the resources and the costs per unit per resources – but it does not return the effective costs. If you want to get the costs, then you have to get the usage data and combine it with the ratecard data (the costs per unit per resource). I already blogged about each of those two APIs, but not about how to connect the data of both of them:

Read more

Creating NuGet packages for C# libraries

A few weeks ago I published my first C# NuGet package. The package is a RSS and ATOM FeedReader library that I developed, because existing libraries had issues with encodings, different languages or others. In this blog post, I will quickly describe how to create a NuGet package for a C# library.

The first thing to do is to install nuget.exe. This can be done by downloading the nuget.exe from nuget.org or by using chocolatey. I already blogged about how to use chocolatey (Chocolatey – Package management for Windows) and we will reuse that for the nuget install.

Read more

Chocolatey – Package management for Windows

I already blogged about the package management module of the Powershell and how great and awesome it is (Powershell package management – NuGet, Chocolatey and Co). It just can happen, that the installation of some modules from chocolatey do not work as expected. I had this e.g. for Firefox or Chrome. In such cases, it’s better to directly use chocolatey (choco.exe).

Fastest way to install and run it is to open Powershell as administrator and execute the following script:

Set-ExecutionPolicy Unrestricted
iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex

This installs chocolatey and adds it to the path. After that, you should be able to run chocolatey:

choco install firefox -x86
choco install notepadplusplus -x86 # 64 bit version does not have all plugins

Read more

Export Azure Usage data to CSV with C# and Billing API

The first important thing to mention is, that there are two types of the Azure billing API. One is the billing API for EA (enterprise agreement) customers. This API is easier to use, because it returns the costs in a separate field (extendedCosts). If you have an enterprise agreement, I recommend to check the following blog post: http://www.redbaronofazure.com/?p=631.

The other one is the billing API for non EA users (see Azure Billing REST API Reference. This API has two services, the RateCard API which returns costs for your resources (e.g. S1 DocumentDB costs per hour in region West Europe). I already blogged about how to export the RateCard data to CSV. In this post, I’ll focus on the second one which returns the usage data. This service returns the usage of your resources – e.g. “Standard IO – File Write Operation Units (in 10,000s), quantity: 3.182, …”. Unfortunately, the usage API does not return the costs per resource. If you want to know the costs, then you need to combine the RateCard data with the Usage data.

Update February 7, 2017: I built a .net library and published it as NuGet package which you can use to get data from the usage api and the ratecard api. The library also combines the usage and ratecard data and calculates the costs. The code is published on GitHub and I blogged about the usage and the configuration of it:

This blog post is still valid, it shows the how to configure and build an application that uses the Azure Billing Usage REST API.

Read more

Export Azure RateCard data to CSV with C# and Billing API

The Azure Billing API allows to programmatically read Azure costs. On the one hand, there are is the usage of your resources (how much [unit] you already used for [resource]), on the other hand there are the basic costs for resources – so e.g. the costs for a storage account or a specific virtual machine in a specific region. Each of these two use cases has its own API: the RateCard API which returns the potential costs of the resources (“basic costs”) and the Resource Usage API which returns the usage of your resource of a subscription.

In this blog post, I’ll focus on the RateCard API. There is a sample available on GitHub, but when I used it, I ran into some issues. So I decided to developed a simple C# console application and blog about my experiences. The application reads data from the RateCard API and creates a CSV file out of it. The CSV file can be opened in Excel and should already help to do some calculations.

The application/this post is mostly inspired by: https://github.com/Azure-Samples/billing-dotnet-ratecard-api.

Update February 7, 2017: I built a .net library and published it as NuGet package which you can use to get data from the usage api and the ratecard api. The library also combines the usage and ratecard data and calculates the costs. The code is published on GitHub and I blogged about the usage and the configuration of it:

This blog post is still valid, it shows the how to configure and build an application that uses the Azure Billing RateCard REST API.

Read more

Connect Azure App Service to virtual network

Let’s assume you have to read data from your on-premise network e.g. from a SAP, ERP or other system. It could also be that you want to have access to your virtual machines in your virtual network.
How to connect to your on-premise environment? Simple answer is: via VPN or ExpressRoute! But that’s just a part of the job, you also have to connect the App service to your virtual network at first. If the web app is in the virtual network, you have access to all resources in the network – virtual machines for example. If the virtual network is connected to your on-premise network, you can also access those resources. This blog post is about how to connect the app service to your virtual network and how to design the network. The VPN connection is not part of this blog post.

Overview

The connection between App Service, virtual network and on-premise network needs the following resources:

  • App Service + Web App/API App/Logic App/Function/…
  • Virtual network
  • Virtual network gateway
  • Point-to-Site VPN from Web App etc. to the virtual network gateway
  • Local network gateway
  • Site-to-Site VPN from Azure virtual network gateway to the local network gateway (VPN device)

Read more

Auto shutdown Azure virtual machines

I already blogged about how to Automatically shutdown virtual machines in Azure. The previous post is still useful if you want to shutdown a group (or all) of virtual machines at the same time. It uses the automation service to get the virtual machines and shuts them down. So you can control it at one place.

At November 22, 2016, Microsoft announced a new feature which makes it easy to configure the auto shutdown for a virtual machine: https://azure.microsoft.com/en-us/updates/set-auto-shutdown-within-a-couple-of-clicks-for-vms-using-azure-resource-manager/.

This new feature is available in the Azure portal. Just navigate to your virtual machine, scroll down to “Schedules” and select “Auto-shutdown”:

Read more

Working with Azure functions (part 2 – C#)

In my first blog post about Azure functions, I created an Azure function app and a function that uses Powershell to read data from RSS and writes it to Azure Table Storage. In this post, I’ll create a C# function that reads all upcoming events of my https://www.meetup.com groups and creates an iCal file out of it.
Unfortunately it’s not possible to do that at the meetup site. What you can do is, that you (manually) subscribe to each iCal calendar of each group that you have, but that results in a lot of calendars and if you join or leave a group, you also have to add/remove the calendar subscription.

Building the C# application

I’ll at first create a simple C# application in VisualStudio and move the code later on to the Azure function. The application itself is simple and does the following steps:

  1. Read data from the meetup API
  2. Transform the data to an event object
  3. Create an iCal file

To achieve that, I’ll at first add the NuGet packages “Ical.Net” and “Newtonsoft.Json” to my console application.

20161109_01_nugetpackages

Read more

Working with Azure functions (part 1 – Powershell)

Azure functions, also called Azure function apps, are a great way to build simple components – functions – and run them in the cloud (also called “serverless computing” or FaaS). Those functions are triggered via timer, http trigger, webhooks and many others. The functions itself can be implemented in one of the following languages: C#, F#, JavaScript/Node.js, PHP, Powershell, Python, Batch, Bash.

It’s important to mention, that functions have a timeout of 5 minutes – so if you have an endless running job, then you should go for webjobs. The idea behind Azure functions is, that you execute just a small piece of code. That’s why there is this timeout. Running those small pieces is very cheap. The first 1.000.000 executions and the first 400.000 GB/s of execution are for free. 400.000 GB/s means: Let’s assume you have a memory size for your function app of 512 MB: 400.000*1024 / 512 = 800.000 seconds are for free. So you can execute your function 1 Mio times with an average execution time of 1.25 seconds and it’s still free.

I will use the Azure functions to build two “applications”/functions. One of them will read data from my RSS feed and write it to my table storage. The second one will read all my upcoming events from https://www.meetup.com/ and create an iCal file out of it so that I can add it to my calendar.

Read more