I recently started experimenting with the beta versions of the new Azure Storage and Event Hub extensions for Azure Functions. The new extensions use the new Azure SDK, and as a result, include support for using Azure AD to authenticate to specific Azure resources (a.k.a., managed identities). I’m a fan of having fewer secrets to manage. Less secrets . . . more better. 😉 This intent of this blog post is to share my initial experiences with the extensions.

Earlier this month I had the pleasure to join The Azure Podcast team to talk about my experiences with Azure Functions. We discussed how I came to love working with Azure, my journey from classic Cloud Services to Azure Functions, and the current state of virtual networking with Azure Functions. This was my second time on the podcast. My first appearance was a little more than 5 years ago after the release of a book I co-authored, Fundamentals of Azure.

I was recently asked how to change Azure Functions' system keys, such as the ones automatically created by the Event Grid or Durable Functions extensions. It’s possible to change these keys via the Azure portal. There is a button in the portal to generate a new key. What if you want to change the keys programmatically? I couldn’t find official documentation which stated how to do so. After a bit of splunking through GitHub issues (here, here) and reading Mark Heath’s excellent blog post on Azure Function keys, I think I found an approach that, so far, seems to work.

I recently ran into a situation using the Azure Functions default host key where I did not understand the behavior I was observing. Thanks to the help of some fantastic colleagues, we figured out what was going on. I understand what is happening now. I want to share here in hopes that my experience will help others that may run into a similar challenge. Scenario I needed to create an Azure Function app via an ARM template.

A few months ago one of the greatest scandals to hit Azure Functions erupted . . . ASCIIartgate! #teamAsciiArt became a trending topic on Twitter. Maybe. The Big Deal In an effort to reduce the verbosity of logging output by func start in the Azure Functions Core Tools, the decision was made to remove the famed ASCII art. To be fair, running func start did output quite a bit of logs.

Earlier this year I wrote a post showing how to set up private site access for Azure Functions. To briefly recap, private site access refers to setting up a virtual network service endpoint to restrict HTTP-based access to the function to be only traffic from the designated virtual network (i.e. inbound HTTP requests). Attempts to access the public endpoint (e.g., https://contoso.azurewebsites.net) result in an HTTP 403 Forbidden message. Service endpoints are great, but they are not without some drawbacks (use a public IP address, doesn’t work with connections from on-premises resources (i.

I’ve moved my blog again! Well, sort of. Not a new engine this time. I’ve moved to a new host! I’ve moved my blog to Azure Static Web Apps. The docs for Static Web Apps (SWA) include a good tutorial on using Hugo with SWA. I followed that tutorial. Once I got the content set up and GitHub action publishing working, it was time to set up the custom domain name.

As enterprises continue to adopt serverless (and Platform-as-a-Service, or PaaS) solutions, they often need a way to integrate with existing resources on a virtual network. These existing resources could be databases, file storage, message queues or event streams, or REST APIs. In doing so, those interactions need to take place within the virtual network. Until relatively recently, combining serverless/PaaS offerings with traditional network access restrictions was complex, if not nearly impossible.

Earlier this year I moved my blog to Jekyll. It was fun while it lasted. I’ve decided to give Hugo a try. The main reason is that I wanted something I could easily from either my Windows or Mac machines. I didn’t want to mess with installing or configuring Ruby gems. I’m giving Hugo a try. I expect to change the theme and make tweaks over the coming weeks.

This post will demonstrate how to create an Azure Function with private site access. Private site access refers to a way for resources within a virtual network to reach out to an Azure Function. Configuring private site access ensures that the specified Azure Function is not able to be triggered via the public internet. Instead, the function can only be accessed via a specific virtual network. The function is private to the specified virtual network.