Managed Services vs Self-Hosted — A Decision Framework
Every platform team faces the same question: run it yourself, or let the cloud provider run it for you? The answer is rarely technical alone — it depends on who maintains the system, what breaks at 3am, and whether the choice still serves the team in two years.
Who Benefits
Technical leaders and architects use this framework to justify decisions to stakeholders. Engineering teams gain clarity on where to invest learning depth vs where to delegate operational burden.
The Framework
Score each option against five dimensions. Weight dimensions by your organisation’s context — a startup weights team size differently from an enterprise with compliance obligations.
1. Operational Burden
| Managed service | Self-hosted |
|---|---|
| Provider handles patching, scaling, backups | Your team owns upgrades, failover, and capacity planning |
| Best when operational toil drains feature delivery | Best when you need fine-grained control over operational behaviour |
Ask: Does our team have sustained capacity to operate this component well?
2. Team Capability
| Managed service | Self-hosted |
|---|---|
| Lowers the skill floor — good defaults out of the box | Requires deep expertise to run safely in production |
| Best when the capability is adjacent to core business, not core competency | Best when the technology is your product differentiator |
Ask: Will we maintain the skills to operate this, or will knowledge walk out the door with the next departure?
3. Cost Trajectory
| Managed service | Self-hosted |
|---|---|
| Predictable per-unit pricing; can exceed self-hosted at scale | Lower unit cost at scale; hidden costs in engineering time |
| Best at moderate scale or when engineering time is expensive | Best at high scale with existing operational maturity |
Ask: Have we modelled cost including on-call, incident response, and engineer salaries — not just infrastructure line items?
4. Portability and Lock-In
| Managed service | Self-hosted |
|---|---|
| Deep integration with provider APIs and identity | Portable across environments with standard tooling |
| Best when migration cost is acceptable for the productivity gain | Best when multi-cloud or exit strategy is a requirement |
Ask: What is our exit cost if the provider changes pricing, deprecates a feature, or we need to move?
5. Compliance and Sovereignty
| Managed service | Self-hosted |
|---|---|
| Provider certifications (SOC 2, ISO 27001) inherited | You demonstrate control for auditors directly |
| Best when provider attestation satisfies regulators | Best when data residency or custom controls are non-negotiable |
Ask: Can we meet NZ Privacy Act, industry, or contractual obligations with this choice?
Worked Example — Managed Kubernetes vs Self-Managed
| Dimension | AKS (managed) | Self-managed on VMs |
|---|---|---|
| Operational burden | Control plane managed; you manage nodes and workloads | Full stack ownership |
| Team capability | Kubernetes skills focused on workloads, not etcd | Requires cluster operations expertise |
| Cost trajectory | Higher at small scale; competitive at medium scale | Lower infra cost; higher people cost |
| Portability | Kubernetes API is portable; AKS-specific features are not | Maximum control; maximum responsibility |
| Compliance | Azure compliance inheritance | Direct audit evidence; more documentation burden |
For most NZ-scale teams building product on cloud, managed Kubernetes wins unless compliance or cost-at-scale demands self-management.
When PaaS Beats Kubernetes Entirely
If your team spends more time operating the platform than shipping features, consider moving up the abstraction stack:
- Container Apps or App Service for HTTP workloads
- Managed databases over self-hosted PostgreSQL clusters
- Event Grid or Service Bus over self-managed message brokers
The goal is not the most flexible architecture — it is the architecture your people can operate with mauri (inherent strength).
Decision Output
Document every build-vs-buy decision with:
- Dimensions scored and weighted
- Assumed team size and skill level
- Revisit trigger (e.g. “re-evaluate when monthly spend exceeds $X or team grows past Y engineers”)
- Named owner accountable for the operational outcome
Technology doesn’t matter if it is of no value to the people operating it.