The DevOps buzzword has been growing at an insane rate over the last ten years. But what is it? Is it automation? Scripting? Programming? Programmers that know networking and server administration? Google engineers? A business unit? A team of specialists?
No, DevOps is a culture. The culture can encompass all of the things mentioned above, but the root of the movement started as a culture.
There was an Agile meeting in 2008 that no one showed up to. A couple of guys were having a conversation about âAgile, but for sysadminsâ. They made some decent progress at the idea and created a Google group. After that, one of the people from the Agile meeting showed up to Velocity 2009 where two employees of Flickr discussed performing 10 deployments per day to production.
10 times a day, the development and operations teams would push code changes into production. That was not a typo.
John Allspaw and Paul Hammond, the Flickr people, did some role playing about how traditional Ops and Dev worked together. They mentioned the âthrowing the code over the wallâ method. With this strategy, the development team would make code changes and send it to the Ops team, throwing the code over the metaphorical wall that separated Dev and Ops, and go home for the weekend. The Ops folks would be working night and day trying to get the code deployed and working in production. It was a pretty toxic environment, as you can probably imagine, and it still happens in a lot of organizations today.
At Flickr, they did things differently. Development and Operations worked together to plan, build, and release the code into production. There were insane improvements into the existing workflow, reducing bugs, roll backs, time to resolve failures, and an increase in resilience and robust applications. Thus, enabling ten deployments per day. Note, some companies have exceeded this more than ten times that amount. If youâre interested in the science and research behind it, check out Accelerate by Dr. Nicole Forsgren.
Remember that guy from the Agile 2008 discussion? Thatâs Patrick Debois. He was blown away by what Flickr and team had done. He started a new conference called DevOpsDays, unofficially officially coining the term DevOps. DevOpsDays is an international annual conference.
Since DevOpsDays and the term DevOps, companies all over have been attempting to change the way they deploy and release into production. Some have been successful, some have not. Some are still working on it.
The primary topics surrounding a DevOps culture or role involve packing and deploying software, often referred to as build/release engineering, automating the deployment process and pipeline, so with one click or one command the entire deployment occurs, and providing stable, consistent monitoring and feedback once the application is in production.
There are a lot more than that, too. Some DevOps roles are deep into the networking and systems administration component. Some focus just on writing out the infrastructure, usually dubbed âInfrastructure as Codeâ. If youâve ever heard Chef, Puppet, Ansible, SaltStack, Terraform, those are common Infrastructure as Code frameworks/DSL. Technically, theâre configuration management, but this thread isnât really for semantics.
Anyway, I assume @Goalkeeper wanted myself or @SgtAwesomesauce to start contributing to this section, so here you go lol. Note that DevOps isnât just about automating things, or deploying things, or monitoring. It is about culture and working as a single cohesive unit, despite your role and job title. Finance is DevOps, development is DevOps, marketing is DevOps, I.T. is DevOps. An important note is that most research into the culture suggests that management is a large component, and most teams or organizations fail because of the management teamâs lack of faith or enthusiasm. This isnât limited to DevOps, in my experience, but noteworthy nonetheless.
