Integration Platform: Service Description¶
This page describes what the Integration Platform offers, how changes are made and where the boundaries are. The other pages go into the details: Architecture, Operating model, Request and change, Modules, Service Bus and Shared services.
Optional offering, set per platform
The service is an optional building block, delivered by the platform team under an agreement (Operating models). Support hours, response times, availability targets, contacts and fees are part of that agreement and are not in this documentation. Where this page names a default, it is the usual value of the reference design. Your platform can differ.
In short¶
The platform packages Azure Integration Services into a builder-friendly environment. Integration builders do not need to be infrastructure experts: they ask for what they need through configuration files and pull requests, and the platform deploys it in a standard, secure and monitored way.
| Value | What it means |
|---|---|
| Simple infrastructure deployment | Predefined Terraform modules and automation deploy and configure the underlying Azure resources. |
| Monitoring and observability | Built-in monitoring with Azure Monitor and Application Insights. Builders monitor their integrations, platform engineers monitor the shared services and their dependencies. |
| Governance and security by design | Shared, pre-configured services apply security policies, authentication and governance automatically. |
| Faster time to value | Shared infrastructure and simple deployment mechanisms let teams spend their time on the business problem. |
Ingredients¶
An ingredient is a reusable, compliant infrastructure package that the platform team maintains. There are three kinds.
| Kind | What | Examples |
|---|---|---|
| Platform services | Offered across the whole Integration Platform | DNS, documentation generation |
| Shared services | Costly, commonly used integration infrastructure for several workloads. Offered platform-wide to balance cost, security and governance. | API Management, Service Bus, Event Hubs, Azure Container Registry |
| Modules | Deploy one integration service in a workload spoke, connected to the spoke and to the shared services | Logic App, Function App, Container App, Data Factory |
Platform services¶
- DNS. Centrally managed domain name services for the Integration Platform, so that names resolve to the Azure resources in the platform, including shared services and modules. Azure DNS public and private zones serve resources that must be reachable through an IP address, such as an HTTP endpoint. See also Private endpoint DNS.
- Documentation generation. Generates documentation for the published ingredients.
Shared services¶
| Service | What it is for | Page |
|---|---|---|
| Service Bus | Reliable enterprise messaging: queues and topics, dead-lettering, scheduling, transactions. Entities and access are managed from JSON files. | Service Bus |
| Event Hubs | High-throughput event streaming, Kafka protocol support, capture and retention | Shared services |
| API Management | One gateway to publish, secure and observe APIs, with an APIOps workflow | Shared services |
| Azure Container Registry | Central storage for private container images used by custom integrations. Workload deployment identities push and pull. Only the platform team can delete images. | Shared services |
Shared services belong to the platform team and have their own lifecycle. Each one has an automation layer, so that builders can ask for what they need (which topics, queues or APIs, with which permissions) through pull requests. Permissions are assigned per workload, which isolates workloads from each other.
Modules¶
| Module | What it deploys in your spoke |
|---|---|
| Logic App | A Logic App Standard with private endpoint, built-in authentication, own storage account and monitoring |
| Function App | A Function App with VNet integration and private endpoint, using managed identity for storage |
| Container App | A Container Apps environment with container apps and container jobs (manual, event-triggered, scheduled), in t-shirt sizes |
| Data Factory | A Data Factory with managed virtual network, integration runtime and linked services to the spoke Key Vault and storage |
Details and defaults: Modules.
How teams work with the platform¶
All interaction with the platform runs through Git and pull requests: requesting and configuring ingredients, and changing them. This gives version control, traceability and review. The code and platform capabilities are supported by GitHub or Azure DevOps. The reference design uses GitHub.
- Managed promotion. New versions of ingredients and integration logic are promoted across environments by the platform, with environments and approvals in the repository platform and a workflow for versioned packages.
- Industry-standard languages. The automation is written in Terraform and PowerShell.
- Shared source code. The source code of the automation is delivered with the platform, so builders can read how it works.
- Reusability. Every deployable ingredient is a Terraform module.
- Automated permissions and deployments. The platform sets up permissions and deployment pipelines so that a team can manage and deploy only its own integrations (least privilege).
- Connection to shared services. The platform manages the connection points to the shared services. Builders focus on the business logic in their own Logic App or Function App.
Who does what in the central, hybrid and decentral model: Operating model.
Security and compliance¶
The reference design is built to align with CIS (version 2.0), ISO 27001 and the Microsoft cloud security benchmark. These standards are embedded in the automation, governance and deployment, so that builders do not configure compliance settings by hand. The generic platform controls are in the MCP documentation (Governance).
| Topic | Default in the reference design |
|---|---|
| Network | Shared services and modules use private networking by default (private endpoints, VNet integration or injection). No connection between workloads exists unless the hub firewall allows it. |
| Identity | Entra ID and Azure RBAC. Access to Service Bus entities and the registry through groups. No shared keys for Service Bus (the namespace has local authentication disabled). |
| Encryption at rest | The design intends customer-managed keys for the shared services and for the resources that the platform deploys. For Service Bus, Microsoft-managed encryption is the default and a customer-managed key is optional. Check what your deployment uses. |
| Defender | Microsoft Defender for APIs on the integration subscriptions, on top of the Defender plans of the platform |
| Policy | No additional Azure Policy besides the platform's own. Extra policy can be added later, for example to forbid workload-owned API Management or Service Bus. |
Monitoring and alerting¶
- Automated alert deployment. Alerts are applied during deployment, without manual configuration.
- Coverage. Metric alerts (for example CPU, memory, queue depth), log-based alerts for application errors, and health checks for the critical services.
- Action groups. Notifications are routed through configurable action groups, to the platform team or workload owners.
- Dashboards. Azure Monitor and Application Insights.
What each ingredient actually deploys is described per module in Modules and in Operations.
Standard changes¶
A standard change is highly automated and has no maximum number. The more they are used, the better the platform serves you. Pull requests from builders that improve a process are welcome. The platform team performs these in a managed service. If you manage the platform yourself, the list shows what managing the platform involves. The list is on Request and change.
Availability targets¶
The agreement defines an availability target per shared service (Service Bus, Event Hubs, API Management, container registry), measured per quarter. The values are contract details and are not repeated here. For the resilience of the Azure services that the platform is built on, see Availability.
Responsibilities¶
The responsibility split between the platform team and the workload team, and the reference RACI, are on Operating model.