AWS, Azure, Feature Flags

Feature Flag Freedom: Using OpenFeature with AWS & Azure

Introduction

Feature flags have revolutionised how teams deploy and test features, allowing controlled rollouts, A/B testing, and quick toggling of functionality. But teams adopting feature flagging often face vendor lock-in, making it difficult to switch providers or maintain a consistent implementation across their codebase.

I was recently catching up on some talks from Kubecon 2025 on the CNCF YouTube channel and there were some talks around Feature Flags and OpenFeature. Curious about its potential, I decided to take a deeper dive into OpenFeature to understand its advantages.

OpenFeature is a CNCF project that provides a standardised SDK, allowing you to integrate with custom logic or external vendors. OpenFeature abstracts away the complexities of working with different providers, ensuring flexibility, portability, and consistency in how applications manage flags.

The architecture looks like this (taken from their website)

OpenFeature supports multiple feature flag providers, ensuring flexibility across different ecosystems. Some of the current providers include:

  • Flagd – An open-source remote flag evaluation service.
  • LaunchDarkly – A popular enterprise feature flag management platform.
  • Flipt – A lightweight, self-hosted feature flag solution.
  • GrowthBook – A powerful open-source A/B testing and feature flagging tool.
  • These are just a few examples, with many more integrations available.

OpenFeature supports creating custom Providers that allow developers to build their own providers for their feature flag management or even connect to providers not currently supported by OpenFeature.

Since OpenFeature provides a consistent API, teams can easily switch providers without modifying their application logic, making feature flag management truly flexible.

These days I use a mix Azure and AWS and wondered how OpenFeature would work with Azure App Configuration and AWS AppConfig, so in this post, we’ll explore:

  • How OpenFeature eliminates vendor lock-in for feature flags.
  • Implementing feature flags with OpenFeature and utilising cloud services Azure App Configuration and AWS AppConfig.
  • How you can use OpenFeature in .NET and Python applications with a couple of basic examples

This post assumes you already have an instance of Azure App Configuration and/or AWS App Config set up. If not, refer to their respective documentation for provisioning.

Let’s dive in and see what it’s all about! 🚀

Getting Started with OpenFeature

Adding OpenFeature to code is fairly simple, the documentation is well structured with clear examples for multiple languages. While OpenFeature supports multiple languages including Go, Java, and Rust—this post will focus on its implementation in .NET and Python

Here’s a basic implementation using OpenFeature in a console application, demonstrating how to register a provider and retrieve flag values

dotnet add package OpenFeature

Following the documentation the basic code in a console app would look something like this in .NET:

using OpenFeature;
using OpenFeature.Model;

 // Register your feature flag provider
 await Api.Instance.SetProviderAsync(new InMemoryProvider());

// Create a new client
FeatureClient client = Api.Instance.GetClient();

// Retrieve and evaluate the flag
var feature1Enabled = await client.GetBooleanValueAsync("feature1", false);
Console.WriteLine(feature1Enabled ? "Flag is Enabled!" : "Flag is Disabled!");

and in Python:

pip install openfeature-sdk
from openfeature import api
from openfeature.provider.in_memory_provider import InMemoryFlag, InMemoryProvider

feature_flags = {
  "feature1": InMemoryFlag("on", {"on": True, "off": False})
}

# Register your feature flag provider
api.set_provider(InMemoryProvider(feature_flags))

# Create a client
client = api.get_client()

# Retrieve and evaluate the flag
feature1_enabled = client.get_boolean_value("feature1", False)
print("Flag is Enabled!" if feature1_enabled else "Flag is Disabled!")

Exploring OpenFeature with Azure App Configuration

With the setup in place, let’s explore how OpenFeature integrates seamlessly with Azure App Configuration to manage feature flags.

The below image shows some sample feature flags defined in Azure App Configuration ready to use for this demo

Azure App Configuration Feature Flags

Azure App Configuration provides centralised configuration management, versioning, and built-in feature flag support, making it a powerful choice for dynamic application settings. To evaluate feature flags within Azure App Configuration, Microsoft recommends using the Feature Management Library, which provides a robust and flexible way to manage flag states.

Let’s add the packages for Azure App Configuration

dotnet add package Microsoft.Extensions.Configuration
dotnet add package Microsoft.Extensions.Configuration.AzureAppConfiguration

After some looking around at the OpenFeature sdk Contrib in GitHub, I found there was already a provider for the FeatureManagement and found a preview version on Nuget, so let’s add that.

dotnet add package OpenFeature.Contrib.Provider.FeatureManagement --version 0.1.0-preview

It is good practice to use Azure Identity for connecting to Azure App Configuration but for this demo we are just going to use the ConnectionString. You can get the connection string from the Azure Portal.

Let’s add the additional code to use the Feature Manager Provider

using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Configuration.AzureAppConfiguration;
using OpenFeature;
using OpenFeature.Contrib.Providers.FeatureManagement;

IConfigurationRefresher refresher = null;
var builder = new ConfigurationBuilder();
builder.AddAzureAppConfiguration(async options =>
{
    var endpoint = "Endpoint=https://flagsdemo-dev.azconfig.io;Id=xxxxxx;Secret=xxxxxxxxxxxxxxxxxxxx";
    options.Connect(endpoint)
        .ConfigureRefresh(refresh =>
        {
            refresh.Register($".appconfig.featureflag/feature1")
                .SetRefreshInterval(TimeSpan.FromSeconds(30));
        });
    refresher = options.GetRefresher();
});
var config = builder.Build();

// Register your feature flag provider
await Api.Instance.SetProviderAsync(new FeatureManagementProvider(config));

// Create a new client
FeatureClient client = Api.Instance.GetClient();

// Get the flag value
var feature1Enabled = await client.GetBooleanValueAsync("feature1", false);
Console.WriteLine(feature1Enabled ? "Flag is Enabled!" : "Flag is Disabled!");

Running the code gives the same value as previously “Flag is Disabled!”, so let’s enable the flag via the Azure Portal

Using the contrib provider, we encountered an issue where basic feature flags were not being evaluated correctly, consistently returning ‘Flag is Disabled!’ regardless of configuration. After submitting a PR to address this issue, we’ll have to use a workaround and create a new provider, which, in a way, is a great opportunity to showcase just how simple it is to implement a custom provider for feature flag management.

Following the instructions from the OpenFeature documentation we created a provider, implementing the bare minimum and adding the FeatureManagement Library

dotnet add package Microsoft.FeatureManagement
using Microsoft.Extensions.Configuration;
using Microsoft.FeatureManagement;
using OpenFeature;
using OpenFeature.Model;

public class FeatureManagementProvider : FeatureProvider
{
    private readonly FeatureManager _featureManager;

    public FeatureManagementProvider(IConfiguration configuration)
    {
        _featureManager = new FeatureManager(new ConfigurationFeatureDefinitionProvider(configuration), new FeatureManagementOptions());

    }
    public override Metadata GetMetadata()
    {
        return new Metadata("Feature Management Provider");
    }

    public override async Task<ResolutionDetails<bool>> ResolveBooleanValueAsync(string flagKey, bool defaultValue, EvaluationContext? context = null, CancellationToken cancellationToken = default)
    {
        var enabled = await _featureManager.IsEnabledAsync(flagKey, context, cancellationToken);
        return new ResolutionDetails<bool>(flagKey, enabled);
    }

    public override Task<ResolutionDetails<string>> ResolveStringValueAsync(string flagKey, string defaultValue, EvaluationContext? context = null, CancellationToken cancellationToken = default)
    {
        throw new NotImplementedException();
    }

    public override Task<ResolutionDetails<int>> ResolveIntegerValueAsync(string flagKey, int defaultValue, EvaluationContext? context = null,
        CancellationToken cancellationToken = new CancellationToken())
    {
        throw new NotImplementedException();
    }

    public override Task<ResolutionDetails<double>> ResolveDoubleValueAsync(string flagKey, double defaultValue, EvaluationContext? context = null, CancellationToken cancellationToken = default)
    {
        throw new NotImplementedException();
    }

    public override Task<ResolutionDetails<Value>> ResolveStructureValueAsync(string flagKey, Value defaultValue, EvaluationContext? context = null, CancellationToken cancellationToken = default)
    {
        throw new NotImplementedException();
    }
}

Using this new provider the code now returns correctly “Flag is Enabled!” as expected, the code is far from production ready but certainly shows how simple adding a new Provider is.

To make feature flag updates more visible in real time, let’s introduce a refresh interval and a polling mechanism. The refresh interval will be set to 30 seconds, while a loop running every 10 seconds will control when the app sends requests to the Azure App Configuration Service.

using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Configuration.AzureAppConfiguration;
using OpenFeature;

IConfigurationRefresher refresher = null;
var builder = new ConfigurationBuilder();
builder.AddAzureAppConfiguration(async options =>
{
    var endpoint = "Endpoint=https://flagsdemo-dev.azconfig.io;Id=xxxxxx;Secret=xxxxxxxxxxxxxxxxxxxx";
    options.Connect(endpoint)
        .ConfigureRefresh(refresh =>
        {
            refresh.Register($".appconfig.featureflag/feature1")
                .SetRefreshInterval(TimeSpan.FromSeconds(30));
        });
    refresher = options.GetRefresher();
});
var config = builder.Build();

// Register your feature flag provider
await Api.Instance.SetProviderAsync(new FeatureManagementProvider(config));

// Create a new client
FeatureClient client = Api.Instance.GetClient();

// Get the flag value
while (!Console.KeyAvailable)
{
    if (refresher != null)
    {
        await refresher.TryRefreshAsync();
        Console.WriteLine("Configuration refreshed at: " + DateTime.UtcNow);
    }
    var feature1Enabled = await client.GetBooleanValueAsync("feature1", false);
    Console.WriteLine(feature1Enabled ? "Flag is Enabled!" : "Flag is Disabled!");
    Thread.Sleep(TimeSpan.FromSeconds(10));
}
Console.ReadKey();
Console.WriteLine("Application stopped.");

So, if the flag is enabled and then disabled during the run we should see the change

Let’s see what the Python code looks like for the same setup

We’ll need to install some additional packages for Azure App Configuration and Feature Management

pip install featuremanagement azure-appconfiguration-provider
import asyncio
from openfeature import api
from featureManagementProvider import FeatureManagementProvider
import azure.appconfiguration.provider
from datetime import datetime, timezone
from time import sleep

async def open_feature():
  # Register your feature flag provider
  endpoint = "Endpoint=https://flagsdemo-dev.azconfig.io;Id=xxxxxx;Secret=xxxxxxxxxxxxxxxxxxxx"
  config = azure.appconfiguration.provider.load(connection_string=endpoint,refresh_interval=30, feature_flag_enabled=True, feature_flag_refresh_enabled=True)
  api.set_provider(FeatureManagementProvider(config))
  client = api.get_client()

  # create a client
  client = api.get_client()
  print(f"feature1 is ", await client.get_boolean_value_async("feature1", False))
  while True:
    config.refresh()
    print("Configuration refreshed at: " + datetime.now(timezone.utc).strftime("%m/%d/%Y, %H:%M:%S"))    
    print(f"feature1 is ", await client.get_boolean_value_async("feature1", False))
    sleep(10)

async def main():
    await open_feature()

asyncio.run(main())

As before following the OpenFeature documentation we created a provider with the bare minimum implementation

from typing import Any, List, Optional, Dict, Union

from openfeature.evaluation_context import EvaluationContext
from openfeature.flag_evaluation import FlagResolutionDetails
from openfeature.hook import Hook
from openfeature.provider import AbstractProvider, Metadata
from featuremanagement import FeatureManager

class FeatureManagementProvider(AbstractProvider):

    def __init__(self, configuration: Dict[str, Any]):
       self.feature_manager = FeatureManager(configuration)
    def get_metadata(self) -> Metadata:
        return Metadata(name="FeatureManagement Provider")

    def get_provider_hooks(self) -> List[Hook]:
        return []

    def resolve_boolean_details(
        self,
        flag_key: str,
        default_value: bool,
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[bool]:
        enabled = self.feature_manager.is_enabled(flag_key)
        return FlagResolutionDetails(value=enabled)

    def resolve_string_details(
        self,
        flag_key: str,
        default_value: str,
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[str]:
        ...

    def resolve_integer_details(
        self,
        flag_key: str,
        default_value: int,
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[int]:
        ...

    def resolve_float_details(
        self,
        flag_key: str,
        default_value: float,
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[float]:
        ...

    def resolve_object_details(
        self,
        flag_key: str,
        default_value: Union[dict, list],
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[Union[dict, list]]:
        ...

Exploring OpenFeature with AWS App Config

One of OpenFeature’s biggest strengths is its flexibility, switching to another provider requires only minor configuration updates. Here’s how to transition from Azure App Configuration to AWS App Config

Below is a screenshot of sample feature flags configured in AWS App Config, ready for use in this demo

AWS App Config Feature Flags

in .NET we would need to add a new package

 dotnet add package AWSSDK.AppConfigData

Then remove the ConfigurationBuilder, add the AWS App Config Data Client and set the new provider to use AwsAppConfigProvider

using Amazon.AppConfigData;
using Amazon.Runtime;
using OpenFeature;

var awsClient = new AmazonAppConfigDataClient(new BasicAWSCredentials("xxxxxxxx", "xxxxxxxx"), Amazon.RegionEndpoint.EUWest2);

// Register your feature flag provider
await Api.Instance.SetProviderAsync(new AwsAppConfigProvider(awsClient, "demo-app", "xxxxxx", "demo"));

// Create a new client
FeatureClient client = Api.Instance.GetClient();

// Get the flag value
while (!Console.KeyAvailable)
{
    var feature1Enabled = await client.GetBooleanValueAsync("feature1", false);
    Console.WriteLine(feature1Enabled ? "Flag is Enabled!" : "Flag is Disabled!");
    Thread.Sleep(TimeSpan.FromSeconds(10));
}

Console.ReadKey();
Console.WriteLine("Application stopped.");

and in Python we would need to add a new package

pip install boto3

Before running the Python implementation, set the following environment variables to authenticate with AWS:

export AWS_DEFAULT_REGION=eu-west-2
export AWS_ACCESS_KEY_ID="xxxxxxxxxxxxxx"
export AWS_SECRET_ACCESS_KEY="xxxxxxxxxxxxxx"

and update the provider to use AwsAppConfigProvider

import asyncio
from openfeature import api
from datetime import datetime, timezone
from time import sleep
from awsAppConfigProvider import AwsAppConfigProvider

async def open_feature():
  # Register your feature flag provider
  
  api.set_provider(AwsAppConfigProvider("demo-app", "72ig5p6", "demo"))
  client = api.get_client()

  # create a client
  client = api.get_client()
  print(f"feature1 is ", await client.get_boolean_value_async("feature1", False))
  while True:
    print("Configuration refreshed at: " + datetime.now(timezone.utc).strftime("%m/%d/%Y, %H:%M:%S"))    
    print(f"feature1 is ", await client.get_boolean_value_async("feature1", False))
    sleep(10)

async def main():
    await open_feature()

asyncio.run(main())

As before the code is far from production ready but still demonstrates how easy it is to integrate a new provider with OpenFeature, here’s a minimal AWS App Config provider for both .NET and Python:

in .NET

using Amazon.AppConfigData;
using Amazon.AppConfigData.Model;
using OpenFeature;
using OpenFeature.Model;
using System.Text;
using System.Text.Json;
using System.Text.Json.Serialization;

internal class FeatureFlag
{
    public bool Enabled { get; set; }

    [JsonPropertyName("_variant")]
    public string Variant { get; set; }
}

public sealed class AwsAppConfigProvider : FeatureProvider
{
    private readonly IAmazonAppConfigData _client;
    private readonly StartConfigurationSessionRequest _sessionRequest;

    public AwsAppConfigProvider(IAmazonAppConfigData client, string applicationIdentifier, string configurationProfileIdentifier, string environmentIdentifier)
    {
        ArgumentNullException.ThrowIfNull(client);

        _client = client;
        _sessionRequest = new StartConfigurationSessionRequest
        {
            ApplicationIdentifier = applicationIdentifier,
            ConfigurationProfileIdentifier = configurationProfileIdentifier,
            EnvironmentIdentifier = environmentIdentifier
        };
    }

    public override Metadata? GetMetadata()
    {
        return new Metadata("AWS Config Provider");
    }

    public override async Task<ResolutionDetails<bool>> ResolveBooleanValueAsync(string flagKey, bool defaultValue, EvaluationContext? context = null,
        CancellationToken cancellationToken = new CancellationToken())
    {
        var sessionResponse = await _client.StartConfigurationSessionAsync(_sessionRequest);


        var configRequest = new GetLatestConfigurationRequest
        {
            ConfigurationToken = sessionResponse.InitialConfigurationToken
        };

        var configResponse = await _client.GetLatestConfigurationAsync(configRequest);

        using var memoryStream = configResponse.Configuration;
        var buffer = new byte[memoryStream.Length];
        await memoryStream.ReadExactlyAsync(buffer, 0, buffer.Length, cancellationToken);
        var configData = Encoding.UTF8.GetString(buffer);

        var flags = JsonSerializer.Deserialize<Dictionary<string, FeatureFlag>>(configData, new JsonSerializerOptions { PropertyNamingPolicy = JsonNamingPolicy.CamelCase }) ?? new Dictionary<string, FeatureFlag>();

        var enabled = flags[flagKey].Enabled;
        return new ResolutionDetails<bool>(flagKey, enabled);
    }

    public override Task<ResolutionDetails<string>> ResolveStringValueAsync(string flagKey, string defaultValue, EvaluationContext? context = null,
        CancellationToken cancellationToken = new CancellationToken())
    {
        throw new NotImplementedException();
    }

    public override Task<ResolutionDetails<int>> ResolveIntegerValueAsync(string flagKey, int defaultValue, EvaluationContext? context = null,
        CancellationToken cancellationToken = new CancellationToken())
    {
        throw new NotImplementedException();
    }

    public override Task<ResolutionDetails<double>> ResolveDoubleValueAsync(string flagKey, double defaultValue, EvaluationContext? context = null,
        CancellationToken cancellationToken = new CancellationToken())
    {
        throw new NotImplementedException();
    }

    public override Task<ResolutionDetails<Value>> ResolveStructureValueAsync(string flagKey, Value defaultValue, EvaluationContext? context = null,
        CancellationToken cancellationToken = new CancellationToken())
    {
        throw new NotImplementedException();
    }
}

in Python

from typing import List, Optional, Union

from openfeature.evaluation_context import EvaluationContext
from openfeature.flag_evaluation import FlagResolutionDetails
from openfeature.hook import Hook
from openfeature.provider import AbstractProvider, Metadata
import boto3
import json
from io import BytesIO

class AwsAppConfigProvider(AbstractProvider):

    def __init__(self, application_identifier: str, configuration_profile_identifier: str, environment_identifier: str):       
       self.client = boto3.client('appconfigdata')
       self.app_id = application_identifier
       self.profile_id = configuration_profile_identifier
       self.env_id = environment_identifier
    def get_metadata(self) -> Metadata:
        return Metadata(name="AWS App Config Provider")

    def get_provider_hooks(self) -> List[Hook]:
        return []

    def resolve_boolean_details(
        self,
        flag_key: str,
        default_value: bool,
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[bool]:
        
        response = self.client.start_configuration_session(
            ApplicationIdentifier=self.app_id,
            EnvironmentIdentifier=self.env_id,
            ConfigurationProfileIdentifier=self.profile_id
        )
        
        session_token = response['InitialConfigurationToken']
        config_response = self.client.get_latest_configuration(
            ConfigurationToken=session_token
        )

        # Extract the streaming body
        streaming_body = config_response['Configuration']
        config_data = json.load(BytesIO(streaming_body.read()))        
        feature_details = config_data.get(flag_key, {})
        enabled = feature_details.get("enabled", default_value)
        
        return FlagResolutionDetails(value=enabled)

    def resolve_string_details(
        self,
        flag_key: str,
        default_value: str,
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[str]:
        ...

    def resolve_integer_details(
        self,
        flag_key: str,
        default_value: int,
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[int]:
        ...

    def resolve_float_details(
        self,
        flag_key: str,
        default_value: float,
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[float]:
        ...

    def resolve_object_details(
        self,
        flag_key: str,
        default_value: Union[dict, list],
        evaluation_context: Optional[EvaluationContext] = None,
    ) -> FlagResolutionDetails[Union[dict, list]]:
        ...

The code would need to be modified to be production ready but it is enough to get started with an integration.

Conclusion: Feature Flag Freedom Starts Here

In this post, we explored how OpenFeature provides a vendor-neutral approach to feature flags, allowing teams to integrate cloud services like Azure App Configuration and AWS AppConfig without vendor lock-in. By adopting OpenFeature, developers gain flexibility, consistency, and scalability in managing feature flags across different environments and maintain the ability to change providers or create something custom or homegrown.

Beyond simple on/off switches, feature flags can be far more dynamic. Multi-variant flags unlock capabilities like A/B testing, gradual rollouts, and personalised user experiences, and traffic splitting, helping teams deliver smarter, data-driven features. In an future post, we’ll take a deeper look at multi-variant flags with OpenFeature and explore practical use cases. Until then, I encourage you to check out OpenFeature and support its continued development!🚀

Azure, Bicep, Platform Engineering

Building a Self-Service Portal with Port, Azure and Bicep

Introduction

Platform Engineering has become the talk of the town and with it the rise of tooling aimed to help create an IDP (Internal Development Platform), it makes sense to take a look a what’s on offer. One such tool is Port. Port has a lot of features including Software Catalog, Automation, RBAC, Self-Service Actions, Scorecards, etc. as well as integrations into tools such as Datadog, Jira, Pager Duty, GitHub, ArgoCD, etc. Port can also import your existing cloud resources from AWS, Azure and GCP.

Our current cloud provider is Azure and the IaC is in Bicep deployed via Azure Pipelines, Port however does not support Bicep (or ARM) as a provider for importing resources from Azure. The question then is could Port be used to create a self-service portal using Bicep and Azure Pipelines?

The answer is yes, in this article we are going to look at creating a small self-service portal using the above mentioned technologies.

Blank Slate

When you first login to Port you are presented with a blank slate and the feeling of not sure what to do next but fortunately there is a Live Demo site which shows how some of the things go together and there is a lot of documentation as well as an active community to help out too.

Port has capability of being configured from code and supports a number of providers, however, for this article we are going to just add blueprints via the UI.

First Blueprint

Let’s first create a Cloud Host blueprint we can use to store information such as locations for use with the cloud provider (in this case Azure).

To add a new blueprint, select the button on the right hand side of the Builder screen.

Then fill in name as Cloud Host and pick an icon.

Once this has been created we can add some properties to associate with the provider.

Let’s start with some locations to use with creating some resources.

At this point there is just a blueprint for the cloud host and in order to be useful we will need to add some details for the Cloud Hosts in the Catalog, as Bicep is not a supported ingestion we’ll have to add this manually.

After adding the Cloud Host details manually the catalog looks like this:

Note: In this demo we are just using the location but other information could be added for each configuration.

Resource Blueprint

Let’s head back to the Builder screen and add a new blueprint for creating an Azure Resource. As previously, add a new blueprint for creating resources.

Once created we can add a relation link to the Cloud Host blueprint.

We can also add properties to the Create Resource Blueprint like with Cloud Host that we might want to see in the catalog e.g. IaC used, Environment, App name, etc.

Actions with Azure DevOps

So next up is to add some actions to the blueprint so that actually create some resources.

For our new Action, let’s create a small Azure resource like an Azure Storage Account.

On the next screen we get to define what parameters we want the user to provide when the action is ran, for this example we will add an AppName, Location, Environment, Sku and Access Tier.

Note: Location is going to be linked to the Cloud Host blueprint using the Entity Selection property type.

Note: The identifiers for the form fields must match the expected entries in Bicep e.g. Access Tier would default to access_tier but the Bicep parameter might be accessTier.

The next part is to configure the backend, for this we are going to hook up Azure Pipelines, this page provides a client secret to use to add to Azure DevOps.

In an Azure DevOps project setup a service connection for Port to connect to using “Incoming Webhook”.

Fill in the details from the Port configuration including the client secret and Http Header.

Once saved, fill in the details back in Port and go the final page which is permissions.

For the purposes of this demo we will leave this as is with the default settings.

Pipeline

Now everything is configured in Port, we need to add a pipeline to Azure DevOps to trigger on a selection from Port. The Backend page in the action setup gives an example of a starting pipeline but additional steps are needed to support creating resources using Bicep and we also didn’t think there needed to be a multiple job configuration for this purpose.

The below pipeline is triggered by the configured webhook, it deploys Azure resources using a Bicep template and communicates with Port.io. Key steps include fetching an access token, creating a Bicep parameters file, deploying resources, and updating Port.io with deployment status and information. The pipeline includes logging steps, outputs display, and interaction with the Port.io API for entity upserts and status updates.

The goal of this pipeline is to be one that can be reused for building different kinds of resources instead of having multiple pipelines for each resource. After multiple runs and attempts, we finally arrived at this configuration.

trigger: none
pr: none

resources:
  webhooks:
    - webhook: incomingport
      connection: Port.io

variables:
  subscription: 'MySubscription'
  System.debug: true
  runId: ${{ parameters.incomingport.context.runId }}
  deployParametersFileName: 'deploy.bicepparam'
  deployFileName: deploy_${{ lower(replace(parameters.incomingport.action,'create_', '')) }}.bicep
  deployStatus: "FAILURE"
  deployStatusMessage: "Azure Resource Creation Failed"
  deployMessage: "Deployment Pipeline Failed"

stages:
  - stage: run_resource_creation
    displayName: 'Run Resource Creation'
    jobs:
    - job: fetch_port_access_token
      displayName: 'Create Resources'
      pool:
            vmImage: 'ubuntu-latest'
      steps:
        - script: |
            accessToken=$(curl -X POST \
            -H 'Content-Type: application/json' \
            -d '{"clientId": "$(PORT_CLIENT_ID)", "clientSecret": "$(PORT_CLIENT_SECRET)"}' \
            -s 'https://api.getport.io/v1/auth/access_token' | jq -r '.accessToken')
            echo "##vso[task.setvariable variable=accessToken;issecret=true]$accessToken"
            echo "runId=$(runId)"
          displayName: Fetch Access Token and Run ID
          name: getToken
        - template: templates/sendlogs.yml
          parameters:
            Message: "Create parameters file"
            AccessToken: $(accessToken)
            RunId: $(runId)
            conditionLevel: succeeded()
        - pwsh: |
            $obj = $env:payload | ConvertFrom-Json -AsHashtable
            $additionalObj = $env:entityPayload ?? @() | ConvertFrom-Json -AsHashtable
            $excludeList = @()
            $filename = "$env:deployParametersFileName"

            Out-File -FilePath $filename
            "using '$(deployFileName)'" | Out-File -FilePath $filename -Append
            "param runId = '$env:runId'" | Out-File -FilePath $filename -Append
            # Payload Properties
            ($obj.Keys | ForEach-Object { 
              if ($_ -notin $excludeList) { 
                if($($obj[$_]).GetType().Name -eq "String") {
                  "param $_ = '$($obj[$_])'"
                } 
                else {
                  "param $_ = $($obj[$_])"
                }
              }
            }) | Out-File -FilePath $filename -Append
            # Entity Payload Properties
            if($additionalObj.count -ne 0) {
              $entityExcludeList = @("iac","provider","appname")
              ($additionalObj.Keys | ForEach-Object {
                  if ($_ -notin $entityExcludeList) {
                    if($($additionalObj[$_]).GetType().Name -eq "String") {
                      "param $_ = '$($additionalObj[$_])'"
                    } 
                    else {
                      "param $_ = $($additionalObj[$_])"
                    }
                  }
                }) | Out-File -FilePath $filename -Append
                if($env:entityIdentifier -ne $null) {
                  "param parentName = '$env:entityIdentifier'" | Out-File -FilePath $filename -Append
                }
            }
          displayName: 'Create Parameters File'
          env:
            runId: $(runId)
            payload: ${{ convertToJson(parameters.incomingport.payload.properties) }}
            entityPayload: ${{ convertToJson(parameters.incomingport.payload.entity.properties) }}
            entityIdentifier: ${{ parameters.incomingport.payload.entity.identifier }}
            deployParametersFileName: $(deployParametersFileName)
        - bash: |
            cat $(deployParametersFileName)
          displayName: 'Show File'
          condition: and(succeeded(), eq(variables['System.debug'], 'true'))
        - template: templates/sendlogs.yml
          parameters:
            Message: "Deploying Resources"
            AccessToken: $(accessToken)
            RunId: $(runId)
            conditionLevel: succeeded()
        - task: AzureCLI@2
          displayName: "Deploy Resources"
          inputs:
            azureSubscription: $(subscription)
            scriptType: "pscore"
            scriptLocation: "inlineScript"
            inlineScript: |
              $outputStatus = "SUCCESS"
              $outputStatusMessage = "Azure Resource Creation Succeeded"
              $resourceGroupName = "$env:environment-$env:appname-rg"
              $deploymentName = "deploy_$env:runId"
              if($(az group exists --name $resourceGroupName) -eq $false) {
                az group create --name $resourceGroupName --location $env:location
              }
              $output = $(az deployment group create --resource-group $resourceGroupName --template-file $env:deployFileName --parameters $env:deployParametersFileName --name $deploymentName 2>&1)
              if (!$?) {
                $outputStatus = "FAILURE"
                $outputStatusMessage = "Azure Resource Creation Failed"
                try {
                  $obj = $output.Exception.Message -replace '["()]', '\$&'
                  $output = $obj
                } catch {
                  $output = "Something went wrong"
                }
              } else {
                $output = $output -replace '["()]', '\$&'
              }
              $title = (Get-Culture).TextInfo.ToTitleCase($env:deployTitle)

              $resourceName = $(az deployment group show -g $resourceGroupName -n $deploymentName --query properties.outputs.resourceName.value -o tsv)
              Write-Host "##vso[task.setvariable variable=resourceName;]$resourceName"
              Write-Host "##vso[task.setvariable variable=deployMessage;]$output"
              Write-Host "##vso[task.setvariable variable=deployStatus;]$outputStatus"
              Write-Host "##vso[task.setvariable variable=deployStatusMessage;]$outputStatusMessage"
              Write-Host "##vso[task.setvariable variable=deployTitle;]$title"
          env:
            runId: $(runId)
            location: ${{ parameters.incomingport.payload.properties.location }}
            environment: ${{ coalesce(parameters.incomingport.payload.properties.environment, parameters.incomingport.payload.entity.properties.environment) }}
            appname: ${{ coalesce(parameters.incomingport.payload.properties.appname, parameters.incomingport.payload.entity.properties.appname) }}
            deployFileName: $(deployFileName)
            deployParametersFileName: $(deployParametersFileName)
            deployTitle: ${{ lower(replace(replace(parameters.incomingport.action,'create_', ''),'_',' ')) }}
        - script: |
            echo '$(resourceName)'
          displayName: 'Show Outputs'
        - script: |
            curl -X POST \
              -H 'Content-Type: application/json' \
              -H "Authorization: Bearer $(accessToken)" \
              -d '{
                    "identifier": "$(resourceName)",
                    "title": "$(deployTitle)",
                    "properties": {"environment": "${{ parameters.incomingport.payload.properties.environment }}","iac": "Bicep","appname": "${{ coalesce(parameters.incomingport.payload.properties.appname, parameters.incomingport.payload.properties.name) }}"},
                    "relations": {"cloud_host": "${{ parameters.incomingport.payload.properties.location }}"}
                  }' \
              "https://api.getport.io/v1/blueprints/${{ parameters.incomingport.context.blueprint }}/entities?upsert=true&run_id=$(runId)&create_missing_related_entities=true"
          displayName: 'Upsert entity'
        - template: templates/sendlogs.yml
          parameters:
            Message: $(deployMessage)
            AccessToken: $(accessToken)
            RunId: $(runId)
        - template: templates/sendlogs.yml
          parameters:
            Message: "Deployment Finished"
            AccessToken: $(accessToken)
            RunId: $(runId)
        - template: templates/sendStatus.yml
          parameters:
            Status: $(deployStatus)
            Message: $(deployStatusMessage)
            AccessToken: $(accessToken)
            RunId: $(runId)

sendlogs.yml

parameters:
- name: Message
  type: object  
- name: RunId
  type: string
- name: AccessToken
  type: string
- name: conditionLevel
  type: object
  default: always()
  values:
   - always()
   - succeeded()
   - failed()
steps:
- bash: |
    curl -X POST \
      -H 'Content-Type: application/json' \
      -H "Authorization: Bearer ${{ parameters.AccessToken }}" \
      -d '{"message": "${{ parameters.Message }}"}' \
      "https://api.getport.io/v1/actions/runs/${{ parameters.RunId }}/logs"
  displayName: Send Logs  
  condition: and(${{ parameters.conditionLevel }}, ne('${{ parameters.Message }}', ''))

sendStatus.yml

parameters:
- name: Status
  type: string
  default: 'FAILURE'
- name: Message
  type: string
  default: "Azure Resource Creation Successful"
- name: RunId
  type: string
- name: AccessToken
  type: string
steps:
- bash: |
    curl -X PATCH \
      -H 'Content-Type: application/json' \
      -H "Authorization: Bearer ${{ parameters.AccessToken }}" \
      -d '{"status":"${{ parameters.Status }}", "message": {"run_status": "${{ parameters.Message }}"}}' \
      "https://api.getport.io/v1/actions/runs/${{ parameters.RunId }}"
  displayName: 'Send Status'
  condition: always()

There is also a couple of required variables from Port that are needed by the pipeline, the port client id and port client secret

These values can be found in Port by selecting the … icon and then credentials.

Self-Service

With the pipeline created we can now use the Self-Service Hub in Port to create our new resource.

Add some details and execute.

When execute has begun then there is a status on the right hand side.

In Azure DevOps the webhook triggers the running pipeline.

When running the pipeline returns status information to Port and on completion updates the status.

And on the catalog screen there is now an entry for the storage account.

Additional Blueprints

The pipeline has been created to be generic and so should allow other types of resources to be created with accompanying Bicep configurations. The Create Azure Resource blueprint doesn’t seem to be the best place for resources that might need a Day-2 operation so, lets add another blueprint for SQL Server with a Day-2 operation to add a SQL Database into a built SQL Server.

Following the earlier example of creating blueprints and actions, first create a “Create Azure SQL Server” blueprint and then 2 actions “Create Azure SQL Server” using the Create type with user form of Environment, AppName and Location (as previously) and then “Create Azure SQL Database” using the Day-2 type with a single user form entry of Name.

This should then look something like this:

The Self-Service screen now includes the additional actions.

Trying to run the Day-2 operation at this point would not provide an entry for a SQL Server.

But once there is a SQL Server created this will allow it to be selected for the Day-2 operation and deploy a database.

Still not entirely sure how to get a display of the databases deployed in the catalog screen for the Day-2 operation but the run history shows the Create Azure SQL Database action and payload.

All the code shown here for the Bicep and Azure Pipelines can be found here in GitHub.

Final Thoughts

Before writing this article I had no prior experience of Port and there maybe different ways to achieve the above but after the initial “where does everything go” part it seemed a lot easier to see where effort is required to build something functional. You might think why use Bicep when you could import things using the supported integrations, mainly because I use a lot of Bicep and Pulumi and I wanted to see if Port was still an option even without direct support for those technologies and I think that it has merit and as something that is still evolving and improving it’s possible Bicep could be supported one day.

Exploring the Self-Service part of Port was the driving force for this article but there is so much more on offer to dive into and explorer. Port’s free tier supports 15 registered users and so it is a great place to get started and try it out without having to think about costs.

I really like the direction that Platform Engineering is taking and these types of tools are a game changer when it comes to reducing the cognitive load of deployment, infrastructure, etc.. from the Developers and allowing them to concentrate on the features they are delivering instead of how it gets where it needs to.

I hope this article has been interesting and directed you to take a look at Port for your own IDP needs, I am interested to see how Port evolves in the coming months/years.