NoOps

WHAT IT IS NoOps is the proposition that managed platforms, serverless runtimes and provider-operated services can remove operational work from an engineering organisation entirely. Treated as a claim to examine rather than a goal to pursue, it is a useful lens: it forces an explicit account of which operational work is genuinely eliminated, which is transferred to a vendor, and which remains yours regardless. **Not this:** NoOps is not the absence of operations: it is a shift in where operational work happens and who is accountable for it, and the work that cannot be shifted is not reduced by the label. WHY IT EXISTS The term exists because the underlying shift is real and large. Provider-managed databases, queues and runtimes genuinely remove patching, capacity provisioning and hardware failure handling from most teams' concerns, and pretending otherwise is as unhelpful as the maximalist claim. The discipline exists to keep the accounting honest, because organisations that adopt the slogan without the accounting discover the remainder during an incident — typically that nobody owns observability, cost, or the vendor relationship. WHEN TO USE IT Use this lens when choosing between self-operated and managed components, when a team argues that a serverless architecture removes the need for operational roles, or when planning what an operations function should do after a significant managed-service migration. It is a decision aid, not an architecture. WHO OWNS IT Engineering leadership owns the honest accounting, because the question is fundamentally about where accountability sits after the work moves. Whoever adopts a managed service owns what remains of its operation: configuration, cost, limits, failure behaviour and the upgrade path the vendor imposes. Procurement and legal own the contractual side, which becomes an operational dependency the first time a provider changes terms or deprecates something you rely on. WHAT GOOD LOOKS LIKE The organisation can state, service by service, which operational responsibilities transferred and which did not. The residue is explicitly owned: observability of managed components, cost management, service limits and quotas, data durability verification, failure behaviour when the provider degrades, and exit cost. Provider status is monitored and the response to a provider outage is defined rather than improvised. Nobody claims that operational maturity was achieved by procurement. HOW TO IMPLEMENT Write the split down for one real service: list every operational responsibility and mark each as eliminated, transferred, or retained. The retained column is usually longer than expected, and that is the output. Assign owners to everything retained. Verify what the provider actually guarantees rather than what the marketing implies, especially around durability and recovery. Define your behaviour when the provider is degraded — the practices in /resilience-engineering apply unchanged. Keep cost visible through /finops, since managed services move cost from capital to a bill that grows quietly. HOW TO ASSESS YOURSELF Pick a managed component and ask who is paged when it degrades, who watches its cost, and what your recovery position is if its data is lost. Ask what your exit cost would be. Ask whether anyone has read what the provider actually commits to. Take the scored self-assessment at /assess and plan the gaps with /roadmaps.