Gedecentraliseerde data gateway¶

Een patroon voor services die toegang nodig hebben tot private data maar nog geen duidelijke eigenaar hebben. Het voorbeeld is een data gateway voor een business-intelligence- of analyticsservice, maar dezelfde redenering geldt voor elke service die private resources van buiten het netwerk moet bereiken.

Situatie¶

Teams gebruiken een analyticsservice (bijvoorbeeld Power BI) die gegevensbronnen via publieke endpoints bereikt, zoals storage accounts of SQL-servers. In het managed platform worden publieke endpoints op dataresources geweigerd, waardoor de oude aanpak niet meer werkt.

De service ondersteunt een data gateway die private resources bereikt. De gateway moet draaien in een gedelegeerd subnet van een virtual network op het platform.

Ideaal zou één centrale gatewayservice zijn. In de praktijk geldt:

geen enkel team kan eigenaar worden van een centrale gateway,
applicatieservices zoals deze gateway draaien valt meestal buiten de scope van de managed service,
de licentie en productlijn van de leverancier kunnen in transitie zijn (bijvoorbeeld het ene product vervangen door een ander), dus het is onduidelijk wat de langetermijneis is,
de omvang van het gebruik is onbekend.

Migraties van workloads mogen niet op deze beslissingen wachten.

Richtlijn: decentraliseer, tijdelijk¶

Laat elk team dat de service nodig heeft zijn eigen gateway draaien:

Het team krijgt een subnet met de juiste delegatie in zijn eigen spoke virtual network.
Het team deployt en beheert zijn eigen gateway in dat subnet.
De gateway bereikt de gegevensbronnen in de eigen subscriptions van het team. Een team met meerdere subscriptions kan ze allemaal via één gateway bereiken.
Er is voorlopig geen centrale gatewayservice.
De beslissing is uitdrukkelijk tijdelijk. Plan een herevaluatie op een vast moment, bijvoorbeeld wanneer het migratieprogramma eindigt of wanneer de producttransitie is afgerond.

Hoe doe je dit in MCP¶

Vraag een spoke-wijziging aan die een subnet toevoegt met de delegatie die de service nodig heeft (Spoke wijzigen). Een subnet krijgt een delegations-item waarvan de name een van de waarden uit het JSON-schema moet zijn (Spoke JSON-referentie). Controleer of de delegatie die je service nodig heeft in die lijst staat voordat je erop plant. Het subnet moet groot genoeg zijn voor de service: controleer de minimale grootte van de leverancier en zie Je IP-range en subnets plannen.

De firewall blijft van toepassing. De gateway moet de service-endpoints van de leverancier en de gegevensbronnen bereiken, dus vraag regels aan zoals voor elke andere workload (Organisatie van firewallregels).

Gevolgen¶

Positief:

migraties gaan door zonder te wachten op organisatorische beslissingen,
geen publieke endpoints op dataresources, dus de beveiliging verbetert ten opzichte van de oude situatie,
teams behouden autonomie,
je krijgt feiten voor de latere beslissing: hoeveel gateways, hoeveel gedelegeerde subnets, hoe ze worden gebruikt.

Negatief:

hetzelfde werk wordt in meerdere teams herhaald, en de gateways kunnen inconsistent worden,
meer gateways om te onderhouden, en elk team heeft de expertise nodig,
herwerk bij de overstap naar een centraal model,
onzekerheid over het effect van de producttransitie.

Vervolg¶

Actie	Inhoud
Evalueren na de migratie	Alle gateways inventariseren, gebruik per team documenteren, de totale operationele inspanning beoordelen
De producttransitie beoordelen	De tijdlijn van de leverancier volgen en bepalen wat technisch verandert
Beslissen over het toekomstige model	Gedecentraliseerd houden, consolideren in een centrale service met een duidelijke eigenaar, of een hybride kiezen (bijvoorbeeld één per domein)
Bij centraliseren	Een eigenaar aanwijzen en operationele verantwoordelijkheden, service levels en het supportmodel definiëren

Leg deze beslissing, de einddatum en de eigenaar vast in het besluitenlogboek (Governance).