Integration Platform: Servicebeschreibung¶
Diese Seite beschreibt, was die Integration Platform bietet, wie Änderungen laufen und wo die Grenzen liegen. Die anderen Seiten gehen ins Detail: Architektur, Betriebsmodell, Anfragen und Änderungen, Module, Service Bus und Shared Services.
Optionales Angebot, pro Plattform festgelegt
Der Service ist ein optionaler Baustein, den das Plattform-Team im Rahmen einer Vereinbarung liefert (Betriebsmodelle). support-Zeiten, Reaktionszeiten, Verfügbarkeitsziele, Kontakte und Gebühren sind Teil dieser Vereinbarung und stehen nicht in dieser Dokumentation. Wo diese Seite einen Standardwert nennt, ist das der übliche Wert des Referenzdesigns. Deine Plattform kann abweichen.
Kurz gesagt¶
Die Plattform verpackt Azure Integration Services in eine Umgebung, die für builders gemacht ist. Integration builders müssen keine Infrastruktur-Experten sein: Sie fragen über Konfigurationsdateien und pull requests an, was sie brauchen, und die Plattform deployt es auf standardisierte, sichere und überwachte Weise.
| Nutzen | Was er bedeutet |
|---|---|
| Einfaches Infrastruktur-Deployment | Vordefinierte Terraform-Module und Automatisierung deployen und konfigurieren die zugrunde liegenden Azure-Ressourcen. |
| Monitoring und Observability | Integriertes Monitoring mit Azure Monitor und Application Insights. Builders überwachen ihre Integrationen, Platform Engineers die Shared Services und deren Abhängigkeiten. |
| Governance und Security by Design | Gemeinsame, vorkonfigurierte Services wenden Security-Policies, Authentifizierung und Governance automatisch an. |
| Schnellerer Time to Value | Gemeinsame Infrastruktur und einfache Deployment-Mechanismen lassen Teams ihre Zeit für das fachliche Problem nutzen. |
Ingredients¶
Ein Ingredient ist ein wiederverwendbares, konformes Infrastrukturpaket, das das Plattform-Team pflegt. Es gibt drei Arten.
| Art | Was | Beispiele |
|---|---|---|
| Plattform-Services | Auf der gesamten Integration Platform angeboten | DNS, Dokumentationsgenerierung |
| Shared Services | Kostenintensive, häufig genutzte Integrationsinfrastruktur für mehrere workloads. Plattformweit angeboten, um Kosten, Security und Governance auszubalancieren. | API Management, Service Bus, Event Hubs, Azure Container Registry |
| Module | Deployen einen Integrationsservice in einem Workload-spoke, verbunden mit dem spoke und mit den Shared Services | Logic App, Function App, Container App, Data Factory |
Plattform-Services¶
- DNS. Zentral verwaltete Domain-Name-Services für die Integration Platform, damit Namen zu den Azure- Ressourcen in der Plattform aufgelöst werden, einschließlich Shared Services und Modulen. Öffentliche und private Azure-DNS-zones bedienen Ressourcen, die über eine IP-Adresse erreichbar sein müssen, etwa einen HTTP-Endpoint. Siehe auch Private-Endpoint-DNS.
- Dokumentationsgenerierung. Erzeugt Dokumentation für die veröffentlichten Ingredients.
Shared Services¶
| Service | Wofür er da ist | Seite |
|---|---|---|
| Service Bus | Zuverlässiges Enterprise-Messaging: queues und topics, Dead-Lettering, Scheduling, Transaktionen. Entitäten und Zugriff werden aus JSON-Dateien verwaltet. | Service Bus |
| Event Hubs | Event-Streaming mit hohem Durchsatz, Unterstützung des Kafka-Protokolls, Capture und Retention | Shared Services |
| API Management | Ein Gateway, um APIs zu veröffentlichen, abzusichern und zu beobachten, mit einem APIOps-Workflow | Shared Services |
| Azure Container Registry | Zentraler Speicher für private Container-Images, die von eigenen Integrationen genutzt werden. Die Deployment-Identitäten der workloads pushen und pullen. Nur das Plattform-Team kann Images löschen. | Shared Services |
Shared Services gehören dem Plattform-Team und haben einen eigenen Lebenszyklus. Jeder hat eine Automatisierungsschicht, damit builders über pull requests anfragen können, was sie brauchen (welche topics, queues oder APIs, mit welchen Berechtigungen). Berechtigungen werden pro workload vergeben, was workloads voneinander isoliert.
Module¶
| Modul | Was es in deinem spoke deployt |
|---|---|
| Logic App | Eine Logic App Standard mit private endpoint, integrierter Authentifizierung, eigenem Storage Account und Monitoring |
| Function App | Eine Function App mit VNet-Integration und private endpoint, die managed identity für Storage nutzt |
| Container App | Eine Container Apps environment mit Container Apps und Container Jobs (manuell, event-getriggert, zeitgesteuert), in T-Shirt-Größen |
| Data Factory | Eine Data Factory mit managed virtual network, Integration Runtime und Linked Services zum Key Vault und Storage des spokes |
Details und Standardwerte: Module.
Wie Teams mit der Plattform arbeiten¶
Jede Interaktion mit der Plattform läuft über Git und pull requests: Ingredients anfragen und konfigurieren und ändern. Das gibt Versionskontrolle, Nachvollziehbarkeit und Review. Der Code und die Plattformfähigkeiten werden von GitHub oder Azure DevOps unterstützt. Das Referenzdesign nutzt GitHub.
- Gesteuerte Promotion. Neue Versionen von Ingredients und Integrationslogik werden von der Plattform über die Umgebungen promotet, mit Environments und Genehmigungen auf der Repository-Plattform und einem Workflow für versionierte Pakete.
- Branchenübliche Sprachen. Die Automatisierung ist in Terraform und PowerShell geschrieben.
- Gemeinsamer Quellcode. Der Quellcode der Automatisierung wird mit der Plattform geliefert, sodass builders nachlesen können, wie sie funktioniert.
- Wiederverwendbarkeit. Jedes deploybare Ingredient ist ein Terraform-Modul.
- Automatisierte Berechtigungen und Deployments. Die Plattform richtet Berechtigungen und Deployment-pipelines so ein, dass ein Team nur seine eigenen Integrationen verwalten und deployen kann (Least Privilege).
- Anbindung an Shared Services. Die Plattform verwaltet die Anbindungspunkte zu den Shared Services. Builders konzentrieren sich auf die Geschäftslogik in ihrer eigenen Logic App oder Function App.
Wer im zentralen, hybriden und dezentralen Modell was macht: Betriebsmodell.
Security und Compliance¶
Das Referenzdesign ist darauf ausgelegt, sich an CIS (Version 2.0), ISO 27001 und dem Microsoft cloud security benchmark auszurichten. Diese Standards sind in Automatisierung, Governance und Deployment eingebettet, sodass builders Compliance-Einstellungen nicht von Hand konfigurieren. Die generischen Plattformkontrollen stehen in der MCP-Dokumentation (Governance).
| Thema | Standard im Referenzdesign |
|---|---|
| Netzwerk | Shared Services und Module nutzen standardmäßig privates Networking (private endpoints, VNet-Integration oder -Injection). Es gibt keine Verbindung zwischen workloads, solange die hub-Firewall sie nicht erlaubt. |
| Identität | Entra ID und Azure RBAC. Zugriff auf Service-Bus-Entitäten und die Registry über Gruppen. Keine Shared Keys für Service Bus (im Namespace ist die lokale Authentifizierung deaktiviert). |
| Verschlüsselung at rest | Das Design sieht customer-managed keys für die Shared Services und für die Ressourcen vor, die die Plattform deployt. Für Service Bus ist die von Microsoft verwaltete Verschlüsselung der Standard und ein customer-managed key optional. Prüfe, was dein Deployment nutzt. |
| Defender | Microsoft Defender for APIs auf den Integration-subscriptions, zusätzlich zu den Defender-Plänen der Plattform |
| Policy | Keine zusätzliche Azure Policy neben den eigenen der Plattform. Zusätzliche policies können später ergänzt werden, zum Beispiel um workload-eigenes API Management oder Service Bus zu verbieten. |
Monitoring und Alerting¶
- Automatisiertes Deployment von Alerts. Alerts werden beim Deployment angewendet, ohne manuelle Konfiguration.
- Abdeckung. Metric Alerts (zum Beispiel CPU, Memory, Queue-Tiefe), log-basierte Alerts für Anwendungsfehler und Health Checks für die kritischen Services.
- Action groups. Benachrichtigungen werden über konfigurierbare Action Groups geleitet, an das Plattform-Team oder die Workload-Owner.
- Dashboards. Azure Monitor und Application Insights.
Was jedes Ingredient tatsächlich deployt, steht pro Modul in Module und in Betrieb.
Standardänderungen¶
Eine Standardänderung ist stark automatisiert und hat keine Obergrenze. Je häufiger sie genutzt werden, desto besser dient die Plattform dir. Pull requests von builders, die einen Prozess verbessern, sind willkommen. Das Plattform-Team führt sie in einem Managed Service durch. Wenn du die Plattform selbst betreibst, zeigt die Liste, was den Betrieb der Plattform ausmacht. Die Liste steht auf Anfragen und Änderungen.
Verfügbarkeitsziele¶
Die Vereinbarung legt ein Verfügbarkeitsziel pro Shared Service fest (Service Bus, Event Hubs, API Management, Container Registry), gemessen pro Quartal. Die Werte sind Vertragsdetails und werden hier nicht wiederholt. Zur Resilienz der Azure-Services, auf denen die Plattform aufbaut, siehe Verfügbarkeit.
Verantwortlichkeiten¶
Die Aufteilung der Verantwortung zwischen Plattform-Team und Workload-Team und die Referenz-RACI stehen in Betriebsmodell.