Where I believe from that cornerstone of my hear in this role, I often see it misinterpreted or even abused… So today we’ll talk about the “devops”-animal, and what it should be doing. Let’s first take a glance at Wikipedia (as it’s always a nice reference) ;
DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.
So the essence of the role (and yes, it is a role, not an animal, sorry to disappoint you) lies as a bridging function between “Development” & “Operations”. This statement is backed up in the Wikipedia article too ;
DevOps is frequently described as a more collaborative and productive relationship between development teams and operations teams. This improved relationship and collaboration increases efficiency and reduces the production risk associated with frequent changes.
The role of a DevOps professional has similarities to that of a Chief Engineer within the Toyota Production System. Such persons have responsibilities for the project’s success, but no formal authority over different teams involved. This requires technical knowledge in order to convince managers of the needs. Company executives can make convincing the managers more effective by formally endorsing the role of the Chief Engineer.
Many organizations divide Development and System Administration into different departments. While Development departments are usually driven by user needs for frequent delivery of new features, Operations departments focus more on availability, stability of IT services and IT cost efficiency. These two contradicting goals create a “gap” between Development and Operations, which slows down IT’s delivery of business value.
What does it bring?
The article visualizes the role as following ;
Where this might seem a bit different from the “bridging role” as just mentioned, imaging the “Quality Assurance” as the role you often see with your Architect(s). When we go to the stereotypes of each departement; we see that development is typically the team that wants to “inovate”, where operations is the team that wants the least amount of change in order to provide the needed stability. The devops will take both worlds into account. (S)he will introduce things like “High Availability”, “Scalibility”, “Performance”, “Security”, “Data Integrity”, “Monitoring”, and so on from the Operations world. On the other side, (s)he’ll also introduce versioning, automation, release management, and so on from the development world.
So what isn’t it?
Think about the following pitfalls ;
- Devops is not a team…
- Devops does not live within one technology team. (S)he stretches accross boundaries!
- It’s also not the chinese volunteer that will be scr*wed with all your releases.
I think with those statements a lot of companies their interpretation of “Devops” went down the drain…
Still not sure what it is? Check Patrick Debois’s slideshare presentation on Devops, as that one is spot on!