In the last article we talked about securing Azure Functions and we saw how to insert a message into an Event Hub. To insert the message, we needed the connection string to be in an application setting. This is not the most secure way to store a connection string. We talked that it would be a much better option to store it in Key Vault. Until a couple of days ago, to do that we needed to use a library to get the secret from Key Vault and then use an imperative binding to be able to insert the message into the Event Hub.

(Thanks to Francesc Ribera, Alex Casquete and Jerry Liu for their guidance on this topic) As far as I know (correct me in the comments if I’m wrong, please), when you create a brand new Azure Function, it has access to everything in your subscription as a contributor. That’s really not great. When you develop a new Lambda function you have to specify all the permissions that the function has to have.

In our previous articles we’ve seen how to deploy a Function App using the Azure CLI or Terraform. Once we have a function deployed and accepting traffic, the next obvious thing to do is to monitor it. Adding some logs to the function is fairly easy. If you take a look at the signature of the function [FunctionName("HelloWorld")] public static async Task<IActionResult> Run( [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req, ILogger log) you’ll see that we hava a parameter of type ILogger that we can use to, yes, you guessed it right, log.

In previous articles we’ve seen how to deploy a Function App using Azure Functions Core Tools, Terraform and Azure CLI with Zip Deploy. In this article we’re going to take a look on how to deploy Function apps using deployment slots. Why deployment slots Being able to deploy into slots and decide which slot you use in production has many benefits. To name some of them: - Enable A/B testing - Enable blue/green deployments - No downtime deployments - Easy rollback system

In a previous article we’ve seen how to deploy a Function App using the Azure CLI and the Azure Functions Core Tools. In this article we’ll see how to get rid of the help of the latter and use the Zip Deploy feauture. Fixing the script. We already have a deployment script. It is something like this: #!/bin/bash location=$2 stage=$3 serviceName=$1-$stage resourceGroupName=$serviceName"-rg" serviceNameToLower="$(echo $serviceName | tr '[:upper:]' '[:lower:]')" storageAccountName="$(echo ${serviceNameToLower//"-"/""})" echo "Creating resource group" az group create --name $resourceGroupName --location $location echo "Creating storage account" az storage account create --name $storageAccountName --location $location --resource-group $resourceGroupName --sku Standard_LRS echo "Creating function app" az functionapp create --name $serviceName --storage-account $storageAccountName --consumption-plan-location westeurope --resource-group $resourceGroupName echo "Publishing function locally" dotnet build echo "Publisihng function to Azure" func azure functionapp publish $serviceName What are we going to do is to change the last two steps.

In previous articles (I, II) we’ve seen how to deploy an Azure Function App using the Azure CLI and the Azure Functions Core Tools. In this article we’ll see how to deploy it using Terraform. Prerequisites In order to follow this article you will need the .Net SDK 2.1, the Azure CLI and Terraform installed in your laptop/container/VM/whatever. Building the package What Terraform is going to do is take advantage of the Zip deployment capability (More on this in a future article).

In the last article we saw how to deploy an azure function from the CLI. In this article we’ll see how we can use the same script to deploy the function from a continuous integration environment. In this case we’ll use CircleCI. Creating a new docker image As we saw, if we want to deploy the Function App using the same script we’d need to use the Azure CLI and the Azure Functions Core Tools.

In the last few days, I’ve been tinkering with Azure Functions, reading the documentation a bit and doing a Pluralsight course. As it happens quite offten, these introductory courses use easy techniques to deploy the code, focusing on showing what you can do with the platform. Although obviously this has some value, I don’t think it’s a good idea because, at the end, it will be something that you won’t be able to use in a serious test.

In the previous article we saw how to create a basic deployment pipeline for a serverless application. In this article, we’re going to enrich the deployment by allowing to have different values for configuration settings in each stage. Background The moment your application starts to be a little bit more complex, you need to use configuration settings. These settings can be things like the log level, addresses of external services, usernames and (encrypted) passwords, etc.

Starting with AWS Lambda is really easy. You can even write a function in the browser! But that’s not how you should work on a daily basis. You must have a CI/CD pipeline set up, you probably have two accounts (one for production and another one for development), you need a repeatable and reliable way to create your infrastructure and so on. In this article I’ll show you how to create a simple continuous delivery pipeline that brings us closer to a professional application development.