DevOpsDays Warsaw 2017 - Bastian Widmer - Is #NoOps The New Evil? Or Is It Just „I Don’t Care“-Ops?

# Overview Bastian Widmer, a system engineer at Amazo (a Swiss company), explores the concept of NoOps—not as the elimination of operations, but as the natural evolution of DevOps through aggressive automation and self-service infrastructure. The talk challenges misconceptions about NoOps while demonstrating how his company has implemented it in practice.

# Key Topics Widmer defines NoOps as an operational paradigm and service design approach where infrastructure is so well-defined and standardized that developers can deploy and manage services without needing to contact operations teams. He contrasts this with DevOps, positioning DevOps as the culture and collaboration aspect while NoOps represents the focus on automation. The core misconception he addresses is that NoOps means eliminating operations staff—in reality, it redistributes their focus toward infrastructure improvement rather than repetitive manual tasks.

# Technical Implementation Widmer's company demonstrates NoOps principles through several concrete practices: - Automated environment creation: developers create a git branch and receive a Slack notification within 30 seconds confirming the environment is deployed, with no operational effort required - Infrastructure as code: treating infrastructure configurations as versioned, tested code rather than precious "snowflake" servers - Self-service tooling: developers modify nginx configurations and Docker containers locally, with automated checks preventing catastrophic failures - Externalized services: outsourcing email delivery (SendGrid) and other non-core operations, with one contact required per year for scaling needs - Blameless post-mortems: when an employee accidentally deleted customer files, the team focused on process improvements rather than blame, restoring everything within an hour

The team runs containers in production, uses a fully open-source stack, and conducts annual security audits by giving customers root access to their repository for self-directed penetration testing.

# Cultural Shifts A critical insight is that modern software developers must increasingly understand operational concerns—distributed systems, queuing mechanisms, performance characteristics—to be effective. Rather than viewing this as burden-shifting, Widmer frames it as empowerment: giving developers access to configuration files and deployment tools enables faster iteration while safeguards (automated checks, staged rollouts) prevent disasters. His developers were "very welcoming" to this increased autonomy.

The team practices direct customer communication through Slack rather than ticketing systems, improving documentation when patterns of repeated questions emerge. This philosophy extends to support: if customers can self-serve, the operations team scales better and can focus on infrastructure resilience.

# Takeaways NoOps is not about job elimination—cloud computing, containerization, and service automation have increased rather than decreased operational workload over the past 10+ years. Instead, NoOps represents a redesign of what operations teams focus on. Operations teams still exist; they work on building systems robust enough that developers need minimal intervention. The phone call analogy encapsulates the principle: you don't call your service provider to make each call; the system simply works through self-service standards. Widmer suggests renaming NoOps to "RelaxOps" to better capture that it's about building systems that take care of themselves while operations teams handle exceptions and continuous improvement.