5 — App Integration Services (AZ-305)

A. Messaging vs Eventing

Règle : "data flowing TO an action" → Messaging. "Notification OF an action" → Eventing.

B. Vocabulaire messaging — base

• Producer : envoie messages. Consumer : lit/traite.
• Compete consumer (queue) : 1 message = 1 consumer (N workers se partagent). Use case : load balancing tasks.
• Pub/Sub (topic) : 1 message = N consumers (chacun reçoit une copie). Use case : notifier plusieurs systèmes du même event.
• Topic = channel. Subscription = abonnement avec filtre. Chaque sub reçoit une copie filtrée.
• FIFO : ordre exact d'envoi. Sessions = FIFO par clé (orderId) → ordre strict par entité, parallèle entre entités.
• DLQ (Dead Letter Queue) : messages qui échouent N fois → atterrissent en DLQ pour inspection/replay.
• Transactions : envoyer/recevoir plusieurs messages atomiquement (tout ou rien).
• At-least-once : message arrive au moins 1 fois (peut arriver 2-3× en cas de retry). → Idempotence côté consumer obligatoire.
• Duplicate detection (Service Bus) : broker rejette doublons via MessageId dans une fenêtre.
• Load leveling : queue absorbe pics (5k/s in → 100/s out → 0 crash).
• Décorrélation : producer/consumer pas besoin d'être up en même temps.
• Buffer async : tier web rend la main <200ms, queue + worker fait le job long en background.

C. Azure Queue Storage

🎯 Présentation

Messaging simple intégré au Storage Account, compete consumer pattern. Solution low-cost pour découpler producer/consumer sans features enterprise.

🏗️ Architecture

• Queue hébergée dans un Storage Account (pas de namespace séparé)
• Compete consumer : 1 message = 1 consumer (N workers se partagent la charge)
• Accès via REST API ou SDK Azure Storage
• Pas de topics/subscriptions — file unique

🎚️ Tiers / SKU

✅ Quand l'utiliser

• Buffer simple (resize images, archive logs)
• Load leveling pour pic (Black Friday checkout)
• Notifications email différées
• Queue jobs longue durée (rapports CSV)

🚨 Pièges

• Pas de FIFO strict garanti → si requis, basculer Service Bus + sessions
• Pas de DLQ native → gestion erreurs côté code consumer
• Pas de pub/sub ni de filtres broker-side → topic = Service Bus
• Pas de duplicate detection → consumer doit être idempotent (at-least-once)
• Limite message 64 KB : payload plus gros → stocker en Blob + envoyer référence

D. Azure Service Bus

🎯 Présentation

Enterprise messaging broker avec FIFO, sessions, transactions, pub/sub, DLQ natif. Cœur des architectures messaging fiables Azure.

🏗️ Architecture

• Namespace : container régional (Basic / Standard / Premium)
• Queue : FIFO compete consumer
• Topic : pub/sub vers N subscriptions
• Subscription : filtre (SQL/Correlation/Boolean) + endpoint
• DLQ : messages morts (auto par sub/queue)

🎚️ Tiers / SKU

✅ Quand l'utiliser

• Besoin de FIFO strict (sessions par clé : orderId)
• Transactions atomiques (pop + push multi-queues)
• DLQ native + replay admin
• Pub/Sub avec filtres broker-side (SQL/Correlation)
• Scheduled messages, auto-forwarding, duplicate detection

Features clés (cas concret)

🚨 Pièges

• Basic = pas de topics → migration douloureuse si besoin pub/sub plus tard
• Geo-DR Premium : réplique structure (queues/subs/filters) mais PAS les messages en attente
• Throughput limité pour streaming massif → Event Hub si > ~1M msg/s
• Sessions = FIFO par clé, pas global → bien choisir la session key
• Transactions limitées à un namespace (pas cross-namespace)
• 🚨 Sessions vs Partitioning (Premium) : Sessions = FIFO strict par sessionId (ex: OrderCreated > Paid > Shipped ordonné par orderId). Partitioning = juste sharding pour throughput, AUCUNE garantie FIFO. "Ordre garanti par entité" → Sessions (pas Partitioning). Les 2 peuvent coexister mais le FIFO vient uniquement de Sessions.

E. Azure Event Grid

🎯 Présentation

Service eventing pub/sub pour events discrets (state changes) avec latence ms. Réagir aux changements (Azure resources, apps custom, partenaires SaaS) sans poller.

🏗️ Architecture

• Event source : Storage, Resource Mgr, IoT Hub, custom, partner SaaS
• Topic : channel
• Event : payload <1 MB
• Event handler : Functions, Logic Apps, Webhook, Event Hub, Queue, Service Bus
• Event filter : subject, type, advanced filter
• At-least-once (retries exponentiels 24h), DLQ sur Storage Account
• Push (default) ou Pull (Namespace mode)

🎚️ Tiers / SKU (Modes)

✅ Quand l'utiliser

• Réagir à un changement Azure (blob uploaded, RG deleted) → System Topics
• App émet ses propres events vers N consommateurs → Custom Topics
• SaaS multi-tenant avec ~10k+ clients à notifier → Domains ⭐
• IoT MQTT broker managé / pull delivery → Namespaces

🚨 Pièges

• Payload limit 1 MB → gros volumes data = Event Hub, pas Event Grid
• Pas de filter SQL avancé broker-side (subject/type only, ou advanced filter) — pour SQL filter complet → Service Bus Topic
• At-least-once → handler doit être idempotent
• DLQ doit être configuré explicitement (Storage Account) sinon events perdus après 24h retries
• Push delivery → endpoint cible doit être public OU dans VNet (Premium)

F. Azure Event Hubs

🎯 Présentation

Plateforme de streaming massif (millions events/sec) pour telemetry, logs, IoT, click-stream. Équivalent Kafka managé sur Azure.

🏗️ Architecture

• Namespace : container régional
• Event Hub : équivalent Kafka topic
• Partitions : 1-32 Standard, 1024 Premium (parallel consumption)
• Consumer group : vue indépendante du stream (1 = 1 reader avec curseur)
• TU/PU/CU : capacity units (Standard/Premium/Dedicated)
• Capture auto-archive vers Blob/ADLS (Avro/Parquet)
• Schema Registry, Kafka protocol compat, Geo-DR async

🎚️ Tiers / SKU

✅ Quand l'utiliser

• Streaming big data : telemetry IoT, logs apps, click-stream
• Kafka workloads sur Azure sans gérer cluster (Standard min)
• Ingest pour Stream Analytics / Synapse / Databricks
• VNet integration → Premium min

• 10 GB/s soutenu ou HSM-grade isolation → Dedicated

🚨 Pièges

• Basic : 1 consumer group seulement → impossible d'avoir plusieurs apps consommatrices
• Partition count immuable après création (Standard) → choisir large dès le début
• Pas de pub/sub broker-side filter → filtering côté consumer
• Retention Standard max 7j → archivage long terme = Capture vers Blob/ADLS
• Sur-dimensionné pour faible volume (100 msg/j) → préférer Service Bus

G. Azure IoT Hub

G.1 C'est quoi

Service managé pour devices IoT avec communication bidirectionnelle (devices ↔ cloud). C'est l'équivalent IoT-spécifique d'Event Hub mais avec des features devices natives.

G.2 IoT Hub vs Event Hub ⭐⭐ (le seul piège 305)

🎯 "Devices doivent recevoir des commandes / updates de config" → IoT Hub. 🎯 "Telemetry massive unidirectionnelle → analytics" → Event Hub.

H. SignalR Service + Notification Hubs (light awareness)

H.1 Azure SignalR Service

Service managé pour real-time bidirectional (WebSocket / Server-Sent Events / Long Polling) sans gérer scale ni connection management.

Use cases AZ-305 :

• Chat temps-réel multi-utilisateurs
• Live dashboards (Power BI live tile)
• Notifications push web (push-to-browser)
• Collaborative apps (Google Docs-like)
• Live sports / trading scoreboard

H.2 Azure Notification Hubs

Service push notifications mobiles cross-platform : iOS (APNS), Android (FCM), Windows, Amazon Kindle, Baidu (China).

Use cases AZ-305 :

• Push notifs mobile à des millions d'users
• Targeting par tags (geo, user segment, language)
• Schedule notifs
• Multi-platform unified API

H.3 Decision rapide

• "Real-time browser, chat, dashboard" → SignalR Service
• "Push notifs mobile iOS+Android" → Notification Hubs
• "Devices IoT bidirectionnels" → IoT Hub

I. Decision Messaging/Eventing/Streaming AZ-305 ⭐⭐

Comparaison rapide

Anti-patterns

J. Azure API Management (APIM)

🎯 Présentation

Gateway façade managée centralisant security, throttling, transformation, analytics, doc OpenAPI sur N backends. Évite la duplication auth/rate-limit dans chaque microservice.

🏗️ Architecture

• API : interface logique (REST/SOAP/GraphQL/WebSocket)
• Backend : où tape l'API (App Service, Function, AKS, FQDN)
• Product : bundle d'APIs avec subscription key
• Policies ⭐ : XML transformations in/out flow (validate-jwt, rate-limit, cache, transform, circuit-breaker)
• Developer portal : self-service devs (OpenAPI auto)

[Clients] → [APIM Gateway] (auth/throttle/cache/log) → [Microservices privés via PE]

🎚️ Tiers / SKU (v2, 2026)

✅ Quand l'utiliser

• ≥ 2 backends exposés + besoin auth/rate-limit/monitoring centralisé
• 1 DNS/cert SSL pour N microservices, versioning d'APIs
• Mock-response (frontend dev avant backend ready)
• Backends privés via Private Endpoint + zero-trust
• Compliance VNet/AZ multi-region → Premium v2

Policies clés

• Auth : validate-jwt, validate-azure-ad-token, OAuth2, mTLS
• Rate limit / quota : rate-limit-by-key, quota-by-key
• CORS / IP filter, Mock response
• Caching : cache-lookup / cache-store
• Transform : set-header, set-body, xml-to-json
• Backend : set-backend-service, circuit-breaker

K. Azure Logic Apps

🎯 Présentation

Workflow orchestration low-code visual avec 1000+ connectors (M365, SAP, Salesforce). Automatise les processus métier sans écrire de code.

🏗️ Architecture

• Trigger : HTTP, Schedule, Event Grid, Service Bus, connector SaaS
• Actions : call API, transform, send mail, Function, conditional, loop
• Connectors : built-in (HTTP) ou Managed (1000+ : M365, SAP, Salesforce, ServiceNow)
• Designer visuel + JSON workflow (code-behind)
• Run history pour debug

🎚️ Tiers / SKU

✅ Quand l'utiliser

• Workflow low-code, intégrations SaaS (M365, SAP, Salesforce)
• Collab business owner ↔ IT (designer visuel)
• Schedule-based jobs avec connectors prêts à l'emploi
• Standard si VNet integration / perf max / multi-workflow par plan
• Pour orchestration code-first complexe haute perf → Durable Functions plutôt

Logic Apps vs Durable Functions

🎯 On-premises Data Gateway (piège MeasureUp) : permet à Logic Apps / Power Platform d'accéder à une ressource on-prem (DB, fichiers) sans l'exposer à Internet (agent on-prem = connection broker, outbound only). → "Logic App doit lire une DB on-prem sans accès Internet" = on-prem data gateway. (utiliser Azure Relay quand on expose une API plutot qu'un workflow)

L. Patterns AZ-305

Producer-Consumer (Buffer)

[Producer] → [Queue/Service Bus] → [Worker (Function/VMSS)]

Pub/Sub (Fan-out)

[Event source] → [Service Bus Topic OR Event Grid] → [N Subscribers]

Streaming Analytics

[Devices] → [Event Hub] → [Stream Analytics / Databricks] → [Power BI / SQL]

IoT bidirectionnel

[Devices IoT] ←→ [IoT Hub Standard] ←→ [Backend + Device Twin sync]
                       ↓ message routing
                  [Event Hub / Service Bus / Storage]

API Façade

[Clients] → [APIM] → [Microservices (App Service / AKS / Functions)]

Workflow Orchestration

[Trigger] → [Logic App] → actions (parallel/sequential, branches, loops)

M. Azure Cache for Redis & Azure Managed Redis (caching)

🎯 Présentation

Cache distribué in-memory managé pour sessions multi-instance, accélération DB, rate limiting, distributed lock. Objectif AZ-305 "Recommend a caching solution for applications".

🏗️ Architecture

• Cache key-value in-memory (sub-ms latency)
• Patterns : session store, output cache, data cache, pub/sub léger, rate limiting, distributed lock
• Accès via Redis protocol (SDK StackExchange.Redis, lettuce, etc.)
• Azure Managed Redis = remplaçant moderne (zone redundancy + persistence + modules + active geo-rep par défaut, 1 DB seulement, TLS XOR non-TLS)

⚠️ Retrait Cache for Redis 2026-2028 (annonce oct 2025)

Azure Cache for Redis retire tous SKUs. Remplaçant : Azure Managed Redis.

• 1 avril 2026 : new caches bloquées (Enterprise/Flash all, Basic/Std/Prem new customers)
• 31 mars 2027 : Enterprise/Flash migrés
• 1 oct 2028 : Basic/Std/Prem éteints

Nouveaux projets 2026+ → Azure Managed Redis ⭐

🎚️ Tiers / SKU

Cache for Redis (legacy) — 5 tiers :

🚨 Pièges

• Basic en prod → pas de SLA, data perdue si panne
• Geo-rep passive (Premium classique) = read-only secondary → app gère failover manuel. Active = Enterprise / Managed Redis only.

🌐 Caching DONNÉES (Redis) vs caching CONTENU (CDN/Front Door)

💡 Le caching AZ-305 a 2 familles : Redis = cache de DONNÉES (sessions, résultats DB, in-memory) ; CDN/Front Door = cache de CONTENU (fichiers statiques, images, JS/CSS) au bord du réseau (edge), proche des users.

🎯 Réflexes : "sessions/données backend" → Redis · "contenu statique users mondiaux" → Front Door / CDN · "front global app + WAF + cache" → Front Door (fiche 6).

N. Azure App Configuration (centralized config + feature flags)

🎯 Présentation

Service managé pour centraliser config (key-values), feature flags, et références Key Vault. Élimine la config éparpillée multi-services/multi-env qui force des redéploiements. Objectif AZ-305 "Recommend an application configuration management solution".

🏗️ Architecture

• Key-value pairs avec labels env (dev/prod), hiérarchie via préfixes
• Feature flags (UI Feature Manager : % rollout, targeting groups, time windows)
• Key Vault references : secrets dans KV, référencés depuis App Config — app code lit 1 endpoint unique
• Snapshots & point-in-time (replay 7j), soft-delete (Standard+), refresh dynamique (default 30s TTL)
• Auth recommandée : Managed Identity + rôle App Configuration Data Reader

✅ Quand l'utiliser

• Microservices K8s : 1 App Config partagé, pas de config baker dans image
• Multi-env : labels dev/staging/prod, 1 store N envs
• A/B testing & canary : feature flag avec % filter
• Compliance kill-switch : disable feature instantanément sans redéploiement
• Combo recommandé : secrets → KV, config + feature flags → App Config (référence KV)

App Config vs Key Vault

Règle d'or : Secrets → KV. Config + feature flags → App Config. KV référencé depuis App Config (1 endpoint côté app).

O. Scénarios 305 → solution ⭐⭐

DEMO

Demo Portail — Service Bus Topic + Subs (e-commerce)

1. Service Bus > Create → RG rg-shop, Namespace sb-shop-prod, Tier Standard → Review + Create
2. sb-shop-prod > Topics > + Topic :
   • Name : orders-events
   • Enable duplicate detection : ON
   • Duplicate detection history : 10 min
   • Create
3. Pour chaque sub (inventory, billing, shipping) : orders-events > Subscriptions > + Subscription → Max delivery count 5
4. Filter SQL sur inventory : sélectionner sub → Default rule → Filter type SQL → expression eventType = 'OrderPlaced' → Save

CLI équivalent (pour IaC) :

az servicebus topic create -g rg-shop --namespace-name sb-shop-prod -n orders-events \
  --enable-duplicate-detection true --duplicate-detection-history-time-window PT10M
az servicebus topic subscription rule create -g rg-shop --namespace-name sb-shop-prod \
  --topic-name orders-events --subscription-name inventory \
  --name OrderPlacedFilter --filter-sql-expression "eventType = 'OrderPlaced'"

Demo Portail — Event Grid Storage Blob → Function

1. Storage accounts > sashoploads > Events > + Event Subscription
2. Name : csv-uploaded-trigger, Event Schema : Event Grid Schema
3. Event Types : cocher uniquement Blob Created
4. Endpoint Type : Azure Function → sélectionner func-csv-parser > ParseCsv
5. Onglet Filters :
   • Subject Begins With : /blobServices/default/containers/uploads/
   • Subject Ends With : .csv
6. Onglet Additional Features : Max delivery attempts 30, Dead-letter Storage (optionnel)
7. Create

CLI équivalent (pour IaC) :

az eventgrid event-subscription create --name csv-uploaded-trigger \
  --source-resource-id $(az storage account show -g myrg -n sashoploads --query id -o tsv) \
  --endpoint-type azurefunction --endpoint $FUNC_ID \
  --included-event-types Microsoft.Storage.BlobCreated \
  --subject-begins-with "/blobServices/default/containers/uploads/" --subject-ends-with ".csv"

Demo Portail — Event Hub + Capture

1. Event Hubs > Create namespace → RG myrg, Namespace myns, Tier Standard, TU 1 → Review + Create
2. myns > + Event Hub :
   • Name : myhub
   • Partition Count : 4, Message Retention : 7j
   • Section Capture : ON → Time 300s, Size 300 MB, Storage mystorage, container mycontainer, format Avro
   • Create

CLI équivalent (pour IaC) :

az eventhubs eventhub update -g myrg --namespace-name myns -n myhub \
  --enable-capture true --capture-interval 300 --capture-size-limit 314572800 \
  --destination-name EventHubArchive.AzureBlockBlob \
  --storage-account /subscriptions/.../mystorage --blob-container mycontainer

📚 DEMO IoT Hub + DPS détaillée = AZ-220 (IoT Specialty), pas AZ-305.

APIM Premium v2 — policy validate-jwt + rate-limit

<inbound>
  <validate-jwt header-name="Authorization" failed-validation-httpcode="401">
    <openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" />
  </validate-jwt>
  <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription.Id)" />
</inbound>

Logic App Standard

1. Logic Apps > Create > Plan = Standard (single-tenant, VNet) ou Consumption (pay-per-exec)
2. Storage Account requis (Standard), Plan WS1/WS2/WS3, VNet injection optionnelle
3. Workflows > + Add : Stateful (durable, history) ou Stateless (latence basse)
4. Designer : Trigger + Actions
5. Run history pour debug

Demo Portal — Azure Managed Redis + Private Endpoint

1. Create resource > Azure Managed Redis
2. Basics : Name, region, Cache type (Balanced/Memory Optimized/Compute Optimized/Flash Optimized)
3. Cache size selon besoin
4. Networking : Private Endpoint + Private DNS zone privatelink.redis.azure.net
5. Advanced : TLS port (TLS XOR non-TLS), Clustering policy OSS ou Enterprise, Modules optionnels
6. High availability : Enabled (zone-redundant par défaut si région supporte AZ)
7. Review + Create → Auth via Entra ID (recommandé) ou Access keys

Demo Portal — App Config + KV reference

1. Create resource > App Configuration
2. Basics : Name, region, Pricing tier : Standard
3. Networking : Private Endpoint si compliance
4. Encryption : Microsoft-managed (default) ou CMK
5. Review + Create
6. Configuration explorer > + Create > Key-value pour ajouter clés
7. Feature manager > + Create > Feature flag : EnableNewCheckout, Enable ON/OFF, ajouter Feature filter (Targeting/Percentage/Time)
8. Key Vault reference : Configuration explorer > + Create > Key vault reference → Key + Subscription/KV/Secret
9. Access control (IAM) : rôle App Configuration Data Reader à la MI de l'app