Integration Platform: Entscheidungen¶

Diese Seite verdichtet die Architecture Decision Records (ADRs) der Integration Platform in einer Tabelle, mit einer kurzen Zusammenfassung der Entscheidungen, die das Design prägen. Der Status entspricht dem in der Quelle. Zwei Records sind noch Proposed.

ADR	Entscheidung	Status
001	Azure Service Bus Premium als Message Broker nutzen	Accepted
002	Konfigurationsgesteuerte Infrastruktur: JSON-Dateien sind die Schnittstelle für Workload-Teams	Accepted
003	Rekursive Erkennung von Konfigurationsdateien in jeder Ordnerstruktur	Accepted
004	Administrative Units isolieren die Identitäten, die die Automatisierung verwaltet	Accepted
005	Zugriffsdelegation über Gruppen: Der Zugriff geht an Gruppen, die Workload-Teams besitzen die Mitgliedschaft	Accepted
006	Service-Bus-Konfiguration in `queues.json` und `topics.json`	Accepted
007	Service-Bus-Zugriffskontrolle pro Entität, mit Sender- und Receiver-Gruppen	Accepted
008	Eine eigene queue pro Topic-Subscription für die Wiederverarbeitung	Accepted
010	Schichtenarchitektur: Foundation, Platform Core (Shared Services und Control Plane), Consumption	Accepted
011	Die Schichten mit der hub-and-spoke-Landing-Zone umsetzen	Accepted
012	Geteilte Verantwortung für Service Bus: Shared Service, spoke extension, Automatisierung	Accepted
013	Umgang mit Multi-Faktor-Authentifizierung in der UI-Testautomatisierung	Accepted (Testautomatisierung, hier nicht behandelt)
014	Secret-Management für Identitäten der Testautomatisierung	Accepted (Testautomatisierung, hier nicht behandelt)
015	API Management als Shared Service: Premium- und Standard-v2-Angebote, workspaces nur per Opt-in	Proposed
016	Event Hubs als Shared Service auf dem Premium-Tier	Proposed

ADR-009 (Einführung der hub-spoke-Workload-Architektur) wird als durch ADR-011 verfeinert referenziert und steht nicht in der Quellenmenge.

ADR-001: Service Bus Premium¶

Kontext. Workloads brauchen asynchrones Messaging auf gemeinsamer Infrastruktur, mit privater Konnektivität, Entra-ID- Authentifizierung, Zonenredundanz und Enterprise-Skalierung.

Entscheidung. Ein Premium-Namespace pro Shared-Services-Umgebung, nur über private endpoint erreichbar, mit Entra-ID- (RBAC-)Authentifizierung und ohne Connection Strings. Queues und topics werden zentral verwaltet. Der Zugriff läuft über workload-spezifische Gruppen.

Warum. Event Hubs fehlen Features auf Nachrichtenebene wie Dead-Letter-Queues und Transaktionen. Service Bus Standard hat keine private endpoints und keine Zonenredundanz und eine kleinere Nachrichtengröße. Storage Queues sind zu einfach. Ein selbst betriebenes RabbitMQ auf einem Kubernetes-Cluster bringt Betriebsaufwand und keine native Entra-ID-Integration.

Konsequenzen. Premium kostet mehr und hat eine feste monatliche Grundgebühr. Workloads teilen sich einen Namespace, daher sind Zugriffskontrolle und Quotas wichtig. Messaging Units werden manuell skaliert, und das Skalieren kann Verbindungen kurz zurücksetzen. Änderungen müssen über die Automatisierung laufen, um Drift zu vermeiden.

ADR-002 und ADR-003: konfigurationsgesteuert¶

Workload-Teams sollen kein Terraform schreiben müssen, um eine queue zu bekommen. Sie beschreiben in JSON, was sie brauchen (den Intent), die Plattform pflegt das Terraform, das durchsetzt, wie es gebaut wird. Das begrenzt, was ein Nutzer ändern kann, hält Namensgebung, Tagging und Security-Einstellungen einheitlich und lässt andere Tools die Dateien generieren oder validieren. Der Preis: Die Validierung schlägt eventuell erst beim plan fehl, und ein zu einfaches Schema lädt zu Anfragen ein, rohe Optionen durchzureichen.

Die Automatisierung findet die Dateien mit einem Glob-Muster im Root-Ordner und in jedem Unterordner und führt sie zusammen. Teams organisieren sich nach Umgebung, Domäne oder Team. Der Preis: Eine doppelte Definition in zwei Ordnern ist schwer zu erkennen, daher muss die Validierung auf Eindeutigkeit prüfen.

ADR-004 und ADR-005: Identitätsisolierung und Gruppen¶

Die Automatisierung braucht Rechte, um Entra-ID-Gruppen anzulegen. Das auf Tenant-Ebene zu vergeben ist inakzeptabel, daher ist es auf eine Administrative Unit begrenzt, pro Umgebung. Ein kompromittiertes Credential der Automatisierung kann nur die Gruppen in seiner Unit anfassen. Die Unit muss existieren, bevor die Automatisierung läuft.

Die Automatisierung weist Ressourcen keine Workload-Identitäten zu. Sie gibt einer Gruppe die Berechtigung und macht das Workload- Team zum Owner der Gruppe. Eine Rotation der Identität braucht dann keine Infrastrukturänderung, Access Reviews lassen sich auf Gruppen durchführen, und das Muster ist für jeden Ressourcentyp gleich. Der Preis sind viele Gruppen und eine kurze Verzögerung, bis Änderungen der Mitgliedschaft wirken.

ADR-006 bis ADR-008: Service-Bus-Modell¶

Queues werden in queues.json definiert, topics, subscriptions und rules in topics.json, jeweils mit einem expliziten workload- Owner. Ein Feature hinzuzufügen (zum Beispiel sessions oder TTLs) heißt, das Terraform-Schema zu erweitern.
Gruppen werden pro Entität angelegt, nicht pro Namespace, sodass ein workload die queue eines anderen nicht lesen kann. Standardprofile sind Sender und Receiver. Der Record nennt auch ein Manager-Profil, das das aktuelle Terraform nicht anlegt. Das Muster für den Gruppen- namen identifiziert workload, Entität und Rolle. Die Mitgliedschaft verwaltet das Workload-Team, nicht das JSON.
Für jede Topic-Subscription legt die Plattform eine queue an und leitet die Subscription dorthin weiter. Nutzer lesen die queue. Fehlgeschlagene Nachrichten landen in der Dead-Letter-Queue einer queue, die nur dieser workload besitzt. Ein Retry sendet erneut an diese queue, nicht an das topic, sodass andere Subscriber keine Duplikate bekommen. Die Kosten sind ein paar zusätzliche Entitäten.

ADR-010 bis ADR-012: Schichten und geteilte Verantwortung¶

Die Plattform ist in drei Schichten gebaut: die Foundation (Netzwerk, Identität, Security, also die Landing Zone), der Platform Core (ein Shared-Services-workload mit den Engines und ein Control-Plane-workload, der deren Konfiguration und Zugriff verwaltet) und die Consumption-Schicht (die Integrationen). Die Trennung von Engine und Control Plane gibt ihnen unabhängige Lebenszyklen.

Auf Azure werden die Schichten auf hub und spokes abgebildet: Die Shared Services laufen in einem eigenen Shared-Services-spoke, die Control Plane in einem eigenen spoke und jeder Integration-workload in einem eigenen spoke. Die Plattform nutzt den hub für Konnektivität und Firewalling und baut kein eigenes Netzwerk. Ein Sicherheitsvorfall im Control-Plane-spoke kann die Shared Services nicht direkt lahmlegen. Der Traffic zwischen ihnen läuft über die hub-Firewall.

Für Service Bus werden daraus drei Schichten, die der Reihe nach deployt werden: der Namespace als Shared Service, die spoke extension für Berechtigungen und die Automatisierung für Entitäten und Gruppen. Das Plattform-Team verwaltet die Leitungen, das Integrationsteam den Inhalt. Die Fehlersuche erstreckt sich über drei Codebasen, und jede Schicht muss ihre Abhängigkeiten validieren. Siehe Service-Bus-Automatisierung.

Eine festgehaltene Inkonsistenz: Die Datei zu ADR-010 beschreibt in der Entscheidung drei Schichten und erwähnt in den Konsequenzen einen Stack aus fünf Schichten. Betrachte das Drei-Schichten-Modell als die Entscheidung.

ADR-015: API Management als Shared Service¶

Proposed. Zwei Angebote: Premium (classic) mit VNet-Injection, Zonenredundanz und optional Multi-Region oder Standard v2 mit private endpoints und VNet-Integration zu geringeren Kosten und mit reduzierter Isolation. Beide werden über ein Application Gateway mit WAF im Internet bereitgestellt. Workspaces gibt es nur per Opt-in wegen ihrer Grenzen, dedizierte Workspace-Gateways und selbst gehostete Gateways werden nicht unterstützt, die Skalierung ist manuell, und APIs werden mit APIOps verwaltet. Details: Shared Services.

ADR-016: Event Hubs als Shared Service¶

Proposed. Premium-Tier, für Ressourcenisolation, customer-managed keys, enthaltenes Capture, 90 Tage Retention, dynamische Partitionen und privates Networking. Dedicated ist eine künftige Option für sehr hohen, dauerhaften Durchsatz. Details: Shared Services.

Nicht verdichtet¶

ADR-013 und ADR-014 (MFA-Handling und Secrets für die UI-Testautomatisierung des Quell-Repositorys) betreffen das eigene Test- Setup des Teams und sind nicht Teil des Services. Das ADR-Template und der Leitfaden des Quell-Repositorys werden hier nicht wiederholt.