Azure Integration & Application Platform Azure Integration & Application Platform

Technische Referenz zu Logic Apps, Service Bus, Event Grid, Event Hubs, API Management, IoT-Diensten, Static Web Apps, SignalR, Web PubSub, Communication Services, Azure AI/AML, AKS, ACR, Container Apps, Azure Migrate, Site Recovery und DMS. Technical reference for Logic Apps, Service Bus, Event Grid, Event Hubs, API Management, IoT services, Static Web Apps, SignalR, Web PubSub, Communication Services, Azure AI/AML, AKS, ACR, Container Apps, Azure Migrate, Site Recovery, and DMS.

Service-Auswahl: Logic Apps, Service Bus, Event Grid, Event Hubs und API Management Service selection: Logic Apps, Service Bus, Event Grid, Event Hubs, and API Management

Azure bietet mehrere Integrationsdienste mit bewusst unterschiedlichen Semantiken. Logic Apps orchestrieren Workflows und Connectoren, Service Bus liefert geschäftskritische Messaging-Garantien, Event Grid verteilt reaktive Ereignisse, Event Hubs nimmt Hochdurchsatz-Streams auf, und API Management kontrolliert den synchronen Vertragsrand. Azure offers multiple integration services with deliberately different semantics. Logic Apps orchestrate workflows and connectors, Service Bus provides business-critical messaging guarantees, Event Grid distributes reactive events, Event Hubs ingests high-throughput streams, and API Management controls the synchronous contract edge.

Die häufigste Fehlentscheidung ist, einen Dienst für alle Integrationsprobleme verwenden zu wollen. Gute Plattformarchitekturen akzeptieren stattdessen, dass Workflow, Command, Event, Stream und API unterschiedliche Betriebs- und Fehlermodelle brauchen. The most common mistake is trying to use one service for every integration problem. Strong platform architectures instead accept that workflows, commands, events, streams, and APIs need different operating and failure models.

• Commands mit fachlichem Wert eher über Service Bus statt über Event Grid senden. Send business commands through Service Bus rather than Event Grid.
• Event Grid für lose gekoppelte Reaktionen und Fan-out einsetzen. Use Event Grid for loosely coupled reactions and fan-out.
• Event Hubs für hohe Ereignisraten und Stream-Verarbeitung wählen. Choose Event Hubs for high event rates and stream processing.
• Logic Apps dort nutzen, wo Konnektoren, menschliche Freigaben oder Prozessorchestrierung dominieren. Use Logic Apps where connectors, human approvals, or process orchestration dominate.
• API Management als Sicherheits- und Vertragskante vor APIs platzieren. Place API Management as the security and contract edge in front of APIs.

Service-Auswahl nach Semantik Selecting services by semantics

Die Wahl zwischen Queue, Topic, Event und Stream sollte von Zustellgarantie, Reihenfolge, Replay-Bedarf, Ereignisvolumen und Ownership-Grenzen abhängen. Latenz allein ist kein tragfähiges Auswahlkriterium. Choosing between queue, topic, event, and stream should depend on delivery guarantees, ordering, replay needs, event volume, and ownership boundaries. Latency alone is not a durable selection criterion.

Identität, Netzwerk und Private Endpoints Identity, networking, and private endpoints

Fast alle Integrationsdienste unterstützen Entra ID, Managed Identities, Private Endpoints und IP- oder VNet-Kontrollen. Diese Optionen sollten früh bewertet werden, weil sie Durchsatz, Betriebsmodell und Deployment-Pipelines beeinflussen. Almost all integration services support Entra ID, managed identities, private endpoints, and IP or VNet controls. These options should be evaluated early because they influence throughput, operations, and deployment pipelines.

Fehlermodelle bewusst designen Design failure models consciously

Retry, Backoff, Idempotenz, Poison-Message-Handling, Replay und Observability müssen pro Dienst explizit gestaltet werden. Ohne diese Festlegungen wird aus Entkopplung sehr schnell operative Intransparenz. Retry, backoff, idempotency, poison-message handling, replay, and observability must be designed explicitly per service. Without them, decoupling quickly turns into operational opacity.

Logic Apps: Consumption, Standard, Connectoren, B2B und Resilienz Logic Apps: Consumption, Standard, connectors, B2B, and resiliency

Logic Apps Consumption ist ein hochgradig serverloses Modell für event- oder triggergetriebene Integrationsworkflows. Logic Apps Standard bringt dagegen eine Single-Tenant-Runtime auf App-Service-Basis, lokale Projektstruktur, besseren DevOps-Fit, VNet-Integration und mehrere Workflows pro Instanz. Logic Apps Consumption is a highly serverless model for event- or trigger-driven integration workflows. Logic Apps Standard provides a single-tenant App Service-based runtime, local project structure, stronger DevOps fit, VNet integration, and multiple workflows per instance.

Die Wahl hängt von Betriebsmodell, Isolation, Connector-Bedarf, Netzwerkanforderungen, Laufzeitprofil und CI/CD-Ansprüchen ab. Standard ist häufig die bessere Plattformwahl für produktive Integrationslösungen, Consumption kann aber für kleinere, klar abgegrenzte Flows wirtschaftlicher sein. The choice depends on operating model, isolation, connector needs, networking requirements, runtime profile, and CI/CD expectations. Standard is often the better platform choice for production integration solutions, while Consumption can be more economical for smaller, clearly bounded flows.

• Standard bevorzugen, wenn VNet-Integration, DevOps-Disziplin oder höhere Isolation gefordert sind. Prefer Standard when VNet integration, DevOps discipline, or stronger isolation is required.
• Connector-Limits, Polling-Kosten und API-Limits immer in die Prozessarchitektur einbeziehen. Always include connector limits, polling cost, and API limits in process architecture.
• Fehlerpfade mit Retry-Policies, Compensating Actions und Dead-Letter-Ersatzmustern entwerfen. Design failure paths with retry policies, compensating actions, and dead-letter substitute patterns.
• B2B-Szenarien benötigen früh abgestimmte Partnerverträge, Zertifikate und EDI-Standards. B2B scenarios require partner agreements, certificates, and EDI standards to be aligned early.
• Workflow-Historie und Diagnose müssen in das zentrale Monitoring-Modell eingebunden werden. Workflow history and diagnostics must be integrated into the central monitoring model.

Logic Apps Standard als Plattformbaustein Logic Apps Standard as a platform building block

Logic Apps Standard eignet sich für produktive Integrationsplattformen mit VNet-Anforderungen, wiederverwendbaren Workflows, Quellcodeverwaltung und DevOps-Pipelines. Die Runtime nähert sich dadurch stärker klassischen App-Plattformmustern an. Logic Apps Standard is well suited for production integration platforms with VNet requirements, reusable workflows, source control, and DevOps pipelines. The runtime therefore behaves more like a classic application platform.

resource logicApp 'Microsoft.Web/sites@2023-12-01' = {
  name: 'la-standard-orders-prod'
  location: location
  kind: 'functionapp,workflowapp'
  properties: {
    serverFarmId: plan.id
    httpsOnly: true
  }
}
        

B2B, EDI und Integration Account B2B, EDI, and integration account

Für EDIFACT-, X12- oder AS2-Szenarien sind Partnervereinbarungen, Zertifikate, Schemas und Maps nicht nachgelagerte Details, sondern Kernbestandteile der Integrationsarchitektur. Governance für Zertifikatsrotation und Testpartner gehört von Anfang an dazu. For EDIFACT, X12, or AS2 scenarios, partner agreements, certificates, schemas, and maps are not afterthoughts, but core parts of the integration architecture. Governance for certificate rotation and test partners belongs in the design from the start.

Resiliente Workflows Resilient workflows

Resilienz in Logic Apps entsteht durch Trigger-Strategie, Parallelitätsgrenzen, Fehlerpfade, Timeouts und kompensierende Aktionen. Gerade bei langen Orchestrierungen ist klar definierte Wiederanlauf-Logik wichtiger als ein einzelner Connector-Schritt. Resilience in Logic Apps comes from trigger strategy, concurrency limits, failure paths, timeouts, and compensating actions. Especially for long-running orchestrations, clearly defined resume logic matters more than any single connector step.

{
  "type": "Http",
  "inputs": {
    "method": "POST",
    "retryPolicy": {
      "type": "exponential",
      "count": 5,
      "interval": "PT10S"
    }
  }
}
        

Messaging Backbone: Service Bus, Event Grid und Event Hubs Messaging backbone: Service Bus, Event Grid, and Event Hubs

Service Bus, Event Grid und Event Hubs lösen drei unterschiedliche Problemklassen. Service Bus ist der robuste Geschäftsbus für Commands und Aufträge, Event Grid verteilt Ereignisse mit reaktiver Kopplung, und Event Hubs bildet das Streaming-Rückgrat für Telemetrie oder High-Volume-Ereignisse. Service Bus, Event Grid, and Event Hubs solve three different problem classes. Service Bus is the robust business bus for commands and jobs, Event Grid distributes events with reactive coupling, and Event Hubs forms the streaming backbone for telemetry or high-volume events.

Architektonisch sind Topics, Sessions, Duplicate Detection, DLQs, Event-Schema-Versionierung, Consumer Groups, Replay und Capture keine Betriebsdetails, sondern Kernbestandteile des Designs. Wer sie ignoriert, verlagert Komplexität nur in spätere Incidents. Architecturally, topics, sessions, duplicate detection, DLQs, event schema versioning, consumer groups, replay, and capture are not operational details but core design elements. Ignoring them only shifts complexity into later incidents.

• Service Bus für zustandskritische Commands und geschäftliche Arbeitsaufträge einsetzen. Use Service Bus for state-critical commands and business work items.
• Event Grid für lose gekoppelte, reaktive Benachrichtigungen und Fan-out verwenden. Use Event Grid for loosely coupled reactive notifications and fan-out.
• Event Hubs für Telemetrie, Clickstream und Streaming-Pipelines reservieren. Reserve Event Hubs for telemetry, clickstream, and streaming pipelines.
• DLQ, Replay und Poison-Message-Strategien im Betriebsmodell verankern. Embed DLQ, replay, and poison-message strategies in the operating model.
• Entra ID und Private Endpoints früh mitdenken, weil sie Client- und Netzwerkdesign beeinflussen. Consider Entra ID and private endpoints early because they influence client and network design.

Service Bus für Commands, Sagas und Dead-Letter-Handling Service Bus for commands, sagas, and dead-letter handling

Service Bus ist ideal für fachlich wertvolle Nachrichten mit Zustellgarantien, Sessions, verzögerter Zustellung und nachvollziehbarer Fehlerbehandlung. DLQs, Duplicate Detection und Message Lock Renewal gehören dabei in jedes Betriebsmodell. Service Bus is ideal for business-important messages with delivery guarantees, sessions, scheduled delivery, and traceable error handling. DLQs, duplicate detection, and message lock renewal should be part of every operating model.

az servicebus queue create
  --resource-group rg-int-prod
  --namespace-name sb-orders-prod
  --name orders-in
  --enable-duplicate-detection true
  --max-delivery-count 10
        

Event Grid für reaktive Ereignisse Event Grid for reactive events

Event Grid passt hervorragend zu reaktiven Plattformmustern wie Blob-Events, Ressourcenänderungen, Integrationsfan-out oder Domain Events mit vielen Konsumenten. Schema-Versionierung und idempotente Subscriber bleiben trotzdem Pflicht. Event Grid fits reactive platform patterns such as blob events, resource changes, integration fan-out, or domain events with many consumers. Schema versioning and idempotent subscribers remain mandatory.

az eventgrid event-subscription create
  --name orders-created-sub
  --source-resource-id /subscriptions/000.../resourceGroups/rg-app/providers/Microsoft.Storage/storageAccounts/storders
  --endpoint-type webhook
  --endpoint https://api.contoso.com/events/orders-created
        

Event Hubs für Telemetrie und Streaming Event Hubs for telemetry and streaming

Event Hubs ist für hohe Ereignisraten und Streaming-Verarbeitung optimiert. Partitionierung, Throughput Units oder Processing Units, Consumer Groups, Capture und Schema Registry sollten vor dem ersten Lasttest festgelegt sein. Event Hubs is optimized for high event rates and stream processing. Partitioning, throughput units or processing units, consumer groups, capture, and schema registry should be decided before the first load test.

az eventhubs eventhub create
  --resource-group rg-int-prod
  --namespace-name eh-telemetry-prod
  --name devices-stream
  --partition-count 8
  --message-retention 3
        

API- und Web-Ebene: API Management, Static Web Apps, SignalR, Web PubSub und Communication Services API and web layer: API Management, Static Web Apps, SignalR, Web PubSub, and Communication Services

API Management bildet die kontrollierte Vertragskante für APIs: Authentifizierung, Autorisierung, Versionierung, Ratenbegrenzung, Caching, Transformationen und Developer Experience. Static Web Apps ergänzt dies auf der Frontend-Seite mit globalem Hosting, GitOps-Deployment und integrierten Auth-Optionen. API Management forms the controlled contract edge for APIs: authentication, authorization, versioning, rate limiting, caching, transformations, and developer experience. Static Web Apps complements that on the frontend side with global hosting, GitOps deployment, and integrated authentication options.

Für Echtzeit-Szenarien kommen SignalR Service, Azure Web PubSub und Communication Services hinzu. Dabei entscheidet das Kommunikationsmuster: SignalR ist stark für Hub-zentrierte App-Echtzeit, Web PubSub für generische WebSocket-Fan-out-Szenarien, und Communication Services für Omnichannel-Kommunikation mit Sprache, Chat oder SMS. For real-time scenarios, SignalR Service, Azure Web PubSub, and Communication Services join the picture. The deciding factor is the communication pattern: SignalR is strong for hub-centered app real time, Web PubSub for generic WebSocket fan-out scenarios, and Communication Services for omnichannel communication with voice, chat, or SMS.

• API Management vor externe oder partnerfähige APIs stellen. Place API Management in front of external or partner-facing APIs.
• Policies versionieren und in CI/CD mitführen. Version policies and carry them through CI/CD.
• Static Web Apps für Frontends mit einfacher globaler Bereitstellung und Entra-Integration nutzen. Use Static Web Apps for frontends that need simple global deployment and Entra integration.
• SignalR oder Web PubSub nach Kommunikationsmuster statt nach Marketingbegriff wählen. Choose SignalR or Web PubSub based on the communication pattern rather than the marketing label.
• Communication Services früh mit Datenschutz- und Aufbewahrungsanforderungen abstimmen. Align Communication Services early with privacy and retention requirements.

API Management Policies und Zero-Trust-Rand API Management policies and the zero-trust edge

API Management ermöglicht mTLS, OAuth/OIDC, Quoten, Header-Transformation, Caching, Backend-Routing und Entwicklerportale. Für produktive Plattformen sollten Policies versioniert, wiederverwendet und nach Domänenverantwortung strukturiert sein. API Management enables mTLS, OAuth/OIDC, quotas, header transformation, caching, backend routing, and developer portals. For production platforms, policies should be versioned, reusable, and structured by domain responsibility.

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

Static Web Apps für Frontend + API Static Web Apps for frontend plus API

Static Web Apps eignet sich besonders für SPA- oder Jamstack-Szenarien mit GitHub- oder Azure-DevOps-Workflow, globaler Auslieferung und einfacher Preview-Umgebungslogik. Entscheidend ist die saubere Trennung zwischen Frontend-Konfiguration, API-Zugriff und Umgebungsgeheimnissen. Static Web Apps is especially suitable for SPA or Jamstack scenarios with GitHub or Azure DevOps workflows, global delivery, and easy preview-environment logic. The key is a clean split between frontend configuration, API access, and environment secrets.

{
  "routes": [
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "navigationFallback": {
    "rewrite": "/index.html"
  }
}
        

SignalR, Web PubSub und ACS korrekt einordnen Place SignalR, Web PubSub, and ACS correctly

SignalR passt gut zu hub-zentrierter App-Echtzeit mit starkem Framework-Fit, während Web PubSub für generische WebSocket-Kommunikation oder sehr große Fan-out-Szenarien attraktiv ist. Communication Services erweitert dies um echte Kommunikationskanäle wie Chat, Sprache oder SMS. SignalR fits hub-centric application real time with strong framework alignment, while Web PubSub is attractive for generic WebSocket communication or very large fan-out scenarios. Communication Services extends the picture with real communication channels such as chat, voice, or SMS.

const client = new WebPubSubClient(tokenUrl);
await client.start();
client.on('group-message', e => console.log(e.message));
await client.joinGroup('ops-dashboard');
await client.sendToGroup('ops-dashboard', 'deployment-started');
        

IoT-Plattform: IoT Hub, IoT Central, Digital Twins und Azure Sphere IoT platform: IoT Hub, IoT Central, Digital Twins, and Azure Sphere

IoT Hub ist der skalierbare Geräteeinstieg für Telemetrie, Cloud-to-Device-Kommandos, Device Twins, sichere Identitäten und Protokoll-Gateways. IoT Central abstrahiert viele Plattformdetails für lösungsnahe IoT-Anwendungen mit Dashboards, Regeln und Gerätevorlagen. IoT Hub is the scalable device entry point for telemetry, cloud-to-device commands, device twins, secure identities, and protocol gateways. IoT Central abstracts many platform details for solution-oriented IoT applications with dashboards, rules, and device templates.

Azure Digital Twins modelliert physische Umgebungen als graphbasierte Beziehungen mit DTDL. Azure Sphere ergänzt die Edge-Sicherheitsseite durch geschützte MCU-Geräte, ein sicheres OS und cloudgestützte Sicherheitsdienste für hochsensitives oder langlebiges Edge-Design. Azure Digital Twins models physical environments as graph-based relationships using DTDL. Azure Sphere adds the edge security side through protected MCU devices, a secure OS, and cloud-backed security services for highly sensitive or long-lived edge designs.

• Device Provisioning Service und Zertifikatsstrategie früh festlegen. Define device provisioning service and certificate strategy early.
• Routing, Enrichment und nachgelagerte Analytics-Pfade in IoT Hub explizit modellieren. Model routing, enrichment, and downstream analytics paths explicitly in IoT Hub.
• IoT Central wählen, wenn Business Time-to-Value wichtiger als maximale Plattformfreiheit ist. Choose IoT Central when business time-to-value matters more than maximum platform freedom.
• Digital-Twin-Modelle versionieren und nach Ownership-Domänen strukturieren. Version digital twin models and structure them by ownership domains.
• Azure Sphere für Geräte mit hohen Sicherheits- und Wartungsanforderungen bewerten. Evaluate Azure Sphere for devices with high security and maintenance requirements.

IoT Hub für Geräteeinstieg und Routing IoT Hub for device entry and routing

IoT Hub verbindet sichere Geräteidentitäten mit Telemetrie, Commands und Device Twins. Besonders wichtig sind Routing-Regeln, Message Enrichment, DPS und die klare Trennung zwischen Geräte- und Backend-Verantwortung. IoT Hub combines secure device identities with telemetry, commands, and device twins. Especially important are routing rules, message enrichment, DPS, and a clear split between device and backend responsibility.

az iot hub create
  --name iothub-factory-prod
  --resource-group rg-iot-prod
  --sku S1
  --partition-count 4
        

Azure Digital Twins und DTDL Azure Digital Twins and DTDL

Digital Twins erzeugt Mehrwert erst, wenn das Modell nicht nur technisch korrekt, sondern auch fachlich belastbar ist. Ownership, Modellversionen, Ereignisflüsse und Beziehungen müssen daher ähnlich streng wie APIs geführt werden. Digital Twins creates value only when the model is not just technically valid, but also business-meaningful. Ownership, model versions, event flows, and relationships should therefore be governed almost as strictly as APIs.

{
  "@id": "dtmi:contoso:factory:Boiler;1",
  "@type": "Interface",
  "displayName": "Boiler",
  "contents": [
    {
      "@type": "Telemetry",
      "name": "temperature",
      "schema": "double"
    }
  ],
  "@context": "dtmi:dtdl:context;3"
}
        

Azure Sphere als Sicherheitsbaustein Azure Sphere as a security building block

Azure Sphere ist kein universeller IoT-Ersatz, sondern eine speziell gehärtete Lösung für MCU-basierte Geräte mit langfristigem Sicherheits- und Update-Bedarf. Sie sollte gemeinsam mit Hardware-, Zertifikats- und Fertigungsentscheidungen bewertet werden. Azure Sphere is not a universal IoT replacement, but a specifically hardened solution for MCU-based devices with long-term security and update needs. It should be evaluated together with hardware, certificate, and manufacturing decisions.

Azure AI, AML, AKS, ACR und Container Apps als moderne Integrationsplattform Azure AI, AML, AKS, ACR, and Container Apps as a modern integration platform

Azure OpenAI, Azure AI Services und Azure Machine Learning erweitern Integrationslösungen um Inferenz, Wissensanreicherung, Dokumentverarbeitung, Agenten, RAG und modellgetriebene Automatisierung. Entscheidend ist dabei, ob vortrainierte APIs ausreichen oder ein vollständiger MLOps- und Modell-Lifecycle benötigt wird. Azure OpenAI, Azure AI Services, and Azure Machine Learning extend integration solutions with inference, knowledge enrichment, document processing, agents, RAG, and model-driven automation. The key question is whether pretrained APIs are enough or a full MLOps and model lifecycle is needed.

Für die Laufzeit moderner Integrationskomponenten stehen AKS, ACR und Container Apps bereit. AKS eignet sich für komplexe, clusterzentrierte Plattformen; Container Apps für eventgetriebene, microserviceartige Workloads mit geringerem Plattformaufwand; ACR bleibt die zentrale Supply-Chain-Komponente für Images und Artefakte. AKS, ACR, and Container Apps provide runtime options for modern integration components. AKS fits complex cluster-centric platforms; Container Apps fit event-driven, microservice-style workloads with lower platform overhead; ACR remains the central supply-chain component for images and artifacts.

• OpenAI und AI Services für schnelle Wertschöpfung, AML für echten Modell-Lifecycle einsetzen. Use OpenAI and AI Services for fast value, AML for a true model lifecycle.
• ACR mit Signierung, Aufbewahrung, Inhaltsprüfung und Pull-Rechten absichern. Secure ACR with signing, retention, content scanning, and pull permissions.
• AKS nur wählen, wenn Cluster-Flexibilität und Plattformkompetenz vorhanden sind. Choose AKS only when cluster flexibility and platform capability exist.
• Container Apps bevorzugen, wenn Event-Driven, Autoscaling und geringerer Betriebsaufwand im Vordergrund stehen. Prefer Container Apps when event-driven scaling and lower operational overhead matter most.
• AI-Funktionen mit zentralem Prompt-, Daten- und Kosten-Governance-Modell betreiben. Operate AI capabilities with centralized prompt, data, and cost governance.

Azure OpenAI und AI Services im Integrationskontext Azure OpenAI and AI Services in integration scenarios

Generative oder kognitive Anreicherung gehört oft an den Rand eines Prozesses: Eingangsverarbeitung, Klassifikation, Wissensabfrage oder Antwortgenerierung. Identität, Netzwerkzugriff und Content Governance müssen dabei genauso ernst genommen werden wie bei klassischen APIs. Generative or cognitive enrichment often belongs at the edge of a process: intake handling, classification, knowledge retrieval, or response generation. Identity, network access, and content governance must be treated as seriously as with classic APIs.

POST https://my-openai-resource.openai.azure.com/openai/deployments/gpt-4o-mini/chat/completions?api-version=2024-10-21
Content-Type: application/json
Authorization: Bearer <token>

{
  "messages": [
    {"role": "system", "content": "Summarize the incident."},
    {"role": "user", "content": "Queue depth tripled after deployment."}
  ]
}
        

Azure Machine Learning für echten Modell-Lifecycle Azure Machine Learning for a real model lifecycle

Azure Machine Learning wird relevant, wenn Datenwissenschaft, Training, Modellregistrierung, Batch- und Online-Endpunkte, Evaluierung und Promotion zwischen Umgebungen kontrolliert werden müssen. Für reine Inferenz ist AML oft zu schwergewichtig. Azure Machine Learning becomes relevant when data science, training, model registration, batch and online endpoints, evaluation, and promotion between environments need to be controlled. For pure inference, AML is often too heavyweight.

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineEndpoint.schema.json
name: fraud-score-prod
auth_mode: aad_token
identity:
  type: system_assigned
traffic:
  blue: 100
        

AKS, ACR und Container Apps richtig wählen Choose AKS, ACR, and Container Apps appropriately

Container Apps eignet sich hervorragend für eventgetriebene APIs, Worker und Jobs mit KEDA, Dapr und einfacher Skalierung. AKS ist dagegen die richtige Wahl, wenn Plattformteams Service Mesh, Operators, komplexes Networking oder tiefe Kubernetes-Kontrolle benötigen. Container Apps is excellent for event-driven APIs, workers, and jobs with KEDA, Dapr, and simple scaling. AKS is the right choice when platform teams need service mesh, operators, complex networking, or deep Kubernetes control.

resource env 'Microsoft.App/managedEnvironments@2024-03-01' = {
  name: 'cae-int-prod'
  location: location
}

resource app 'Microsoft.App/containerApps@2024-03-01' = {
  name: 'ca-orders-worker'
  location: location
  properties: {
    managedEnvironmentId: env.id
  }
}
        

Modernisierung und Umzug: Azure Migrate, Site Recovery und DMS Modernization and relocation: Azure Migrate, Site Recovery, and DMS

Azure Migrate schafft Transparenz über Discovery, Abhängigkeiten, Assessment und Migrationswellen für Server, Anwendungen und teilweise Datenplattformen. Site Recovery deckt kontinuierliche Replikation und orchestrierte Failover-Szenarien ab, während Database Migration Service strukturierte Datenbankmigrationen und Cutover-Pfade unterstützt. Azure Migrate creates transparency for discovery, dependencies, assessment, and migration waves across servers, applications, and parts of the data estate. Site Recovery covers continuous replication and orchestrated failover scenarios, while Database Migration Service supports structured database migrations and cutover paths.

Technisch erfolgreiche Migrationen scheitern selten am ersten Replikationslauf, sondern an Ownership, Netzwerkanforderungen, Authentifizierungsabhängigkeiten, Testfenstern und der fehlenden Entscheidung zwischen Rehost, Refactor, Rearchitect und Replace. Deshalb gehört Modernisierung in dasselbe Governance-Modell wie Integration. Technically successful migrations rarely fail at the first replication run; they fail on ownership, networking requirements, authentication dependencies, test windows, and the missing decision between rehost, refactor, rearchitect, and replace. Modernization therefore belongs in the same governance model as integration.

• Migrationen nach Betriebsdomänen und Abhängigkeiten in Wellen schneiden. Slice migrations into waves by operating domain and dependencies.
• Test-Failover und Rückfallpfade vor produktivem Cutover durchführen. Run test failovers and fallback paths before production cutover.
• Monitoring, Backup, DNS und Identity je Welle explizit mitplanen. Plan monitoring, backup, DNS, and identity explicitly for each wave.
• DMS nur mit vorbereiteter Netzwerk- und Schemahygiene einsetzen. Use DMS only with prepared networking and schema hygiene.
• Modernisierungschancen parallel zur Lift-and-Shift-Planung bewerten. Evaluate modernization opportunities in parallel with lift-and-shift planning.

Azure Migrate für Discovery und Wellenplanung Azure Migrate for discovery and wave planning

Azure Migrate liefert technische Inventur, Azure-Readiness und teilweise Kostenindikationen. Der eigentliche Mehrwert entsteht aber erst, wenn diese Daten mit Ownern, Kritikalität, Wartungsfenstern und Applikationsabhängigkeiten kombiniert werden. Azure Migrate provides technical inventory, Azure readiness, and some cost indicators. The real value appears only when those data points are combined with owners, criticality, maintenance windows, and application dependencies.

az migrate project create
  --name migrate-enterprise-prod
  --resource-group rg-migrate-prod
  --location westeurope
        

Site Recovery für Replikation und Test-Failover Site Recovery for replication and test failover

ASR ist wertvoll, wenn Migration oder DR nicht nur von Backup-Restore, sondern von laufender Replikation und orchestrierten Test-Failovers abhängen. Netzwerkkonnektivität und Runbook-Integration entscheiden über die Praxistauglichkeit. ASR is valuable when migration or DR depends not only on backup restore but on ongoing replication and orchestrated test failovers. Network connectivity and runbook integration determine real-world usefulness.

$vault = Get-AzRecoveryServicesVault -Name "rsv-dr-prod"
Set-AzRecoveryServicesAsrVaultContext -Vault $vault
Get-AzRecoveryServicesAsrProtectionContainerMapping
        

DMS für Datenbank-Cutover DMS for database cutover

Database Migration Service reduziert Migrationsrisiken, wenn Schema, Netzwerk, Firewall, Authentifizierung und Downtime-Fenster früh abgestimmt wurden. Für geschäftskritische Datenbanken gehören Testmigration und Rückfallplan zwingend dazu. Database Migration Service reduces migration risk when schema, networking, firewall, authentication, and downtime windows have been aligned early. For business-critical databases, test migration and rollback planning are mandatory.

az dms project create
  --name dms-sql-cutover
  --resource-group rg-data-migration
  --service-name dms-prod
  --source-platform SQL
  --target-platform SQLDB
        

Betriebsmodell über alle Integrationsdienste Operating model across all integration services

Unabhängig vom konkreten Dienst brauchen Integrationsplattformen gemeinsame Standards für Identität, Secrets, Netzwerk, Logging, Tracing, Alerting, Schemaversionierung, Runbooks und Kostenkontrolle. Ohne diese Querschnittsdisziplinen wächst jede neue Schnittstelle als Sonderfall. Regardless of the specific service, integration platforms need shared standards for identity, secrets, networking, logging, tracing, alerting, schema versioning, runbooks, and cost control. Without these cross-cutting disciplines, every new interface grows as a special case.

Die Azure-Management-Seite liefert dafür die zentralen Ergänzungen zu Monitor, Policy, Resource Graph, Cost Management und Automation. Integrationsteams sollten diese Plattformdienste bewusst konsumieren statt sich eigene Schatten-Governance aufzubauen. The Azure Management page provides the central complements for Monitor, Policy, Resource Graph, Cost Management, and Automation. Integration teams should consume those platform services deliberately instead of building their own shadow governance.

• Managed Identities und Key Vault als Standardpfad definieren. Define managed identities and Key Vault as the standard path.
• Tracing und Korrelation über API, Workflow, Queue und Backend hinweg etablieren. Establish tracing and correlation across API, workflow, queue, and backend.
• Dead-Letter-Queues und Replay-Prozesse als operative Pflicht behandeln. Treat dead-letter queues and replay processes as operational obligations.
• Skalierungsgrenzen, Quotas und Budgetsignale pro Integrationsdomäne dokumentieren. Document scaling limits, quotas, and budget signals per integration domain.
• Die Referenzen Azure Management und Azure Security ergänzend in jedes Design Review einbeziehen. Include the Azure Management and Azure Security references as companions in every design review.

Review-Checkliste pro Integrationsservice Review checklist per integration service

Jede neue Integrationskomponente sollte gegen dieselben Fragen geprüft werden: Wer ist Owner? Wie funktioniert Retry? Wo landen Dead Letters? Wie wird skaliert? Welche Identität wird genutzt? Welche Logs und Traces gibt es? Wie erfolgt das Cutover? Every new integration component should be tested against the same questions: Who is the owner? How does retry work? Where do dead letters go? How does it scale? Which identity is used? Which logs and traces exist? How does cutover happen?

Link zur Management-Plattform Link back to the management platform

Azure Monitor, Cost Management, Policy, Automation und Resource Graph sind keine separaten Teamsilos, sondern Grundlage für belastbaren Integrationsbetrieb. Je früher diese Dienste gemeinsam genutzt werden, desto weniger Speziallösungen entstehen. Azure Monitor, Cost Management, Policy, Automation, and Resource Graph are not separate team silos, but the basis of reliable integration operations. The earlier these services are used together, the fewer one-off solutions are created.

Begriffe, Auswahlhilfe und Merksätze Terms, selection aid, and reminders

Die folgende Übersicht fasst zentrale Integrationsbegriffe und ihre praktische Bedeutung zusammen. Sie eignet sich als Kurzcheck für Architektur- und Betriebsreviews. The following overview summarizes key integration terms and their practical meaning. It works as a short check for architecture and operations reviews.

• Nicht einen Integrationsdienst für alle Problemklassen erzwingen. Do not force one integration service onto every problem class.
• Idempotenz und Replay gehören von Beginn an in die Architektur. Idempotency and replay belong in the architecture from day one.
• APIs, Events, Commands und Streams haben unterschiedliche Betriebsmodelle. APIs, events, commands, and streams have different operating models.
• AI- und Container-Dienste sollten in dasselbe Governance-Modell eingebettet werden. AI and container services should be embedded into the same governance model.
• Migration, Integration und Modernisierung müssen als gemeinsamer Transformationspfad gedacht werden. Migration, integration, and modernization should be treated as a shared transformation path.