Integratieplatform: besluiten¶

Deze pagina vat de architecture decision records (ADR's) van het Integratieplatform samen in één tabel, met een korte samenvatting van de besluiten die het ontwerp bepalen. De status is zoals vastgelegd in de bron. Twee records hebben nog de status Proposed.

ADR	Besluit	Status
001	Gebruik Azure Service Bus Premium als message broker	Accepted
002	Configuratiegestuurde infrastructuur: JSON-bestanden zijn de interface voor workload teams	Accepted
003	Recursieve discovery van configuratiebestanden in elke mapstructuur	Accepted
004	Administrative units isoleren de identities die de automatisering beheert	Accepted
005	Toegangsdelegatie op basis van groepen: toegang gaat naar groepen, workload teams beheren het lidmaatschap	Accepted
006	Service Bus-configuratie in `queues.json` en `topics.json`	Accepted
007	Service Bus-toegangsbeheer per entiteit, met sender- en receiver-groepen	Accepted
008	Een eigen queue per topic subscription voor reprocessing	Accepted
010	Gelaagde architectuur: foundation, platform core (gedeelde services en control plane), consumption	Accepted
011	Realiseer de lagen met de hub-and-spoke landing zone	Accepted
012	Gesplitste verantwoordelijkheid voor Service Bus: gedeelde service, spoke extension, automatisering	Accepted
013	Omgaan met multi-factor authentication in UI-testautomatisering	Accepted (testautomatisering, hier niet behandeld)
014	Secretbeheer voor identities van testautomatisering	Accepted (testautomatisering, hier niet behandeld)
015	Gedeelde service API Management: Premium- en Standard v2-aanbod, workspaces opt-in	Proposed
016	Gedeelde service Event Hubs op de Premium-tier	Proposed

ADR-009 (adoptie van de hub-spoke-workloadarchitectuur) wordt genoemd als verfijnd door ADR-011 en staat niet in de bronset.

ADR-001: Service Bus Premium¶

Context. Workloads hebben asynchrone messaging nodig op gedeelde infrastructuur, met private connectiviteit, Entra ID- authenticatie, zoneredundantie en enterprise-schaal.

Besluit. Eén Premium-namespace per shared-services-omgeving, alleen bereikbaar via een private endpoint, met Entra ID- (RBAC-)authenticatie en zonder connection strings. Queues en topics worden centraal beheerd. Toegang loopt via workloadspecifieke groepen.

Waarom. Event Hubs mist features op berichtniveau zoals dead-letter queues en transacties. Service Bus Standard heeft geen private endpoints of zoneredundantie en een kleinere berichtgrootte. Storage queues zijn te basaal. Zelfbeheerde RabbitMQ op een Kubernetes-cluster brengt operationele last en geen native Entra ID-integratie met zich mee.

Gevolgen. Premium kost meer en heeft een vaste maandelijkse basis. Workloads delen een namespace, dus toegangsbeheer en quota zijn belangrijk. Messaging units worden handmatig geschaald en schalen kan verbindingen even resetten. Wijzigingen moeten via de automatisering lopen om drift te voorkomen.

ADR-002 en ADR-003: configuratiegestuurd¶

Workload teams moeten geen Terraform hoeven schrijven om een queue te krijgen. Ze beschrijven in JSON wat ze nodig hebben (de intent), het platform onderhoudt de Terraform die afdwingt hoe het wordt gebouwd. Dat beperkt wat een gebruiker kan wijzigen, houdt naamgeving, tagging en beveiligingsinstellingen uniform, en laat andere tools de bestanden genereren of valideren. De prijs is dat validatie pas bij het plannen kan falen, en dat een te eenvoudig schema verzoeken uitlokt om ruwe opties door te geven.

De automatisering vindt de bestanden met een glob-patroon in de rootmap en elke submap, en voegt ze samen. Teams organiseren per omgeving, domein of team. De prijs: een dubbele definitie in twee mappen is moeilijk te zien, dus de validatie moet op uniciteit controleren.

ADR-004 en ADR-005: identiteitsisolatie en groepen¶

De automatisering heeft rechten nodig om Entra ID-groepen aan te maken. Dat op tenantniveau toekennen is onaanvaardbaar, dus het wordt per omgeving beperkt tot een administrative unit. Een gecompromitteerde credential van de automatisering kan alleen de groepen in zijn unit raken. De unit moet bestaan voordat de automatisering draait.

De automatisering wijst geen workload identities aan resources toe. Ze geeft een groep de permissie en maakt het workload team eigenaar van de groep. Identity-rotatie vraagt dan geen infrastructuurwijziging, access reviews kunnen op groepen worden gedaan, en het patroon is hetzelfde voor elk resourcetype. De prijs is veel groepen en een korte vertraging voordat wijzigingen in lidmaatschap ingaan.

ADR-006 tot en met ADR-008: Service Bus-model¶

Queues worden gedefinieerd in queues.json en topics, subscriptions en rules in topics.json, elk met een expliciete workload- eigenaar. Een feature toevoegen (bijvoorbeeld sessions of TTL's) betekent het Terraform-schema uitbreiden.
Groepen worden per entiteit aangemaakt, niet per namespace, zodat één workload de queue van een andere niet kan lezen. Standaardprofielen zijn sender en receiver. Het record noemt ook een manager-profiel, dat de huidige Terraform niet aanmaakt. Het patroon voor de groepsnaam identificeert workload, entiteit en rol. Het lidmaatschap wordt door het workload team beheerd, niet in de JSON.
Voor elke topic subscription maakt het platform een queue aan en stuurt de subscription ernaar door. Consumers lezen de queue. Mislukte berichten komen in de dead-letter van een queue die alleen die workload beheert. Een retry stuurt opnieuw naar die queue, niet naar de topic, zodat andere subscribers geen duplicaten krijgen. De kosten zijn een paar extra entiteiten.

ADR-010 tot en met ADR-012: lagen en gesplitste verantwoordelijkheid¶

Het platform is in drie lagen gebouwd: de foundation (netwerk, identiteit, security, oftewel de landing zone), de platform core (een shared services-workload met de engines, en een control plane-workload die hun configuratie en toegang beheert) en de consumption-laag (de integraties). Door engine en control plane te splitsen krijgen ze onafhankelijke lifecycles.

Op Azure worden de lagen afgebeeld op de hub en spokes: de gedeelde services draaien in een eigen shared services-spoke, de control plane in een eigen spoke, en elke integratieworkload in een eigen spoke. Het platform gebruikt de hub voor connectiviteit en firewalling en bouwt geen eigen netwerk. Een securityincident in de control plane-spoke kan de gedeelde services niet direct platleggen. Verkeer ertussen passeert de hub firewall.

Voor Service Bus wordt dit drie lagen, in volgorde gedeployd: de namespace als gedeelde service, de spoke extension voor permissies, en de automatisering voor entiteiten en groepen. Het platformteam beheert de leidingen, het integratieteam de inhoud. Troubleshooting beslaat drie codebases en elke laag moet zijn afhankelijkheden valideren. Zie Service Bus-automatisering.

Een vastgelegde inconsistentie: het ADR-010-bestand beschrijft drie lagen in het besluit en noemt een stack van vijf lagen in de gevolgen. Beschouw het model met drie lagen als het besluit.

ADR-015: gedeelde service API Management¶

Proposed. Twee aanbiedingen: Premium (classic) met VNet-injectie, zoneredundantie en optioneel multi-region, of Standard v2 met private endpoints en VNet-integratie tegen lagere kosten en met minder isolatie. Beide worden via een Application Gateway met WAF aan het internet blootgesteld. Workspaces zijn opt-in vanwege hun limieten, dedicated workspace gateways en self-hosted gateways worden niet ondersteund, schalen is handmatig en API's worden beheerd met APIOps. Details: Gedeelde services.

ADR-016: gedeelde service Event Hubs¶

Proposed. Premium-tier, voor resource-isolatie, customer-managed keys, inbegrepen capture, 90 dagen retentie, dynamische partities en privénetwerken. Dedicated is een toekomstige optie voor zeer hoge aanhoudende doorvoer. Details: Gedeelde services.

Niet samengevat¶

ADR-013 en ADR-014 (MFA-afhandeling en secrets voor UI-testautomatisering van de bronrepository) gaan over de eigen testopzet van het team en maken geen deel uit van de service. Het ADR-template en de handleiding van de bronrepository worden hier niet herhaald.