Lesson 1: Azure Integration Services on One Page

Why start with one page?

You've been asked to connect two applications by Friday. An order system has to tell a warehouse system that something happened, a partner wants an API, and someone in finance wants an approval step. Azure gives you at least eight services that can each "connect things". Each one has a home page that makes it sound like the answer. The most common mistake I see from experienced engineers is to pick the service they used last time. Usually that's Event Hubs for people coming from data work, or a Logic App for people who like the designer.

So before we compare anything, we put every service on one page and group it by the job it does. Think of a post office. Some counters hold parcels until you collect them (queues). Some send one newsletter to many subscribers (publish-subscribe). Some ring a bell when something changes (event routing). Some run a multi-step process (workflow). Some act as the front desk for outside visitors (API management). Some build a tunnel into a building that has no public door (hybrid relay).

The map

Two things to notice. First, Service Bus appears twice, because queues and topics are different jobs on the same namespace. Second, Event Grid has two personalities. The basic tier does push routing, and it's the only tier that can subscribe to Azure system events and partner events. The standard tier (namespaces) adds MQTT, pull delivery and 7-day retention.

Old names you'll meet in old docs and Terraform

Integration services have been renamed and re-platformed many times. When a blog post from 2018 or an inherited module uses a name you don't recognise, look it up here:

Gotcha: "v2" in API Management is overloaded. stv2 is the compute platform under the classic Developer, Basic, Standard and Premium tiers. The v2 tiers are separate SKUs, and today they're only available as new instances. There's no automated upgrade from classic.

Walkthrough: find what you already run

Before you choose anything new, take stock of what's already in your subscription. Every service on the map has its own ARM resource type:

# List integration resources in the current subscription, grouped by type
az resource list \
  --query "[?contains('Microsoft.ServiceBus/namespaces Microsoft.EventGrid/topics Microsoft.EventGrid/systemTopics Microsoft.EventGrid/domains Microsoft.EventGrid/namespaces Microsoft.EventHub/namespaces Microsoft.Logic/workflows Microsoft.ApiManagement/service Microsoft.Relay/namespaces', type)].{name:name, type:type, rg:resourceGroup}" \
  --output table

# Logic Apps Standard and Durable Functions both live under Microsoft.Web/sites,
# so filter on 'kind' to tell them apart
az resource list --resource-type Microsoft.Web/sites \
  --query "[].{name:name, kind:kind}" -o table

The output looks something like this:

Name              Type                              Rg
----------------  --------------------------------  --------
sb-orders-prod    Microsoft.ServiceBus/namespaces   rg-core
eg-blob-events    Microsoft.EventGrid/systemTopics  rg-core
logic-invoice     Microsoft.Logic/workflows         rg-fin    # Consumption
apim-public       Microsoft.ApiManagement/service   rg-edge
relay-onprem      Microsoft.Relay/namespaces        rg-hybrid

Name             Kind
---------------  ------------------------
la-std-partners  functionapp,workflowapp   # Logic Apps Standard
fn-orchestrator  functionapp               # may host Durable Functions

Note: Queue Storage doesn't show up as its own type. It lives inside Microsoft.Storage/storageAccounts, so check for queues on each storage account. Durable Functions isn't a resource either. It's an extension inside a Function App, and you'll only find it by reading the code or the host.json file.

Integrating applications is not streaming data

If you've done the analytics course, Event Hubs feels like home. Resist that pull. Microsoft's own comparison draws the line clearly:

• Event: a lightweight notification. The publisher has no expectation about what happens next. Events come either as discrete events ("order 1042 shipped"), which suit Event Grid, or as a time-ordered series ("temperature every second"), which suits Event Hubs.
• Message: high-value data with a contract between sender and receiver. "Charge this card and tell me when it's done" belongs in Service Bus.

Event Hubs keeps order within a partition, and it can replay a stream through Capture. But it has no dead-lettering and no duplicate detection. Service Bus has both, and it adds transactions. When one application commands another, a single lost or doubled message costs real money, and that's the job a broker is built for. Streaming is built for volume and replay, not for handling each message correctly.

Best practice: Real systems use several services together. An online shop might use Service Bus for orders, Event Grid to react to "item shipped", and Event Hubs for site telemetry. One page helps you choose a service for each job, not one service for every job.

Key takeaways

• Group services by job: queues (Service Bus, Queue Storage), publish-subscribe (Service Bus topics, Event Grid namespaces), event routing (Event Grid basic), workflow (Logic Apps, Durable Functions), API management (APIM), and connectors and hybrid relay (Logic Apps connectors, Azure Relay).
• Event Hubs is the streaming neighbour. Use it for high-volume, time-ordered data, not for commands between applications.
• Service Bus Relay became Azure Relay. ISE was retired on 31 Aug 2024, and Logic Apps Standard replaces it. The legacy Service Bus SDKs and SBMP were retired on 30 Sep 2026.
• In API Management, the v2 tiers (Basic, Standard and Premium v2) are not the same thing as the stv2 platform.
• Run an inventory with az resource list before you design anything new.