A Eulogy for DevOps
Many engineers argue that “DevOps” started as a culture shift to break down walls between developers and ops, but was captured by enterprises as a tooling buzzword that often just recreated old silos under new names. Commenters describe how microservices, Kubernetes, and constant deployment brought valuable standardization and automation, yet also shifted operational burden onto developers, erased QA, and increased complexity and costs that smaller teams struggle to manage. A recurring theme is that the enduring value now lives in platform engineering, SRE, and fast feedback practices, while organizations that chase DevOps aesthetics without investing in skills, documentation, and clear ownership see worse reliability and developer experience.
Relationship between DevOps, Microservices, and “Ownership”
- Many see DevOps and microservices as parallel outcomes of pushing “you build it, you run it” ownership to teams.
- Others stress they’re orthogonal: DevOps is about breaking silos; microservices are just SOA with different tech, and can be overkill for small orgs.
- Several note that microservices swapped code complexity for operational complexity, demanding strong platform/security teams to work well.
Culture Shift: Docs, QA, and Product Chaos
- Widespread complaint that documentation, requirements, and QA have degraded under “move fast” cultures.
- Dedicated QA teams are widely missed; devs and users now act as testers, lowering quality and raising rework.
- Product managers often absorb QA/marketing duties, while devs juggle PM, dev, and QA, leading to duct-tape solutions instead of solid design.
What DevOps Was Supposed to Be vs Reality
- Repeated claim: DevOps was a cultural practice to break dev/ops silos, not a job title or separate team.
- Once companies created “DevOps teams,” they effectively rebuilt old ops silos under new branding, often without deep ops skills.
- Some argue DevOps has simply become the standard: CI/CD, automated deployments, infrastructure-as-code, and self-service are now expected.
Kubernetes, Containers, and Complexity
- Strong divide: some praise K8s/containers for reproducibility, portability, multi-environment parity, and stable APIs.
- Others see K8s as overengineered, leaking internal complexity, demanding specialized platform teams, and being ill-suited for small/medium orgs.
- For small systems, several advocate monoliths, simple bash/compose setups, or PaaS-style platforms instead of full K8s stacks.
Roles, Skills, and Gatekeeping
- Nostalgia for seasoned sysadmins/DBAs with deep Unix/DB knowledge; many feel these skills were lost in cost-cutting and “cloud will handle it” thinking.
- Others criticize old-school ops that resisted basic practices like version control.
- Consensus that engineers who combine app dev with solid infra/DB skills are rare and undervalued; promotion structures often ignore this hybrid work.
Release Cadence, CI/CD, and Risk
- Debate over deploying to production multiple times per day vs slower, regulated releases.
- Advocates of trunk-based development and frequent prod releases claim it reduces incidents via smaller changes and stronger automation.
- Others note regulatory and organizational constraints, arguing frequent deploy pipelines can still stop at non-prod environments.
Ethics and “User as Tester”
- One view: using users as testers is acceptable when each user’s stake is tiny.
- Counterview: if you take money, you have a moral duty to deliver a working service, regardless of ticket price; relying on users as testers is negligence.