Integration Platform: Operations¶
This page is for the platform team (the integration platform engineers, and the MCP platform team where it supports them). It collects the regular tasks, scaling, monitoring, lifecycle and how to extend the platform. The runbooks of the MCP (Operations) apply to the hub and spokes. This page adds what is specific to integration.
Two operating models
The platform team is XMMS under a managed-service contract, or your own team (Operating models). Contract-specific items such as support hours, standby and response targets come from your agreement. The reference design assumes standby for the platform (not for the integrations) from the first live integration. Check what applies to you.
Regular tasks¶
| Task | Frequency | What |
|---|---|---|
| Handle standard changes | Per request | Request and change |
| Review configuration pull requests | Per request | Service Bus checklist |
| Watch load on the shared services | Continuous (alerts), regular review | Messaging units of Service Bus, units of API Management, processing units of Event Hubs |
| Watch dead-letter growth and connection health | Continuous | Service Bus metrics and logs |
| Check cost and budgets | Regular | Shared services have a fixed base cost. Cost alerts on message volume and namespace metrics. |
| Keep components current | Regular | See Lifecycle |
| Review the DNS forwarding list | When a capability is added | Private endpoint DNS |
Scaling¶
| Service | How |
|---|---|
| Service Bus | Messaging units are scaled manually. Allowed capacity values in the reference code: 1, 2, 4, 8, 16. Scaling can reset connections briefly: plan it as a change and tell the workload teams. Do not increase partitions of a running namespace without a migration plan. |
| API Management | Manual. Raise the number of scale units for the shared service and redeploy it. No downtime for the gateway or developer portal. |
| Event Hubs (proposed design) | Premium processing units, 1 to 16 |
Monitoring and alerts¶
Logging extends the MCP logging.
| Where | What exists | Note |
|---|---|---|
| Integration Platform spoke | Only the alert rules of the MCP | Add custom rules when needed |
| Service Bus | Azure Monitor metrics and Log Analytics for throughput, dead-letter growth, connection health and diagnostics | |
| API Management | An Application Insights resource connected to the Log Analytics workspace of its spoke | The monitoring section of the decision record is still open |
| Modules in workload spokes | Logs to the spoke workspace, per-module alerts and action groups (Modules) | Some modules need extra implementation by the workload team |
Action groups route notifications to the platform team or to workload owners. Alerts about an integration's own logic belong to the workload team (Operate your workload).
Useful checks:
- Dead-letter queues growing on a workload's queue: tell the workload team. They resubmit with the operators group.
- Throttling or connection resets on the namespace: look at the messaging units.
- API errors: Application Insights of the API Management instance.
Lifecycle and patching¶
The platform team keeps the platform components, the spoke canvas components and the deployment automation up to date. In a managed-service model that is the service provider until your own team takes over. Platform code arrives in releases: see What to do when a new version is released. Pin the reusable deployment workflow and the module repository to a release, and move the pin on purpose (Deploy integration resources).
A major change that touches several layers (foundation, shared service, control plane) needs coordinated releases and a deployment in the right order: shared service, spoke extension, then automation (Service Bus automation).
Standby and incidents¶
The reference design lets the MCP platform team provide standby for the platform from the first live integration. The integrations themselves are not in scope of that standby. Incident handling follows the MCP (Incident management).
Extend the platform¶
The control plane repository is organised by component, so a new component (for example API Management or DNS automation) sits next to the existing one and is deployable on its own.
infra/
service-bus/ existing component
main.tf, variables.tf, outputs.tf, providers.tf
modules/entities/ queues, topics, access
<new-component>/ add main.tf, variables.tf, outputs.tf, modules/
docs/
<new-component>.md one documentation page per component
Follow the existing conventions: names in lowercase with hyphens, configuration in JSON files found recursively, access through groups of the form workload, entity and role. A new shared service goes through the assessment of architecture, operations and security first (Service types), and a new spoke extension follows the rules of Spoke extensions.