Integration Platform: Architektur¶
Diese Seite beschreibt das High-Level-Design der Integration Platform: die Layer, die workloads und spokes, die Umgebungen, Networking, Identität, Security und Resilienz. Sie ist das Referenzdesign. Dein Deployment kann sich bei der Anzahl der Umgebungen, den aktivierten Shared Services und den gewählten Optionen unterscheiden. Frag dein Plattform-Team.
Prinzipien¶
Die Integration Platform übernimmt die Designprinzipien der MCP (Designprinzipien) und ergänzt vier eigene.
| Prinzip | Bedeutung |
|---|---|
| Cloud-first | Nutze Cloud-native Azure-Services für Skalierbarkeit, Zuverlässigkeit und Kosteneffizienz. |
| Standardisiert, aber erweiterbar | Standardmuster nehmen Infrastrukturkomplexität weg und ermöglichen Wiederverwendung. Wenn ein neues Muster auftaucht, lässt sich kontrolliert ein neuer Baustein ergänzen. |
| Event-driven | Integrationen reagieren in Echtzeit, skalieren unabhängig und bleiben lose gekoppelt. |
| You build it, you run it | Das Team, das eine Integration baut, verantwortet sie über ihren gesamten Lebenszyklus: Deployment, Monitoring und Behebung von Problemen. Automatisierung und DevOps-Praktiken unterstützen das. |
Capabilities¶
Die Plattform formuliert ihr Angebot als technologieunabhängige Capabilities. Das Referenzdesign ordnet jede Capability Ingredients zu. Eine Capability kann für eine Organisation erforderlich sein oder nicht. Was erforderlich ist, ist eine Entscheidung pro Plattform.
| Capability | Was sie abdeckt | Typische Ingredients |
|---|---|---|
| Message and event brokering | Asynchrone, eventbasierte Kommunikation mit Reihenfolge, Zustellgarantien, Deduplizierung | Service Bus, Event Hubs |
| API management | APIs entwickeln, veröffentlichen, absichern, überwachen und analysieren | API Management |
| Low-code modules | Integrationen, die mit Konfiguration, Workflows und Drag-and-drop gebaut werden | Logic App, Data Factory |
| High-code modules | Integrationslogik in einer Programmiersprache, mit bereitgestellter Runtime und Infrastruktur | Function App, Container App |
| Triggers and jobs | Zeitgesteuerte und eventgetriggerte Verarbeitung, Batch-Jobs | Container Jobs, Logic Apps, Data Factory |
| Infrastructure | Plattforminfrastruktur und Infrastruktur für neue Integrationen, einschließlich gemeinsamer Build-Runner | Spoke canvas, Module, Container Registry |
| Recipes and documentation | Anleitungen, Beispiele und Best Practices für Builder | Dokumentationsgenerierung |
| Provisioning and automation | Templates für Deployment-pipelines, keine manuelle Infrastruktur | Terraform-Module, wiederverwendbarer Workflow |
| Collaboration | Quellcode und Automatisierung in der Repository-Plattform, Work Items in einem Ticket-Tool | GitHub (Referenzdesign) |
Weitere Capabilities, die eine Plattform ergänzen kann, wenn es einen klaren Bedarf gibt: Verbindungen zu Quellsystemen, Dokument- verarbeitung, ein Integrationsverzeichnis, KI-Unterstützung und B2B-Integration (EDI, AS2). Sie sind nicht Teil des Referenz- designs.
Layer¶
Das Design trennt, was worauf läuft (ADR-010, ADR-011).
flowchart TB
subgraph L3["Consumption"]
iw["Integration workloads<br/>Logic Apps, Function Apps, Container Apps, Data Factory, API definitions"]
end
subgraph L2["Platform core"]
ssw["Shared services workload<br/>Service Bus, Event Hubs, API Management, ACR"]
cpw["Control plane workload<br/>configuration, access control, governance of the shared services"]
cpw -->|"configures"| ssw
end
subgraph L1["Foundation: MCP"]
hub["Hub: network, firewall, DNS, identity governance"]
sp["Spokes (spoke canvas)"]
end
iw -->|"consumes"| ssw
L2 -->|"runs on"| L1
L3 -->|"runs on"| L1| Layer | Verantwortung | Umgesetzt als |
|---|---|---|
| Foundation | Netzwerk, Firewalling, DNS, Identity Governance, Security-Grenzen („der Wählton“) | MCP hub und spokes. Die Plattform baut kein eigenes Netzwerk-Backbone. |
| Platform core | Die Engines (Shared Services) und die Control Plane, die ihre Konfiguration und ihren Zugriff verwaltet | Ein Shared-Services-spoke und ein Control-Plane-Deployment |
| Consumption | Die Integrationen, die Builder erstellen | Spokes der Integration-workloads |
Die Trennung in Engine und Control Plane erlaubt es, die Control Plane neu zu deployen oder zu aktualisieren, ohne die Verfügbarkeit der Shared Services zu beeinträchtigen. Der Preis ist Koordination: Beide müssen sich abstimmen, was deployt ist, und der Verkehr zwischen ihnen läuft über die hub- firewall.
Workloads, spokes und Umgebungen¶
Ein workload besteht aus einer oder mehreren Umgebungen, und jede Umgebung ist ein spoke, also eine eigene Azure- subscription mit der Basisinfrastruktur des spoke canvas (Was du bekommst). Jedes spoke-Virtual-Network ist mit dem hub gepeert.
| Workload | Enthält |
|---|---|
| Shared-Services-workload | Die aktivierten Shared Services. Das Basis-Deployment enthält nur die Azure Container Registry, weil die Plattform sie braucht, um Ingredients zu veröffentlichen. Weitere kommen dazu, wenn workloads sie brauchen. |
| Integration-Platform-workload | Die aktivierten Plattform-Services. Das Basis-Deployment enthält DNS, zum Beispiel für die Namensauflösung extern veröffentlichter APIs. |
| Integration-workloads | Die Integrationen. Jede nutzt spoke extensions, um sich mit den Shared Services zu verbinden, die sie braucht, und Module, um ihre Integrationsservices zu deployen. |
flowchart TB
hub["MCP hub: firewall, DNS"]
subgraph prd["Production"]
ssp["Shared services spoke (prod)"]
ipp["Integration Platform spoke (prod)"]
w1p["Integration workload spoke (prod)"]
end
subgraph nprd["Non-production"]
ssn["Shared services spoke (non-prod)"]
ipn["Integration Platform spoke (non-prod)"]
w1n["Integration workload spoke (non-prod)"]
end
hub --- ssp & ipp & w1p
hub --- ssn & ipn & w1n
w1p -.->|"extension"| ssp
w1n -.->|"extension"| ssnDesignentscheidungen des Referenzdesigns:
- Zwei Umgebungen für die Plattform, Produktion und Nicht-Produktion, damit neue Versionen der Shared Services außerhalb der Produktion getestet werden können. Weitere Umgebungen lassen sich ergänzen, weil eine Plattform-Instanz per Automatisierung erneut deployt werden kann. Kosten und Komplexität sind der Grund, es bei zwei zu belassen.
- Workloads folgen ihrer Umgebung. Produktions-workloads verbinden sich mit der Produktionsplattform, Nicht-Produktions-workloads mit der Nicht-Produktionsplattform. Die Anzahl der spokes pro workload wird pro workload gewählt.
- Eine Ressource, die günstig ist und keine Geschäftsdaten hält, kann einmal deployt werden. Eine Azure Container Registry zum Beispiel wird typischerweise einmal für die gesamte Landschaft deployt statt pro Umgebung.
- Verbindungen sind nie implizit. Jede Verbindung zwischen workloads oder nach außen läuft über die hub-firewall und braucht eine Regel (Firewallregeln und IP groups). Ein Integration-workload nutzt standardmäßig keinen Shared Service. Ein workload kann auch keinen nutzen.
- Integrationen mit On-Premises-Systemen laufen über den hub und seine firewall. Sie sollen in einer Migration nur vorübergehend bestehen.
Wie du einen workload zuschneidest¶
Ein Integration-workload lässt sich auf mehrere Arten abgrenzen, einzeln oder kombiniert. Beginne mit einem oder wenigen workloads und teile sie bei Bedarf auf.
| Schnitt | Stärke | Worauf du achten musst |
|---|---|---|
| Pro Team | Klare Verantwortung und Autonomie, schnelle Entscheidungen | Duplizierung, wenn Teams kein Wissen teilen |
| Pro fachlicher Domäne | Passt zu Domain-driven Design, Wiederverwendung innerhalb einer Domäne | Abstimmung bei übergreifenden Themen |
| Pro System | Einfacher Lebenszyklus, systemspezifische Kontrollen | Unklare Zuständigkeit, wenn mehrere Teams das System anfassen, schwierig bei Integrationen über mehrere Systeme hinweg |
| Pro Flow (alles zwischen System A und B) | Nachvollziehbarkeit, Isolation, einfache Fehlersuche | Viele kleine workloads, operativer Aufwand pro Flow |
Networking¶
Die Integration Platform wendet dieselbe Trennung an wie die MCP. Standardmäßig erlaubt die hub-firewall nur Verkehr innerhalb eines spokes. Um Verkehr von oder zu einer Quelle oder einem Ziel außerhalb des spokes zu erlauben, stellst du beim Plattform-Team eine Standardänderung (Firewallregeln und IP groups). Verkehr von und zu On-Premises ist standardmäßig blockiert.
Shared Services und Module nutzen standardmäßig privates Networking. Azure bietet drei Isolationsstufen:
| Stufe | Was sie tut | Richtung |
|---|---|---|
| VNet integration | Der Service sendet ausgehenden Verkehr über das Azure-Backbone in das VNet und in gepeerte VNets | Ausgehend |
| VNet injection (Subnet Delegation) | Der Service läuft in einem eigenen Subnetz mit eigenen privaten IPs | Eingehend und ausgehend |
| Private Link mit private endpoints | Der Service bekommt eine private IP in einem Subnetz, und sein öffentlicher Zugriff lässt sich abschalten | Nur eingehend |
VNet injection ist zu bevorzugen, wenn der Service sie unterstützt, kann aber wegen dedizierter Compute mehr kosten. Andernfalls werden private endpoints mit VNet integration kombiniert. API Management zeigt den Unterschied: Der Premium-Tier (klassisch) unterstützt Injection, Standard v2 nur Integration mit private endpoints (Shared Services).
Private endpoints in der Plattform brauchen auch aus deinen eigenen Netzwerken eine Namensauflösung. Das erforderliche DNS-Forwarding steht unter Private endpoint DNS. Das MCP-Design steht unter DNS-Design.
Wenn eine API oder ein Endpunkt aus dem Internet erreichbar sein muss, setze ihn hinter das Application Gateway mit WAF des hub (Shared Services). Der hub bietet DDoS-Schutz auf der öffentlichen IP des Application Gateway.
Identität und Zugriff¶
Die Integration Platform folgt den RBAC- und PIM-Standards der MCP (Identitäts- und Zugriffsmodell, Zugriff, Gruppen und PIM): Least Privilege und Just-in-Time.
Darüber hinaus nutzt die Plattform zwei Muster, die beide unter Entscheidungen beschrieben sind:
- Gruppenbasierte Zugriffsdelegation (ADR-005). Ressourcen bekommen nie Rollen- zuweisungen für einzelne Identitäten. Jede Berechtigung (zum Beispiel „an Queue X senden“) ist eine Entra-ID-Gruppe. Das Workload-Team besitzt die Mitgliedschaft und ändert sie ohne pipeline-Lauf.
- Administrative Units (ADR-004). Die Automatisierung, die Gruppen erstellt, ist auf eine Entra-ID Administrative Unit beschränkt. Eine kompromittierte Automatisierungsidentität kann Gruppen außerhalb davon nicht ändern.
Spoke extensions erstellen pro spoke die Basisgruppen und Rollenzuweisungen. Was eine Extension erstellt, steht unter Spoke extensions.
Security¶
| Thema | Referenzdesign |
|---|---|
| Policies | Keine Policies außer denen der MCP. Optionale zusätzliche Policies können später ergänzt, durchgesetzt und remediiert werden. Ein workload oder spoke kann zum Beispiel eine Regulatory-Policy-Initiative auf seiner eigenen subscription aktivieren. |
| Defender for Cloud | Die Pläne der Plattform plus Defender for APIs auf den Integrations-subscriptions. Die Kosten sind Teil der subscription-Kosten. Beachte, dass Defender for APIs für Workspace-APIs in API Management nicht verfügbar ist. |
| Verschlüsselung bei der Übertragung und im Ruhezustand | MCP-Standards. Customer-managed Keys, wo ein Shared Service sie unterstützt. |
| IP-Allowlists | API Management kann Aufrufer per IP-Adresse einschränken. Empfohlen für bekannte, im Internet gehostete Systeme. |
| Umfang der Plattform | Die Plattform verwaltet die Management Plane (Ressourcen und RBAC). Data-Plane-Aktionen und Data-Plane-RBAC der deployten Ressourcen liegen in der Verantwortung des workload-Owners. |
Auslieferung der Plattform und der Ingredients¶
Die Plattform wird aus der Repository-Plattform mit pipelines deployt und verwaltet. Die gesamte Deployment-Logik, die Umgebungs- parameter und die Automatisierungsskripte sind Code, sodass Deployments wiederholbar und prüfbar sind. Die Plattform wird durch vordefinierte Workflows gebootstrapped, die die Kernkomponenten deployen, etwa die Shared Services.
Integration-spokes deployt das Plattform-Team über die normale spoke-pipeline: zuerst ein regulärer spoke, optional erweitert um spoke extensions, die dem spoke Zugriff auf die Shared Services geben (Spoke extensions). Danach können die Builder loslegen.
Ein Ingredient veröffentlichen und nutzen:
flowchart LR
pe["Integration platform engineer<br/>adds or updates ingredient code"] --> build["Build automation<br/>creates a package"]
build --> reg["Container registry<br/>(shared service)"]
ib["Integration builder<br/>references the ingredient, sets parameters"] --> tpl["Build templates of the platform"]
reg --> tpl
tpl --> spoke["Deploy into the workload spoke(s)"]Der Zugriff auf die Registry ist mit Entra ID geschützt.
Resilienz¶
| Thema | Referenzdesign |
|---|---|
| Region | Eine Region. Availability Zones verteilen die Services über Rechenzentren, was vor einem Ausfall eines Rechenzentrums schützt, aber nicht vor einem regionalen Ausfall. |
| Disaster Recovery | Folgt der MCP. Die Plattform und die Shared Services lassen sich innerhalb von Stunden in einer anderen Region neu deployen, passend zu einem Recovery Time Objective von 24 Stunden und einem Recovery Point Objective von 48 Stunden. Beide Werte werden pro Plattform festgelegt. |
| Workloads | Ein workload, der nur Shared Services und Module der Plattform nutzt, lässt sich ebenfalls in einer anderen Region neu deployen, weil die Module eine Location akzeptieren. Andere Ressourcen liegen in der Verantwortung des Workload-Teams. |
| Verfügbarkeit | Hängt von der Konfiguration ab: zum Beispiel von der Anzahl der Replicas einer Container App oder der Anzahl der Instanzen eines Logic-App-Plans. Service-Level-Agreements von Azure-Services sind nicht dasselbe wie die Verfügbarkeitsziele, die du deinen Nutzern zusagst. |
| Konfiguration | Die Plattformkonfiguration ist Code in einem Git-Repository. |
Mehr Details, Abhängigkeiten und zusammengesetzte Verfügbarkeit pro Integrationsmuster: Verfügbarkeit.
Monitoring¶
Das Logging erweitert das Logging der MCP.
- Integration-Platform-spoke: keine zusätzlichen Alert-Regeln außer denen der MCP. Das Team kann eigene Regeln ergänzen.
- Shared Services: können eigenes Logging ergänzen. Der Shared Service API Management zum Beispiel deployt eine Application-Insights-Ressource, die mit dem Log-Analytics-Workspace seines spokes verbunden ist.
- Module: senden Logs an den Log-Analytics-Workspace des spokes, in manchen Fällen über eine Application-Insights- Ressource. Sie können eine Action Group und Alert-Regeln ergänzen. Einige verlangen, dass das Workload-Team zusätzliche Dinge umsetzt (Module).