Managed Spokes¶
A managed spoke is a normal spoke where the platform team also builds, deploys, maintains and monitors the Azure resources of your workload. You keep ownership of the workload. The platform team does the technical work for you, within a separate agreement. This page describes what the service is, when it fits, how it is set up and where its boundaries are.
Optional offering, agreed per workload
A managed spoke is an additional service. Its scope, its service window, the fee and the reporting are in a separate
agreement and depend on your workload (Operating models). Hours, response times and
contacts are not part of this documentation. They are written as <support channel> and similar placeholders.
What it is¶
| Standard spoke | Managed spoke | |
|---|---|---|
| The subscription, network, groups, PIM, Key Vault, storage, Log Analytics and the connection to the hub | The platform team (What you get) | The same |
| The Azure resources of the workload (for example databases, app services, data platform components) | You build and run them | The platform team builds, deploys, maintains and monitors them, as infrastructure as code on top of the standard spoke |
| Accountability for the workload, its data and its security classification | You | You |
| Support for the workload resources | Your team | The platform team, within the agreed service window |
The baseline is the same as for the standard spoke. All rules of the platform apply: policies, naming, tags, firewall rules and the approvals (Policy and exemptions, Naming and tags).
When it fits¶
Choose a managed spoke when:
- the team is still learning Azure;
- the team does not want to invest in the technical skills to run the workload; or
- the team is too small to support the workload technically.
If you only need virtual machines that are patched, backed up and monitored for you, look at Managed virtual machines first. If you can build and run the workload yourself, the standard spoke is enough, and the Managed Templates can help you to follow the standards.
How it starts¶
The usual process is:
- Intake with the platform team. You describe the workload and what you need.
- Assessment of the current or the new solution. The platform team checks what is needed to run it in the platform, and what would have to change.
- Agreement. A service level addendum with the scope and the service window. If the workload must first be made compliant with the service, an implementation statement of work comes with it.
- Build and deploy of the infrastructure as code. Changes follow the normal change process, with a pull request and a review (The standard change process).
- Operate. The platform team supports the workload within the agreed window and reports to you.
What the agreement contains¶
A typical agreement describes:
- the scope: which resources and which environments;
- the service window and the availability of day-to-day support;
- an implementation statement of work, when the workload needs work before it can be managed;
- a fee;
- reporting to the workload team.
Ask for these items before you sign. Everything that is not in the agreement stays with your team.
Who does what¶
| Platform team | Your team | |
|---|---|---|
| Build, deploy and maintain the workload resources as code | Yes | Gives the requirements and accepts the changes |
| Monitoring of the workload resources, within the window | Yes | |
| Requirements, priorities and acceptance of changes | Yes | |
| Application logic, application-level roles and incident handling for your users | Yes | |
| The workload, its data and its security classification | Accountable | |
| Keeping tags, owner and contacts correct | Yes |
The generic split is in Responsibilities, and the operating side in Operating responsibilities.
Boundaries¶
- A managed spoke does not make the platform team accountable for your application or your data.
- Anything outside the scope of the agreement, such as extra environments or new components, needs a change of the agreement.
- Firewall rules, Application Gateway publishing and policy exemptions go through the normal approvals, like in every spoke.
- The platform team works through code, so the resources of the workload are changed through the configuration, not in the portal.