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.
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)
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”:
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: