Dezentrales Data Gateway¶

Ein Muster für Dienste, die Zugriff auf private Daten brauchen, aber noch keinen klaren Owner haben. Das Beispiel ist ein Data Gateway für einen Business-Intelligence- oder Analytics-Dienst, aber dieselbe Überlegung gilt für jeden Dienst, der von außerhalb des Netzwerks private Ressourcen erreichen muss.

Situation¶

Teams nutzen einen Analytics-Dienst (zum Beispiel Power BI), der Datenquellen über öffentliche Endpunkte erreicht, etwa Storage Accounts oder SQL-Server. In der Managed Platform sind öffentliche Endpunkte an Datenressourcen verboten, daher funktioniert der alte Ansatz nicht mehr.

Der Dienst unterstützt ein Data Gateway, das private Ressourcen erreicht. Das Gateway muss in einem delegierten Subnetz eines Virtual Network auf der Plattform laufen.

Ideal wäre ein zentraler Gateway-Dienst. In der Praxis gilt:

kein Team kann die Verantwortung für ein zentrales Gateway übernehmen,
der Betrieb von Diensten auf Anwendungsebene wie diesem Gateway liegt meist außerhalb des Umfangs des Managed Service,
Lizenz und Produktlinie des Herstellers können im Wandel sein (zum Beispiel ein Produkt, das durch ein anderes ersetzt wird), sodass unklar ist, was langfristig gebraucht wird,
der Umfang der Nutzung ist unbekannt.

Migrationen von workloads dürfen nicht auf diese Entscheidungen warten.

Empfehlung: dezentralisieren, vorübergehend¶

Lass jedes Team, das den Dienst braucht, sein eigenes Gateway betreiben:

Das Team bekommt in seinem eigenen Spoke-Virtual-Network ein Subnetz mit der richtigen Delegierung.
Das Team deployt und verwaltet sein eigenes Gateway in diesem Subnetz.
Das Gateway erreicht die Datenquellen in den eigenen Subscriptions des Teams. Ein Team mit mehreren Subscriptions kann alle über ein Gateway erreichen.
Es gibt vorerst keinen zentralen Gateway-Dienst.
Die Entscheidung ist ausdrücklich vorübergehend. Plane eine erneute Bewertung zu einem festen Zeitpunkt, zum Beispiel wenn das Migrationsprogramm endet oder der Produktwechsel abgeschlossen ist.

So geht es in MCP¶

Beantrage eine Spoke-Änderung, die ein Subnetz mit der Delegierung hinzufügt, die der Dienst braucht (Spoke ändern). Ein Subnetz erhält einen delegations-Eintrag, dessen name einer der Werte des JSON-Schemas sein muss (Spoke-JSON-Referenz). Prüfe, dass die Delegierung, die dein Dienst braucht, in dieser Liste steht, bevor du darauf planst. Das Subnetz muss für den Dienst groß genug sein: prüfe die Mindestgröße des Herstellers und siehe IP-Bereich und Subnets planen.

Die firewall gilt weiterhin. Das Gateway muss die Service-Endpunkte des Herstellers und die Datenquellen erreichen, also beantrage Regeln wie für jeden anderen workload (Organisation der firewall-Regeln).

Konsequenzen¶

Positiv:

Migrationen laufen weiter, ohne auf organisatorische Entscheidungen zu warten,
keine öffentlichen Endpunkte an Datenressourcen, die Sicherheit verbessert sich also gegenüber der alten Situation,
Teams behalten ihre Autonomie,
du bekommst Fakten für die spätere Entscheidung: wie viele Gateways, wie viele delegierte Subnetze, wie sie genutzt werden.

Negativ:

dieselbe Arbeit wird in mehreren Teams wiederholt, und die Gateways können uneinheitlich werden,
mehr Gateways zu pflegen, und jedes Team braucht die Expertise,
Nacharbeit beim Wechsel zu einem zentralen Modell,
Unsicherheit über die Auswirkung des Produktwechsels.

Nächste Schritte¶

Aktion	Inhalt
Nach der Migration bewerten	Alle Gateways inventarisieren, die Nutzung pro Team dokumentieren, den gesamten Betriebsaufwand einschätzen
Den Produktwechsel bewerten	Dem Zeitplan des Herstellers folgen und entscheiden, was sich technisch ändert
Über das künftige Modell entscheiden	Dezentral lassen, in einem zentralen Dienst mit klarem Owner konsolidieren oder einen hybriden Weg wählen (zum Beispiel eines pro Domäne)
Bei Zentralisierung	Einen Owner benennen und Betriebsverantwortlichkeiten, Service Levels und das Support-Modell festlegen

Halte diese Entscheidung, ihr Enddatum und ihren Owner im Entscheidungslog fest (Governance).