Decentralised Data Gateway

A pattern for services that need access to private data but have no clear owner yet. The example is a data gateway for a business-intelligence or analytics service, but the same reasoning applies to any service that must reach private resources from outside the network.

Situation

Teams use an analytics service (for example Power BI) that reaches data sources through public endpoints, such as storage accounts or SQL servers. In the managed platform, public endpoints on data resources are denied, so the old approach no longer works.

The service supports a data gateway that reaches private resources. The gateway must run in a delegated subnet of a virtual network on the platform.

The ideal would be one central gateway service. In practice:

• no team can take ownership of a central gateway,
• running application-level services like this gateway is usually outside the scope of the managed service,
• the vendor's licence and product line may be in transition (for example one product replaced by another), so it is unclear what the long-term requirement is,
• the scale of the usage is unknown.

Migrations of workloads must not wait for these decisions.

Guidance: decentralise, temporarily

Let each team that needs the service run its own gateway:

1. The team gets a subnet with the right delegation in its own spoke virtual network.
2. The team deploys and manages its own gateway in that subnet.
3. The gateway reaches the data sources in the team's own subscriptions. A team with several subscriptions can reach all of them through one gateway.
4. There is no central gateway service for now.
5. The decision is explicitly temporary. Plan a re-evaluation at a fixed moment, for example when the migration programme ends or when the product transition completes.

How to do it in MCP

Request a spoke change that adds a subnet with the delegation the service needs (Change spoke). A subnet takes a delegations entry whose name must be one of the values of the JSON schema (Spoke JSON reference). Check that the delegation your service needs is in that list before you plan on it. The subnet must be large enough for the service: check the vendor's minimum size and see Plan your IP range and subnets.

The firewall still applies. The gateway must reach the vendor's service endpoints and the data sources, so request rules like for any other workload (Firewall rule organisation).

Consequences

Positive:

• migrations continue without waiting for organisational decisions,
• no public endpoints on data resources, so security improves compared with the old situation,
• teams keep autonomy,
• you get facts for the later decision: how many gateways, how many delegated subnets, how they are used.

Negative:

• the same work is repeated in several teams, and the gateways may end up inconsistent,
• more gateways to maintain, and every team needs the expertise,
• rework when you move to a central model,
• uncertainty about the effect of the product transition.

Follow-up

Action	Content
Evaluate after the migration	Inventory all gateways, document usage per team, assess the total operational effort
Assess the product transition	Follow the vendor's timeline and decide what changes technically
Decide on the future model	Keep decentralised, consolidate into a central service with a clear owner, or choose a hybrid (for example one per domain)
If centralising	Name an owner and define operational responsibilities, service levels and the support model

Record this decision, its end date and its owner in the decision log (Governance).