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

Question

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:

1. For system operation: like scripting for deployment, configuration of Puppet or Ansible, etc.
2. 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?

Answer 1

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:

1. 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.
2. Amplification of Feedback Loops - creation and tightening of information flowing between the consumer and the parts of the system.
3. 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":

1. DevOps Bridge - where a team of DevOps engineers write the code to automate deployment and operations and often operate that.
2. DevOps Operations Teams - where a team writes code to operate the software, but the development team writes the code, infrastructure and deployment automation.
3. Tools Teams - where a group of DevOps engineers write tools that developers use.
4. Embedded DevOps - where a DevOps engineer is embedded in the team to write infrastructure and deployment automation and built out the operational capability.
5. 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:

1. "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.
2. 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:

1. 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.
2. 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 Services) was first as a Network Technician and IT Manager, then becoming a .NET Developer, and then a DevOps consultant, finally taking up my current role. I'm at the point in my career where I can turn my hand to more or less any task.

When I hire, I look for T-Shaped individuals, i.e. people who are experts in one or two disciplines but are moderately capable in the full range of disciplines we need to be successful.

Summing Up

When you're just starting, start with the end in mind:

• If the goal is a team that is cross-functional and capable of building and running a product - then work out what that team needs to do and make sure that there is more than one person that is proficient in each capability.

• If the goal is to become a DevOps engineer, start with the basics of Infrastructure of Code, Continous Deployment and Operations. As you learn, teach those in your team how to do those things themselves and ask them how they do their role (this includes QA, Front-end, Backend and Hardware engineers) eventually you become that T-Shaped individual.

Answer 2

As already mentioned, "It Dependes" and more importantly who are your "Users",

1. is it the dev/test team for whom you are creating an infrastructure -> sure.
2. is it the staging server/deployment server -> ofcourese.
3. is it end users, yes. In many cases there are scenarios like encrypitng data on transport or at encryption at rest, a devops professional do write code to fulfill those requirements.