Integration Platform: architectuur¶

Deze pagina beschrijft het globale ontwerp van het Integration Platform: de layers, de workloads en spokes, de omgevingen, het netwerk, identity, security en resilience. Het is het referentieontwerp. Jouw deployment kan afwijken in het aantal omgevingen, de shared services die zijn ingeschakeld en de gekozen opties. Vraag het aan je platformteam.

Principes¶

Het Integration Platform erft de ontwerpprincipes van MCP (Ontwerpprincipes) en voegt er vier van zichzelf aan toe.

Principe	Betekenis
Cloud-first	Gebruik cloud-native Azure-services voor schaalbaarheid, betrouwbaarheid en kostenefficiëntie.
Gestandaardiseerd maar uitbreidbaar	Standaardpatronen halen infrastructuurcomplexiteit weg en geven hergebruik. Als er een nieuw patroon opkomt, kan op beheerste wijze een nieuwe bouwsteen worden toegevoegd.
Event-driven	Integraties reageren in real time, schalen onafhankelijk en blijven losjes gekoppeld.
You build it, you run it	Het team dat een integratie bouwt is gedurende de hele levensduur verantwoordelijk voor die integratie: deployment, monitoring en herstel. Automatisering en DevOps-praktijken ondersteunen dat.

Capabilities¶

Het platform drukt zijn aanbod uit in technologie-agnostische capabilities. Het referentieontwerp koppelt elke capability aan ingrediënten. Een capability kan door een organisatie wel of niet nodig zijn. Wat nodig is, is een keuze per platform.

Capability	Wat het omvat	Typische ingrediënten
Message and event brokering	Asynchrone, event-gebaseerde communicatie met volgorde, leveringsgaranties en ontdubbeling	Service Bus, Event Hubs
API management	API's ontwikkelen, publiceren, beveiligen, monitoren en analyseren	API Management
Low-code modules	Integraties gebouwd met configuratie, workflows en drag-and-drop	Logic App, Data Factory
High-code modules	Integratielogica in een programmeertaal, met de runtime en infrastructuur geleverd	Function App, Container App
Triggers and jobs	Geplande en door events getriggerde verwerking, batchjobs	Container jobs, Logic Apps, Data Factory
Infrastructure	Platforminfrastructuur en infrastructuur voor nieuwe integraties, inclusief gedeelde build runners	Spoke canvas, modules, container registry
Recipes and documentation	Richtlijnen, voorbeelden en best practices voor builders	Documentatiegeneratie
Provisioning and automation	Templates voor deploymentpipelines, geen handmatige infrastructuur	Terraform-modules, herbruikbare workflow
Collaboration	Broncode en automatisering op het repositoryplatform, work items in een ticketingtool	GitHub (referentieontwerp)

Verdere capabilities die een platform kan toevoegen als er een duidelijke behoefte is: verbindingen met bronsystemen, documentverwerking, een integratiedirectory, AI-augmentatie en B2B-integratie (EDI, AS2). Ze maken geen deel uit van het referentieontwerp.

Layers¶

Het ontwerp scheidt wat waarop draait (ADR-010, ADR-011).

flowchart TB
    subgraph L3["Consumption"]
        iw["Integration workloads<br/>Logic Apps, Function Apps, Container Apps, Data Factory, API definitions"]
    end
    subgraph L2["Platform core"]
        ssw["Shared services workload<br/>Service Bus, Event Hubs, API Management, ACR"]
        cpw["Control plane workload<br/>configuration, access control, governance of the shared services"]
        cpw -->|"configures"| ssw
    end
    subgraph L1["Foundation: MCP"]
        hub["Hub: network, firewall, DNS, identity governance"]
        sp["Spokes (spoke canvas)"]
    end
    iw -->|"consumes"| ssw
    L2 -->|"runs on"| L1
    L3 -->|"runs on"| L1

Layer	Verantwoordelijkheid	Gerealiseerd als
Foundation	Netwerk, firewalling, DNS, identity governance, securitygrenzen ("de kiestoon")	MCP hub en spokes. Het platform bouwt geen eigen netwerkbackbone.
Platform core	De engines (shared services) en het control plane dat hun configuratie en toegang beheert	Een shared services spoke en een control plane-deployment
Consumption	De integraties die builders maken	Spokes voor integratieworkloads

Door engine en control plane te scheiden kan het control plane opnieuw worden gedeployd of bijgewerkt zonder de uptime van de shared services te raken. De prijs is afstemming: beide moeten het eens zijn over wat er is gedeployd, en het verkeer ertussen loopt via de hub firewall.

Workloads, spokes en omgevingen¶

Een workload bestaat uit één of meer omgevingen, en elke omgeving is een spoke: een eigen Azure subscription met de basisinfrastructuur van het spoke canvas (Wat je krijgt). Elk virtueel netwerk van een spoke is gepeerd met de hub.

Workload	Bevat
Shared services workload	De ingeschakelde shared services. De basisdeployment bevat alleen de Azure Container Registry, omdat het platform die nodig heeft om ingrediënten te publiceren. Andere worden toegevoegd als workloads ze nodig hebben.
Integration Platform workload	De ingeschakelde platformservices. De basisdeployment bevat DNS, bijvoorbeeld voor de naamresolutie van extern blootgestelde API's.
Integratieworkloads	De integraties. Elke gebruikt spoke-extensies om te verbinden met de shared services die ze nodig heeft, en modules om haar integratieservices te deployen.

flowchart TB
    hub["MCP hub: firewall, DNS"]
    subgraph prd["Production"]
        ssp["Shared services spoke (prod)"]
        ipp["Integration Platform spoke (prod)"]
        w1p["Integration workload spoke (prod)"]
    end
    subgraph nprd["Non-production"]
        ssn["Shared services spoke (non-prod)"]
        ipn["Integration Platform spoke (non-prod)"]
        w1n["Integration workload spoke (non-prod)"]
    end
    hub --- ssp & ipp & w1p
    hub --- ssn & ipn & w1n
    w1p -.->|"extension"| ssp
    w1n -.->|"extension"| ssn

Ontwerpkeuzes van het referentieontwerp:

Twee omgevingen voor het platform, productie en niet-productie, zodat nieuwe versies van shared services buiten productie kunnen worden getest. Er kunnen meer omgevingen worden toegevoegd, omdat een platforminstantie met automatisering opnieuw kan worden gedeployd. Kosten en complexiteit zijn de reden om het bij twee te houden.
Workloads volgen hun omgeving. Productieworkloads verbinden met het productieplatform, niet-productieworkloads met het niet-productieplatform. Het aantal spokes per workload wordt per workload gekozen.
Een resource die goedkoop is en geen bedrijfsdata bevat, kan één keer worden gedeployd. Een Azure Container Registry wordt bijvoorbeeld doorgaans één keer voor het hele landschap gedeployd, niet per omgeving.
Verbindingen zijn nooit impliciet. Elke verbinding tussen workloads, of naar buiten, loopt via de hub firewall en heeft een regel nodig (Firewallregels en IP-groepen). Een integratieworkload gebruikt niet standaard een shared service. Een workload mag er geen gebruiken.
Integraties met on-premises systemen lopen via de hub en zijn firewall. Het is de bedoeling dat ze in een migratie tijdelijk zijn.

Hoe je een workload afbakent¶

Een integratieworkload kan op verschillende manieren worden afgebakend, alleen of gecombineerd. Begin met één of een paar workloads en splits ze als dat nodig is.

Afbakening	Sterk punt	Let op
Per team	Duidelijke verantwoordelijkheid en autonomie, snelle beslissingen	Duplicatie als teams geen kennis delen
Per functioneel domein	Past bij domain-driven design, hergebruik binnen een domein	Afstemming voor domeinoverstijgende zaken
Per systeem	Eenvoudige lifecycle, systeemspecifieke controls	Vervaagd eigenaarschap als meerdere teams het systeem raken, lastig voor integraties die meerdere systemen beslaan
Per flow (alles tussen systeem A en B)	Traceerbaarheid, isolatie, eenvoudige troubleshooting	Veel kleine workloads, operationele overhead per flow

Netwerk¶

Het Integration Platform past dezelfde segregatie toe als MCP. De hub firewall staat standaard alleen verkeer binnen een spoke toe. Om verkeer naar of vanaf een bron of bestemming buiten de spoke toe te staan, dien je een standaardwijziging in bij het platformteam (Firewallregels en IP-groepen). Verkeer van en naar on-premises wordt standaard geblokkeerd.

Shared services en modules gebruiken standaard private networking. Azure kent drie isolatieniveaus:

Niveau	Wat het doet	Richting
VNet integration	De service stuurt uitgaand verkeer via de Azure-backbone het VNet en gepeerde VNets in	Uitgaand
VNet injection (subnet delegation)	De service draait in een eigen subnet met eigen private IP's	Inkomend en uitgaand
Private Link met private endpoints	De service krijgt een privé-IP in een subnet en zijn publieke toegang kan worden uitgezet	Alleen inkomend

VNet injection heeft de voorkeur als de service het ondersteunt, maar het kan meer kosten vanwege dedicated compute. Anders worden private endpoints gecombineerd met VNet integration. API Management laat het verschil zien: de Premium-tier (classic) ondersteunt injection, Standard v2 alleen integration met private endpoints (Shared services).

Private endpoints in het platform hebben ook naamresolutie nodig vanuit je eigen netwerken. De vereiste DNS-forwarding staat op DNS voor private endpoints. Het MCP-ontwerp staat in DNS-ontwerp.

Als een API of endpoint vanaf internet bereikbaar moet zijn, zet die dan achter de Application Gateway met WAF van de hub (Shared services). De hub biedt DDoS-bescherming op het publieke IP van de Application Gateway.

Identity en toegang¶

Het Integration Platform volgt de RBAC- en PIM-standaarden van MCP (Identity- en toegangsmodel, Toegang, groepen en PIM): least privilege en just-in-time.

Daarbovenop gebruikt het platform twee patronen, beide beschreven in Beslissingen:

Groepsgebaseerde delegatie van toegang (ADR-005). Resources krijgen nooit roltoewijzingen voor individuele identities. Elke permissie (bijvoorbeeld "send to queue X") is een Entra ID-groep. Het workload team is eigenaar van het lidmaatschap en wijzigt het zonder pipelinerun.
Administrative units (ADR-004). De automatisering die groepen aanmaakt is beperkt tot een Entra ID administrative unit. Een gecompromitteerde automatiseringsidentity kan geen groepen buiten die unit wijzigen.

Spoke-extensies maken per spoke de basisgroepen en roltoewijzingen aan. Lees wat een extensie aanmaakt in Spoke-extensies.

Security¶

Onderwerp	Referentieontwerp
Policies	Geen andere policies dan die van MCP. Optionele extra policies kunnen later worden toegevoegd, afgedwongen en geremedieerd. Een workload of spoke kan bijvoorbeeld op zijn eigen subscription een regulatory policy initiative inschakelen.
Defender for Cloud	De plannen van het platform plus Defender for APIs op de integratiesubscriptions. De kosten maken deel uit van de subscriptionkosten. Let op: Defender for APIs is niet beschikbaar voor workspace-API's in API Management.
Encryptie in transit en at rest	MCP-standaarden. Customer-managed keys waar een shared service dat ondersteunt.
IP-allowlists	API Management kan aanroepers beperken op IP-adres. Aanbevolen voor bekende, op internet gehoste systemen.
Scope van het platform	Het platform beheert het management plane (resources en RBAC). Data-plane-acties en data-plane-RBAC van de gedeployde resources zijn de verantwoordelijkheid van de workload-eigenaar.

Levering van het platform en van ingrediënten¶

Het platform wordt vanaf het repositoryplatform met pipelines gedeployd en beheerd. Alle deploymentlogica, omgevingsparameters en automatiseringsscripts zijn code, dus deployments zijn herhaalbaar en auditbaar. Het platform wordt opgestart met vooraf gedefinieerde workflows die de kerncomponenten deployen, zoals de shared services.

Integratiespokes worden door het platformteam gedeployd via de normale spoke-pipeline: eerst een gewone spoke, optioneel uitgebreid met spoke-extensies die de spoke toegang geven tot de shared services (Spoke-extensies). Daarna kunnen builders beginnen.

Een ingrediënt publiceren en gebruiken:

flowchart LR
    pe["Integration platform engineer<br/>adds or updates ingredient code"] --> build["Build automation<br/>creates a package"]
    build --> reg["Container registry<br/>(shared service)"]
    ib["Integration builder<br/>references the ingredient, sets parameters"] --> tpl["Build templates of the platform"]
    reg --> tpl
    tpl --> spoke["Deploy into the workload spoke(s)"]

Toegang tot de registry wordt met Entra ID beschermd.

Resilience¶

Onderwerp	Referentieontwerp
Regio	Eén regio. Availability zones spreiden de services over datacenters, wat beschermt tegen de uitval van een datacenter maar niet tegen een regionale uitval.
Disaster recovery	Volgt MCP. Het platform en de shared services kunnen binnen enkele uren in een andere regio opnieuw worden gedeployd, in lijn met een recovery time objective van 24 uur en een recovery point objective van 48 uur. Beide waarden worden per platform ingesteld.
Workloads	Een workload die alleen shared services en modules van het platform gebruikt, kan ook in een andere regio opnieuw worden gedeployd, omdat de modules een locatie accepteren. Andere resources zijn de verantwoordelijkheid van het workload team.
Beschikbaarheid	Hangt af van de configuratie: bijvoorbeeld het aantal replicas van een Container App of het aantal instances van een Logic App-plan. Service-level agreements van Azure-services zijn niet hetzelfde als de beschikbaarheidsdoelen die je aan je afnemers belooft.
Configuratie	De platformconfiguratie is code in een Git-repository.

Meer detail, afhankelijkheden en samengestelde beschikbaarheid per integratiepatroon: Beschikbaarheid.

Monitoring¶

De logging breidt de logging van MCP uit.

Integration Platform spoke: geen extra alertregels naast die van MCP. Het team kan eigen regels toevoegen.
Shared services: mogen eigen logging toevoegen. De shared service API Management deployt bijvoorbeeld een Application Insights-resource die met de Log Analytics workspace van zijn spoke is verbonden.
Modules: sturen logs naar de Log Analytics workspace van de spoke, in sommige gevallen via een Application Insights-resource. Ze kunnen een action group en alertregels toevoegen. Sommige vereisen dat het workload team extra onderdelen implementeert (Modules).