Azure Serverless Performance / Cost Monitoring – Retrieving CosmosDB Request Charges per Function


For me, one of the major advantages of cloud is that you become very aware of the costs involved. Where this might seem like an odd thing to say, this also forces you to think in terms of the costs and develop accordingly. Every session I have with customers, I’m focussed on keeping the costs as low as possible, given the requirements at hand.

Where Virtual Machines have their place, I -really- love the PaaS-services, and especially the entire “Serverless”space. A typical combination you see here, is Azure Functions & Azure CosmosDB. Both have a nice modular pricing model, where Azure Functions even go towards a subsecond billing model based on the actual CPU cycles. Though, how granular the pricing might be, if we look towards the resource costs… Then we see that is still linked to an “App Service” (being a consumption plan here) ;

The same goes for my Azure Cosmos DB Account (which hosts several collections)…

To go even a step further, I wanted to be able which functions (low level code) are the things I need to focus on in terms of costs. If we would succeed in this, then suddenly, refactoring would have a tangible ROI.


CosmosDB : Request Units / Charges

When you are using CosmosDB, your budget is determined by the amount of Request Units per Seconds your collection can process.

The throughput of this collection is sized at the minimum of 400 RU/s. Now let’s run a query on this collection ;

You’ll notice that with the results are accompanied by a statement that indicates the “Request Charge”. This is the amount of RUs that were needed to process the query. So the objective here is to try to keep this numbers as low as possible… In this case, as the collection is provisioned at 400RU/s and the query needs 45 RU/s. This would mean that this collection can process 8 concurrent requests per second of this query. So I immediately know the impact on my costs if the amount of requests increases.


CosmosDB : Monitoring RU/second

The first view towards the RU consumption is in the “Metrics”-view on the Azure Monitoring pane ;

Now this provides us with a view on collection level. Wouldn’t it be great if we could link consumption towards an individual function?


Monitoring Request Charges per Functions

As I’m using MongoDB in this case (Sidenote ; the same is possible when using for instance the DocumentDB api), I can use the “getLastRequestStatistics” command to retrieve the request charges of CosmosDB. Let’s take a look at the following sample (taken from this function) ;

    var findVms = function(db, callback) {
      var cursor =db.collection('vmchooserdb').find( { "type": "disk", "region": region } );
      cursor.each(function(err, doc) {
        assert.equal(err, null);
        if (doc != null) {
            if (index === 0) {
              db.command({getLastRequestStatistics:1}).then(result => {
                context.log.metric("RequestCharge", result.RequestCharge); 
              .catch(error => {
            output[index] = doc;
        } else {

What can you see here? Via the “db.Command…” I get the request charge and I send it to both “context.log.metric” (which is the Application Insights integration) and “context.log” (which is the “default logging”). Let’s take a look at the monitoring tab of our function. When I look at the logs of a certain invocation. Here we can see that the request charge was 11.1 ;

Now let’s take a look at Application Insights… Here we’ll go to the “Analytics” view ;

Here I can filter the “customMetrics” based on the name of the function (getVmSize/getDiskSize) and the “RequestCharge” indicator.


This provides me with the ability to monitor the evolution of the request charges of my function. And this is also the first part of gathering the data I need about my end-to-end cost of a single function.


Function Charges

The same logic as what we just saw with CosmosDB can be applied to function too… Due to that integration with Application Insights, we do not need to send any customMetrics, as they are gathered by default. Here we can see what the memory consumption was (in buckets of 128MB, conform the billing model ;

But also summarize the duration of a given function ;


Closing Thoughts

In today’s post, we discussed how we can monitor costs & performance on the granular level of an individual function. When you have this knowledge at your fingertips, then you can now make very informed decisions on refactoring. In addition, sizing in terms of scaling is also very easily extrapolated. You can calculate what impact an increase in load will have on your budget…

I hope you liked today’s post. For my this journey was very insightful! It has provided me with yet again another set of metrics that can guide me through well-informed decisions. 😉


FaaS & Serverless – Vendor lock-in or not? Consider the cost of the full application lifecycle


In my current role at Microsoft, I often talk about the possibilities in regards to application modernization. A typical ask in this space is to what kind of service they should use as a underlying platform for their own services. Where this commonly results in a (brief) discussion about VMs vs Containers vs Serverless/FaaS. Today’s post is about my personal take on the matter.


Setting the scene

First let’s start with setting the scene a bit… For today I’ll try to focus on the application modernization landscape, where the same goes for the data platform stack. Here you can pretty much interchange “Functions” with “Data Lake Analytics” and “Containers” with “HD Insights”. Though we’ll not go into that detail, in order to reduce the complexity of the post. 😉

When looking towards the spectum, the first thing to acknowledge is the difference in service models. Here we mainly have two service models in play ;

Continue reading “FaaS & Serverless – Vendor lock-in or not? Consider the cost of the full application lifecycle”

The anatomy of “vmchooser”… Adding some serverless into the architecture!


In an earlier blog post I discussed the decision criteria in selecting a VM. In that post I also showed a tool called “VMchooser“. Today’s post will be on the architecture I used to build this one. As you might have guessed, it’s built on Azure components. Let’s get to it and check the anatomy of this application.


High Level Architecture

VMchooser has the following high level architecture ;

  • Web App : The front-end of the application is hosted on an Azure Web App.
  • Azure Functions : The back-end API & batch parser are built with Azure Functions. Which unlocks insane scaling possibilities.
  • Storage Account : The storage account serves as decoupled/central storage component for the batch parsing. And it could also be used for hosting the “database” (flat file).
  • Application Insights : Application insights is used to have the needed insights into the usage & other metrics.
  • Github : All code for this project is open-source and publically hosted. You can run your own VMchooser if you want… 😉 Every change is immediately pushed towards the front-end, back-end & database.
  • API Management : As the back-end API is decoupled from the application, I’ve also linked this api with api management. This would provide me with the option to allow 3th party application integrations via an API subscription plan.


Continue reading “The anatomy of “vmchooser”… Adding some serverless into the architecture!”

Azure Functions : Increasing the time-out of your function…


When I was working on the “CSV import” of  VMchooser, I noticed that long jobs sometimes had issues. After some investigation, it quickly became apparent that I was hitting the time-out. So I had a need to increase it…


Logic Apps Time-out = 2 minutes

As a bit of back story, I first started off with my async parsing flow by using the combination of logic apps & functions. Where I at first thought it was due to the time-out on the functions side, it actually appeared to be on the logic apps side. And that one cannot be changed…


Azure Functions Time-out 

So I browsed the web, and encountered two variables, which I both set on my platform ;

To reach set these, click on your functions bar (“kvaesvmapi” here), then “Platform Features”, and then “Application Settings” ;

But let’s get back to the variables… From various posts I saw these two popping up. Where I set them both to be safe, I started investigating a bit. The first one ;

WEBJOBS_IDLE_TIMEOUT – Time in seconds after which we’ll abort a running triggered job’s process if it’s in idle, has no cpu time or output (Only for triggered jobs).

This is actually the one you need for your function. As it’s clearly described in the kudu docs. Where the second one apparently is only related to the deployment phase;  hence the “SCM_”-prefix.



Set the “WEBJOBS_IDLE_TIMEOUT” in your “Application Settings” ;

And don’t be distracted by the “SCM_COMMAND_IDLE_TIMEOUT”. 😉

How to roll your own rss2twitter bot in 15 minutes in Azure?


For today I’ll show you how to roll your own rss2twitter bot in about 15 minutes. What will this bot do?

  • Check an RSS feed for new entries
  • Parse the new entry and replace key words with hashtags
  • Post it to twitter

For this we’ll be using ;

  • Azure Function : as the customer code to find/replace certain words
  • Logic App : as the tool to create our process via a visual tool

And in the end, we’ll see something like this ;


Continue reading “How to roll your own rss2twitter bot in 15 minutes in Azure?”

Changing the timezone on your Azure Webapp / App Service / Function



With one of my flows, I was using an Azure function to generate a filename for my Azure logic app. This name was generated based on the date…


What did I see happening…2017-01-24-20_11_20-scoreboard-microsoft-azure

As I the script ran just after midnight, I saw that I was getting the day before instead of the actual date.

Continue reading “Changing the timezone on your Azure Webapp / App Service / Function”

Azure : Mixing LogicApps & Functions as a periodic data retriever


There are various articles/blogs/etc that compare logicapps vs flow vs functions vs azure automation, etc… Though there was one use case where I often struggled what to use ;

What to use when I want to retrieve a file from X on a Y timed interval?

Azure Functions? Great abstraction, though the output files have random names. Sometimes / Often I want to be able to control that.

Flow? Doesn’t allow the customization I was looking for. More to integrate existing / popular services.

Azure Automation? Very good and gets the job done. The only downside, you need to code a lot of logic yourself.

Azure Logic Apps? Shows potential, but doesn’t let you include custom functions. Or does it…?!?

You can link Azure Functions to Logic Apps and create some the flow I was looking for.


The Flow

So what do I want to do?

  • On a daily basis
  • Retrieve content from an authenticated API
  • Save the content to a Blob storage

And afterwards I’ll use other services to process that data. 🙂


The Proof-of-Concept

What do I want to achieve? On a daily basis I want to retrieve data from a service provider that serves sports data. And if you are looking for such a thing, check out MySportsFeed! So back to our proof-of-concept; how will this look in Logic Apps?


Let’s dissect this flow…

Continue reading “Azure : Mixing LogicApps & Functions as a periodic data retriever”