Integratieplatform: servicebeschrijving¶
Deze pagina beschrijft wat het Integratieplatform biedt, hoe wijzigingen verlopen en waar de grenzen liggen. De andere pagina's gaan dieper in op de details: Architectuur, Beheermodel, Aanvragen en wijzigen, Modules, Service Bus en Gedeelde services.
Optioneel aanbod, per platform ingesteld
De service is een optionele bouwsteen, geleverd door het platformteam onder een overeenkomst (Beheermodellen). Supporturen, reactietijden, beschikbaarheidsdoelen, contactpersonen en tarieven maken deel uit van die overeenkomst en staan niet in deze documentatie. Waar deze pagina een standaardwaarde noemt, is dat de gebruikelijke waarde van het referentieontwerp. Jouw platform kan afwijken.
In het kort¶
Het platform verpakt Azure Integration Services in een omgeving die bouwers prettig vinden. Integratiebouwers hoeven geen infrastructuurexperts te zijn: ze vragen wat ze nodig hebben aan via configuratiebestanden en pull requests, en het platform deployt het op een standaard, veilige en gemonitorde manier.
| Waarde | Wat het betekent |
|---|---|
| Eenvoudige infrastructuurdeployment | Vooraf gedefinieerde Terraform-modules en automatisering deployen en configureren de onderliggende Azure-resources. |
| Monitoring en observability | Ingebouwde monitoring met Azure Monitor en Application Insights. Bouwers monitoren hun integraties, platform engineers monitoren de gedeelde services en hun afhankelijkheden. |
| Governance en security by design | Gedeelde, voorgeconfigureerde services passen beveiligingsbeleid, authenticatie en governance automatisch toe. |
| Sneller waarde leveren | Gedeelde infrastructuur en eenvoudige deploymentmechanismen laten teams hun tijd aan het bedrijfsprobleem besteden. |
Ingredients¶
Een ingredient is een herbruikbaar, compliant infrastructuurpakket dat het platformteam onderhoudt. Er zijn drie soorten.
| Soort | Wat | Voorbeelden |
|---|---|---|
| Platformservices | Aangeboden voor het hele Integratieplatform | DNS, documentatiegeneratie |
| Gedeelde services | Dure, veelgebruikte integratie-infrastructuur voor meerdere workloads. Platformbreed aangeboden om kosten, security en governance in balans te houden. | API Management, Service Bus, Event Hubs, Azure Container Registry |
| Modules | Deployen één integratieservice in een workload-spoke, verbonden met de spoke en met de gedeelde services | Logic App, Function App, Container App, Data Factory |
Platformservices¶
- DNS. Centraal beheerde domeinnaamservices voor het Integratieplatform, zodat namen worden opgelost naar de Azure- resources in het platform, inclusief gedeelde services en modules. Publieke en private Azure DNS-zones bedienen resources die via een IP-adres bereikbaar moeten zijn, zoals een HTTP-endpoint. Zie ook DNS voor private endpoints.
- Documentatiegeneratie. Genereert documentatie voor de gepubliceerde ingredients.
Gedeelde services¶
| Service | Waarvoor | Pagina |
|---|---|---|
| Service Bus | Betrouwbare enterprise messaging: queues en topics, dead-lettering, scheduling, transacties. Entiteiten en toegang worden beheerd vanuit JSON-bestanden. | Service Bus |
| Event Hubs | Event streaming met hoge doorvoer, ondersteuning van het Kafka-protocol, capture en retentie | Gedeelde services |
| API Management | Eén gateway om API's te publiceren, te beveiligen en te observeren, met een APIOps-workflow | Gedeelde services |
| Azure Container Registry | Centrale opslag voor private container images die door eigen integraties worden gebruikt. Deployment identities van workloads pushen en pullen. Alleen het platformteam kan images verwijderen. | Gedeelde services |
Gedeelde services zijn van het platformteam en hebben een eigen lifecycle. Elk heeft een automatiseringslaag, zodat bouwers via pull requests kunnen aanvragen wat ze nodig hebben (welke topics, queues of API's, met welke permissies). Permissies worden per workload toegewezen, wat workloads van elkaar isoleert.
Modules¶
| Module | Wat het in je spoke deployt |
|---|---|
| Logic App | Een Logic App Standard met private endpoint, ingebouwde authenticatie, eigen storage account en monitoring |
| Function App | Een Function App met VNet-integratie en private endpoint, met managed identity voor storage |
| Container App | Een Container Apps-omgeving met container apps en container jobs (handmatig, event-getriggerd, gepland), in t-shirtmaten |
| Data Factory | Een Data Factory met managed virtual network, integration runtime en linked services naar de Key Vault en storage van de spoke |
Details en standaardwaarden: Modules.
Hoe teams met het platform werken¶
Alle interactie met het platform loopt via Git en pull requests: ingredients aanvragen en configureren, en wijzigen. Dit geeft versiebeheer, traceerbaarheid en review. De code en platformmogelijkheden worden ondersteund door GitHub of Azure DevOps. Het referentieontwerp gebruikt GitHub.
- Gecontroleerde promotie. Nieuwe versies van ingredients en integratielogica worden door het platform over omgevingen gepromoveerd, met omgevingen en goedkeuringen in het repositoryplatform en een workflow voor versioned packages.
- Industriestandaardtalen. De automatisering is geschreven in Terraform en PowerShell.
- Gedeelde broncode. De broncode van de automatisering wordt met het platform meegeleverd, zodat bouwers kunnen lezen hoe het werkt.
- Herbruikbaarheid. Elk deploybaar ingredient is een Terraform-module.
- Geautomatiseerde permissies en deployments. Het platform richt permissies en deploymentpipelines in zodat een team alleen zijn eigen integraties kan beheren en deployen (least privilege).
- Verbinding met gedeelde services. Het platform beheert de aansluitpunten op de gedeelde services. Bouwers richten zich op de bedrijfslogica in hun eigen Logic App of Function App.
Wie wat doet in het centrale, hybride en decentrale model: Beheermodel.
Security en compliance¶
Het referentieontwerp is gebouwd om aan te sluiten op CIS (versie 2.0), ISO 27001 en de Microsoft cloud security benchmark. Deze standaarden zijn ingebouwd in de automatisering, governance en deployment, zodat bouwers compliance-instellingen niet met de hand hoeven te configureren. De algemene platformcontroles staan in de MCP-documentatie (Governance).
| Onderwerp | Standaard in het referentieontwerp |
|---|---|
| Netwerk | Gedeelde services en modules gebruiken standaard privénetwerken (private endpoints, VNet-integratie of -injectie). Er bestaat geen verbinding tussen workloads tenzij de hub firewall die toestaat. |
| Identiteit | Entra ID en Azure RBAC. Toegang tot Service Bus-entiteiten en de registry via groepen. Geen gedeelde keys voor Service Bus (de namespace heeft lokale authenticatie uitgeschakeld). |
| Encryptie at rest | Het ontwerp beoogt customer-managed keys voor de gedeelde services en voor de resources die het platform deployt. Voor Service Bus is Microsoft-managed encryptie de standaard en een customer-managed key optioneel. Controleer wat jouw deployment gebruikt. |
| Defender | Microsoft Defender for APIs op de integratiesubscriptions, bovenop de Defender-plannen van het platform |
| Policy | Geen extra Azure Policy naast die van het platform zelf. Extra policy kan later worden toegevoegd, bijvoorbeeld om door de workload beheerde API Management of Service Bus te verbieden. |
Monitoring en alerting¶
- Geautomatiseerde alert-deployment. Alerts worden tijdens de deployment toegepast, zonder handmatige configuratie.
- Dekking. Metric alerts (bijvoorbeeld CPU, geheugen, queue depth), logbased alerts voor applicatiefouten en health checks voor de kritieke services.
- Action groups. Notificaties worden via configureerbare action groups gerouteerd, naar het platformteam of de workload owners.
- Dashboards. Azure Monitor en Application Insights.
Wat elk ingredient daadwerkelijk deployt, staat per module beschreven in Modules en in Operations.
Standaardwijzigingen¶
Een standaardwijziging is sterk geautomatiseerd en kent geen maximumaantal. Hoe meer ze worden gebruikt, hoe beter het platform jou dient. Pull requests van bouwers die een proces verbeteren zijn welkom. Het platformteam voert deze uit in een managed service. Als je het platform zelf beheert, laat de lijst zien wat het beheren van het platform inhoudt. De lijst staat op Aanvragen en wijzigen.
Beschikbaarheidsdoelen¶
De overeenkomst definieert een beschikbaarheidsdoel per gedeelde service (Service Bus, Event Hubs, API Management, container registry), gemeten per kwartaal. De waarden zijn contractdetails en worden hier niet herhaald. Voor de veerkracht van de Azure-services waarop het platform is gebouwd, zie Beschikbaarheid.
Verantwoordelijkheden¶
De verdeling van verantwoordelijkheden tussen het platformteam en het workload team, en de referentie-RACI, staan op Beheermodel.