NoOps

NoOps (“no operations”) is the idea that a software organisation can automate and buy infrastructure work so thoroughly that application teams need no dedicated operations team. Forrester analyst Mike Gualtieri proposed it in February 2011 in a blog post that called DevOps “a step backward” and promised that “application developers will never have to speak with an operations professional again”; even he expected that “Ops can run this public, private, or hybrid infrastructure”.^[1] That April, Forrester’s report Augment DevOps With NoOps softened the idea: “Continue to pursue DevOps, but prepare to augment it with NoOps”.^[2]

In one line: NoOps is a design goal for buying and automating as much operational work as is sensible, not a state in which operational work stops existing. Managed services take over patching, hardware, capacity and much availability engineering. You still own data, identities, configuration, cost, announced runtime upgrades, the response when the provider fails, and the decision to leave. This page shows how to estimate and own that remainder.

For leaders deciding whether to hire operations staff, architects choosing building blocks, and engineers who inherit a “NoOps” stack.

Operations work that does not differentiate the product is expensive. Google’s SRE book calls the repetitive part toil: “manual, repetitive, automatable, tactical, devoid of enduring value”.^[6] Developers also waited on operations queues; at Netflix in 2012, hours a week of meetings with operations became seconds of self-service.^[3]

Getting it wrong cuts both ways: self-managing commodity infrastructure wastes time on toil; assuming operations has gone leaves duties unowned until incidents expose them. Hosting alone is not enough: DORA’s 2024 research concluded that “Organizations may be better off staying in the data center if they are not willing to radically transform their application or service.”^[7]

• Not the absence of operations. Serverless “does not mean that we no longer use servers to host and run code; nor does it mean that operations engineers are no longer required” (CNCF).^[8]
• Not a job title, a certification or a synonym for serverless. PaaS, managed Kubernetes, managed databases, SaaS and internal platforms are other routes (ServerlessOps, PlatformOps).
• Not simply the opposite of DevOps, although it began that way. Replying to Netflix in 2012, John Allspaw quoted Mark Imbriaco calling its model the “‘developers own their code throughout the entire lifecycle’ approach” that “the rest of us” had used “for years”.^[9]
• Not a headcount plan. What Netflix described, Allspaw wrote, “is Operations”, whatever the titles: “the responsibility to make it safe to make whatever change to production is necessary”.^[9] This page’s inference: removing operations skills leaves the work with people who may lack the training or time.

Mental model: operations is displaced, not deleted. The provider operates below a responsibility line, you above it. Each abstraction since 2011 has moved the line up, never to the top: Microsoft’s matrix keeps data, identities and configuration with the customer in every model.^[12] For each task that “went away”, ask where did it go?

flowchart LR
  subgraph Before["Self-managed: one ops queue"]
    P1["Patch OS and hosts"]
    P2["Plan and buy capacity"]
    P3["Build redundancy"]
    P5["Answer pages"]
    P4["Deploy releases"]
    P7["Configure services"]
    P6["Manage access and data"]
  end
  subgraph After["Managed-first: work is displaced"]
    D1["Provider: hardware, OS patching, in-service redundancy"]
    D5["Management: quotas, cost, vendors, exit"]
    D3["Product team: on-call, upgrades, deploys, failure design"]
    D2["Platform team: paved road, guardrails"]
    D4["Automation code: needs an owner"]
    D6["Always yours: data, identity, config, access"]
  end
  P1 --> D1
  P2 --> D1
  P2 --> D5
  P3 --> D1
  P3 --> D3
  P5 --> D3
  P4 --> D3
  P4 --> D2
  P4 --> D4
  P7 --> D6
  P6 --> D6
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class P1,P2,P3,P4,P5,P6,P7 neutral
  class D1,D2,D3,D4,D5 core
  class D6 risk

Neighbours teach the mechanisms of “less ops”; this page asks what remains and who owns it (an editorial split, not a standard).

There is no official NoOps manifesto; this charter is this Atlas’s proposal (one-page version with goals in the templates). Mission: buy or automate undifferentiated operations; keep every remaining duty owned, measured and rehearsed.

1. Displacement, not deletion. For every task a change “removes”, name the new owner.
2. The always-retained band. Data, identities, configuration and access policies are yours in every model.^[12][13]
3. Own the critical path. In Charity Majors’s 2016 talk, as reported by InfoQ, “services are not magical pixie dust”; one of her top tips was to “own the critical path (and keep it short)”.^[16]
4. Design for provider failure. “A service cannot be more available than the intersection of all its critical dependencies.”^[17]
5. Operations is a property, not a team. “Operational excellence is not a role, it’s an emergent property.”^[10]
6. Keep decisions reversible. Know the exit cost before you depend on a service.

Non-goals: cutting headcount for its own sake; outsourcing accountability to an SLA. Accepted trade-off: lock-in, which “may be stronger with serverless computing than for serverful computing”.^[11]

Each block moves the line by a different amount; the linked pages teach the mechanics.

Loops you keep, whatever you buy: change control as code (InfraOps), guardrails (CloudSecOps), user-facing SLIs (ObservabilityOps), routed signals, restore tests.

NoOps redistributes roles rather than removing them (Case 1). In Team Topologies terms, stream-aligned teams own a flow of work and platform teams provide “a compelling internal product”.^[24] A named, often rotating residual-ops owner keeps the registers current.

RACI for recurring residual duties (R responsible, A accountable, C consulted, I informed):

• Intake gate (template): what moves, what remains, who owns it, the failure plan, the exit cost.
• A responsibility register per service, with the code (format), reviewed quarterly.
• Signal routing to the owning team’s queue, not a shared mailbox.
• Escalation: product team → platform team → provider support, plus a second path, since AWS support case creation was impaired in December 2021 and October 2025.^[25][26]
• Change control: provider-driven changes (deprecations, plan changes) are planned work with deadlines.

flowchart TB
  U["Users"] --> E["Managed edge and API"]
  L1(["Yours: IaC and guardrails"]) --> E
  L1 --> C
  E --> C["Managed functions or containers"]
  E -.-> L2(["Yours: SLIs and on-call"])
  C --> D[("Managed data and queues")]
  C -.-> L3(["Yours: provider, quota, cost signals"])
  L4(["Yours: backups, restore tests"]) --> D
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class U,E,C,D neutral
  class L1,L2,L3,L4 core

Your side also includes throttling at the edge (an API layer can accept more requests than the functions behind it can run^[15]), backup and versioning strategy,^[23] and idempotency in queues. Alternative: at stable high load, reserved containers or managed Kubernetes, “a middle ground in this continuum”.^[11]

The core workflow estimates and assigns residual operations; in its exception path, an unownable duty changes the design.

flowchart TB
  T["Trigger: new service, migration or a NoOps proposal"] --> P["Profile workload: load, state, latency, regulation"]
  P --> S["Choose candidate building blocks"]
  S --> R["Map responsibility line using provider models"]
  R --> I["List residual duties with frequency and effort"]
  I --> O{"Every duty has an owner?"}
  O -- "Yes" --> E["Estimate work hours and coverage"]
  O -- "No" --> X{"Can we buy, automate or drop it?"}
  X -- "Yes" --> I
  X -- "No" --> RD["Redesign or choose another building block"]
  RD --> S
  E --> F{"Fits team capacity and risk appetite?"}
  F -- "Yes" --> A["Record ADR, wire signals, launch"]
  F -- "No" --> RD
  A --> M["Measure residual hours, pages, currency, cost"]
  M --> Q["Quarterly review"]
  Q --> I
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class T,P,S,R,I,E,A,M,Q core
  class O,X,F decision
  class RD risk

The recurring practices (responsibility mapping, intake, signal routing, runtime currency, quota headroom, data protection, failure design, cost guardrails, exit readiness, automation ownership) have owners in the RACI, measures in the KPIs and a cadence in the checklists. Intake has the most leverage, so it gets a playbook.

1. Map the line from that specific service’s shared responsibility documentation; it differs by service.^[27]
2. List and estimate residual duties in the register: work and coverage.
3. Wire signals and rehearse one restore and one provider-failure drill before launch.
4. Accept when every duty has an owner, signals are tested and the exit cost is in the ADR.
5. Contingency: keep the previous deployment path for one review cycle and a restored data export.

There is no NoOps standard. The decision draws on NIST SP 800-145 for service models;^[28] the providers’ shared responsibility and resiliency models for where the line sits (guidance, not contract: Microsoft calls its page “illustrative guidance”);^{[18][12][13][23]} SLAs, which are contracts for service credits;^[29][14] the Google SRE book and The Calculus of Service Availability for toil, on-call and dependencies;^[6][30][17] Team Topologies for team shapes;^[24] and, in the EU, the Data Act (Regulation (EU) 2023/2854) on switching.^[31]

Start with the jobs (building blocks), then judge products on limits, runtime policy, restart semantics, recovery, export paths and the vendor’s roadmap. Representative options as of October 2026: functions (AWS Lambda, Azure Functions); serverless containers and PaaS (Google Cloud Run, “a fully managed application platform”;^[21] Azure App Service; Heroku, which announced in February 2026 that it is transitioning to a sustaining engineering model and has since shipped some updates^[32][33]); managed Kubernetes (Google Kubernetes Engine^[19]); managed data (Amazon DynamoDB, Azure SQL Database). Lock-in: function semantics and back-end services differ between providers;^[11] portable layers cut exit cost but add operations.

Each feed is a duty to route and read (as of October 2026); organisation-wide wiring belongs to CloudOps.

Automation is a destination of displaced work, so operate it: an unowned rule or script becomes a hidden failure mode (AutomationOps). It clearly helps with signal routing, currency scans, guardrails as code and provider-assisted upgrades (AWS points Lambda customers moving to Java 21 or 25 to AWS Transform custom^[22]), whose output still needs review. Much triage needs no model: AWS Health events can carry an actionability value.^[34] Any agent with change permissions needs an owner, least privilege, audit logs and a kill switch; changes to data, identity and spend keep human approval. AI agents sold as autonomous operations are assessed below.

The core artefact is a responsibility register with an estimator, one per service, next to its code: each duty has an owner, frequency and effort; coverage says when someone must be reachable. Assumptions (illustrative): orders-api runs on a managed API layer, functions and a managed NoSQL table, with business-hours paging and 120 productive hours per person per month.

Example status: verified by execution (Python 3.8.10, 2026-10-16) together with the script below.

{
  "service": "orders-api",
  "assumptions": {"productive_hours_per_person_month": 120},
  "duties": [
    {"id": "runtime-upgrades", "area": "runtime and dependencies", "owner": "orders-team", "per_month": 2, "hours_each": 3},
    {"id": "provider-notices", "area": "provider change notices", "owner": "orders-team", "per_month": 4, "hours_each": 0.5},
    {"id": "quota-review", "area": "quotas and limits", "owner": "platform-team", "per_month": 1, "hours_each": 1},
    {"id": "cost-review", "area": "cost", "owner": "orders-team", "per_month": 1, "hours_each": 3},
    {"id": "cost-anomalies", "area": "cost", "owner": "orders-team", "per_month": 0.5, "hours_each": 2},
    {"id": "access-review", "area": "identity and access", "owner": "security-team", "per_month": 1, "hours_each": 2},
    {"id": "secret-rotation", "area": "identity and access", "owner": "", "per_month": 0.33, "hours_each": 2},
    {"id": "restore-test", "area": "data protection", "owner": "orders-team", "per_month": 0.33, "hours_each": 4},
    {"id": "alert-tuning", "area": "observability", "owner": "orders-team", "per_month": 2, "hours_each": 1},
    {"id": "provider-incidents", "area": "incident response", "owner": "orders-team", "per_month": 0.25, "hours_each": 4},
    {"id": "compliance-evidence", "area": "compliance", "owner": "security-team", "per_month": 1, "hours_each": 2},
    {"id": "vendor-admin", "area": "vendor management", "owner": "", "per_month": 1, "hours_each": 1.5},
    {"id": "pipeline-iac-upkeep", "area": "delivery pipeline", "owner": "platform-team", "per_month": 2, "hours_each": 2}
  ],
  "on_call": {"owner": "orders-team", "pages_per_week": 1.5, "hours_per_page": 1.5},
  "coverage": {"reachable_hours_per_week": 45, "people_per_shift": 1, "max_share_of_weeks_on_call": 0.25},
  "projects": [
    {"id": "exit-plan-and-game-day", "owner": "orders-team", "hours": 24, "amortise_months": 12}
  ]
}

The estimator reports monthly work per duty and owner, and coverage (person-hours of being reachable, minimum rota); it exits with status 1 when a duty is unowned.

Example status: verified by execution (Python 3.8.10, 2026-10-16); the output below is the actual output.

"""Estimate the operations that remain after adopting managed services: work and coverage.

Usage: python3 residual_ops.py residual-ops.json
Standard library only. Prints monthly work hours per duty and per owner, an FTE equivalent,
and the coverage cost: person-hours of being reachable and the minimum rota size.
Exit code 1 if any duty has no owner.
"""
import json
import math
import sys
from collections import defaultdict

WEEKS_PER_MONTH = 52 / 12


def owner_of(item):
    return (item.get("owner") or "").strip() or "UNOWNED"


def work_rows(inv):
    rows = []
    for d in inv.get("duties", []):
        rows.append((d["id"], owner_of(d), float(d["per_month"]) * float(d["hours_each"])))
    oc = inv.get("on_call")
    if oc:
        hours = float(oc["pages_per_week"]) * WEEKS_PER_MONTH * float(oc["hours_per_page"])
        rows.append(("on-call-pages", owner_of(oc), hours))
    for p in inv.get("projects", []):
        rows.append((p["id"] + " (amortised)", owner_of(p), float(p["hours"]) / max(1, int(p["amortise_months"]))))
    return sorted(rows, key=lambda r: r[2], reverse=True)


def main(path):
    with open(path, encoding="utf-8") as fh:
        inv = json.load(fh)
    rows = work_rows(inv)
    total = sum(r[2] for r in rows)
    per_owner = defaultdict(float)
    for _, owner, hours in rows:
        per_owner[owner] += hours
    capacity = float(inv["assumptions"]["productive_hours_per_person_month"])
    print(f"Residual operations estimate for {inv['service']}")
    print("WORK")
    for duty, owner, hours in rows:
        print(f"  {duty:<34} {owner:<14} {hours:6.1f} h/month")
    print(f"  {'TOTAL':<34} {'':<14} {total:6.1f} h/month")
    print(f"  FTE equivalent (at {capacity:.0f} productive h/person-month): {total / capacity:.2f}")
    for owner, hours in sorted(per_owner.items(), key=lambda kv: kv[1], reverse=True):
        share = 100 * hours / total if total else 0.0
        print(f"  owner {owner:<20} {hours:6.1f} h/month ({share:4.1f}%)")
    cov = inv.get("coverage")
    if cov:
        reach = float(cov["reachable_hours_per_week"]) * int(cov["people_per_shift"]) * WEEKS_PER_MONTH
        rota = math.ceil(int(cov["people_per_shift"]) / float(cov["max_share_of_weeks_on_call"]))
        print("COVERAGE")
        print(f"  reachable {cov['reachable_hours_per_week']} h/week x {cov['people_per_shift']} per shift"
              f" = {reach:.0f} person-hours/month on call")
        print(f"  minimum rota at <= {float(cov['max_share_of_weeks_on_call']):.0%} of weeks on call: {rota} people")
    if per_owner.get("UNOWNED"):
        print(f"WARNING: {per_owner['UNOWNED']:.1f} h/month of duties have no owner")
        return 1
    return 0


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("usage: python3 residual_ops.py <inventory.json>")
    sys.exit(main(sys.argv[1]))

$ python3 residual_ops.py residual-ops.json
Residual operations estimate for orders-api
WORK
  on-call-pages                      orders-team       9.8 h/month
  runtime-upgrades                   orders-team       6.0 h/month
  pipeline-iac-upkeep                platform-team     4.0 h/month
  cost-review                        orders-team       3.0 h/month
  provider-notices                   orders-team       2.0 h/month
  access-review                      security-team     2.0 h/month
  alert-tuning                       orders-team       2.0 h/month
  compliance-evidence                security-team     2.0 h/month
  exit-plan-and-game-day (amortised) orders-team       2.0 h/month
  vendor-admin                       UNOWNED           1.5 h/month
  restore-test                       orders-team       1.3 h/month
  quota-review                       platform-team     1.0 h/month
  cost-anomalies                     orders-team       1.0 h/month
  provider-incidents                 orders-team       1.0 h/month
  secret-rotation                    UNOWNED           0.7 h/month
  TOTAL                                               39.2 h/month
  FTE equivalent (at 120 productive h/person-month): 0.33
  owner orders-team            28.1 h/month (71.6%)
  owner platform-team           5.0 h/month (12.7%)
  owner security-team           4.0 h/month (10.2%)
  owner UNOWNED                 2.2 h/month ( 5.5%)
COVERAGE
  reachable 45 h/week x 1 per shift = 195 person-hours/month on call
  minimum rota at <= 25% of weeks on call: 4 people
WARNING: 2.2 h/month of duties have no owner

How to read it. About 39 hours a month, a third of a person, is the work; unowned duties are how “NoOps” stacks fail quietly. Coverage is larger: 195 person-hours a month of being reachable, and at least four people if nobody is on call for more than a quarter of their weeks. Google caps SRE on-call at 25% of time and, assuming week-long shifts, derives a minimum of eight engineers for a single-site 24/7 rota with a primary and a secondary;^[30] on business-hours rotas, where people do project work between pages, a cap on weeks is a conservative proxy. Check the inputs: Google reports about 6 hours per on-call incident;^[30] at that rate the total becomes about 68.5 hours (0.57 FTE).

Objective: a work-and-coverage estimate for one service, with unowned duties found. Prerequisites: Python 3.8 or later; no cloud account, cost or risk; under an hour.

1. Save the reference register as residual-ops.json and the estimator as residual_ops.py.
2. Run python3 residual_ops.py residual-ops.json.
3. Give both unowned duties an owner (for example orders-team) and run again.
4. Change coverage to {"reachable_hours_per_week": 168, "people_per_shift": 2, "max_share_of_weeks_on_call": 0.25} (24/7, primary and secondary) and run again.
5. Replace the example with your own service’s duties.

Expected output (checked by execution). Step 2: the reference output; echo $? prints 1. Step 3: no warning, exit 0, total 39.2 h/month, orders-team 30.2 h/month (77.1%). Step 4: work unchanged; coverage 1,456 person-hours a month, minimum rota 8. Validation: every duty has an owner, and the people doing the work find the total plausible. Troubleshooting: JSONDecodeError is often a trailing comma. Teardown: delete the directory, or commit the register.

Objective: prove that every class of provider signal reaches an owner; test two AWS rules without deploying anything. Prerequisites: read access to your providers’ health settings; for step 3, AWS CLI v2 with credentials. No cost or risk. Status: step 3 not executed.

1. Inventory. Per account or project, list the signal classes in the comparison table plus quota and budget alerts, and where each goes: a team queue, a person, a shared mailbox or nowhere.
2. Trace. Who acknowledged the latest notice of each class, and how long after it arrived?
3. Test the AWS rules. Save the two patterns below as pattern-ops.json and pattern-abuse.json and the sample event as sample-health-event.json, then run the script; it evaluates patterns without sending anything.^[41]
4. Record. Every class that reaches nobody, or only a shared mailbox, becomes an owned duty in your register.

Why two rules. AWS Health sends two event types to EventBridge, AWS Health Event and AWS Health Abuse Event,^[36] and for security use cases AWS suggests focusing on “all AWS Health Abuse events”.^[42] The operations rule filters no category, since AWS calls it “a best practice that you monitor all event type categories”;^[35] route pages on the optional detail.actionability field.^[34] It keeps only events whose backupEvent is “false”, which drops the copies AWS also delivers to the backup Region, as AWS suggests.^[38] The abuse rule does not: the schema marks backupEvent as required for both types,^[34] but no abuse-event sample confirms it, so the worst case is a duplicate. Region coverage and deployment as code belong to CloudOps.

Example status: JSON syntax-checked; both patterns matched against the sample and its abuse variant with a local exact-match simulation (2026-10-16); not deployed; no AWS API called.

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {"backupEvent": ["false"]}
}

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Abuse Event"]
}

{
  "version": "0",
  "id": "7bf73129-1428-4cd3-a780-95db273d1602",
  "detail-type": "AWS Health Event",
  "source": "aws.health",
  "account": "123456789012",
  "time": "2026-10-16T09:00:00Z",
  "region": "eu-west-1",
  "resources": ["arn:aws:lambda:eu-west-1:123456789012:function:orders-api"],
  "detail": {
    "eventArn": "arn:aws:health:eu-west-1::event/LAMBDA/AWS_LAMBDA_PLANNED_LIFECYCLE_EVENT/AWS_LAMBDA_PLANNED_LIFECYCLE_EVENT_EXAMPLE",
    "service": "LAMBDA",
    "eventTypeCode": "AWS_LAMBDA_PLANNED_LIFECYCLE_EVENT",
    "eventTypeCategory": "scheduledChange",
    "eventScopeCode": "ACCOUNT_SPECIFIC",
    "communicationId": "example-communication-1",
    "startTime": "Fri, 30 Apr 2027 00:00:00 GMT",
    "lastUpdatedTime": "Fri, 16 Oct 2026 09:00:00 GMT",
    "statusCode": "upcoming",
    "eventRegion": "eu-west-1",
    "eventDescription": [{"language": "en_US", "latestDescription": "Example: a runtime used by this function reaches end of support."}],
    "affectedEntities": [{"entityValue": "arn:aws:lambda:eu-west-1:123456789012:function:orders-api", "lastUpdatedTime": "Fri, 16 Oct 2026 09:00:00 GMT", "status": "PENDING"}],
    "page": "1",
    "totalPages": "1",
    "backupEvent": "false",
    "affectedAccount": "123456789012",
    "actionability": "ACTION_REQUIRED",
    "personas": ["OPERATIONS"]
  }
}

Example status: syntax-checked with bash -n; not executed (requires AWS credentials).

#!/usr/bin/env bash
set -euo pipefail
export AWS_REGION="eu-west-1"   # any Region; the test creates nothing
# Same event with the abuse detail-type, to prove each rule catches only its own type.
sed 's/"AWS Health Event"/"AWS Health Abuse Event"/' sample-health-event.json > sample-abuse-event.json
for pattern in pattern-ops.json pattern-abuse.json; do
  for event in sample-health-event.json sample-abuse-event.json; do
    printf '%s + %s: ' "$pattern" "$event"
    aws events test-event-pattern --event-pattern "file://$pattern" --event "file://$event" \
      --query Result --output json
  done
done

Expected output (local simulation; the AWS call was not made): true for each rule with its own event type, false for the crossed pairs. Validation: with eventTypeCategory set to accountNotification the operations rule still matches; with backupEvent “true” it does not; steps 1–2 pass when every signal class has a named owner. Troubleshooting: InvalidEventPatternException means an invalid pattern;^[43] an event error, a missing mandatory field (id, account, source, time, region, resources, detail-type).^[41] Teardown: delete the working files; nothing was created.

Objective: test whether a managed-first service survives a hard dependency’s failure and whether its exit cost is known. Prerequisites: two hours with the team, residual-ops owner, security and finance; the dependency list; no production changes.

1. Availability. Compare your hard dependencies’ SLA product and measured product with your SLO (worked calculation).
2. Scenario A, regional disruption. “The primary Region’s managed database endpoint stops resolving; the status page has not updated.” Walk through the worked runbook.
3. Scenario B, forced upgrade. “40% of functions use a runtime deprecated in 60 days; a security fix ships next week.” (See the deprecated-runtime risk under security.)
4. Scenario C, exit. “A service you use will be retired in a year”, as Google Cloud IoT Core was in 2023.^[44] Estimate the exit in person-weeks.

Expected output: an availability comparison, runbook gaps, a dated exit estimate. Validation: every gap has an owner and a date (an unknown dependency list is the first finding). Teardown: none; follow up in 30 days.

In 2012 Cockcroft wrote that “There is no ops organization involved in running our cloud”: developers deployed through a self-service portal and carried the pager, a reliability team would “never make changes to production applications”, and transferred ITops staff built base images. Yet “Netflix stil [sic] does Ops to run its datacenter DVD business.”^[3] Lesson: the label rested on a platform, operations skills and developer on-call.

InfoQ reports that Prime Video’s stream monitoring on AWS Step Functions and Lambda handled only “around 5% of the expected load”, hit an account limit on state transitions and was costly. The team “packed all of the components into a single process” on Amazon ECS on EC2 and reported “a 90% reduction in operational costs”, meaning running cost, not operations work (the original post has moved).^[45] Lesson: the building block must fit the workload; this page adds that the team accepted more infrastructure to run for a lower unit cost.

In 2024 Mandiant investigated a campaign (UNC5537) that stole data from Snowflake customer instances. It “has not found any evidence” of a breach of Snowflake’s enterprise environment; accounts “were not configured with multi-factor authentication”, unrotated credentials stayed valid for years, and network allow lists were missing.^[46] Lesson: SaaS moves the line almost to the top, but identity hygiene stays yours.

Review work, coverage and unit cost quarterly, the rest monthly; ownership, currency, headroom and restores are leading indicators.

flowchart TB
  M["Measure: residual hours, pages, currency, headroom, unit cost"] --> C{"Classify each duty"}
  C -- "Buyable" --> B["Buy"]
  C -- "Repetitive" --> A["Automate, with an owner"]
  C -- "Unneeded" --> X["Eliminate"]
  C -- "Essential" --> K["Keep and rehearse"]
  B --> V["Verify the duty moved and nothing new appeared"]
  A --> V
  X --> V
  K --> V
  V --> M
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class M,B,A,X,K,V core
  class C decision

1. SLA-implied versus measured availability. A request path uses a managed API layer (SLA 99.95% monthly), functions (99.95%) and a managed NoSQL table (99.99% for standard tables).^[47][29][48] If each ran exactly at its SLA with independent failures: 0.9995 × 0.9995 × 0.9999 ≈ 99.89%, about 47.5 minutes of unavailability in a 30-day month, against 21.6 minutes for one 99.95% dependency. This is not a ceiling: AWS calls such a product “only likely to produce a rough order of magnitude calculation” and notes that a workload on two or three 99.99% dependencies “can still achieve 99.99% availability itself, or higher”.^[49] The Calculus ceiling (principle 4) applies to actual availability:^[17] the SLA product shows what the contracts support, the measured product what users get. If the latter misses your target, add mitigations (caches, graceful degradation) or dependencies with an extra nine.^[17]

2. Total unit cost (illustrative). Bill 1,800 currency units a month; 39.2 residual hours at a loaded 90 an hour (3,528); 30 million requests: (1,800 + 3,528) ÷ 30 = 177.6 per million requests, 66% of it people time. The 39.2 hours already include 2 hours a month of amortised exit planning, so no separate exit reserve is added. Here people time outweighs the bill, which is why the “NoOps” pitch is really about people; at high, steady volume the balance can flip (Case 2). Vanity traps: “servers we manage: 0”, “percentage serverless”, “operations headcount”, “provider SLA met”.

Auditability. Provider attestations cover the provider’s scope;^[27] evidence for your configuration is a recurring duty (ComplianceOps); EU switching rules are under exit cost.

Cost drivers change shape. The Berkeley paper names “Paying in proportion to resources used instead of for resources allocated” as a defining serverless trait and “Serverless computing can have unpredictable costs” as a pitfall;^[11] at high, steady volume, per-use charges can exceed reserved capacity.^[45]

Capacity becomes quota management. AWS documents 1,000 concurrent Lambda executions per Region by default and API Gateway’s default of 10,000 requests per second; it recommends load testing.^[15]

Exit cost is a liability that grows with proprietary code and data, and providers change on their own schedule: Google Cloud IoT Core was discontinued in August 2023, and Heroku’s February 2026 announcement changed its roadmap.^[44][32] In the EU (not legal advice), the European Commission states that the Data Act removes switching charges, including data egress charges for switching, from 12 January 2027 (cost-based charges are allowed until then);^[31] that cuts transfer costs, not engineering work.

Sustainability. AWS lists “Use managed services” as a sustainability design principle, because shared services maximise utilisation;^[50] treat it as directional (GreenOps).

Service monitoring belongs to ObservabilityOps; this asks whether the residual duties get done.

• Register audit. Quarterly, sample three duties per service and check their evidence.
• Risk indicators that open an action (this Atlas’s thresholds): any unowned duty; headroom below 20%; restore older than 90 days; provider notice unacknowledged after 14 days; exit estimate older than 12 months.
• Signal health. Test the signal path twice a year; health events arrive at least once, so de-duplicate.^[37]

An illustrative scenario modelled on documented events. In October 2025 an empty DNS record for DynamoDB in us-east-1 caused API errors from 11:48 PM PDT on 19 October to 2:40 AM on 20 October; Lambda event processing and EC2, ECS, EKS and Fargate launches stayed impaired for hours, and the whole event ended at 2:20 PM PDT.^[26] In December 2021 launches and DNS changes were impaired while running EC2 instances were unaffected.^[25]

sequenceDiagram
  autonumber
  participant U as Users
  participant S as Service
  participant O as On-call
  participant P as Provider
  U->>S: Requests
  S-->>U: Errors, latency
  S->>O: SLO burn alert
  O->>P: Check health feed
  O->>O: Declare, assign roles
  alt Tested multi-Region design
    O->>S: Fail over to another Region
  else No tested failover
    O->>S: Degrade: queue writes, serve cache
  end
  O-->>U: Status page update
  O->>P: Open case if possible
  P-->>O: Recovered
  opt Service failed over
    O->>S: Fail back
  end
  O->>S: Drain queues, watch throttling
  O-->>U: Resolved, review scheduled

1. Detect from your SLO alert or synthetic check; the absence of a provider event is not evidence of health.
2. Declare: incident commander and communications lead (IncidentOps); scope dependency, Region and user journeys from the register.
3. Mitigate: degrade by feature flag, queue writes, serve cached reads, pause batch jobs, break retry storms. Fail over only to a tested design, and avoid actions that need the affected Region’s control plane, which was impaired in both events.^[25][26]
4. Communicate every 30 minutes on your own status page.
5. Recover: fail back if you failed over; drain queues idempotently and watch throttling. In 2025, downstream recovery took hours longer than the DNS fault.^[26]
6. Learn: separate the provider’s root cause from your contributing factors; AWS places testing, including “game day practices”, on the customer’s side.^[23]

Pursue “less ops” (managed-first) when most of these hold:

• A common workload shape (web, API, events, batch) with spiky or low load, where pay-per-use and scale-to-zero help.^[11][21]
• A small team whose scarce skill is product engineering; limits that fit with headroom; an exit cost you accept.

Avoid or limit it when:

• Load is high and steady, so reserved capacity is probably cheaper.^[45]
• The workload needs exotic hardware, kernel settings, or runtime and maintenance control the provider lacks.
• Latency must be consistently low. The Berkeley paper calls it a fallacy that functions cannot serve low-latency applications, since they can be pre-warmed;^[11] warm capacity is then a cost you pay.
• A provider retirement would be existential and the exit cost is unknown, or “NoOps” would remove operations skills rather than redeploy them.

A counterpoint. In 2022 David Heinemeier Hansson, co-owner and CTO of 37signals, called renting computers “(mostly) a bad deal” for medium-sized companies like his with stable growth: “The savings promised in reduced complexity never materialized”.^[53] One company’s view, but a useful test: if your operations team would not shrink and load is stable, the managed premium needs another justification.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 24, "rankSpacing": 36}}}%%
flowchart TB
  S["Workload to place"] --> Q1{"Sold as SaaS?"}
  Q1 -- "Yes, data rules fit" --> SaaS["SaaS"]
  Q1 -- "No" --> Q2{"Fits managed limits?"}
  Q2 -- "No" --> SM["Self-managed or managed Kubernetes"]
  Q2 -- "Yes" --> Q3{"Load high and steady?"}
  Q3 -- "No" --> MF["Managed-first: PaaS or functions"]
  Q3 -- "Yes" --> Q4{"Cheaper on reserved capacity?"}
  Q4 -- "No" --> MF
  Q4 -- "Yes" --> CT["Reserved containers or Kubernetes"]
  SaaS --> Q5{"Duties owned, coverage affordable?"}
  SM --> Q5
  MF --> Q5
  CT --> Q5
  Q5 -- "Yes" --> GO["Adopt; wire signals; record ADR and exit cost"]
  Q5 -- "No" --> RD["Not yet: redesign, cut coverage needs or staff up"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class S,SaaS,SM,CT,MF,GO core
  class Q1,Q2,Q3,Q4,Q5 decision
  class RD risk

When options are close, use a weighted matrix (illustrative): a spiky customer-facing API, five-person team, moderate compliance; scores 1 (poor) to 5 (good); weighted score = Σ(weight × score) ÷ 5, out of 100.

PaaS and functions tie and the extremes drop out; weight exit cost higher and PaaS wins, weight team capacity higher and functions do. Record the weights in the ADR.

These levels are this Atlas’s model; no official one exists. The diagram adds proposed regression triggers, because this maturity is easily lost.

flowchart TB
  L0["Level 0: NoOps by assertion"] --> L1["Level 1: Owners named"]
  L1 --> L2["Level 2: Signals and recovery proven"]
  L2 --> L3["Level 3: Remainder engineered"]
  L3 --> L4["Level 4: Low-ops by design"]
  L2 -. "Unowned duty found in an incident" .-> L1
  L3 -. "Restore or signal test fails" .-> L2
  L4 -. "Service adopted without intake" .-> L3
  L1 -. "Reorganisation leaves registers stale" .-> L0
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class L0 risk
  class L1,L2 neutral
  class L3,L4 core

Assess per product area; Level 2 suits most organisations.

For an organisation already running some managed services, led by a part-time residual-ops owner:

• Shared responsibility page summarised; quotas checked against peak, with headroom.
• Residual duties owned and estimated; coverage stated; failure plan written.
• Data location, backup and export path confirmed; exit cost in the ADR.
• MFA or SSO, credential rotation and least-privilege roles designed in.

• Signals deployed as code and tested in every used Region: health and abuse events, budgets, quota alarms, SLIs.
• Synthetic checks independent of the provider’s status page; rota and escalation path, including a second path.
• One timed restore done; degrade-versus-fail-over rules and dependency-failure runbook written.

• Unowned duties at zero; residual hours, coverage and pages against the trend.
• Runtime currency across all versions; quota headroom; unit cost including people time.
• Provider incidents and roadmap announcements reviewed.
• Every automation and agent has an owner and a kill switch.

LOW-OPS CHARTER — <product area>                      Owner: <name>   Review: quarterly
Mission:    Buy or automate undifferentiated operations; own the remainder explicitly.
Scope:      Services <list>. Out of scope: <list>.
Principles: Displacement not deletion · Always-retained band (data, identity, config, access)
            · Design for provider failure · Measure the remainder · Keep decisions reversible.
Goals:      0 unowned duties · runtime currency >= <target>% · restore test <= 90 days old
            · exit estimate <= 12 months old · residual work and coverage tracked per service.
Coverage:   Paging hours: <business hours | 24/7>. Rota: <names/size>. Max share of weeks on call: <x>%.
Non-goals:  Cutting operations skills; adopting abstractions for their own sake;
            treating provider SLAs as our SLOs.
Decision rights: Adopting a new managed service requires an intake form and an ADR.

MANAGED-SERVICE INTAKE — <service name> for <workload>          Date: <YYYY-MM-DD>
1. Job to be done and alternatives considered:
2. Provider responsibility (link to provider's shared responsibility page):
3. Residual duties (area · owner · frequency · effort) and coverage needed:
4. Limits and quotas that could bind (value · our peak · headroom):
5. SLA · measured availability · our SLO · mitigation if it fails:
6. Data: classification · location · backup · export path tested? (Y/N)
7. Security: identity model · MFA/SSO · least-privilege roles · audit logs:
8. Cost: pricing basis · expected monthly cost · budget alert:
9. Exit cost: person-weeks · money · biggest unknown:
10. Decision · approver · review trigger:

ADR-<nnn>: <Use managed X | Run Y ourselves> for <workload>
Status: proposed | accepted | superseded by ADR-<nnn>       Date: <YYYY-MM-DD>
Context:   Workload profile; team capacity; compliance; volume forecast and horizon.
Options:   1) ... 2) ... 3) ... (scores from the weighted matrix, with weights)
Decision:  <option>, because <evidence>.
Residual operations: work <hours/month>; coverage <hours/week, rota size>; owners <names>.
Dependency availability: SLA-implied <x>%, measured <y>%; mitigations: <list>.
Exit cost: <person-weeks, money>; export path: <tested on date>.
Consequences: what gets easier, what gets harder, what we will monitor.
Revisit when: <volume, price, regulation, limit, or provider roadmap trigger>.

RESIDUAL-OPS REVIEW — <area> — <quarter>                Attendees: <names>
Per service: residual h/month (trend) · coverage · pages/shift · unowned duties · runtime currency
             · quota headroom · restore age · unit cost · provider incidents · exit-cost age
Top 3 duties by hours -> decision: buy | automate | eliminate | keep (owner, date)
Provider notices and roadmap changes received / acknowledged / overdue:
Risks above threshold and actions:
Decisions changed since last review (ADR links):

Is NoOps real? As a direction, yes; as a literal state, no. Even its originator expected “Ops” to run the infrastructure.^[1]

Does NoOps mean developers do all the operations? Often, for their own services; it works only when they have the skills, time and authority to run production.

We outsource operations to a managed service provider. Are we NoOps? No: you bought operations. Oversight and accountability stay with you, and the exit cost now includes what the provider knows.

Our platform team answers every production page. Did we just rename the ops team? Probably. The CNCF Platforms White Paper says a platform team “doesn’t necessarily run compute, network, storage or other services” and that an internal platform “should rely on externally-provided services and capabilities as much as possible”.^[54] A platform team carrying every pager is a relabelled ops team.

Is a solo developer on a PaaS the case where NoOps is literally true? It is the closest: with no coverage promise, the remainder can be a few hours a month, but it includes data, identities, upgrades, cost and exit. When Heroku stopped offering free plans and began shutting down free dynos and data services from 28 November 2022,^[55] keeping a hobby app running meant paying or moving.

Autonomous operations (the second meaning). Google’s SRE book describes automation evolving from none, through externally maintained and then built-in automation, to “Systems that don’t need any automation”, where “The database notices problems, and automatically fails over without human intervention”; it adds that “sometimes manual operations are unavoidable”.^[52] That top level is the technical NoOps ideal, reached one failure mode at a time, not bought. The same chapter shows automation failing at scale: a decommissioning workflow read an empty machine list as “everything” and, within minutes, wiped the disks of all machines in Google’s CDN; users were served from Google’s own datacentres, and very few noticed.^[52]

AI operations agents (as of October 2026). AWS made AWS DevOps Agent generally available on 31 March 2026, calling it “your always-available operations teammate”; it investigates incidents and can “suggest code-level fixes as part of mitigation plans”, and its improvement figures come from preview customers and partners.^[56] Microsoft’s Azure SRE Agent offers a review mode, in which the “Agent proposes an action; you approve or deny”, and an autonomous mode; Microsoft recommends review for production incidents and security alerts and advises: “Start with review mode.”^[57] This page’s reading: such agents shorten investigation, Microsoft’s guidance keeps a person in the loop for production changes, and someone still owns each agent’s permissions and mistakes. Separate established automation (event routing, autoscaling, managed patching), real but limited practice (agent investigations, remediation proposed for approval) and speculative claims (fully autonomous production incident resolution).

The serverless boundary keeps moving. As of October 2026 AWS documentation refers to “Lambda Event Functions (previously known as Lambda functions)” and lists further compute types (Lambda Managed Instances, Web Functions, MicroVMs) with their own quotas and security controls;^[22][15][27] map the line per compute type.

• Beginner: read to the decision framework; then the CNCF Serverless Whitepaper and Majors’s essay; shadow an on-call rotation; continue with ServerlessOps.
• Practitioner: Lab 1 on a real service, then Lab 2 and the SRE book on toil, on-call and automation; run the 30-day roadmap for one area; continue with PlatformOps or AutomationOps.
• Leader or architect: the judgement call, then Lab 3 with one team; introduce the intake form and a coverage policy; continue with FinOps and SRE.

Situation (illustrative). A 12-engineer company runs six services; whoever is awake handles incidents. The CTO can make one hire: Option A, a dedicated operations or platform engineer, or Option B, no hire, managed-first (“NoOps”) with the remainder spread across product engineers. A large customer wants 24/7 support; two services hold regulated data; load is spiky.

Residual work after migration, by the Lab 1 method:

Sensitivity: about 122 hours if the smaller services need a third of the Lab 1 rate, about 201 if all six match it: one to one and three-quarter people of work.

The attractive choice and why it can be wrong. Option B looks cheaper, and the migration is probably right, but it fails three ways: about 140 hours a month is 12 hours per engineer competing with features; the 24/7 clause needs a rota (at Google’s 25% cap, eight people with a primary and a secondary, or four with a primary only, by this page’s arithmetic^[30]), so a third to two-thirds of the company would carry night pages; and regulated data adds evidence work nobody owns by default. Option A has its own trap: one operations hire can become a new silo, and one person cannot cover 24/7.

Recommendation. Separate work from coverage. Work can be distributed if every duty has an owner; coverage depends on whether the contract needs 24/7 response or 24/7 availability with graceful degradation. Migrate managed-first and hire a platform engineer who owns the paved road, signals, registers and shared duties, not “operations for everyone”; product teams stay on call in business hours. If true 24/7 response is needed, price it in and staff a rota or a follow-the-sun partner. Uncertainty: the estimate could be off by half; without the 24/7 clause, Option B alone is reasonable.

After this page you should be able to explain why NoOps is aspirational and its two meanings; map a service’s responsibility line; estimate residual work and coverage; design signals and failure handling; and evaluate whether “less ops” fits a workload. Self-check:

1. “We moved to a fully managed database, so backups are the provider’s problem.” What is wrong?

2. Your request path depends on services with SLAs of 99.95%, 99.95% and 99.99%. Is a 99.95% SLO achievable?

3. On a managed function runtime, which remain yours: (a) minor runtime patches, (b) a new major language version, © dependency updates, (d) rebuilding container-image functions on new base images?

4. Lab 1 shows 39 hours a month of work. The CEO concludes the team needs “a third of an ops person”. What is missing?

5. A teammate proposes a health-event rule that matches only issue and scheduledChange “to cut noise”. What do you say?

NoOps began as a provocation and was softened within months; even at Netflix, people built the platform and carried pagers. Operations without humans is now sold again with AI agents, and the conclusion holds: operations moves up the stack and into new hands. It does not leave.

The useful version of NoOps is a discipline of honesty: buy what a provider does better, automate what is repetitive and safe, name an owner for each remaining duty, count work and coverage, rehearse the failures you cannot buy away, and know the cost of leaving. Teams that skip it get the operations anyway, at the worst possible time.

Every source below was opened on 2026-10-16; dates are the source’s own. Claim-level support is in the Atlas evidence ledger (research/noops-ledger.md).

Changelog. 2026-10-16, r1: revised after independent review (origins, two meanings, signals, coverage, estimates). r2: minimal AWS rule, provider-neutral lab, redrawn diagrams, neighbour rows, boundary-case FAQ. r3: regrouped into 13 parts (Blueprint v2); abuse events routed; Figures 5 and 6 corrected; GKE qualifier; AI operations agents added; repetition cut; AWS quota and budget details handed to CloudOps. r3 follow-up (orchestrator): Majors attribution (“one of her top tips”); Lab 2 backup-event wording clarified.