In one of my Azure Web Apps I create an Azure Topic when it doesn't exist yet during the warmup(start) of our Azure Web App.
On topic creation time I want to know whether the service bus has a premium pricing tier, when yes I want to disable express, when no (standard pricing tier) I want to enable express, to prevent exceptions.
Is there a defensive way to check if a premium pricing tier is available on the service bus (for example: using the service bus connection string) ?
When there is no defensive way, I can always catch the web exception that know raises, but I want to prevent the exception if I can.
Edit: After consulting our lead-dev we decided to skip the EnableExpress setting completely in our DTAP. So I don't need to implement the SKU check at all. Be aware to not set the EnableExpress property at all otherwise you get the webexception in Premium SKU.
Is there a defensive way to check if a premium pricing tier is
available on the service bus (for example: using the service bus
connection string)?
Unfortunately there's none as of today. Service Bus Client SDK does not expose this information. This feature has been asked from the Service Bus team and there's an open issue on Github for that: https://github.com/Azure/azure-service-bus/issues/42.
The differences between Premium and Standard tiers are highlighted here: https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-premium-messaging. Kind of an anti-pattern but one thing you could do is perform and operation that is only available in Premium tier (say sending a message greater than 256KB in size) and catch the exception (or lack of) to determine if the Service Bus tier is Premium or not.
If we want to check the Azure Service Bus Pricing tier,we could use the following code with Microsoft.Azure.Management.Fluent SDK.
var credentials = SdkContext.AzureCredentialsFactory.FromFile(#"c:\tom\azureCredential.txt");
var azure = Azure
.Configure()
.WithLogLevel(HttpLoggingDelegatingHandler.Level.Basic)
.Authenticate(credentials)
.WithDefaultSubscription();
var serviceBus = azure.ServiceBusNamespaces.GetByResourceGroup("resourcegroup", "servicebusnamespace");
var priceTier = serviceBus.Sku.Tier;
Before code we need to create an azure active directory application and assign the correspondent role. We could create the azure credential file following the document. The following is the credential file format.
subscription=########-####-####-####-############
client=########-####-####-####-############
tenant=########-####-####-####-############
key=XXXXXXXXXXXXXXXX
managementURI=https\://management.core.windows.net/
baseURL=https\://management.azure.com/
authURL=https\://login.windows.net/
graphURL=https\://graph.windows.net/
Related
I created a service bus account with Basic tier and tried to create a Topic but I saw that it was not possible due to the Basic tier. So I deleted this service bus and created another one with the same name, but this time with the tier as Standard. Now when I try to create a topic I get the message:
SubCode=40000. Cannot operate on type Topic because the namespace 'XXXX' is using 'Basic' tier.
But it´s Standard as you can see on the image:
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
Service Bus is not an exception. Your best bet at this point is to contact Azure support directly or via Twitter.
I want to determine the current pricing tier of my hub so I can use/not use telemetry functions without generating errors. I have found a PricingTier class, but it states it "Creates a custom value for PricingTier". Does the NotificationHubClient have access to the pricing tier in use?
I'm building a queue messaging system in Azure and what I'm trying to do is an outbound message queue container in Azure Storage Queue that allows my desktop Windows Services to get the latest messages from that queue. The problem I'm facing is that I want to have multiple queues per tenant (each Windows service serves one client) in one storage account. As far as I see, there is no way to restrict the connection string access to each queue. On the other hand, it is not practical for me to create one storage account per tenant. What is the best way to restrict client access to one specific queue with the current security methods available in Azure? I was thinking about using Service Bus Queues, but even that doesn't solve the connection string issue I have in the client application.
I think service bus queues is your answer; they allow a multi-subscriber model with "subjects" and various filters etc.
Storage queues are very simplistic and are not the right answer for this particular scenario.
Sorry, on my mobile so haven't got all the relevant docs to hand.
One option is to use AAD identities and Storage's AAD authentication support (which is currently in public preview).
You would need a Service Principal in Azure AD for each tenant for this,
and add the principal to the Storage Queue Data Reader or Storage Queue Data Contributor role on their respective queue.
You can then use the principal's credentials to get an access token that is tenant-specific.
Documentation:
https://azure.microsoft.com/en-us/blog/announcing-the-preview-of-aad-authentication-for-storage/
https://joonasw.net/view/azure-ad-authentication-with-azure-storage-and-managed-service-identity
Do Logic Apps have some sort of built in geo-replication like the Azure Scheduler or Key Vaults? I can't seem to find any information about it.
I have seen some implementations using API management but that is for Logic App that use HTTP triggers, in my case I'm using Service Bus triggers.
If there is no geo-replication how would a disaster recovery implementation look like for my scenario?
I think you are asking three questions - How do I get a geo-redundant Logic Apps deployment and How do I get a geo-redundant Service Bus Messaging deployment and how do I use them in combination.
I would start with the Service Bus Messaging side as it is the foundation for the LA process. In order to have a geo-redundant Service Bus Messaging queue you have to use the Premium SKU and this article goes into detail on how it works: https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-geo-dr
For the Logic Apps side you would setup an LA in each region (primary and secondary) and point the Logic Apps to the alias for Service Bus Queue. You would then disable the Logic App in the secondary region and only enable it when the primary region's Logic App was not operational. This would have to be done with some endpoint monitoring scripting and then switch over to the secondary and disable the primary.
Like you said, there are other more automated options (Traffic Manager) when Logic Apps is being triggered by HTTP traffic but since you are reading queues the recovery is more complex.
Is there currently a way to autoscale an Azure App Service plan by a "v2" storage account message queue? When I attempt to set up autoscaling based on a message queue, it is only showing my "classic" storage accounts. I would prefer to not destroy and recreate the storage account as classic just because of this.
Currently that supports classic storage accounts only. I would suggest you to provide feedback here: https://feedback.azure.com/forums/169385-web-apps-formerly-websites