Azure Architecture topics

[Architecture Pattern] Scaling Sync-over-Async Edge Gateways by Bypassing Service Bus Sessions

ssaluja72 — Mon, 13 Apr 2026 17:25:35 GMT

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

Mabs1 — Mon, 13 Apr 2026 15:43:30 GMT

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?.

Detecting ACI IP Drift and Auto-Updating Private DNS (A + PTR) with Event Grid + Azure Functions

Chiragsharma30 — Wed, 01 Apr 2026 11:35:49 GMT

Solution Author	Aditya_AzureNinja , Chiragsharma30
Solution Version	v1.0

TL;DR

Azure Container Instances (ACI) container groups can be recreated/updated over time and may receive new private IPs, which can cause DNS mismatches if forward and reverse records aren’t updated. This post shares an event-driven pattern that detects ACI IP drift and automatically reconciles Private DNS A (forward) and PTR (reverse) records using Event Grid + Azure Functions.

Key requirement: Event delivery is at-least-once, so the solution must be idempotent.

Problem statement

In hub-and-spoke environments using per-spoke Private DNS zones for isolation, ACI workloads created/updated/deleted over time can receive new private IPs. We need to ensure:

Forward lookup: aci-name.<spoke-zone> (A record) → current ACI private IP
Reverse lookup: IP → aci-name.<spoke-zone> (PTR record)

Two constraints drive this design:

Azure Private DNS auto-registration is VM-only and does not create PTR records, so ACI needs explicit A/PTR record management.
Reverse DNS is scoped to the VNet (reverse zone must be linked to the querying VNet, otherwise reverse lookup returns NXDOMAIN).

Design principle:

This solution was designed with the following non‑negotiable engineering goals:

Event‑driven
DNS updates must be triggered directly from resource lifecycle events, not polling or scheduled jobs. Container creation, restart, and deletion are the only reliable sources of truth for IP changes in ACI.
Idempotent
Azure Event Grid delivers events with at‑least‑once semantics. The system must safely process duplicate events without creating conflicting DNS records or failing on retries.
Stateless
The automation must not rely on in‑memory or persisted state to determine correctness. DNS itself is treated as the baseline state, allowing functions to scale, restart, and replay events without drift or dependency on prior executions.
Clear failure modes
DNS reconciliation failures must be explicit and observable. If DNS updates fail, the function invocation must fail loudly so the issue is visible, alertable, and actionable—never silently ignored.

Components

Event Grid subscriptions (filtered to ACI container group lifecycle events)
Azure Function App (Python) with System Assigned Managed Identity
Private DNS forward zone (A records)
Private DNS reverse zone (PTR records)
Supporting infra (typical):
- Storage account (function artifacts / operational needs)
- Application Insights + Log Analytics (observability)

Event-driven flow

ACI container group is created/updated/deleted.
Event Grid emits a lifecycle event (delivery can be repeated).
Function is triggered and reads the current ACI private IP.
Function reconciles DNS:
- Upsert A record to current IP
- Upsert PTR record to FQDN
- Remove stale PTR(s) for hostname/IP as needed
Function logs reconciliation outcome (updated vs no-op).

Architecture overview (INFRA)

This follows the“Event-driven registration” approach: Event Grid → Azure Function that reconciles DNS on ACI lifecycle events.

RBAC at a glance (Managed Identity)

Role	Scope	Purpose
Storage Blob Data Owner	Function App deployment storage account	Access function artifacts and operational blobs (required because shared key access is disabled).
Reader	Each ACI workload resource group	Read container group state and determine the current private IP.
Private DNS Zone Contributor	Private DNS forward zone(s)	Create, update, and delete A records for ACI hostnames.
Private DNS Zone Contributor	Private DNS reverse zone(s)	Create, update, and clean up PTR records for ACI IPs.
Monitoring Metrics Publisher (optional)	Data Collection Rule (DCR)	Upload structured IP‑drift events to Log Analytics via the ingestion API.

---

Architecture overview (APP)

Event‑Driven DNS Reconciliation for Azure Container Instances

1. Event contract: what the function receives

Azure Event Grid delivers events using a consistent envelope (Event Grid schema). Each event includes, at a minimum:

topic
subject
id
eventType
eventTime
data
dataVersion
metadataVersion

In Azure Functions, the Event Grid trigger binding is the recommended way to receive these events directly.

Why the subject field matters

The subject field typically contains the ARM resource ID path of the affected resource.
This solution relies on subject to:

verify that the event is for an ACI container group
(Microsoft.ContainerInstance/containerGroups)
extract:
- subscription ID
- resource group name
- container group name

Using subject avoids dependence on publisher‑specific payload fields and keeps parsing fast, deterministic, and resilient.

2. Subscription design: filter hard, process little

The solution follows a strict runbook pattern:

subscribe only to ARM lifecycle events
filter aggressively so only ACI container groups are included
trigger reconciliation only on meaningful state transitions

Recommended Event Grid event types

Microsoft.Resources.ResourceWriteSuccess
(create / update / stop state changes)
Microsoft.Resources.ResourceDeleteSuccess
(container group deletion)
Microsoft.Resources.ResourceActionSuccess (optional)
(restart / start / stop actions, environment‑dependent)

This keeps the Function App simple, predictable, and low‑noise.

3. Application design: two functions, one contract

The application is intentionally split into authoritative mutation and read‑only validation.

Component A — DNS Reconciler (authoritative writer)

A thin Python v2 model wrapper:

receives the Event Grid event
validates this is an ACI container group event
parses identifiers from the ARM subject
resolves DNS configuration from a JSON mapping (environment variable)
delegates DNS mutation to a deterministic worker script

DNS changes are not implemented inline in Python. Instead, the function:

constructs a controlled set of environment variables
invokes a worker script (/bin/bash) via subprocess
streams stdout/stderr into function logs
treats non‑zero exit codes as hard failures

This thin wrapper + deterministic worker pattern isolates DNS correctness logic while keeping the event handler stable and testable.

Component B — IP Drift Tracker (stateless observer)

The drift tracker is a read‑only, stateless validator designed for correctness monitoring.

It:

parses identifiers from the event subject
exits early on delete events (nothing to validate)
reads the live ACI private IP using the Azure SDK
reads the current DNS A record baseline
compares live vs DNS state and emits drift telemetry

Core comparison logic

No DNS record exists → emit first_seen
DNS record matches live IP → emit no_change
DNS record differs from live IP → emit drift_detected (old/new IP)

Optionally, drift events can be shipped to Log Analytics using DCR‑based ingestion.

4. DNS Reconciler: execution flow

Step 1 — Early filtering

Reject any event whose subject does not contain: Microsoft.ContainerInstance/containerGroups.

This avoids unnecessary processing and ensures strict contract enforcement.

Step 2 — ARM subject parsing

The function splits the subject path and extracts:

resource group
container group name

This approach is fast, robust, and avoids publisher‑specific schema dependencies.

Step 3 — Zone configuration resolution

DNS configuration is resolved from a JSON map stored in an environment variable.

If no matching configuration exists for the resource group:

the function logs the condition
exits without error

Why this matters
This keeps the solution multi‑environment without duplicating deployments.
Only configuration changes — not code — are required.

Step 4 — Delegation to worker logic

The function constructs a deterministic runtime context and invokes the worker:

forward zone name
reverse zone name(s)
container group name
current private IP
TTL and execution flags

The worker performs reconciliation and exits with explicit success or failure.

5. What “reconciliation” actually means

Reconciliation follows clear, idempotent semantics.

Create / Update events

Upsert A record
- if record exists and matches current IP → no‑op
- else → create or overwrite with new IP
Upsert PTR record
- compute PTR name using IP octets and reverse zone alignment
- create or overwrite PTR to hostname.<forward-zone>

Delete events

delete the A record for the hostname
scan PTR record sets:
- remove targets matching the hostname
- delete record set if empty

All operations are safe to repeat.

6. Why IP drift tracking is separate

DNS reconciliation enforces correctness at event time, but drift can still occur due to:

manual DNS edits
partial failures
delete / recreate race conditions
unexpected redeployments or restarts

The drift tracker exists as a continuous correctness validator, not as a repair mechanism.

This separation keeps responsibilities clear:

Reconciler → fixes state
Drift tracker → observes and reports state

7. Observability: correctness vs runtime health

There is an important distinction:

Runtime health

container crashes
image pull failures
restarts
platform events
(visible in standard ACI / Container logs)

DNS correctness

A record != live IP
missing PTR records
stale reverse mappings

The IP Drift Tracker provides this correctness layer, which complements — not replaces — runtime monitoring.

8. Engineering constraints that shape the design

At‑least‑once delivery → idempotency

Event Grid delivery must be treated as at‑least‑once.
Every reconciliation action is safe to execute multiple times.

Explicit failure behavior

If the worker script returns a non‑zero exit code:

the function invocation fails
the failure is visible and alertable
incorrect DNS does not silently persist

Help wanted: Refresh articles in Azure Architecture Center (AAC)

jodimartis — Tue, 17 Mar 2026 18:12:50 GMT

I’m the Project Manager for architecture review boards (ARBs) in the Azure Architecture Center (AAC).

We’re looking for subject matter experts to help us improve the freshness of the AAC, Cloud Adoption Framework (CAF), and Well-Architected Framework (WAF) repos. This opportunity is currently limited to Microsoft employees only.

As an ARB member, your main focus is to review, update, and maintain content to meet quarterly freshness targets. Your involvement directly impacts the quality, relevance, and direction of Azure Patterns & Practices content across AAC, CAF, and WAF. The content in these repos reaches almost 900,000 unique readers per month, so your time investment has a big, global impact. The expected commitment is 4-6 hours per month, including attendance at weekly or bi-weekly sync meetings.

Become an ARB member to gain:

Increased visibility and credibility as a subject‑matter expert by contributing to Microsoft‑authored guidance used by customers and partners worldwide.
Broader internal reach and networking without changing roles or teams.
Attribution on Microsoft Learn articles that you own.
Opportunity to take on expanded roles over time (for example, owning a set of articles, mentoring contributors, or helping shape ARB direction).

We’re recruiting new members across several ARBs. Our highest needs are in the Web ARB, Containers ARB, and Data & Analytics ARB:

The Web ARB focuses on modern web application architecture on Azure—App Service and PaaS web apps, APIs and API Management, ingress and networking (Application Gateway, Front Door, DNS), security and identity, and designing for reliability, scalability, and disaster recovery.
The Containers ARB focuses on containerized and Kubernetes‑based architectures—AKS design and operations, networking and ingress, security and identity, scalability, and reliability for production container platforms.
The Data & Analytics ARB focuses on data platform and analytics architectures—data ingestion and integration, analytics and reporting, streaming and real‑time scenarios, data security and governance, and designing scalable, reliable data solutions on Azure.

We’re also looking for people to take ownership of other articles across AAC, CAF, and WAF. These articles span many areas, including application and solution architectures, containers and compute, networking and security, governance and observability, data and integration, and reliability and operational best practices.

You don’t need to know everything—deep expertise in one or two areas and an interest in keeping Azure architecture guidance accurate and current is what matters most.

Please reply to this post if you’re interested in becoming an ARB member, and I’ll follow up with next steps. If you prefer, you can email me at v-jodimartis@microsoft.com.

Thanks! 🙂

Admin‑On‑Behalf‑Of issue when purchasing subscription

ivoko — Thu, 12 Feb 2026 07:56:13 GMT

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.

AOBO explanation from a Microsoft technical stream

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"

Elevation is needed 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?

[Design Pattern] Handling race conditions and state in serverless data pipelines

Chameseddine — Sat, 13 Dec 2025 12:22:51 GMT

Hello community,

I recently faced a tricky data engineering challenge involving a lot of Parquet files (about 2 million records) that needed to be ingested, transformed, and split into different entities.

The hard part wasn't the volume, but the logic. We needed to generate globally unique, sequential IDs for specific columns while keeping the execution time under two hours.

We were restricted to using only Azure Functions, ADF, and Storage. This created a conflict: we needed parallel processing to meet the time limit, but parallel processing usually breaks sequential ID generation due to race conditions on the counters.

I documented the three architecture patterns we tested to solve this:

Sequential processing with ADF (Safe, but failed the 2-hour time limit).
2. Parallel processing with external locking/e-tags on Table Storage (Too complex and we still hit issues with inserts).
3. A "Fan-Out/Fan-In" pattern using Azure Durable Functions and Durable Entities.

We ended up going with Durable Entities. Since they act as stateful actors, they allowed us to handle the ID counter state sequentially in memory while the heavy lifting (transformation) ran in parallel. It solved the race condition issue without killing performance.

I wrote a detailed breakdown of the logic and trade-offs here if anyone is interested in the implementation details:

Data Ingestion Pipeline: A Data Engineer’s Dilemma and Azure Solutions

I am curious if others have used Durable Entities for this kind of ETL work, or if you usually rely on an external database sequence to handle ID generation in serverless setups?

Thanks,
Chameseddine

Understanding Azure AD Tenants, Users, Groups, and Roles: A Practical Guide

JohnNaguib — Wed, 26 Nov 2025 15:52:55 GMT

As cloud adoption continues to shape modern IT infrastructures, Microsoft Azure Active Directory (Azure AD)—now part of Microsoft Entra ID—has become one of the most essential identity and access management (IAM) solutions for organizations. Whether you’re setting up a brand-new cloud environment or managing a hybrid workforce, understanding how Azure AD tenants, users, groups, and roles work is fundamental to keeping your environment secure, organized, and scalable.

This guide breaks down each of these components in simple, practical terms, helping you gain the confidence to manage Azure identity services effectively.

https://dellenny.com/understanding-azure-ad-tenants-users-groups-and-roles-a-practical-guide/

How to Implement Azure AD Conditional Access Policies Step-by-Step

JohnNaguib — Wed, 26 Nov 2025 15:52:25 GMT

In today’s cloud-first world, identity is the new security perimeter. With employees logging in from different devices, locations, and networks, traditional access control is no longer enough. This is where Azure AD (now Microsoft Entra ID) Conditional Access comes in. It allows organizations to enforce automated decision-making about who can access what, under which conditions, and using which devices.

If you’ve ever wondered how to configure Conditional Access the right way, without breaking user access or causing downtime, this guide walks you through the process

https://dellenny.com/how-to-implement-azure-ad-conditional-access-policies-step-by-step/

Managing Azure AD Identity Protection: Detecting and Mitigating Risky Sign-ins

JohnNaguib — Wed, 26 Nov 2025 15:51:57 GMT

In today’s digital landscape, securing user identities is more critical than ever. Organizations leveraging cloud services, especially Microsoft Azure, face an increasing number of identity-based threats, including account compromise, phishing attacks, and unauthorized access. Azure Active Directory (Azure AD) Identity Protection provides a robust set of tools to help IT teams detect, investigate, and mitigate risky sign-ins effectively. In this blog, we’ll explore how to manage Azure AD Identity Protection, detect risky sign-ins, and implement strategies to minimize security risks.

https://dellenny.com/managing-azure-ad-identity-protection-detecting-and-mitigating-risky-sign-ins/

Azure Enterprise-Scale Landing Zone Building a Future

zahidtimon — Fri, 14 Nov 2025 17:41:43 GMT

The Role of a Software Architect in Modern Teams

JohnNaguib — Fri, 24 Oct 2025 15:59:09 GMT

In today’s fast-moving technology landscape, the role of a software architect is more important — and more nuanced — than ever before. Far from being just the “technical visionary,” modern software architects serve as bridge builders between technology, business goals, and people. They ensure that software systems are scalable, reliable, and aligned with the long-term vision of the organization.

Let’s explore how this role has evolved and why it’s so critical in modern teams

https://dellenny.com/the-role-of-a-software-architect-in-modern-teams/

What Is Software Architecture? A Practical Definition

JohnNaguib — Fri, 24 Oct 2025 15:57:53 GMT

If you’ve ever worked on a software project that grew beyond a few files, you’ve likely run into a question that every developer eventually faces: How should this be structured? That’s where software architecture comes in.

https://dellenny.com/what-is-software-architecture-a-practical-definition/

Azure Enterprise-Scale Landing Zone Building a Future-Ready Cloud Foundation

JohnNaguib — Sun, 12 Oct 2025 08:40:12 GMT

In today’s fast-paced digital landscape, enterprises are under constant pressure to innovate, scale efficiently, and maintain governance and security across their cloud environments. Microsoft Azure’s Enterprise-Scale Landing Zone (ESLZ) provides the blueprint organizations need to accelerate their cloud adoption journey while maintaining control, compliance, and agility.

https://dellenny.com/azure-enterprise-scale-landing-zone-building-a-future-ready-cloud-foundation/

What Microsoft Entra Really Means for Identity and Security

JohnNaguib — Sat, 04 Oct 2025 09:43:05 GMT

In recent years, identity has become the new perimeter. As users, devices, and applications shift beyond the walls of data centers, the classic castle-and-moat network model no longer suffices. Security increasingly hinges on who or what is accessing resources, how they authenticate, and under what conditions access is granted.

Microsoft’s launch of Microsoft Entra signals a more aggressive posture in identity, access, and zero-trust thinking. It’s not just renaming Azure Active Directory; it’s a re-alignment of how Microsoft sees identity in a hybrid, multi-cloud, and AI-driven world.

So: what does Microsoft Entra really mean — beyond the marketing — for identity and security?

https://dellenny.com/what-microsoft-entra-really-means-for-identity-and-security/

The Hybrid Cloud Playbook Mastering Azure Stack

JohnNaguib — Sat, 04 Oct 2025 09:26:44 GMT

In today’s fast-paced digital landscape, organizations face a critical challenge: how to balance the agility and scalability of the public cloud with the control and compliance benefits of on-premises infrastructure. Enter Azure Stack, Microsoft’s hybrid cloud solution, designed to bring the power of Azure into your datacenter while enabling seamless integration with the public cloud.

This blog serves as your playbook for mastering Azure Stack, guiding you through key concepts, strategies, and best practices to help your organization thrive in a hybrid cloud environment.

https://dellenny.com/the-hybrid-cloud-playbook-mastering-azure-stack/

Centralized Logging in Azure Proven Observability Patterns for Modern Apps

JohnNaguib — Tue, 16 Sep 2025 13:26:05 GMT

As modern applications move to distributed and cloud-native architectures, observability becomes critical for ensuring system reliability, diagnosing issues, and improving performance. Among the three pillars of observability—logs, metrics, and traces—logs often form the foundation for troubleshooting. However, in distributed environments, logs are scattered across multiple services, making centralized logging an essential pattern.

https://dellenny.com/centralized-logging-in-azure-proven-observability-patterns-for-modern-apps/

Web Portal - Azure architecture best practice

jimmy123 — Mon, 15 Sep 2025 09:15:58 GMT

I am seeking some ideas and challenges etc.. what else to consider..

Designing a dummy project in Azure. Needs to be secure, scalable etc.

A web portal with SQL back end and site replication for HA / DR.

Many Thanks!

Riding in Tandem Unlocking the Sidecar Pattern in Azure Microservices

JohnNaguib — Sat, 13 Sep 2025 20:24:34 GMT

In the world of cloud-native applications, microservices bring agility, scalability, and speed. But with this modular approach comes complexity: logging, monitoring, proxying, and configuration often become tricky. That’s where the Sidecar Pattern steps in — and Azure makes it easier than ever to implement.

https://dellenny.com/riding-in-tandem-unlocking-the-sidecar-pattern-in-azure-microservices/

Building a Fully Secure Architecture Integrating Azure OpenAI

JohnNaguib — Fri, 29 Aug 2025 18:42:24 GMT

As AI adoption accelerates, organizations must ensure that AI services are secure, scalable, and compliant with enterprise security policies. Azure OpenAI Service provides powerful AI capabilities, but securing access to it is crucial when integrating with applications. In this blog, we will explore how to build a fully secure architecture by integrating Azure OpenAI Service with Azure API Management (APIM), Private Endpoints, and Applications.

https://dellenny.com/building-a-fully-secure-architecture-integrating-azure-openai-with-apim-private-endpoints-and-applications/

Service Mesh Architecture Pattern in Azure

JohnNaguib — Wed, 27 Aug 2025 14:53:05 GMT

As organizations modernize applications using microservices and cloud-native architectures, managing how these services communicate becomes increasingly complex. Microservices often run across distributed environments, scaling dynamically, and interacting over the network. This is where the Service Mesh architecture pattern comes in — providing a dedicated infrastructure layer for service-to-service communication, security, and observability.

In the Azure ecosystem, implementing a Service Mesh can simplify operational challenges while improving reliability and control of microservices deployments.

https://dellenny.com/service-mesh-architecture-pattern-in-azure-handling-service-to-service-communication-security-and-observability/