Forum Widgets
Latest Discussions
How do you decide what belongs in an Azure Resource Group?
One of the Azure design decisions that looks simple at first but becomes surprisingly important in production is how we structure Resource Groups. The common approach is to group related Azure resources together. But in enterprise environments, I have found that a more useful question is: Should a Resource Group represent technology, application, workload ownership, or resource lifecycle? For example, consider an integration platform containing API Management, Azure Functions, Service Bus, Key Vault and networking. Would you put everything into one Resource Group? Or would you separate shared infrastructure from workload-specific resources? In my experience, ownership, lifecycle and operational responsibility are often better boundaries than simply grouping resources by Azure service type. I recently explored this topic in more detail in the first article of a new series I am writing on Azure architecture: Are Azure Resource Groups Just Folders? The article covers workload-based Resource Group design, environment boundaries, shared infrastructure, RBAC and some production lessons learned. I would be interested to hear how others approach Resource Group design in production Azure environments. Article: https://www.linkedin.com/pulse/azure-resource-groups-just-folders-chethan-raj-fakac
Leverage Azure PIM with DataBricks with Contributor role privilege
We are trying to leverage Azure PIM. This works great for most things, however; we've run into a snag. We want to limit the contributor role to a group and only at the resource group level, not subscription. We wish to elevate via PIM. This will then allow the user access within DataBricks. #1 issue - We have to enable PIM at the group level as it doesn't show up for group members within PIM and can't assign a contributor level group within the PIM application in Azure. So an admin has to enable PIM for the user to activate at the group level. We've also tried to do this scenario leveraging the Managed Application Contributor role as well. #2 - Delay - We are using the SCIM connector for User Provisioning leveraging Azure AD Groups. This connects to the unity catalog and are able to assign the groups within the Workspace. The issue - after you elevate the users permission in the contributor group at the resource level, you have to wait for 40 minutes for user provisioning to run or stop/start it. Until then, the user remains in an 'inactive' state within DataBricks. We feel we are missing a more fluid way to grant these rights and leverage PIM. Suggestions? Thanks in advance.FinOps for AI: Cost Optimization Strategies for High-Volume Azure AI Workloads
AI has moved from experimentation to production surprisingly quickly. Teams are now using Azure AI workloads for everything from customer support and document processing to content generation, data extraction, search, and intelligent automation. But as AI usage grows, so does a problem that many engineering teams discover the hard way: AI costs can scale much faster than expected. Link to the Blog
Admin‑On‑Behalf‑Of issue when purchasing subscription
Hello everyone! I want to reach out to you on the internet and ask if anyone has the same issue as we do when creating PAYG Azure subscriptions in a customer's tenant, in which we have delegated access via GDAP through PartnerCenter. It is a bit AI formatted question. When an Azure NCE subscription is created for a customer via an Indirect Provider portal, the CSP Admin Agent (foreign principal) is not automatically assigned Owner on the subscription. As a result: AOBO (Admin‑On‑Behalf‑Of) does not activate The subscription is invisible to the partner when accessing Azure via Partner Center service links The partner cannot manage and deploy to a subscription they just provided This breaks the expected delegated administration flow. Expected Behavior For CSP‑created Azure subscriptions: The CSP Admin Agent group should automatically receive Owner (or equivalent) on the subscription AOBO should work immediately, without customer involvement The partner should be able to see the subscription in Azure Portal and deploy resources Actual Behavior Observed For Azure NCE subscriptions created via an Indirect Provider: No RBAC assignment is created for the foreign AdminAgent group The subscription is visible only to users inside the customer tenant Partner Center role (Admin Agent foreign group) is present, but without Azure RBAC. Required Customer Workaround For each new Azure NCE subscription, the customer must: Sign in as Global Admin Use “Elevate access to manage all Azure subscriptions and management groups” Assign themselves Owner on the subscription Manually assign Owner to the partner’s foreign AdminAgent group Only after this does AOBO start working. Example Partner tries to access the subscription: https://portal.azure.com/#@customer.onmicrosoft.com/resource/subscriptions/<subscription-id>/overview But there is no subscription visible "None of the entries matched the given filter" https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin?tabs=azure-portal%2Centra-audit-logs#step-1-elevate-access-for-a-global-administrator from the customer's global admin. and manual RBAC fix in Cloud console: az role assignment create \ --assignee-object-id "<AdminAgent-Foreign-Group-ObjectId>" \ --role "Owner" \ --scope "/subscriptions/<subscription-id>" \ --assignee-principal-type "ForeignGroup" After this, AOBO works as expected for delegated administrators (foreign user accounts). Why This Is a Problem Partners sell Azure subscriptions that they cannot access Forces resources from customers to involvement from customers Breaks delegated administration principles For Indirect CSPs managing many tenants, this is a decent operational blocker. Key Question to Microsoft / Community Does anyone else struggle with this? Is this behavior by design for Azure NCE + Indirect CSP? Am I missing some point of view on why not to do it in the suggested way?Building Resilient Cloud Architectures with Azure’s Agentic Agents
Cloud computing has evolved far beyond simply moving workloads from on-premises servers to virtual machines. Organizations today expect their cloud environments to be intelligent, resilient, secure, and capable of adapting to changing business demands with minimal human intervention. As artificial intelligence continues to reshape enterprise technology, Microsoft Azure is introducing a new generation of AI-powered capabilities through Agentic AI. https://dellenny.com/building-resilient-cloud-architectures-with-azures-agentic-agents-migration-observability-and-optimization/Portable Azure topology and documentation snapshots with OSIRIS JSON
Ciao everyone, I’m working on https://github.com/osirisjson/osiris, a vendor-neutral specification for describing infrastructure resources and their relationships as portable point-in-time snapshots. To proof that the specification could work in real-scenarios I already built an initial https://osirisjson.org/en/docs/producers/hyperscalers/microsoft-azure in Go. You run on-premise and it connects through the Azure CLI, reads Azure subscriptions and emits an OSIRIS JSON document that can be used for documentation, topology diagrams, audits, configuration drift analysis, CMDB/IPAM/DCIM workflows, or controlled AI/context workflows without giving those platforms/tools direct access to Azure. The producer currently covers several Azure areas, including networking, compute, storage, identity, databases, containers, integration, observability, backup, automation, management groups, and cross-resource dependency edges such as Private Endpoint to PaaS targets, App Service to Application Insights / Log Analytics, AKS to subnets and node pools, and backup vault relationships. It supports two output purposes: documentation: minimal high-level projection for diagrams, inventory dashboards, and architectural documentation audit: deeper projection with readable properties and extensions after sensitive-field redaction This is not intended to replace Azure tooling, Azure Resource Graph, IaC, Azure Policy, or any existing governance/control-plane workflow. OSIRIS JSON is simply a read-only external producer that generates a vendor-neutral snapshot of the observed Azure environment. I would really appreciate feedback from Azure architects, cloud engineers, and governance practitioners on the mapping model: Which Azure resources and relationships are the most important for documentation and topology generation? Are the current connection types useful for real-world architecture views? What should be prioritized in next releases? Would a documentation/audit split be useful in enterprise environments? You find the current Azure producer documentation here: https://osirisjson.org/en/docs/producers/hyperscalers/microsoft-azure I would really appreciate any feedback, suggestions, edge cases, or ideas from people who operate, document, audit, or govern Azure environments and I also welcome anyone who want to participate on development. Ciao from Italy, Tia
AKS run simulation
I have simulation which is sort of command line node app. something like node something.js -p1 -p2 etc. I create docker image of it. I need to run it in AKS cluster. Say I create deployment with 2 or 3 replicas . How I can run it so it can take advantage of cluster to process it faster? I understand web application I can access by public IP. But not understanding how I can run it for such command line application? Can I just SSH to one of pod and run it?
[Architecture Pattern] Scaling Sync-over-Async Edge Gateways by Bypassing Service Bus Sessions
Hi everyone, I wanted to share an architectural pattern and an open-source implementation we recently built to solve a major scaling bottleneck at the edge: bridging legacy synchronous HTTP clients to long-running asynchronous AI workers. The Problem: Stateful Bottlenecks at the Edge When dealing with slow AI generation tasks (e.g., 45+ seconds), standard REST APIs will drop the connection resulting in 504 Gateway Timeouts. The standard integration pattern here is Sync-over-Async. The Gateway accepts the HTTP request, drops a message onto Azure Service Bus, waits for the worker to reply, and maps the reply back to the open HTTP connection. However, the default approach is to use Service Bus Sessions for request-reply correlation. At scale, this introduces severe limitations: 1. Stateful Gateways: The Gateway pod must request an exclusive lock on the session. It becomes tightly coupled to that specific request. 2. Horizontal Elasticity is Broken: If a reply arrives, it must go to the specific pod holding the lock. Other idle pods cannot assist. 3. Hard Limits: A traffic spike easily exhausts the namespace concurrent session limits (especially on the Standard tier). The Solution: Stateless Filtered Topics To achieve true horizontal scale, the API Gateway layer must be 100% stateless. We bypassed Sessions entirely by pushing the routing logic down to the broker using a Filtered Topic Pattern. How it works: 1. The Gateway injects a CorrelationId property (e.g., Instance-A-Req-1) into the outbound request. 2. Instead of locking a session, the Gateway spins up a lightweight, dynamic subscription on a shared Reply Topic with a SQL Filter: CorrelationId = 'Instance-A-Req-1'. 3. The AI worker processes the task and drops the reply onto the shared topic with the same property. 4. The Azure Service Bus broker evaluates the SQL filter and pushes the message directly to the correct Gateway pod. No session locks. No implicit instance affinity. Complete horizontal scalability. If a pod crashes, its temporary subscription simply drops—preventing locked poison messages. Open Source Implementation Implementing dynamic Service Bus Administration clients and receiver lifecycles is complex, so I abstracted this pattern into a Spring Boot starter for the community. It handles all the dynamic subscription and routing logic under the hood, allowing developers to execute highly scalable Sync-over-Async flows with a single line of code returning a CompletableFuture. GitHub Repository: https://github.com/ShivamSaluja/sentinel-servicebus-starter Full Technical Write-up: https://dev.to/shivamsaluja/sync-over-async-bypassing-azure-service-bus-session-limits-for-ai-workloads-269d I would love to hear from other architects in this hub. Have you run into similar session exhaustion limits when building Edge API Gateways? Have you adopted similar stateless broker-side routing, or do you rely on sticky sessions at your load balancers?Proyecto Escolar Tecnológico
Estamos haciendo un trabajo de investigación sobre las nuevas tecnologías aplicadas a la gestión empresarial ya que estamos desarrollando un proyecto de software para el sector de odontología y me gustaría preguntarle a los expertos: ¿Qué tecnologías se consideran "el estándar de oro" o esenciales para aplicar en 2026, y que ustedes ya han utilizado?.
