Is it common for DevOps engineers to write code for user requirements?

After reading some articles about DevOps, I understand that DevOps engineers do write code. However, it's a bit unclear to me about what kind of code a DevOps engineer write.

Assume that there are (very roughly) 2 categories of code:

• For system operation: like scripting for deployment, configuration of Puppet or Ansible, etc.

• For user requirement: e.g. allow user to upload avatar images, add an "export" button to download as .csv files.

I found that some DevOps engineers only do the first category, while some others do both.

My question: is it common for DevOps engineers to write code for user requirements?

Short Answer

It depends on the organisation if you are a dedicated infrastructure specialist without any software development experience, you are unlikely to be writing feature code. However, if you are a Software Engineer who also knows Terraform, you might be called on to do both on the same day.
Long Answer

DevOps is not strictly a job title; in the most general sense, the "DevOps Mindset" forms part of an agile or lean operating model. In this kind of model, DevOps is a way of working for everyone that focuses on the Three Ways:

• Systems Thinking - understanding the creating value is the product of the system as a whole, not any one part of the system. When I say systems, I am talking about systems that include humans and technical components, i.e. people writing automation or features in code and the technology that executes that code.

• Amplification of Feedback Loops - creation and tightening of information flowing between the consumer and the parts of the system.

• Culture of Continuous Experimentation and Learning - enabling a data-driven culture that encourages agility and learning through experimentation.

Adoption Patterns

The three ways don't specify how the organisation should be structured; they just provide the foundational principles of DevOps. Coupled with the fact that most companies don't change quickly, this means there are several DevOps "Adoption Patterns":

• DevOps Bridge - where a team of DevOps engineers write the code to automate deployment and operations and often operate that.

• DevOps Operations Teams - where a team writes code to operate the software, but the development team writes the code, infrastructure and deployment automation.

• Tools Teams - where a group of DevOps engineers write tools that developers use.

• Embedded DevOps - where a DevOps engineer is embedded in the team to write infrastructure and deployment automation and built out the operational capability.

• Ubiquitous DevOps - where the group as a whole is accountable for feature development and infrastructure/deployment automation. They might have a DevOps Engineer or developers might "do DevOps".

Google and Amazon

There are also two general approaches described by Amazon and Google:

• "You build it, you run it" - this is a mantra that Werner Vogels, Amazon's CTO, used to describe how Amazon scaled Development and Operations teams. i.e. the group as a whole is responsible for building features, delivering it into Production and operating it while it is there.

• Site Reliability Engineering - this is Google's (and many other organisations) technology operating model that does split Development and Operations, but in such a way that there is shared accountability for the quality and warranty of code.

Amazon's "You Build It; You Run It" Model

Teams within Amazon are accountable for delivering a service, not software or infrastructure. Therefore they need to have people in the group who are capable of fulfilling every technical role: Software Architects, Back-end Developers, Front-end Engineers, Infrastructure Engineers, Automated Testers, Operations Engineers, and so on. Some people in those teams can fulfil more than one role; others may be much more specialist.

Within Amazon's model, it's the team as a whole's responsibility both implement features and write automation (amongst other things) they may:

• Choose to hire a Software Engineer to write the code for the features; plus a DevOps Engineer to write the code for the automation, or.

• Hire two engineers who can both do both roles within the team.

Google's Site Reliability Engineering Model

Google did their own thing for about eight years and came up with Site Reliability Engineering, SRE. Broadly Google employs Software Engineers (SWEs) and Site Reliability Engineers (SREs), Software Engineers are responsible for building code, automating infrastructure and automated deployment with the promise that if the project is important enough and they have proven they can operate it in Production themselves that Site Reliability Engineers will take over the operation of the project.

SRE gives Google the best of both worlds; teams are accountable for getting a product live and making sure it's reliable. Site Reliability Engineers can then take over up to ten live products meaning Google reduce their on-call costs and free up Software Engineers to concentrate on developing new features or products.

If you refer to Google's Site Reliability Engineering triangle:

• Product - is what you think of as high-level "feature" development, i.e. understanding what the user wants and implementing it.

• Release Processes - is what you probably think of as code that improves the flow of features into Production which could be deployment code or infrastructure.

• Development - is a bit of all three worlds: code that implements a feature, deployment code or infrastructure as code.

My Journey

My journey to where I am now (heading up Managed Serv

StackExchange DevOps Q#11870, answer score: 5