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:
- Read data from the meetup API
- Transform the data to an event object
- Create an iCal file
To achieve that, I’ll at first add the NuGet packages “Ical.Net” and “Newtonsoft.Json” to my console application.
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.
Azure table storage is a NoSql table and it’s great for storing tons of data, but it’s also good for just a few records. You can connect to the table storage with Excel, Access and – by sure – with PowerBI. It’s easy to programmatically write data to the table storage and with the Excel/PowerBI connection, it’s great to use it for data analysis or for dynamic Excel files.
Additionally, the Azure table storage is very cheap! 1 GB storage + 100.000 transactions = 0.06€ per month. That’s nearly nothing, because it is designed to work with tons of data. Troy Hunt used it with 154 million records – and it worked like a charm! https://www.troyhunt.com/working-with-154-million-records-on/.
There are many articles about how to protect an API in Azure API management. Most of them target the API in the API management itself. So for example I imported an API (see Introduction to API management part 1) and can now access them via: https://codehollowtestapi.azure-api.net/simpleapi. After the creation, I secured the API (in API management service) with Azure Active Directory Introduction to Azure API management (part 2). Everything’s fine, but what about the API that is running in the background? In my case the webservice URL of the backend service is: https://codehollowsimpleapi.azurewebsites.net/
This service was public available (and easily accessible via Swagger – you’re welcome ;)). Sure, you need to know the URL, but if you know it, then you can easily use it and spam my API. All my efforts in building up an API management were useless.
My first blog post about Azure API management service (Introduction to Azure API management (part 1)) contained the basics of API management. What it is about and how to configure it. In this post I want to describe how to configure basic Azure Active Directory authentication and have glimpse into policies.
This is the first blog post about Azure API management. In this post I will describe how to set it up and how to basically use it. In the second blog post I will focus on features like security, how to connect the Azure Active Directory or how the policies work.
API Management is a really cool service in Azure. It’s currently only accessible via the classic portal, which doesn’t mean that it is out of date. The API management allows you to give developers access to your APIs. In the B2B context, you can use it to implement things like security, analyzers and others. In the B2C world you can offer your customers access to your APIs and you can control who, how much etc. they will access your APIs.
I already wrote a blog post about Azure ServiceBus filters which contains the basics of ServiceBus filters and how to use them (Azure ServiceBus filters). It describes most of the filters, but it does not contain how to work with datetime filters. The reason for it is, that datetime filters need to be set programmatically via C#, Powershell or others. The very nice and useful tool ServiceBus explorer also doesn’t support datetime filters and therefore it’s not so easy to test them. So let’s at first see how a standard filter looks like:
A “standard” filter in servicebus looks like:
sys.label LIKE ‘%bus%’
A datetime filter must be set via C# and looks like:
var filter = new SqlFilter("datetime >= @datetime");
There is a new feature available in Azure. It’s currently in public preview and it was announced in the end of July (https://azure.microsoft.com/en-us/updates/public-preview-vnet-peering-for-azure-virtual-network/). It’s called VNet Peering and it allows you to connect two azure virtual networks in the same region. You can even connect a classic virtual network with a resource manager virtual network. The configuration of the peering is available in the new portal.
This is really awesome because it helps us to connect a resource manager virtual machine with the Azure active directory domain services. I already blogged about configuring the domain services (Configure Azure Active Directory Domain Services) and stated, that this works only with classic virtual networks. This could be an issue if we create all virtual machines in the resource manager mode. So let’s have a look on vnet peering and how to work with it:
There are already a few blog posts available about how to shutdown virtual machines in Azure. I listed some of them at the bottom of this post, but anyhow – I wanted to try it on my own and wrote a short documentation about it.
There are different ways how to automatically shutdown a virtual machine in Azure:
- Automation account (preferred way for existing VMs)
- DevTest-Labs (preferred for development and test environments)
- Install a script on your servers
Update December 1, 2016: there is a new feature available that allows to configure the auto shutdown directly as a virtual machine configuration – see: Auto shutdown Azure virtual machines. If you want to shutdown multiple virtual machines and/or control it from a central point – continue reading this article.
The Azure active directory domain services are currently in preview, but you can already use it to connect your virtual machines to it. One of the main limitations right now is, that it works only with the classic deployment model. You can only use a virtual network that is created in the classic mode and also the virtual machine that should be connected to the AD must part of this virtual network. As the network is in classic mode, the virtual machine also needs to be created in classic mode. But let’s start to find out, what the Azure active directory domain services are.