How can there be a DevOps engineer?

How can there be a DevOps engineer? I often see vacancies with the job title DevOps engineer and always think, this makes no sense. DevOps is all about collaboration between two different expertises. In this blog post, I want to share the history of DevOps and my thought about the role of DevOps engineer.

The history of DevOps

To fully understand where the need of DevOps comes from I think it is important to understand the history.

This is a summary of the video “The (Short) History of DevOps” by Damon Edwards

It has started in Belgium in 2007 by a guy named Patrick Debois. Back then, Patrick was a consultant with the ambition to work in any position in an IT organization. At that time he was doing a government project to execute a large data center migration. Patrick’s role in the migration was testing which positioned him between development and operations. The different ways of working between development and operations were very unsettling for Patrick because of the context switching between the two departments.

During the Agile 2008 conference in Toronto Canada, Andrew Shafer posted an ad hoc session named “Agile Infrastructure” but only one person showed up, which was Patrick Debois. Because the lack of interest even Andrew himself skipped the session. Patrick had a session during the conference to talk about applying SCRUM into operational context. Because they shared the same frustrations they met up during the conference and realized there had to be other people out there that shared the same frustrations. This ended up into the “Agile System Administration” group at Google. Although there were some interesting conversations the general interest remained low.

23rd of June 2009, at Velocity the presentation “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” was broadcasted and watched by Patrick back home in Belgium. Patrick shared publicly he wanted to be there at Velocity and got the response, why don’t you start your own Velocity in Belgium? This resulted in a gathering named DevOpsDays hosted in Ghent Belgium 30th and 31st of October 2009. There was a lot of interest and during the gathering the hashtag #DevOps has evolved. Because this was so well received by the community others started to organize their own gatherings in Sydney and Mountain View.

Over time more and more people shared their experience and vision about DevOps at various conferences, gatherings, blog posts etc. This also formalized the best practice toolset to use for DevOps. This was picked up by analysts and on the 18th of March 2011 Gartner had published “The Rise of a New IT Operation Support Model” which holds the following prediction: “By 2015, DevOps will evolve from a niche strategy employed by large cloud providers into a mainstream strategy employed by 20% of Global 2000 organizations.”. Not long after larger organizations like HP and IBM picked up the word DevOps and started using it in their messaging.

As the history learns us DevOps is a community-driven movement based on experiences from thought leaders, how to handle the gap between development and operations. It is not a product or specification and also not a job title.

The DevOps Life Cycle

It is all about the collaboration between Development and Operations and the continuous flow of feedback between both worlds. This is well shown in the image below.

source: wikipedia.org

Value is created when new functionalities or improvements are released to the customer. The primary goal of DevOps is improving the deployment frequency which can lead to faster time to market. By this high frequency, defects in the deployment and release process are discovered earlier and the lead time of fixes will be decreased. Terms like “continuous integration”, “continuous delivery” and “continuous testing” are approaches to increase agility which helps with continuous releases of the software.

Applying DevOps may require an organizational culture shift as it will conflict with departmental roles. Operations seek organizational stability, developers seeks to change and testers seek risk reduction.

How can this be a single role?

There is a simple answer to this question, it cannot. DevOps engineers do not exist. It is all about the collaboration between different departments. How can this be a single role as a DevOps engineer? There are people that are responsible for creating software, testing software and delivering software. They all share the same goal to bring value to their customers.

The shared responsibility is very important to help each other to achieve the same goal. Understand others expertise and learn from each other helps. Developers that have a proper understanding of deploying and maintaining the software will help with building new functionalities the right way.

Conclusion

As the history learns us DevOps is a community-driven movement based on experiences from thought leaders, how to handle the gap between development and operations. It is all about the collaboration between development, testing and operations with a shared goal: deliver value to the customers. The shared reasonability and the understanding of each others expertise are key. Applying DevOps may require a culture change within the organization in order to get the correct Agile mindset.

DevOps cannot be a single role. What do you think? Do you agree or disagree with me? Feel free to leave your opinion in the comments below.

 

  • Where I have seen this role is someone who’s background span multiple disciplines and is central to communicating and coordinating the talent needed in order to accomplish DevOps goals. They are not a one stop shop but in a department outside of the traditional IT department roles and look for automation opportunities essientially tying it all together.

  • Rafael Nunes

    I agree 100%.
    I’ve seen several Build/Deploy teams entitled DevOps teams out there, working in a way there is actually DevTicketOps.
    Well articulated.

    Rgs
    Rafael Nunes (@datherra)