DevOps Culture: Myths and Reality

The first group of myths concerns who does DevOps: either an all-purpose individual who can handle everything or a separate organizational unit. Sometimes an administrator receives a new title; elsewhere it is a developer who also has to configure pipelines. These labels reveal little about how the team builds a product or takes responsibility for running it.

The second group substitutes tools for the approach. Ansible, Docker, Kubernetes, Jenkins, or GitLab are treated as sufficient evidence of DevOps. Other interpretations rebrand existing IT management or dismiss culture as an empty buzzword. The author argues for examining actual work: owning a technology does not explain which problem it solves or who is responsible for the outcome.

The article describes consultants who leave extensive recommendations, prescribe one fashionable technology for every problem, or take development over as an outsourcing service. It also mentions acquiring entire departments. These expectations share a weakness: assuming that a working culture transfers automatically with a document, a tool, or a group of specialists.

The practical discussion begins with the different perspectives of business and IT. Engineers see physical infrastructure, virtualization, infrastructure services, and platforms; the business primarily cares about a working application. The lower layers still matter. Their ownership must be organized so product teams can deliver changes without repeatedly mastering every detail of the runtime environment.

Moving from a monolith to microservices shifts some complexity toward operations. In the example, an engineering team helps with runtimes, pipelines, logging, and monitoring, including the use of managed services. Development teams focus on code, while recurring needs for shared libraries and services gradually establish another area of responsibility: common product capabilities.

Collaboration between this core team and the engineering team can produce an internal platform for standard workloads. It reduces the need for every product developer to become an infrastructure specialist and makes hiring for specific responsibilities easier. Its value lies in the recurring complexity it removes. The lesson is to distribute responsibilities deliberately as engineering evolves, rather than require every organization to create the same departments.