Gedeelde services van het Integratieplatform¶
Het Integratieplatform biedt vier gedeelde services naast je spoke: Service Bus, Event Hubs, API Management en een container registry. Een gedeelde service is dure of veelgebruikte integratie-infrastructuur die meerdere workloads bedient, met een eigen lifecycle, in eigendom van het platformteam. Deze pagina beschrijft wat per service specifiek is voor integratie. De algemene werking staat in de MCP-documentatie: hoe een spoke verbinding maakt met een gedeelde service (Gedeelde services) en wat elke spoke- extensie aanmaakt (Spoke-extensies).
Optioneel, per platform ingesteld
Welke gedeelde services op je platform bestaan, in welke omgevingen en in welke configuratie, verschilt per platform. Twee van de onderstaande ontwerpen (API Management en Event Hubs) zijn in de besluitenlog gemarkeerd als Proposed: ze beschrijven het beoogde aanbod, niet noodzakelijk wat er draait. Vraag het je platformteam.
Overzicht¶
| Service | Waarvoor | Verbinding met je spoke | Detail |
|---|---|---|---|
| Service Bus | Enterprise messaging met queues en topics | extensions.servicebus en de JSON-automatisering |
Service Bus |
| Event Hubs | Event streaming met hoog volume | extensions.eventhub (een eigen event hub in de gedeelde namespace) |
Event Hubs |
| API Management | Eén gateway om API's te publiceren en te beveiligen | extensions.apim, daarna APIOps |
API Management |
| Container registry | Privé container images, bevat ook gepubliceerde platform-ingredients | extensions.acr |
Container registry |
Een extensie inschakelen is een standaardwijziging: het platformteam zet enabled voor die extensie op true in je spoke-bestand, en het wordt
actief bij de volgende spoke-deployment (Spoke JSON).
Al het verkeer tussen je spoke en een gedeelde service gaat via de hubfirewall en heeft een regel nodig als het niet al is toegestaan. De gedeelde services zijn alleen bereikbaar via private endpoint (Architectuur).
Welke messagingservice?¶
Het platform biedt beide services aan, omdat ze verschillende problemen oplossen.
| Event Hubs | Service Bus | |
|---|---|---|
| Patroon | Event streaming (een reeks events) | Enterprise messaging (losse berichten) |
| Typisch gebruik | Telemetrie, logaggregatie, datapipelines, Kafka-workloads, replay | Orders, commands, request-reply, sessions, transacties |
| Consumers | Gepartitioneerde consumers, meerdere lezers | Competing consumers, één lezer per bericht |
| Volgorde | Per partitie | Strikte volgorde met sessions |
| Retentie | Events kunnen opnieuw worden afgespeeld | Bewaard tot ze zijn verwerkt |
| Protocollen | AMQP, Kafka, HTTPS | AMQP, HTTPS |
| Mislukte berichten | Niet ontworpen voor dead-letter-afhandeling | Dead-letter queues, deferral, scheduled delivery |
Kies Service Bus als leveringsgaranties en foutafhandeling belangrijk zijn. Kies Event Hubs voor volume en replay.
Container registry¶
Een gedeelde Azure Container Registry bevat privé images voor eigen integraties en de pakketten van de gepubliceerde ingredients van het platform. Het is de enige gedeelde service in de basisdeployment van de shared services-spoke, omdat het platform zelf hem nodig heeft.
- Toegang. De deployment identities van workloads pushen en pullen. De extensie geeft je spoke twee groepen en twee managed identities, één om te pullen en één om te pushen (Gedeelde services). Toegang loopt alleen via Entra ID. Gebruik geen adminsleutels.
- Images verwijderen is voorbehouden aan het platformteam, zodat teams elkaars images niet kunnen verwijderen.
- Gebruik door modules. Een Container App-module haalt zijn images op met een managed identity die je noemt (Modules).
- Deployment. Het referentieontwerp deployt één registry voor het hele landschap, omdat een registry niet duur is en geen bedrijfsdata bevat.
- Beschikbaarheid. In de referentieanalyse staat zoneredundantie van de registry uit, en Container Apps zijn ervan afhankelijk om images op te halen. De analyse adviseert het in te schakelen (Beschikbaarheid).
Event Hubs¶
Status: proposed
De besluitenlog staat in de status Proposed (ADR-016).
Het ontwerp biedt Azure Event Hubs aan als gedeelde service, in plaats van een Event Hubs-namespace per workload, om streaming-infrastructuur te centraliseren en de kosten te beperken.
| Onderwerp | Voorgesteld ontwerp |
|---|---|
| Tier | Premium. Ondersteunt private endpoints, isoleert resources tussen tenants, ondersteunt customer-managed keys en runtime auditlogs, bevat capture, staat toe dat partities na het aanmaken worden verhoogd, en bewaart events tot 90 dagen. Schaalt in processing units (1 tot 16). |
| Waarom niet Standard | Geen resource-isolatie, kortere retentie, geen customer-managed keys, capture apart gefactureerd, geen dynamische partities |
| Waarom niet Dedicated | Hogere minimumkosten en minder elasticiteit. Te overwegen als de aanhoudende doorvoer meer wordt dan Premium ondersteunt. |
| Netwerk | Private endpoints, public network access uit |
| Beschikbaarheid | Availability zones worden automatisch gebruikt in de ondersteunde tiers |
| Jouw toegang | Via extensions.eventhub: een eigen event hub in de gedeelde namespace. De extensie geeft je groepen Owners, Contributors en Readers de rollen die staan bij Wat elke extensie aanmaakt. |
API Management¶
Status: proposed
De besluitenlog staat in de status Proposed (ADR-015). Monitoring en hostnaamconfiguratie zijn daarin nog niet beschreven.
Een gedeelde API Management-instance centraliseert API's voor de organisatie: één gateway, consistente authenticatie, versiebeheer en lifecycle, een developer portal, monitoring, rate limiting en transformatie. Het is goedkoper dan een instance per workload.
Twee aanbiedingen¶
| Premium (classic) | Standard v2 | |
|---|---|---|
| Netwerkisolatie | Volledig: VNet injection, niets direct blootgesteld | Beperkter: private endpoints en VNet-integratie, publieke toegang uit. Het management plane en de developer portal blijven publiek bereikbaar (met authenticatie). |
| Blootstelling aan internet | Via Application Gateway met WAF | Via Application Gateway met WAF |
| Beschikbaarheid | Zones, optioneel multi-region. 99,95% in één regio, 99,99% in multi-region | Eén regio, één zone. 99,95% |
| Schaal | 1 tot 99 units (volgens de besluitenlog) | 1 tot 10 units |
| Kosten | Hoger | Lager |
De besluitenlog adviseert Standard v2 met private endpoints voor de meeste enterprise-scenario's, en Premium als volledige netwerkisolatie een (regelgevende) eis is of zoneredundantie nodig is. Gebruik de Developer-tier van de classic-familie alleen voor non-productie als je de beperkingen accepteert. Uitval van een zone veroorzaakt een volledige storing bij een opzet met één zone. Waar het platform in één regio draait, kan een herdeployment via APIOps en infrastructure as code aan de hersteldoelen voldoen.
Stel API Management niet direct bloot aan internet. Publiceer het via de Application Gateway met WAF. Als workspaces uit staan en Defender for Cloud wordt gebruikt, kan Defender for APIs de API's beschermen.
Isolatie tussen workloads: centraal of workspaces¶
| Model | Hoe isolatie werkt | Wanneer |
|---|---|---|
| Centraal (standaard) | Eén instance. Scheid API's met products en subscriptions, en met Azure RBAC met custom rollen. Tags en naamgeving helpen. | Eén team beheert alle API's (centraal beheermodel) |
| Workspaces (opt-in) | Een workspace per workload die API's aanbiedt. Teams beheren daarin hun eigen API's, products en subscriptions. | Decentraal model, als de beperkingen van workspaces acceptabel zijn |
Workspaces op de gedeelde gateway hebben beperkingen: geen authenticatiepolicy met managed identity, geen Key Vault-integratie voor secrets van workspaces, geen GraphQL-resolvers of -validatie, geen authorization-context-policies, alleen geaggregeerde metrics (niet per workspace), geen workspace-specifieke analytics, geen Defender for APIs, en gedeelde compute met de hoofdservice. Het aantal workspaces is per tier beperkt (tot 30 op Premium, 5 op Standard, 1 op Basic en Developer). Dedicated workspace gateways worden niet ondersteund in het aanbod, en self-hosted gateways ook niet. De managed gateway is de standaard.
De spoke-extensie weerspiegelt deze keuze: in het centrale model krijgen je groepen rollen op de hele instance, in het decentrale model op een eigen workspace (Wat elke extensie aanmaakt).
APIOps¶
Workload teams onderhouden hun API's in Git: OpenAPI-specificaties, policies, products, named values en configuratietemplates voor meerdere omgevingen, gedeployd via de pipeline. Dit is het GitOps-idee toegepast op API's. Commit geen subscription keys; verwijs naar secrets in Key Vault (Gedeelde services).
Schalen en policies¶
- Schalen is handmatig. De integratieplatform-engineers volgen de belasting en wijzigen het aantal scale units, en deployen daarna de gedeelde service opnieuw. Schalen veroorzaakt geen downtime voor de gateway of de developer portal.
- Twee optionele policies zijn voorzien: alleen gecentraliseerde API Management (workloads mogen er geen eigen deployen) en geen publiek beschikbare API Management (publieke toegang kan niet worden ingeschakeld).