.NET 10 is set to launch in November 2025 as the next LTS release having free support and patches for three years from its release date. Here are three of my favorite new features that I’ll definitely use in my day-to-day work.

Extension Members

I’ve used extension methods extensively since their introduction in C# 3 back in 2007. Now, with C# 14, this concept is being further expanded to include extension members. Before the release of C# 14, an extension method would typically look like this:

public static void Subtract(this int number, int subtractBy) 
    => number - subtractBy;

But now, with C# 14 we can define an extension method and extension members like this:

public static class Extensions 
{
    extension(string sentence) 
    {
        public int CountWords() 
            => sentence.Split(' ', StringSplitOptions.RemoveEmptyEntries).Length;
        
        public bool FirstWord 
            => sentence.Split(' ', StringSplitOptions.RemoveEmptyEntries).FirstOrDefault() ?? string.Empty;
    }
}

TypedResults for Server Sent Events (SSE)

In client-server communication, a pull-based approach is commonly used where the client requests resources via a RESTful API or a similar mechanisms. The issue with this model is that it can generate excessive server traffic when clients repeatedly poll for resources that aren’t yet available.

To address this, we can shift from a pull-based model to a push-based one, where the server notifies the client as soon as the resource becomes available.

ASP.NET Core already offers several options for push-based communication. You can use SignalR, which leverages WebSockets to notify clients when something happens on the backend. Alternatively, you can use Server-Sent Events (SSE) for one-way, realtime updates from server to client over HTTP. The only requirement for an HTTP response to be recognized as an event stream is that the Content-Type header is set to text/event-stream.

Server Sent Events isn't something new in ASP.NET Core, but with the release of .NET 10 its really easy to implement. When .NET Core 3 was released back in 2019 a new type called IAsyncEnumerable where introduced. IAsyncEnumerable<T> is an interface in C# that allows you to iterate over a sequence of data asynchronously without blocking. This interface can now be passed in as a parameter to the new method in TypedResults:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();
app.MapGet("/results, (CancellationToken token) => 
{    
    IAsyncEnumerable<SseItem<Result>> results = GetResults(token);
    return TypedResults.ServerSentEvents(results);
});    

Validation Support in Minimal APIs

When it comes to validation, ASP.NET offers excellent support through the System.ComponentModel.DataAnnotations namespace. It includes a wide range of built-in attributes and also allows you to define custom ones.

Until now, validation hasn’t been built into Minimal APIs by default, but this will change with the release of .NET 10. When I say ‘built-in,’ I don’t mean it wasn’t possible before, but it required you to manually implement validation logic within each endpoint or create a custom filter.

Beginning with ASP.NET 10 you can simply write

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddValidation();

var app = builder.Build();

app.MapPatch("/update-email", [EmailAddress] string address) =>
{
   ....
   return TypedResults.Ok();
}

The call to AddValidation will ensure that all neccessary services to support validation is being registered within the container. Pretty easy!

Those are my top three new features in .NET 10 that I believe will have a real impact on my day-to-day work as a .NET developer. What are yours?

My most recent posts have been in the landscape of "How to monitor applications running in Kubernetes". This time is no different. Today we'll look at how we can persist prometheus data to an Azure Disk using a custom build Storage Class.

In Kubernetes, a Storage Class defines the "classes" of storage available in a cluster. Administrators use Storage Classes to describe different types of storage offered, such as HDDs or network-attached storage (NAS), or in our case an Azure Disk backed by a SSD disk.
When applications request persistent storage for their applications, they can specify a Storage Class in their Persistent Volume Claim (PVC). The Kubernetes control plane then uses the specified Storage Class to dynamically provision a Persistent Volume (PV) that meets the requirements. Storage Classes allow for flexible and efficient management of storage resources, ensuring that the right type of storage is allocated based on application needs.

Before we'll dive into the world of yaml files, we need to provision our Azure Disk. Its doesnt really matter how this resource is provisioned, I prefer using Bicep to deploy my Azure resources. This will create a Locally Redudant SSD disk with 32 GiB of storage.

param location string
param name string
param tags object

resource diskprometheus 'Microsoft.Compute/disks@2023-10-02' = {
  name: name
  location: location
  tags: tags
  sku: {
    name: 'Premium_LRS'
  }
  properties: {
    creationData: {
      createOption: 'Empty'
    }
    diskSizeGB: 32
    diskIOPSReadWrite: 120
    diskMBpsReadWrite: 25
    encryption: {
      type: 'EncryptionAtRestWithPlatformKey'
    }
    tier: 'P4'
  }
}

Once you have provisioned the resource, we can go ahead crafting our beloved yaml-files.

Crafting our yaml files

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: azuredisk-prometheus
provisioner: disk.csi.azure.com
parameters:
    skuName: PremiumSSD_LRS
reclaimPolicy: Retain
volumeBindingMode: Immediate
allowVolumeExpansion: true

A few things to note down:

• We are using the Azure Disk Container Storage Interface (CSI). CSI drivers in Kubernetes enable the integration of storage systems with Kubernetes clusters. The CSI standardizes how storage vendors can expose their storage systems to containerized workloads.

• We specify Retain as our ReclaimPolicy. This policy dictates the default lifetime of the Persistent Volume when the associated Persistent Volume Claims are deleted. In our case we'll keep the data when the associated PVCs are deleted.

• Our VolumeBindingMode is set to Immediate. In the Immediate binding mode, the Persistent Volume is bound to the Persistent Volume Claim as soon as the latter is created. The binding and provisioning occur immediately without waiting for a pod to be scheduled as it would be in the WaitForFirstConsumer mode.

• Setting AllowVolumeExpansion to true enables the Persistent Volume to be dynamically resized without disrupting the running workloads.

Still with me? Lets go ahead and create the specifications for our Persistent Volume and Persistent Volum Claim.

apiVersion: v1
kind: PersistentVolume
metadata:
    annotations:
        pv.kubernetes.io/provisioned-by: disk.csi.azure.com
    name: azuredisk-prometheus
spec:
    capacity:
        storage: 32Gi
    accessModes:
        - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    storageClassName: azuredisk-prometheus
    csi:
        driver: disk.csi.azure.com
        readOnly: false
        volumeHandle: /subscriptions/{subscription-id}/resourceGroups/{resourceGroupName}/providers/providers/Microsoft.Compute/disks/{disk-name}
        volumeAttributes:
            cachingMode: ReadOnly
            fsType: ext4

The important thing to note is how we reference our Azure Disk under volumeHandle by specifying the Subscription Id, name of the Resource Group and lastly the name of the provisioned disk.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: prometheus
    prometheus: prometheus-kube-prometheus
  name: prometheus-prometheus-kube-prometheus-prometheus-db-prometheus-prometheus-kube-prometheus-prometheus-0
  namespace: k8s-namespace-for-prometheus
spec:
    storageClassName: azuredisk-prometheus
    accessModes:
        - ReadWriteOnce
    resources:
        requests:
            storage: 32Gi

Pay attention to name of this PVC. This is a workaround, outlined in this GitHub Issue, if you want to attach an existing PVC to Prometheus.

We can now apply these three yaml-files to our AKS Cluster by running
kubectl apply on each and every file, or by running kubectl apply -f on the dictionary where these files are located.

Install Prometheus

We'll install Prometheus from the package manager Helm. Before we'll do that, lets configure the values.yml in order the parameterize the Prometheus ConfigMap.

prometheus:
    enabled: true
    prometheusSpec:
        storageSpec:
            volumeClaimTemplate:
                spec:
                    volumeName: azuredisk-prometheus
                    storageClassName: azuredisk-prometheus
                    accessModes: ["ReadWriteOnce"]
                    resources:
                        requests:
                            storage: 32Gi

Lets go ahead and install the Helm Chart with our values.yml file

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm upgrade --install --namespace k8s-namespace-for-prometheus prometheus prometheus-community/kube-prometheus-stack -f values.yaml

To verify that it works you can navigate to the AKS resource, then go to Storage and look for our created Storage Class, Persistent Volumes and Persistent Volume Claims. Verify that the Persistent Volume Claim has the status Bound.

If you are stuck, I highly recommend that you'll running kubectl describeon the various resources and kubectl logs on the prometheus Pod.

If you have any questions, you can reach out to me on Twitter/X.

Thanks for reading!

Introduction

Nine months back I wrote a post on how you can run seq in Azure. Back then we used Azure Container Instances as our hosting platform. A few months back we migrated most of our workloads to Azure Kubernetes Services and it didn't make any sense to continue running Seq on Container Instances when we had a Kubernetes Cluster. So we figured out that we could easily install Seq as a Helm Chart and customize the deployment to fit our needs.

We were quickly up and running with an instance of Seq in our cluster, but one issue remained to be solved: How can we store data such as api keys, configuration and the actual log data outside the cluster so we easily can redeploy the cluster without having to worry about losing configuration and rotating api keys for all of our applications?

Configure a Storage Class, PVC and PV.

In the configuration file for the helm chart, values.yaml, a section named persistence let's us configure persistence (doh) by using something call a PVC, short for Persistent Volume Claim.

A PVC works in conjuction with a PV, short for Persistent Volume. A PVC allows Pods in your cluster to access a PV. A PV is assigned to a Storage Class which essentially abstracts away various storage solutions such as Azure Storage Account. The illustration below sums up how everything is connected

For this to work you'll need an Azure Storage Account with at least Premium_LRS set as the SKU. If you need zone redundancy, you can choose for Premium_ZRS. The storage account needs to be of kind FileStorage and have a File Share Configured. Please see this post for Bicep templates. Please make sure that the Managed Identity configured as Kubelet Identity has access to this Storage Account.

Lets start by defining our StorageClass.yaml:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: seq-azurefile
provisioner: file.csi.azure.com
allowVolumeExpansion: true
mountOptions:
 - dir_mode=0777
 - file_mode=0777
parameters:
  skuName: Premium_LRS
  storageAccount: <storage-account-name>
  location: <storage-account-geographic-location>

Then we'll create our PersistentVolume.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: file.csi.azure.com
  name: seq-azurefile
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: seq-azurefile
  csi:
    driver: file.csi.azure.com
    readOnly: false
    volumeHandle: replace_with_unique_id_across_cluster
    volumeAttributes:
      resourceGroup: replace_with_storage_account_rg
      shareName: replace_with_file_share_name
      storageAccount: replace_with_storage_account_name
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=0
    - gid=0
    - mfsymlinks
    - cache=strict
    - nosharesock
    - nobrl

And finally lets create our PersistentVolumeClaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: seq-azurefile-pvc
  namespace: your-aks-namespace
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: seq-azurefile
  volumeName: seq-azurefile
  resources:
    requests:
      storage: 100Gi

Apply these changes to the cluster by running kubectl apply -f <file-name> or for all yaml-files in the current folder kubectl apply -f.

To verify that everything works as expected you can either run a series of kubectl commands, or by navigating to your cluster in the Azure Portal and select the tab 'Storage'. You should see your PVC and PV with the status Bound. In case you prefer to verify this via your terminal you can run the following commands:

• kubectl get pvc --all-namespaces
• kubectl get pv --all-namespaces
• kubectl get sc --all-namespaces

Configure values.yaml for Seq

In Seq values.yaml we'll need to reference our existing PVC

persistence:
  enabled: true
  existingClaim: seq-azurefile-pvc
  reclaimPolicy: Retain
  volumeBindingMode: Immediate
  allowVolumeExpansion: true

Finnaly we can now install Seq as a Helm Chart with the provided configuration:

helm upgrade --install -f values.yaml --namespace logs seq datalust/seq

Verify that everthing works by describing the pod in your cluster and look for events in case something is wrong:

kubectl get pods -n logs and look for Seq. Copy the name of the Pod and run kubectl describe pod <pod-name> -n logs

Thanks for reading, and if you have any questions, you can find me on X with the handle @thorstensen

So you have created and configured an AKS cluster and life is good. You think. As time goes by, you keep adding features to your cluster and eventually something doesnt work as expected. Sounds familiar?

I my particular case I was trying to mount an Azure File Share to my AKS cluster with the NFS protocol, but without any success. I was getting a pretty useful error message when running kubectl describe on the problematic pod:

Output: mount.nfs: access denied by server while mounting storageaccountname.file.core.windows.net:/storageaccountname/fileshareName

Microsoft troubleshooting guide pointed me in the direction that the node probably was missing nfs-common.

To install packages to the underlying Ubuntu Virtual Machine Scale Set I needed SSH access to the node. Pretty straight forward you think? Think again.

This is where this neat little trick comes in handy:

1. List all your nodes by running kubectl get nodes
2. Find the node you want to SSH into
3. Run kubectl debug node/node-name -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
4. Enjoy root access.

Happy debugging!

If you have worked with Kubernetes you probably know that Secrets are not really secrets. They are just base64 encoded key value pairs stored in etcd. Anyone with access to the cluster will have access to these secrets by running a simple command

kubectl get secrets --all-namespaces
kubectl get secrets/database -n my-namespace -t={{.data.password-key}} | base64 -D

In order to safely store these secrets you can enable encryption at rest or configure role based access control(RBAC). This article won't cover these two alternatives as we'll rather look at a helm chart that will injecting secrets stored in Azure Key Vault as environment variables to a pod running Grafana. That being said, this approach can be used for other scenarios where you'll need secrets from Azure Key vault.

Prerequisites

To follow along you'll need to have the following up and running:

• Helm installed
• An AKS Cluster
• An Azure Key Vault instance in the same subscription
• A User Assigned Managed Identity with the role Key Vault Secrets Officer to the aforementioned Key Vault. This Managed Identity also needs to be associated with the AKS Cluster.

Configure Kubernetes Cluster

We are using a Helm Chart named akv2k8s to get secrets from Azure Key Vault. Once this chart is installed, two pods will run in our cluster fetching and monitoring changes to specific secrets. This chart will only monitor changes in namespaces with the label

azure-key-vault-env-injection: enabled

To label your namespace in an idempotent way, you can run the following command

kubectl create namespace grafana --dry-run=client -o json|jq '.metadata += {"labels":{"azure-key-vault-env-injection":"enabled"}}' | kubectl apply -f -

Now we'll need to add a reference to our Key Vault.

apiVersion: spv.no/v2beta1
kind: AzureKeyVaultSecret
metadata:
  name: azure-keyvault-secret-inject 
  namespace: grafana
spec:
  vault:
    name: someKeyVaultName # name of key vault
    object:
      name: someKeyVaultName # name of the akv object
      type: secret # akv object type

Apply the changes to our cluster:

kubectl apply -f <name-of-file-above-yml>

Now that we have labeled our namespace and created a reference to a secret in our Azure Key Vault, lets install the Helm Charts!

Installing Helm Charts

Helm is a package managing tool for Kubernets and packages are called Charts. We'll use two Helm Charts to achieve our goal by running Grafana with secrets injected as environment variables to the pod.

• Grafana
• akv2k8s

Lets start by adding these two charts:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo add spv-charts https://charts.spvapi.no
helm repo update

Lets install these charts

helm upgrade --install akv2k8s spv-charts/akv2k8s --namespace akv2k8s
helm upgrade --install --namespace grafana grafana grafana/grafana

You should now have three pods running. Verify that by running the following commands:

kubectl get pods -n grafana
kubectl get pods -n akv2k8s

Should result in:

• grafana-xyz
• akv2k8s-controller-xyz
• akv2k8s-envinjector-xyz

Configuring Grafana

Lets take a step back and configure Grafana with the values we configured in AzureKeyVaultSecret.

First we'll need to delete Grafana Helm Chart.

helm delete grafana -n grafana

Now we need to customize Grafana by adding the -f option. This option will allow us to pass in a yml file with custom values. We will be using the template found in Grafana's GitHub Repository.

To achieve reading values from Azure Key Vault, we'll be setting the default administrator password for Grafana by passing it in as an environment variable. Find the section for environment variables in the yml file and add the following:

env:
  GF_SECURITY_ADMIN_USER: "admin"
  GF_SECURITY_ADMIN_PASSWORD: "azure-keyvault-secret-inject@azurekeyvault"

GF_SECURITY_ADMIN_PASSWORD will now refer to the name we specified for AzureKeyVaultSecret.

This is unfortunetly not enough as Grafana won't set this environment variable to the administrator password. We'll need to run a command when the pod has started to set a new password.

Under the specificed environment variables add the following:

command:
  - sh
  - -c
  - grafana-cli admin reset-admin-password ${GF_SECURITY_ADMIN_PASSWORD} && /run.sh

This is a workaround, and it seems that wont be fixed in the near future according to this GitHub Issue.

Depending on your configuring, like Ingress, Persist Volum Claims etc, your values.yml file should look something like this:

env:
  GF_SECURITY_ADMIN_USER: "admin"
  GF_SECURITY_ADMIN_PASSWORD: "azure-keyvault-secret-inject@azurekeyvault"

command:
  - sh
  - -c
  - grafana-cli admin reset-admin-password ${GF_SECURITY_ADMIN_PASSWORD} && /run.sh

Lets install Grafanas Helm Chart once more with these values:

helm upgrade --install --namespace grafana grafana grafana/grafana -f values.yml

You should now see an instance of Grafana running in your cluster. Lets inspect the pod by running

kubectl describe pod <name-of-pod> -n grafana

Scroll all the way up to Environment and here you should see your secret being injected:

Now you should be able to access grafana depending on your configuration, by port forwarding or via the ingress, with the password stored in Azure Key Vault.

If you face any issues I would recommend looking at the events section when you describe the pod, or alternatively get the logs by running

kubectl logs <pod-name> -n grafana

Hope you found the post useful, and thank you for reading!

Managed Identities is a key concept in Microsoft Azure which makes it easy to manage access to various services in Azure without having to worry about rotating secrets. In this article we'll look at how we can use a specific managed identity connected to pods in Azure Kubernetes Services.

Before we start, I'll assume that you have a certain degree of knowledge about Azure and AKS. I will also assume that you have setup a Subscription, a Resource Group, a User Assigned Managed Identity and also the AKS Cluster we are deploy to. So, lets jump into it!

For many years pod-managed identity has been the way to connect a AKS Pod with a Managed Identity. This Open Source project has been replaced by Azure AD Workload Identity. Unfortunately there arent many good articles/blog posts/official documentation on how to setup and configure this is a good way. Hopefully this one will make you succeed.

First of all, lets create our serviceaccount.yml file

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: managed_identity_client_id
  labels:
    azure.workload.identity/use: "true"
  name: serviceaccount_name

Replace managed_identity_client_id with the clientId of your Managed Identity. This can be found in the portal, or by running the following CLI command

az identity show -n name-of-managed-identity \
-g name-of-resource-group \
-o tsv --query clientId

You also need to replace the name with something meaningful. We'll need this name later on when we'll change our deployment.yml and setting up federation for the Managed Identity

Next up you need to change you deployment.yml to include azure.workload.identity/use: "true" under template/metadata/labels and refering to the serviceaccount_name under template/spec/serviceAccountName. Your deployment.yml should look something like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
  labels:
    app: helloworld
spec:
  replicas: 2
  selector:
    matchLabels:
      app: helloworld
  template:
    metadata:
      labels:
        app: helloworld
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: serviceaccount_name
      containers:
        - name: helloworld
          image: mcr.microsoft.com/dotnet/samples:aspnetapp
          ports:
          - containerPort: 80

Finally we'll need to run an az command to create federated credentials for the Managed Identity

issuerUrl="$(az aks show -g rg-name -n aks-clusterName --query oidcIssuerProfile.issuerUrl -o tsv)"
                   
az identity federated-credential create \ 
--name serviceaccount_name \ 
--identity-name mi_name \ 
--resource-group mi_rg \
--issuer $issuerUrl \
--subject system:serviceaccount:your-aks-namespace:serviceaccount_name

Navigating to the overview of your Managed Identity should show you a new element in the menu named 'Federated Credentials'.

You're now all set to apply changes to your AKS Cluster by running kubectl apply on your configuration files.

As a bonus; Please make sure that you have updated to at least version 1.9 of the Azure.Identity package if your application is a .NET app. This package includes WorkloadIdentityCredential when your application uses the DefaultAzureCredentials authentication flow.

When developing open source software published to nuget feeds, E.G nuget.org, versioning becomes really important. Semantic versioning is a popular versioning scheme that introduces three positive numbers that all together forms the version number. Those number are formatted as MAJOR.MINOR.PATCH.

• MAJOR increases when incompatible changes are made.
• MINOR increases when changes are made in a backward compatible manner
• PATCH increases when you make backward compatible bug fixes

The first two numbers are always changed manually when creating the package. For the number that represents PATCH, we can do this automatically with a little hidden gem in Azure DevOps.

Given that you are using the NugetCommand@2 task from Azure DevOps marketplace, you can select versioning scheme byEnvVar that tells the task to fetch the version number from the Environment Variables by the key versionEnvVar.

- task: NuGetCommand@2
  displayName: "Push"
  inputs:
  command: "push"
  feedsToUse: "select" 
  packagesToPush: "nupackages-to-push"
  nuGetFeedType: "internal"
  publishVstsFeed: "myPrivateFeed"
  versioningScheme: "byEnvVar"
  versionEnvVar: PackageVersion
  allowPackageConflicts: false

To set the variables, head over to the Variables section for your pipeline and declare four variables:

Note that the variable PackageVersion is the one we refer to in our NugetCommand@2 task.

Happy Coding!

Seq is one of my favorite logging and monitoring tools out there. Unfortunately Azure does not have built-in support to run Seq as a SaaS offering. But don't worry, this guide will walk you through configuring and deploying Seq as a Docker container running in Azure Container Instances using Bicep.

Defining Bicep resources

To run Seq in Azure we'll three resources:

• Azure Container Instance hosting our docker image
• Azure Storage Account storing log data
• Azure File Share mounted to the storage account

Before we start defining our resources, let's create a new directory and two bicep files.

mkdir infrastructure && cd infrastructure && touch seq.bicep && touch main.bicep

For demonstration purposes seq.bicep will contain all our resources:

param location string = resourceGroup().location
var dnsLabelName = 'aci-seq-test'
var fqdn = 'http://${dnsLabelName}.${location}.azurecontainer.io'

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-05-01' = {
  name: 'saseqtest'
  location: location
  sku: {
    name: 'Premium_LRS'
  }
  kind: 'FileStorage'
}

resource fileShare 'Microsoft.Storage/storageAccounts/fileServices/shares@2021-04-01' = {
  name: '${storageAccount.name}/default/${shareseqtest}'
}

resource containerGroup 'Microsoft.ContainerInstance/containerGroups@2021-09-01' = {
  name: 'aci-seq-test'
  location: location
  properties: {
    containers: [
      {
        name: 'aci-seq-test'
        properties: {
          image: 'datalust/seq:latest'
          ports: [
            {
              port: 80
              protocol: 'TCP'
            }
          ]
          resources: {
            requests: {
              cpu: 1
              memoryInGB: 1
            }
          }
          volumeMounts: [
            {
              mountPath: '/data'
              name: 'seq-data'
            }
          ]
          environmentVariables: [
            {
              name: 'ACCEPT_EULA'
              value: 'Y'
            }
            {
              name: 'SEQ_API_CANONICALURI'
              value: fqdn
            }
          ]
        }
      }
    ]
    volumes: [
      {
        name: 'seq-data'
        azureFile: {
          shareName: fileShareName
          storageAccountName: storageAccount.name
          storageAccountKey: storageAccount.listKeys().keys[0].value
        }
      }
    ]
    osType: 'Linux'
    restartPolicy: 'OnFailure'
    ipAddress: {
      type: 'Public'
      dnsNameLabel: dnsLabelName
      ports: [
        {
          port: 80
          protocol: 'TCP'
        }
      ]
    }
  }
}
output fqdn string = containerGroup.properties.ipAddress.fqdn

Lets define our main.bicep file

module seq 'seq.bicep' = {
  name: 'seq'
}

output seqFqdn string = seq.outputs.fqdn

Thats everything you'll need to create an instance of Seq running in Azure with a File share mounted to it. To create these resources, make sure you are logged into your Azure Tenant and the correct subscription is selected. To deploy these resource you can either use the portal or the CLI by running:

az deployment group create --resource-group <resource-group-name> --template-file main.bicep

The cost of running these resources in Azure adds up to around 50 USD/month. Most of the cost is related to running the Container Instance 24/7. For a more detailed overview of the pricing structure, I would recommend to check out the Azure Pricing Calculator.

Make sure that you enable authentication by accessing the seq dashboard!

Happy logging!

When serving a website from a docker container, we usually create a multi staged Dockerfile using nginx as our web server. The Dockerfile probably looks something like this:

... left out for brevity...

FROM nginx:alpine AS deploy
WORKDIR /usr/share/nginx/html
COPY --from=build /app/dist .
COPY ./nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80 443

If your frontend application ever need to use environment variables passed into your docker container during runtime, you'll probably googled your way to several solutions suggesting that envsubst might help you out.

... left out for brevity...

FROM nginx:alpine AS deploy
WORKDIR /usr/share/nginx/html
COPY --from=build /app/dist .
COPY ./nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80 443

CMD ["/bin/bash",  "-c",  "envsubst < /usr/share/nginx/html/env.template.js > /usr/share/nginx/html/env.js && exec nginx -g 'daemon off;'"]

But, what if you want to swap out nginx and serve your frontend app using ASP.NET Core's web server, Kestrel?

Execute envsubst when running a ASP.NET Core containarized application

Initally our Dockerfile used the mcr.microsoft.com/dotnet/aspnet:7.0 as our runtime base image.

FROM mcr.microsoft.com/dotnet/sdk:7.0 as build-env
WORKDIR /app

# steps to build the application
# is left out..

FROM mcr.microsoft.com/dotnet/aspnet:7.0 as runtime
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "MyExecutingAssembly.dll"]

What happens if we just replace the ENTRYPOINT with

CMD ["/bin/sh",  "-c",  "envsubst < /some-path/env.template.js > /some-other-path/env.js && exec nginx -g 'daemon off;'"]

You're obviously able to build the image, but will fail when you try to run a container with this image

/bin/bash: line 1: envsubst: command not found

Okay, that makes sense given that the image we're using mcr.microsoft.com/dotnet/aspnet:7.0 doesnt support envsubst.

The solution to this problem is to replace the base image with the alpine version, in our case mcr.microsoft.com/dotnet/aspnet:7.0.2-alpine3.17-amd64.

The entrypoint for the container will now look something like this:

CMD ["/bin/sh", "-c", "apk add gettext && envsubst < /some-path/env.template.js > /some-path/env.js && dotnet MyExecutingAssembly.dll"]

Using envsubst is a powerful way to read environment variables passed into a docker container and replace the values served as a javascript file. This articled showed how we can use this command when serving our frontend as static files from ASP.NET Cores web server Kestrel.

This week I learned that serializing and deserialzing the new structs included with .NET 6, DateOnly and TimeOnly, is not supported by System.Text.Json.JsonSerializer. You´ll need to write custom converters and include them in the settings. This an example implementation of these converters:

You´ll then need to include them in the JsonSerializerOptions

Or you could mark the properties in your type with the JsonConverterAttribute:  

Thanks for reading.

Microsoft recently announced that a new service for publish and subscribe scenarios has been made available in Azure. The new service has been branded Azure Web Pub Sub. The service is a managed, distributed version of SignalR that uses WebSockets to perform full duplex communication over a single TCP connection.

In terms of pricing the service comes with two different options. A Free tier which, according to Microsoft, should be used for Dev/testing purposes and a Standard Tier. The illustration below shows the difference between these two tiers as of 30/4-2021.

To create the service head over to the portal and search for Web PubSub Service. As always you need to select a resource group for the service, a name, a region and pricing tier. As of now the service is only available for deployment to East US, North Europe, Southeast Asia, West Europe and West US 2.

Show me the code!

Let's create two simple .NET 6 console applications, one server and one client. We will also use two NuGet packages, Azure.Messaging.WebPubSub and WebSockets.Client.

Both applications will connect to a specific Hub, a concept of separating messages, in the Azure Web Pub Sub service. The server will publish messages and the client will listen for messages in this Hub.

namespace Server
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            var connectionString = "<connection-string>";
            var hub = "test_hub";

            var client = new WebPubSubServiceClient(<connectionString, hub);
            await client.SendToAllAsync("Welcome to Azure Web PubSub!");
        }
    }
}

namespace Client
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            var connectionString = "";
            var hub = "test_hub";
           
            var client = new WebPubSubServiceClient(connectionString, hub);
            var url = client.GetClientAccessUri();
            
            using var websocketClient = new WebsocketClient(url);
            websocketClient.MessageReceived.Subscribe(message =>
            {
                Console.WriteLine($"Received message: {message.Text}");
            });

            await websocketClient.Start();
        }
    }
}

The connection string can be found under Keys in the service.

Start by running the client application: dotnet run Client.csproj and then the Server to publish a single message. dotnet run Server.csproj.
If everything is setup correct, the Client application will now print out Received message: Welcome to Azure Web PubSub!. We can also take a look in the portal to view traffic passing through the service

Wrapping up

This was a very brief introduction to Azure Web Pub Sub Service which Microsoft released yesterday, 29/4-2021. The service is a great for implement chat functionality, notifications, live dashboard and so on in your application.

Thanks for reading!

In part two exploring Azure Front door we'll take a look at routing rules and load balancing services in our backend pool. This article is based upon the application and resources we created in part one.

Lets do a quick recap and list out the resources we created in part 1. Running az resource list --resource-group frontdoor-example-rg -o table lists out all the resources we've created in our resource group

In the resource group we find four services: Azure Front Door, an appservice plan and two web apps hosting our .NET 5 application. Have you noticed Azure Front Door´s location? Its global and this isn't something we have to specify when we create the resource. This is really the core of Azure Front Door, to redirect your requests to the closest available service in terms of latency.

Azure Front Door has a concept of Backends, Backend Pools and Health Probes. A backend can be an Azure hosted web service, On-Prem service or even a non Azure service such as a web service running on Amazon EC2 that receives similar traffic.

A backend pool is a collection of backends. A backend pool controls how to load balance traffic based weight, priority and availablity. Availability are evaluated by configured Health Probes probing endpoints in each backend.

A health probe determines whether a backend is available or not by periodically sending probe requests over HTTP(S) to a specific endpoint in the backend. An example could be an API hosting a /health endpoint returning HTTP 200 if all dependent services are up and running as expected. If other status codes are returned, the service is considered unhealth and traffic will not be sent to this backend instance.

Let's list all health probes in our Azure Front Door service by running the following command on Azure CLI:

az network front-door probe list --front-door-name frontdoor-example --resource-group frontdoor-example-rg

[
  {
    "enabledState": "Enabled",
    "healthProbeMethod": "Head",
    "id": "/subscriptions/<subscription-guid>/resourcegroups/frontdoor-example-rg/providers/Microsoft.Network/Frontdoors/frontdoor-example/HealthProbeSettings/DefaultProbeSettings",
    "intervalInSeconds": 30,
    "name": "DefaultProbeSettings",
    "path": "/",
    "protocol": "Https",
    "resourceGroup": "frontdoor-example-rg",
    "resourceState": "Enabled",
    "type": "Microsoft.Network/Frontdoors/HealthProbeSettings"
  }
]

We can see that this health probe targets the root-path for our backends and that the health probe is the default one created when we created the Azure Front Door service. The default health probe will probe our backends every 30 seconds to determine health of the backend.

We can also see our load balancer by running the following command on Azure CLI

az network front-door load-balancing list --front-door-name frontdoor-example --resource-group frontdoor-example-rg

[
  {
    "additionalLatencyMilliseconds": 0,
    "id": "/subscriptions/<subscription-id>/resourcegroups/frontdoor-example-rg/providers/Microsoft.Network/Frontdoors/frontdoor-example/LoadBalancingSettings/DefaultLoadBalancingSettings",
    "name": "DefaultLoadBalancingSettings",
    "resourceGroup": "frontdoor-example-rg",
    "resourceState": "Enabled",
    "sampleSize": 4,
    "successfulSamplesRequired": 2,
    "type": "Microsoft.Network/Frontdoors/LoadBalancingSettings"
  }
]

There are a couple of things that we need to pay attention to here. AdditionalLatencyMilliseconds defines if requests will be sent to the fastest backend in terms of latency or if Azure Front Door should use Round Robin to schedule traffic between the fastest and the second fastests backend. In this particular case, with the value set to 0, traffic will always be routed to the fastes backend. SampleSize defines how many samples the health probe needs to send before we can evalute the health of a backend in a backend pool. SuccessfulSamplesRequired defines how many of the sampleSize that need to result in a HTTP 200 from the health probe to consider it health. An example:

Our health probe probes our backends health-endpoint every 15 seconds, our SampleSize is set to 4 and SucessfulSamplesRequired is set to 2. To mark our backend as healthy, at least 2 out of the 4 samples performed every 60 seconds(15 x 4) has to return HTTP 200.

Routing and load balancing requests

Lets take a look at the different routing and load balancing mechanisms that Azure Front Door has to offer.

Weighted and prioritized routing

Within a backend pool we can load balance requests based on priority and/or a specified weight. Priority can be a value between 1 and 5. A lower value means higher priority. This is also refered to as Active/Passive deployment. In case a backend in the backend pool with the highest priority is marked as unhealth by the Health Probe, traffic will be routed to the backend with the seconds highest configured priority.

Weighted routing on the other hand is a concept of distributing traffic based on a value between 0 and 1000 with a Round Robin scheduling mechanism. The higher the weight is, the more traffic will be routed to the backend.

But what happends if multiple backends in a backend pool have configured the same priority, but different weight?

As long as our health probe has marked all backends as healthy and available in terms of meeting the accepted latency, requests will distributed with round robin based on the weight. To demonstrate this, let's list out our default backend pool and the configuration for each backend:

az network front-door backend-pool backend list \
--pool-name DefaultBackendPool \
--front-door-name frontdoor-example \
--resource-group frontdoor-example-rg \
--output table

Running this command from Azure CLI will list the following:

As you can see, both of the backends share the same priority, but differs in weight. For this particular configuration approx. 1/10th of the traffic will be distributed to frontdoorwebapp01.azurewebsites.net and the rest to frontdoorwebapp02.azurewebsites.net. Running for instance cURL 20 times on our Azure Front Door url will hit frontdoorwebapp01 approx. two times.

Routing based on content in the HTTP request

Another feature of Azure Front Door is to route traffic to different backend pools based on the http request. Both of our backends are located in the same backend pool, so lets create a new backend pool and move one of the backends to this backend pool.

Create a new backend pool

az network front-door backend-pool create \
--address frontdoorwebapp02.azurewebsites.net \
--front-door-name frontdoor-example \
--load-balancing DefaultLoadBalancingSettings \
--name second-backend-pool \
--probe DefaultProbeSettings \
--resource-group frontdoor-example-rg

In this particular example we are re-using the load balancer and health probe from the default backend pool. You might want to create separate load balancers and probe settings per backend pool. We've also added the FQDN for our web app to this backend pool. Lets remove this one from the other default backend pool

OBS: the parameter --index starts at 1, not 0.

az network front-door backend-pool backend remove \
--front-door-name frontdoor-example \
--resource-group frontdoor-example-rg \
--pool-name DefaultBackendPool \
--index 1

Until now we have create a new backend pool and moved frontdoorwebapp02to this new backend pool. Lets start by creating a new Rule from the Rules Engine Configuration

These two rules are pretty straight forward. If the request has a http header with key x-backend-name equal App01, the request will be forwarded to backend pool DefaultBackendPool. If the header equals to App02 the request will be redirected to the backendpool with name second-backend-pool.

As a last thing we'll need to associate this rule with a routing rule and then assign the routing rule to a backend pool. Lets do that now:

az network front-door routing-rule create \
--front-door-name frontdoor-example \
--name forwardRequestRoutingRule \ 
--resource-group frontdoor-example-rg \
--route-type Forward \
--backend-pool second-backend-pool \
--rules-engine HttpHeaderForwardRule \
--frontend-endpoints DefaultFrontendEndpoint

Lets try it out!

curl -s -H "x-backend-name: App02" -s https://frontdoor-example.azurefd.net
> Greetings from 'Web App 02'

curl -s -H "x-backend-name: App01" -s https://frontdoor-example.azurefd.net
> Greetings from 'Web App 01'

Wrapping up

In this article series we've discovered how to load balance and to create routing rules with Azure Front Door. We've looked at how to override routing to different backend pools by create a custom rule that inspects the HTTP header and forwards the request.

Thanks for reading!

Azure Front Door is a global and scalable entry point that sits between your application and the internet. The service uses edge networks to route traffic to your fastest and and most available backend service. In this article series, in two parts, we'll discover the capabilities and possibilities by using Azure Front Door as a load balancer and routing service in front of two Azure Web Apps hosting a simple application running .NET 5.

Azure Front door is one of four load balancing solutions available in Azure. However, only two of the solutions are meant to load balance HTTP requests, Azure Front Door and Application Gateway. One of the most important differences between Azure Application Gateway and Azure Front Door is that the latter is globally scaled by default and can very quickly failover to a secondary resource in case of a regional outage. Application Gateway on the other hand needs to be deployed in different regions within your subscription meaning that it operates regionally. Another significant difference is that network traffic passes through Azure Front Door and therefore you can capture and create routing rules based properties within the HTTP request such as the HTTP Headers, request protocol, request body etc.

If you are on the verge of choosing one of the four Load balancing solutions Microsoft Azure has to offer, but can't really decide which suits your use case the best, I really recommend this flow chart from Microsoft:

Show me the code!

To demonstrate Azure Front Door, we will create a simple .NET 5 application, deploy two web app instances running the app, create and configure our Azure Front Door service to point to the Web Apps. Our application reads an environment variable and returns it in case of a HTTP GET request

public class Startup
{
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.Use(async (ctx, next) =>
        {
            if(ctx.Request.Method.ToLower() == "get")
            {
                var appName = Environment.GetEnvironmentVariable("AppName");
                await ctx.Response.WriteAsync($"Greetings from '{appName}'");
            }
        });
    }
}

The application gets deployed to Azure whenever a push is done to main. The workflow file is based on my article about GitHub Actions and looks like this:

name: "Build app and deploy to Azure"
on: [push]

jobs:
  build:
    name: 'Build and Deploy a ASP.NET 5 App to Azure App Service'
    runs-on: 'ubuntu-latest'
    steps:
      - name: 'Checkout Code from Repository' 
        uses: actions/checkout@v2
      - name: 'Set up .NET 5.0.x'
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '5.0.x'
      - name: 'Publish a Release of the App'
        run: |
          cd src/
          dotnet publish -c Release --output '../published-app'
      - name: 'Deploy to Azure App Service: Frontdoor-web-app'
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'frontdoorwebapp01'
          publish-profile: ${{ secrets.PUBLISH_PROFILE_APP1 }}
          package: ./published-app
      - name: 'Deploy to Azure App Service: Frontdoor-secondary-web-app'
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'frontdoorwebapp02'
          publish-profile: ${{ secrets.PUBLISH_PROFILE_APP2 }}
          package: ./published-app

Before we can run the workflow, we'll need to create the resources in Azure. Lets do that now.

Create resources in Azure

We'll first start by signing into the Azure Portal by running the following command in Azure CLI az login. Resources in Azure lives in Resource Groups. Lets create one:

az group create --name 'frontdoor-example-rg'

In our resource group we'll create four resources. An App Service Plan, two Azure Web Apps and Azure Front Door. Lets start by creating the App Service Plan

az appservice plan create \
--name 'frontdoor-example-appserviceplan' \
--resource-group 'frontdoor-example-rg' \
--sku FREE

Then we'll two web apps in our App Service Plan.

az webapp create \
--name 'frontdoorwebapp01' \
--resource-group 'Frontdoor-example-rg' \ 
--plan 'frontdoor-example-appserviceplan'

az webapp create \
--name 'frontdoorwebapp02' \
--resource-group 'Frontdoor-example-rg' \ 
--plan 'frontdoor-example-appserviceplan'

Lets wait until the deployment have completed and then update the environment variables for both apps:

az webapp config appsettings set \
-g Frontdoor-example-rg \
-n frontdoorwebapp01 \
--settings AppName="Web App 01"

az webapp config appsettings set \
-g Frontdoor-example-rg \
-n frontdoorwebapp02 \
--settings AppName="Web App 02"

Lets test our apps by running a cURL operation against both endpoints.

curl -s https://frontdoorwebapp01.azurewebsites.net
> Greetings from 'Web App 01'

curl -s https://frontdoorwebapp02.azurewebsites.net
> Greetings from 'Web App 02'

Perfect! Lets create and configure Azure Front Door!

Create and configure Azure Front Door

Again we are working from our terminal and Azure CLI. Until now we have created a resource group with an app service plan with two web apps. Lets create and configure Azure Front Door which will act as a Load Balancer between internet and our web apps. Before we start you probably need to add the front-door extension to your Azure CLI. az extension add --name front-door.

We're ready to create an Azure Front Door resource:

az network front-door create \
--resource-group frontdoor-example-rg \
--name frontdoor-example \
--accepted-protocols "Http" "Https" \
--backend-address frontdoorwebapp01.azurewebsites.net

Azure Front Door uses the term backend pool which consists of several backend-addresses that points to other services, in our case two Azure Web Apps. Deployment of Azure Front Door can take several minutes to complete. Once the service has been created we can browse it from http(s)://<front-door-name>.azurefd.net

Lets try to perform a cURL operation against the Front Door Service.

curl -s https://frontdoor-example.azurefd.net/
> Greetings from 'Web App 01'

As we only have added WebApp01 to the backend-pool, we'll never get routed to WebApp02. Lets do something about it!

az network front-door backend-pool backend add \
--address frontdoorwebapp02.azurewebsites.net \
--front-door-name "frontdoor-example" \
--pool-name "DefaultBackendPool" \
--resource-group "frontdoor-example-rg"

Now we've added both of our apps to the backend pool. Lets try to stop WebApp01 and see what happens:

az webapp stop --name frontdoorwebapp01 \
--resource-group Frontdoor-example-rg

Perform another cURL operation against our Front Door:

curl -s https://frontdoor-example.azurefd.net/
> Greetings from 'Web App 02'

As we can see Front Door redirected to our secondary app, as we stopped WebApp01. This is also visible from the portal:

Thats it. In this article we've demonstrated a really simple way to load balance and automatically failover to a secondary application. In the next article we'll take a look at how to configure routing rules and create custom routing rules in Azure Front Door.

Thanks for reading!

Introduction

GitHub Actions is probably my favourite DevOps tool out there due to its extensibility and tight integration with platform itself. In this article we will take a look at how deploy a simple .NET 5 web application to an App Service in Azure. This article assume that you have both dotnet and Azure CLI installed on your system. If thats not the case, stop here and install it.

The .NET 5 application

Our application is probably the simplest .NET web application you have ever created. Lets open our terminal and create the following folder structure for our project.

project-name
└───src
└───.github
│   └───workflows
│       │   deployment.yml

Create a new .NET 5 project inside the src folder by running the following command. dotnet new web -n 'my-project-name' -f net5.0

Open the project in your favorite code editor tool, find Startup.cs and change the content to:

public class Startup
{
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.Use(async (ctx, next) =>
        {
            if(ctx.Request.Method.ToLower() == "get")
            {
                await ctx.Response.WriteAsync("Hello, world!");
            }
        });
    }
}

Like I said; the simplest app you've ever created. It's time to push everything to your GitHub repository. The next step is to create our App Service in Azure.

Create the Azure App Service

1. Log into your Azure Account by typing az login to bring up the sign-in window to the Azure Portal. Select your account and login.

2. Create a new Resource Group az group create -n 'your-name-rg' -l 'westeurope'

3. Create an App Service Plan for your web app az appservice plan create --name 'my-appservice-plan-name' --resource-group 'your-name-rg' --sku FREE

4. Create an Web App az webapp create --name 'web-app-name' --resource-group 'your-name-rg' --plan 'my-appservice-plan-name'

5. We need to get the publish profile for our web app. Open your browser, navigate to the Azure Portal and find your WebApp. Press the 'Get Publish Profile' button to download it.
   

Create secrets for GitHub Actions

Before we start editing our .github/deployment.yml file, lets upload the Publish profile file to GitHub secrets so that we can access it from our workflow.

1. Find your GitHub Repository Settings tab
2. Select 'Secrets' from the menu.
3. Press 'New Repository Secret'
4. Under 'Name' enter PUBLISH_PROFILE and paste the content of the downloaded publish profile file into 'Value' section.

Create the workflow file

Open the file we created under .github/workflows in your prefered code editor or from GitHub and past in the following.

name: "Build app and deploy to Azure"
on: [push]

jobs:
  build:
    name: 'Build and Deploy a ASP.NET 5 App to Azure App Service'
    runs-on: 'ubuntu-latest'
    steps:
      - name: 'Checkout Code from Repository' 
        uses: actions/checkout@v2
      - name: 'Set up .NET 5.0.x'
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '5.0.x'
      - name: 'Publish a Release of the App'
        run: |
          cd src/
          dotnet publish -c Release --output '../published-app'
      - name: 'Deploy to Azure App Service'
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'web-app-name'
          publish-profile: ${{ secrets.PUBLISH_PROFILE }}
          package: ./published-app

Lets go through the file step by step.

1. First we define a name for this workflow. Secondly we define when the workflow should run. In this particular case, everytime a push is done against any branches within the repository. You can read more about the on:-keyword from the GitHub docs
2. The next step is to define jobs. A GitHub Actions Workflow can consist of many jobs, whereas one job can have multiple steps and each step can run either a shell command or an action. You can either create your own actions or use action created by others. All of the actions can be found on GitHub Marketplace. In this particular example we will use a combination of shell commands and actions to deploy our app to Azure App Service.
3. A job has a name, a machine to run on, either self-hosted or GitHub-hosted, and steps. We choose to run this workflow on a GitHub hosted machine running the latest supported version of ubuntu.
4. Our first step is to checkout code from the repository
5. Next we install dotnet 5.0.x onto the machine running our build by utilizing actions from GitHub Marketplace.
6. Then we run a shell command to navigate to the src-folder and then running dotnet publish which will restore NuGet-packages and create a deployable artifact to the specified directory.
7. Its now time to publish our app to Azure. Again, we're using an action from the GitHub Marketplace called Azure WebApp. This action has three parameters specificed by the 'with:'-keyword. The name of our App Service in Azure, the publish profile we added to GitHub Secrets and a package artifact which was the result from the `dotnet publish´.

Thats it. Remember that each time you do a push to any branch in the repository, this worflow will run. You probably want to change this at a later stage to specify a particular branch. Another element to consider is to run your tests as a step before deploying the app to Azure. This can be achieved by running dotnet test as a shell command.

The result

Go back to your App Service in Azure, Select the 'Overview' tab and find the url for your app. Browse this url and you will see the text 'Hello, world' outputted in your browser.

The source code can be found here

Thanks for reading!

Lets face it: Exceptions happens, it's about how we deal with them. There are obviously several ways to propagate the error back to consumers of our api. This article demonstrates my preferred way.
I've seen a lot of code similar to this:

public async Task<SomeClass> GetByIdAsync(Guid id) 
{
    SomeClass item = null;
    try 
    {
        item = await _somePersistence.GetAsync(id);
    }
    catch(Exception e)
    {
        Logger.LogException(e);
    }

    return item;
}

There are several things that worries me about such code. null can mean different things in the context of this method. You cannot tell whether an exception occured or that _somePersistence returned null. Lets just be more explicit in the way we communicate our intentions.

public async Task<SomeClass> GetByIdAsync(Guid id) 
{
    SomeClass item = null;
    try 
    {
        item = await _somePersistence.GetAsync(id);
        if(item == null)
            thrown new NotFoundException($"Could not find item {id}");
    }
    catch(Exception e)
    {
        Logger.LogException(e);
    }

    return item;
}

The intention are now expressed in a more explicity way by throwing an exception. The only problem now is that the exception doesn't reach the caller of this method as our catch-statement catches every exception. Again, be more specific. Do you know how to handle any exceptions that can occur from the _somePersistence.GetAsync(id) method? No? Why bother to handle it? If the answer is "I dont want my application to crash", use a global exception handler. For ASP.NET Core Web API we have a filter that can help us with that.

IExceptionFilter - Why and where to use it

Instead of dealing with HTTP Status Codes in your controller methods we can take advantage of the extensibility offered by the framework.
Lets assume that your api uses the GetById method above, but its rewritten to be expressive.

public async Task<SomeClass> GetByIdAsync(Guid id) 
{
    var item = await _somePersistence.GetAsync(id);
    if(item == null)
        thrown new NotFoundException($"Could not find item {id}"); 
    
    return item;
}

Your controller method uses this method the following way:

[HttpGet]
[Route("{id}")]
public Task<IHttpActionResult> Get([FromRoute]Guid id)
{
   try 
   {
       return Ok(await _repository.GetByIdAsync(id));
   }
   catch(NotFoundException e)
   {
       return NotFound();
   }
}

Handling errors this way is not very flexible, nor is it convenient. Remove all such exception-handling and introduce an implementation of IExceptionFilter.

An example implementation

Create a new class implementation `IExceptionFilter``

public class ExceptionFilter : IExceptionFilter
{
    public void OnException(ExceptionContext context)
    {
        var exception = context.Exception;
        if(exception is NotFoundException e)
        {
            context.Result = new JsonResult(e.Message)
            {
                StatusCode = (int)HttpStatusCode.NotFound;
            };
        }
    }
}

Register the filter in your Startup.cs class

services.AddMvc(options =>
{
    options.Filters.Add<ExceptionFilter>();
});

Now you can remove try-catches from your api-controllers and leave the exception logic to be handled by this filter. Happy days!

PS: I would also recommend to log exceptions in this filter. You can resolve implementation registered in you dependency injection container of choice by writing context.HttpContext.RequestServices.GetService(typeof(...));

Thanks for reading!