[QUERY] Why are the C# CDK and SDK mixed together?

[garrettlondon1]

trafficstars

Library name and version

Azure.Provisioning

Query/Question

It's unclear to me why the Azure.Provisioning libraries are mixed in with the Azure SDK libraries.

Defining Infrastructure as code (CDK) through C#, is in my opinion, very separate from the code I need to call Azure Key vault from my .NET Web API

Additionally, it's hard to tell what to use for resource groups, vnets not supported by Azure Provisioning. "Management" SDKs for Resource groups, etc. Are they idempotent like CDK's should be?

var client = new ArmClient(new AzureCliCredential());

string resourceGroupName = "alreadyexistsrg";
SubscriptionResource subscription = await client.GetDefaultSubscriptionAsync();
ResourceGroupCollection resourceGroups = subscription.GetResourceGroups();

AzureLocation location = AzureLocation.EastUS2;
ResourceGroupData resourceGroupData = new ResourceGroupData(location);
var rg = await resourceGroups.CreateOrUpdateAsync(WaitUntil.Completed, resourceGroupName, resourceGroupData);

Using this code, I am trying to use Azure Provisioning libraries and azd to deploy IAC through C#. It is not idempotent, it returns a 409 conflict saying my resource group already exists.

I have spent a while and cannot find any documentation that explains how to at the subscription level, create a resource group, add some resources using the Azure Provisioning libraries, and idempotently deploy it to Azure.

Am I missing any crucial documentation to get started here?

I do not want to use Aspire, I am running a monolithic service and do not need the local orchestration. I just want to use the CDK to deploy my resources to azure instead of bicep.

Environment

No response

[github-actions[bot]]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @anthony-c-martin @calecarter @cemheren @j5lim @majastrz.

[jsquire]

@tg-msft and @ArthurMa1978: Would you please offer your thoughts?

[garrettlondon1]

Bump

[tg-msft]

It's unclear to me why the Azure.Provisioning libraries are mixed in with the Azure SDK libraries.

This repo is all about making Azure easier to use for .NET devs. The Azure.Provisioning libraries in particular are all about making Bicep and C# work better together. We've got data plane, management plane, integrations, extensions, etc., all in this repo.

Defining Infrastructure as code (CDK) through C#, is in my opinion, very separate from the code I need to call Azure Key vault from my .NET Web API

I think there are some very interesting scenarios here. Take AI Search as an example. You can create it via Azure.Provisioning, but you won't be able to actually do anything until you create search indexes and seed it with data. Creating a search indexer that accesses your Cosmos DB via managed identity is inherently a cross-plane operation that's too complex today. We'd like to eventually get to a point where you can flow seamlessly across planes so you can create and configure Azure resources without worrying about all the boundaries of where a specific API lives.

Additionally, a lot of the dependencies on ARM were a point in time solution to unblock the first version of Aspire and have been removed in the latest version. For example, Azure.Provisioning.KeyVault doesn't have a dependency on Azure.ResourceManager.KeyVault.

I have spent a while and cannot find any documentation that explains how to at the subscription level, create a resource group, add some resources using the Azure Provisioning libraries, and idempotently deploy it to Azure.

We're working on documentation right now.

There's also a preview package called Azure.Provisioning.Deployment that sketches early thinking about how we can simplify deploying resources directly from C#. That package does take a dependency on Azure.ResourceManager.* packages, primarily as an implementation detail. I guarantee it will absolutely not do everything you want yet though. :smile:

Here's a quick example of deploying a Storage Account:

Infrastructure infra = new();

StorageAccount storage =
    new(nameof(storage))
    {
        Sku = new StorageSku { Name = StorageSkuName.StandardLrs },
        Kind = StorageKind.StorageV2,
        AccessTier = StorageAccountAccessTier.Hot
    };
infra.Add(storage);

BlobService blobs = new(nameof(blobs)) { Parent = storage };
infra.Add(blobs);

ProvisioningPlan plan = infra.Build();

// Optionally save as bicep in my current folder
plan.Save(".");

// Or deploy to a new RG using an implicit `new DefaultAzureCredential()`
ProvisioningDeployment deployment =
    plan.DeployToNewResourceGroup("my-rg", AzureLocation.WestUS2);

which would create and deploy a main.bicep file like:

@description('The location for the resource(s) to be deployed.')
param location string = resourceGroup().location

resource storage 'Microsoft.Storage/storageAccounts@2024-01-01' = {
    name: take('storage${uniqueString(resourceGroup().id)}', 24)
    kind: 'StorageV2'
    location: location
    sku: {
        name: 'Standard_LRS'
    }
    properties: {
        accessTier: 'Hot'
    }
}

resource blobs 'Microsoft.Storage/storageAccounts/blobServices@2024-01-01' = {
    name: 'default'
    parent: storage
}

We've also prototyped (but removed before GA as it's not fully baked) getting data plane clients after deploying to do something like upload lots of documents:

BlobServiceClient client = deployment.CreateClient(blobs);
BlobServiceProperties properties = client.GetProperties();
// ...

[garrettlondon1]

Thank you very much @tg-msft , I will look for updates regarding Azure.Provisioning.Deployment.