Peter Birkholm-Buch

Freelance Cloud Architect

Kategori: Ikke kategoriseret (side 1 af 8)

Azure API Management Gateway

These are my thoughts and key take aways from Azure API Management Gateway (APIM) from working with it for some years now.

Easy to Expose Services

Whether it’s a new service built on Azure Functions or a Logic App, something existing internally or externally – it’s dead easy to expose services and secure them through APIM. In fact it’s so easy people don’t believe me when I tell them it takes minutes rather than weeks.

The builtin Dashboard and Analytics gives you a complete overview of requests, response times, errors and so on. With Application Insights you get x-ray vision into the complete end to end call stack for all requests.

Branding the (old) Developer Portal

Branding the – now almost defunct old – Developer Portal using the underlying Orchard CMS is simple and quite a lot can be achieved in a day or two. Going fancy is also a possibility if you know someone who can do a bit of HTML magic with JavaScript and CSS.

The only real problem is the underlying structuring of APIs into Products (think of a Product as a subscription for your mobile phone with different plans for talk time, data and so on) that can be a bit of a challenge when trying to present and manage APIs and Products in whatever way a customer thinks is most important for them. I hope the new portal (and an update to the Products feature in APIM with support for nesting) will make this easier.

Takes only a few days to get to above look and feel by someone who is familiar with a CMS and some HTML, CSS and JS.

Updating an API (needs better builtin support…)

Updating APIs with new methods or revisions of existing should be simple as APIM supports OpenAPI V2+3 Specifications (OAS) – so just point APIM to the OAS file and APIM will detect changes and import. However APIM is does not support this. So most of the time you’re down to a complete re-import so then just updating the change by hand is easier.

Yes APIs can be programmatically updated through the APIM Managment API but it’s not straight forward especially in multiple APIM instance scenarios and you’re then forced to write and maintain scripting to handle this.

Microsoft recently released the APIM DevOps Toolkit which aims at making it easier to move APIs between different instances of APIM. This is done using some tools which can alleviate some of the pain but it’s based on quite a bit of low level handling of configuration files in both JSON and YAML, OpenAPI, ARM Templates and some .NET Core utilities – it works but it feels like it’s introducing complexity where it should be solving the underlying problem of seamless support for updating the API methods based on an Open API specification (leave the policies to a second layer of configuration and/or store it in the SCM).

Azure DevOps with API Management Extension

I like the API Management Suite extension to Azure DevOps as it integrates directly in the release pipeline and deploys an API based on an OAS file in v2/v3 and JSON/YAML formats.

The extension also includes several predefined tasks to create/update products and versioned APIs.

I like using a repo to decouple the API team from the development team. So that the API specification can be agreed upon before the actual development takes place. The developers then implements the API according to the specification and maintains any changes to the OAS file.

API Driven Development

There are numerous definitions for API Driven Development (ADD) floating around so I’m just going to share my implementation of it.

Step 1:

  • The API specification is implemented by an “API Architect” in collaboration with the business. This ensures that externally exposed APIs are as homogenous as possible by sharing resource names, paths and data models
  • The specification is pushed to a repo in Azure DevOps

Step 2:

  • The developers implements the API according to the specification
  • The specification is updated with any additional information
  • Automated integration tests are added
  • A PR is created with changes and tests

Step 3:

  • The specification is validated against a common ruleset using Spectral
  • The API specification is deployed to APIM
  • Automatic integration tests are run
API Driven Development with Azure API Management

An API is a Product!

This is perhaps more important that whatever platform and process you use to expose the actual API to your customers.

You have to treat an API as a product – same as any other product you sell. You have to have a team to support it, take care of it, listen to customer feedback and to keep an eye on the SLA.

You can’t expose internal QA versions with limited SLA as the “test” version – everything you expose is IN PRODUCTION – period.

This is in my experience something that requires a bit of getting used to for companies just getting into the API game!

Azure Cosmos DB

These are my thoughts and key take aways from working with Azure Cosmos DB for a while now.

Infinite Ease

Creating a database importing some data and querying it through the Data Explorer takes literally 5 minutes.

Creating an interface using Azure Logic Apps with the Cosmos connector or a proper API using Azure Functions with bindings and PowerShell is an additional 5 minutes.

Expose the API through the Azure API Management Gateway and you have a complete schema-less database and data access layer in 15 minutes.

Cosmos is hands down the most easy and accessible database technology I’ve ever worked with – period!

Infinite Scale

Cosmos is built to be infinitely scalable in terms of storage and performance.

Data is stored in storage partitions in chunks of 10GB and Cosmos automatically adds more storage partitions as needed. It works great and is seamless – only gotcha is that Cosmos for some reason won‘t scale storage partitions back to less than two which in most cases probably doesn’t matter much, but it is an issue with regards to cost. See more below.

Performance is measure in a fixed unit called Request Units per Second or RUs. 1 RU is required to read 1 KB of data and 5 RU are required to write 1KB of data. So on the surface calculating how many RUs you need should be easy. Turns out it isn’t and missing your RUs can be costly or make you loose data.

Infinite Cost

This is where infinite scale turns into infinite cost. On the surface it only seems fair that infinite scale should have a price – but controlling cost in Cosmos is difficult and completely different for what you have come to expect of the Cloud.

It’s all about those RUs.

You allocate a fixed amount of RUs either to an entire database (probably can’t recommend doing that) or to individual collections – and then you pay for those fixed RUs whether you use them or not!

Fine you think – how much can it cost in terms of RUs to write and read some data? Quite a lot in fact and there are several factors which have great influence over how many RUs are required to write and read data. I highly recommend reading this and this but it all boils down to the partition key.

The partition key is used to distribute data over logical data partitions when Cosmos writes data. The less data you write to the same logical partition as the same time – the more performant the write is.

When reading data the partition key can be used in a query to tell Cosmos where the data is stored and make reading data more performant. If you don’t know the partition key in a query then Cosmos have to read through all the data that fits the WHERE clause and that drives RUs – because reading 1 KB costs 1 RUs – so reading through 1000s of KBs of data to find that single document can cost a lot of RUs. So if you have a lot of queries without partition key and lots of spikes then you have to provision lots of RUs and pay for them 24/7.

Unfortunately there’s no auto scaling for RUs available in Cosmos even though the competitor seems to have one. However recent additions to Azure Monitor makes it possible to create your own.

Update: At Ignite 2019 CosmosDB AutoPilot was announced which is the long awaited auto scaling feature!

If you have spikes and you run of out provisioned RUs then Cosmos will throttle the requests by sending back an HTTP429 error message. It’s then up to the client to know how to handle this and perform a retry. If the client doesn’t know how, then it’s an error and the data is probably lost. Please be aware of the retries!

Infinite Possibilities

Once you’ve tackled the scaling, cost and partition keys and you start to to use Cosmos with the change feed and hook it up to the event grid – you get a completely new publish and subscribe data layer capable of replacing integration middleware, ingesting data at IoT scale and driving real time data analysis with Spark and Databricks.

Cosmos is a game changer!

Azure Logic Apps

This is not a guide or any kind of introduction to Logic Apps but my thoughts and key take aways from working with them for a while now.

Events & Connectors

Logic Apps are great for reacting to events – especially Azure events – and I usually use them to build up the outer and more general logic of a system. This is to react to things that happens and maybe do comparison against thresholds and other configuration settings. It’s easy to call out to other services both in Azure, Office and external APIs.

As a general rule I don’t use Logic Apps to update data – I prefer to use Azure Functions for that as SDKs usually supports more advanced retries and error handling. However, some connectors supports this also – your mileage may vary.

The connectors really are the stars of Logic Apps – you can receive and act on data from pretty much any resource in the Microsoft eco system and most enterprise systems that support Azure Active Directory have connectors too.

Developer Support

Creating Logic Apps using the visual designer in the Portal and Visual Studio is a breeze – Visual Studio Code still only supports editing the underlying JSON document but will display the visual designer in read-only mode. Actual development using a repo and Azure DevOps CI/CD is a bit clunky and deployment requires an ARM template to be built using a script. Better support for storing the “code” for a Logic App in a code repository and deployment is something I’m hoping that will be added in the future.

I’ve seen integration developers use Logic Apps to quickly and easily build integration pipelines using HTTP, data parsing, conditions and service bus but they get stuck when it comes to CI/CD.

No deployment slots

Logic Apps doesn’t support deployment slots so it requires a service window of some sort when deploying in higher load scenarios. Since we’re exposing our Logic Apps through the Azure API Management Gateway we mock the requests to our Logics Apps during deployments. This is certainly not ideal and I hope that Logic Apps will get some form of deployment slot capability in the future.


Logic Apps on paper supports reacting to and handling 1000s of events and requests per minute (we’ve done that too – Just be aware that the normal limit is 100.000 requests per 5 minutes). However if you’re not carefull then “long” running activations during high load can cause your entire App to freeze. If this happens then a manual restart can become required. If that happens then you have to start thinking about your usage of Logic Apps; the flows, branching, error handling and perhaps if moving to an Azure Function is better fit for what you’re trying to accomplish.

Setting roles and policies on Azure KeyVault to enable getting secrets from an Azure Function

This is just a follow up on this post: for a bit more clarification on the roles and policies required in KeyVault to make this work.

The enable an Azure Function to access secrets in KeyVault you have to do the following:

  1. Create a system assigned managed identity to the Function. Just go to Platform Features in your Function and select Identity and enable the System assigned identity – remember to click save!
  2. Giving the role “Managed Application Reader” to the managed identity of the Function.
    1. Go to KeyVault and click on “Access control (IAM) in the menu and click on “Role assignments”.
    2. If you want to see existing App/Functions that have assignments select “App Services or Function Apps” from the Type dropdown menu.
    3. Click on Add and select the “Managed Applications Reader” from the Role drop down menu.
    4. Type in the name of your Function and select it from the menu – make sure you select the actual identity of the Function – see the icon in the screendump below.
    5. Click on save.
      Adding roles to KeyVault
  3. Assigning at least the “Get Secret” policy to the service principle of the managed identity.
    1. Click on “Access policies” in the KeyVault menu
    2. Click on Add and click on the “Select principal” fly out menu and type in the name of your Function
    3. This time it’s the service principal we want to select – click on it and click on select
    4. From the “Secret permissions” drop down menu select at least the “Get” permission.
    5. Click on OK.
      Adding policies to KeyVault

You’re done and you should now be able to get secrets from your KeyVault in your application settings in your Function.

Payroll Services Firm Transforms its Product Into a Platform with API Management

Bluegarden, a large Scandinavian payroll service, is using Microsoft Azure API Management to gain a simple, efficient, security-enabled way to share application programming interfaces (APIs) with partners. By publishing APIs for key product capabilities, Bluegarden can create an extensible product to fit every customer’s needs, expand its partners and consequently its business, and help keep APIs secure.

Installing ELMAH on IIS

Just for reference because it just too long looking for this information on how to install ELMAH on IIS to troubleshoot a failling application.

Download ELMAH using Nuget:

nuget install elmah

Copy elmah.dll to the bin folder of your application.

Add the following to the same sections in your web.config

              <add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />
              <add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
              <add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah" />
              <add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah" />
       <modules runAllManagedModulesForAllRequests="true">
              <add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
              <add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah" />
              <add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah" />
              <add name="Elmah" verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />

Goto localhost/yourwebapplication/elmah.axd

Definition of Big Data

Windows 8 – God mode

Just hit Windows+x

Windows 7 – God Mode

Go to your desktop, create new folder and call it …


… yes you must name it with the full stop and guid.


Posted this on my internal blog at Traen:

A critical success factor for SCRUM projects is having access to customer representatives who are:

  • Collaborative
  • Representative
  • Authorized
  • Committed
  • Knowledgeable

If the customer representatives are not collaborative, they will sow discord and frustration, resulting in the loss of morale.

If the are not representative, they will lead the developers to deliver unacceptable products.

If they are not authorized, they will incur delays seeking authorization or, even worse, lead the project astray by making unauthorized commitments.

If they are not committed, they won’t do the necessary homework and won’t be there when the developers need them most.

If they are not knowledgeable, they will cause delays, unacceptable products or both.

So SCRUM needs customers who are CRACK!

From “Balacing Agility and Descipline: A Guide for the Perplexed

Actually it’s true for any kind of project based on any proces or methodology…

« Ældre indlæg