What is a "DevOps Engineer" anyway? Just looking for opinions outright.

[mpron]

If you could make your own concrete list of skills and milestones that someone had to have before they could be considered a "DevOps Engineer" what would they be?  I'm just looking for straight opinions here. 

Here's what I found just looking at the first local DevOps engineer posting on dice.com:
(abridged)

DevOps Engineer - Python, Linux, Data storage

Minimum Required Skills:
Python, Linux, Data storage, Automation, Web Application Development, Mobile Applications, Information Retrieval, Distributed Computing

What you need for this position:

- Degree in Computer Science
- 2+ years coding in Python
- Strong skill set as a DevOps Engineer
- Experience working in a Linux environment
- Familiar with data storage and data architecture practices

What's in it for you:

- Excellent work environment and opportunities for growth
- Comprehensive benefits
- Competitive pay
- Other cool perks!!

[Justin Redd]

I think we need to first define what a "devops engineer" is.

Does it align with the early ideals of the movement (that dev & ops work together)? If that's it, I think a devops engineer is distinguished by the engineer's ability to work with techies from other specialties and embrace their concerns. An ops engineer who understands developer workflows. A dev who will think about how the code is released or how it will run in production.

Or does it align with what we see in job listings, which is basically "21st century sysadmin". In that case, an ops engineer who embraces infrastructure-as-code. An ops engineer who automates all the things. And ops engineer who mixes in development practices like TDD and linting.

Thanks,

Justin

--
 
---
You received this message because you are subscribed to the Google Groups "devops" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devops+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Spikelab]

Given that this will end up in blood and tears, I'll bite:

* can communicate with more than his middle finger

* his/her concerns span the organization, not the immediate technology and product he/she is in charge of 

* understands the business and the user he/she is supporting, including internal users (dev, QA, sec, ops)

* understands and has practiced Lean and Agile and can combine gut instinct with data

Yes I have not mentioned a single technology and yes I believe that any mention of one would be going down the wrong path. Devops was born as a response to siloing and a lack of something like agile that reformed the way the many worlds beside development operate in an organization.

This is also why people have been resistant to codify it, which is what you're asking for and why it'll end up in blood :), and why they oppose a

"Devops" job title (mind you, I've supported it as it helps to stress you support the above, but that's just IMHO).

Hope that helps,

Spike / @spikelab

Sent from my iPhone

--

[Zach Hanna]

I'm going to join Spike's camp and agree with him.

[Greg Cockburn]

Following on from what Spike said which was pretty awesome.

Isn't *devops* more of a cultural thing, rather than a way to describe a person?

It is the interactions of the whole [business] that gives everyone an understanding of how the other one works to all work towards the same common goal. (no matter whether you are in finance, sales, marketing or IT)

In that vain, and if you want to describe an ideal developer or operations person, or anyone;

 * can learn

 * understands people

 * has passion

Can learn:  if a person knows puppet, but you use chef, you can teach the person chef.

Understands People:  Understanding technology is one thing, listening and understanding peoples problems and formulating that into a technology strategy is something else

Has passion: self motivated, scratches itches, maybe involved in industry groups, forums, OSS projects, etc.

Greg.

[lavaman]

Greg,

I agree completely. DevOps is about breaking down the silos between different parts of the organization and making sure everyone is on the same page and working in the same direction.

If a company is trying to hire DevOps Engineers, it's usually a pretty good sign they don't understand the concept. It really can be reduced to a single role. If anything, it's more about the makeup of teams than individual roles. If you're doing DevOps, you regularly have Devs, Admins, DBAs, Storage, etc. all in the same room working on the same thing. You can't really abstract that interaction into a separate role.

[lavaman]

*It really CAN'T be reduced to a single role. 

[Steve Conover]

> Isn't *devops* more of a cultural thing, rather than a way to describe a person?

This was the initial conception of devops - a cultural concept, or a state of mind - and IIRC there were strong statements by the folks who came up it that it was not meant to be a job title, that there was no such thing as "a devops". In my view, operations and development are their own specialties, and creating a distinct role here not only comes with the danger of creating jacks-of-all-trades, it risks counteracting the intended cultural changes (dev and ops can do their own thing in isolation and sit back and let the devops people be the bridge).

Coincidentally, a Facebook whitepaper just came out that describes their development and release process, and gets pretty close to what I think of when I hear "devops":

https://www.facebook.com/publications/514128035341603

"Developers must also support the operational use of their software — a combination that’s become known as “devops.” This further motivates writing good code and testing it thoroughly. Developers’ personal stake in keeping the system running smoothly complements the engineering procedures and lets the system maintain quality at scale. Methodologies and tools aren’t enough by themselves because they can always be misused. Thus, a culture of personal responsibility is critical."

[Greg Cockburn]

Steve,

I like this: "Thus, a culture of personal responsibility is critical."

That's a great point.

Greg.

[Damon Edwards]

This thread hasn't described a "DevOps engineer". This thread has just described a "good person to hire". Why does keeping up with the state of the art and refreshing your skills and job approach require a change in title? 

I'm paraphrasing from someone else (and I can't recall the name) who said..."it's a sad comment on our industry when we are so surprised by seeing something actually done well that we have to insist that it is something else and give it a new name."

[Ernest Mueller]

At 11:33 AM 8/21/2013, Justin Redd wrote:
>I think we need to first define what a "devops engineer" is.
>
>Does it align with the early ideals of the movement (that dev & ops
>work together)? If that's it, I think a devops engineer is
>distinguished by the engineer's ability to work with techies from
>other specialties and embrace their concerns. An ops engineer who
>understands developer workflows. A dev who will think about how the
>code is released or how it will run in production.
>
>Or does it align with what we see in job listings, which is
>basically "21st century sysadmin". In that case, an ops engineer who
>embraces infrastructure-as-code. An ops engineer who automates all
>the things. And ops engineer who mixes in development practices like
>TDD and linting.

Good definition, I'd say both!

My response to the "DevOps is not a job title" crowd is the same as
usual. We tried to hire "Infrastructure Engineers" or "Linux Systems
Administrators" with the description of what we wanted. We had
trouble getting good candidates. We switched the title to "DevOps
Systems Engineer" - voila, we suddenly get people that meet Justin's
criteria above instead of troll-hole UNIX admins and "I administered
the Websphere for 8 years" people. Thus we hire for "DevOps!"

I think anyone claiming "I don't understand DevOps" would be
overreaching by a good margin. However, it acts as a signal flag for
"you know, new style" and is therefore valuable. As I value getting
good, highly competent hires over someone's argument over theoretical
purity - I say "Mmmwah hah hah haaa" as I filled yet another job
position this week.

Ernest

[Damon Edwards]

My earlier snarky comment aside... I do agree with Ernest's comment that DevOps has been a good pattern matching filter for hiring. I've heard experiences similar to his from several people. 

Although I do wonder about how much longer that will last. You have to imagine that at some time in the not so distant future, "I do DevOps" will become the standard resume pad... just like developers who all throw Agile on the list.

--

--- You received this message because you are subscribed to the Google Groups "devops" group.

To unsubscribe from this group and stop receiving emails from it, send an email to devops+unsubscribe@googlegroups.com.

[Steve Conover]

> just like developers who all throw Agile on the list.

So ETA to DevOps = meaningless is ~ 2 years :)

To unsubscribe from this group and stop receiving emails from it, send an email to devops+un...@googlegroups.com.

[Jason Edgecombe]

When interviewing interns, I find that the listing OS versions is a good
indicator on a resume. I see lots of resumes with "Linux", but I really
pay attention when I see "Ubuntu 12.04, RHEL 6" and similar items with
specific versions for products/technologies. I'm not sure how well this
applies to non-interns.

I work at a university, so we hire lots of student interns.

Jason

>> email to devops+unsubscribe@**googlegroups.com<devops%2Bunsu...@googlegroups.com>
>> .
>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>

[Justin Redd]

I think ETA to DevOps = meaningless is ~ 1 year :(

One thing I'd like to see is someone using "devops engineer" to hire/describe a operations-aware developer.

Justin

[John Allspaw]

It's not a secret that I'm with Jez on the not-a-title camp. I'll part with Damon that I don't actually believe it's reasonable to oversimplify to "good person to hire", because there is context that is beyond that bit.

FWIW, we don't have 'devops' in our titles or job descriptions and we seem to hire ok without them.

This still is my litmus test for using the term:

s/"devops"/"collaboration, communication, cooperation, and coordination"/g

If I can't find+replace with that and the sentence still doesn't seem right, then I generally don't use the term.

There is also an unshakeable awkward/weird/kissing-your-sibling feeling when 'devops' is ever used in conversation in Etsy's offices. (which is why when it is said, many heads turn to understand why you thought it was necessary to use it. :) 

--
John Allspaw

[Steve Conover]

> There is also an unshakeable awkward/weird/kissing-your-sibling feeling when 'devops' is ever used in conversation in Etsy's offices. (which is why when it is said, many heads turn to understand why you thought it was necessary to use it. :) 

Interesting, it's the same at Square.

[Aaron Nichols]

On Wed, Aug 21, 2013 at 10:17 AM, mpron <mi...@dzone.com> wrote:

If you could make your own concrete list of skills and milestones that someone had to have before they could be considered a "DevOps Engineer" what would they be?  I'm just looking for straight opinions here.  

For what it's worth, despite not seeing much of a direct response to your original request, I've really enjoyed this thread - thanks for starting it. As others have stated, I'd probably find some good "Operations Engineer" job requirements and anything specific you might need and go with whatever title suits you.

As in perl, there's always more than one way to do it. The recruiting angle has become obvious to anyone w/ Devops listed anywhere in their linkedin profile - it's interesting to me to hear Ernest describe the improved luck they've had using the term and I'm not at all surprised to hear that Etsy doesn't need to use it.

Despite my never using the word to describe collaboration / cooperation / etc, never putting it into a job title, really just never using it, the developers in my company use 'devops' to describe my team... often. In parallel I have a number of developers doing *exactly* the same work we do on many fronts - writing chef recipes, getting new infra up, writing docs, etc. Are they developers or part of the "devops" team?

Frankly, I don't care.

I see Ops as another group of Engineers. I tend to work in smaller orgs where Ops is smallish & exclusively "owning" any significant chunk of responsibility is a liability more than an asset. I want folks who will work to make the things we (developers, ops, everyone) do every day easier and safer. Sometimes that means automation, sometimes it means having conversations, sometimes it's documentation, sometimes it's making the wrong things harder. In any case, it usually involves learning about others, sometimes learning about new tools, and sometimes learning from mistakes.

I want folks who do those things well. If they do, the rest usually works itself out.

Aaron

 

--
Twitter: @anichols

Blog: http://www.opsbs.com

Pro: http://www.linkedin.com/in/anichols

[Ernest Mueller]

At 07:31 PM 8/21/2013, Steve Conover wrote:
> > There is also an unshakeable awkward/weird/kissing-your-sibling
> feeling when 'devops' is ever used in conversation in Etsy's
> offices. (which is why when it is said, many heads turn to
> understand why you thought it was necessary to use it. :)
>
>Interesting, it's the same at Square.

Yes, for some reason everyone has gotten all self-conscious about the
term DevOps. At last DevOpsDays I was treated to about a dozen
self-righteous rants about "you can't put DevOps on a sign!" "You
can't put DevOps on a jacket!" "you can't say Enterprise DevOps!"
(real quotes, I'm not really even sure what they mean). I think it's
somewhat disappointing that everyone's getting all squirrelly about
"saying the word" when it's clearly a real thing that's had a
transformative effect on the industry. I feel like discussions like
this - "you're not using DevOps right!" is as chilling as the similar
"you're not using agile right" etc. Might be true, might not be,
certainly is not helping anyone.

Ernest

[James Holmes]

A question if I may:

Given a set of people hired as devs who know Rails, a set of people hired as ops who know Chef and a room with a sign that says "DevOps," who gets desks in the room?

[Benjamin VanEvery]

Knowledge of Rails alone only describes a software developer, which on its own doesn't really imply devops, so I'd bounce the question back as a trick question =) 

On the subject of avoiding the term "devops," I'd like to take Ernest's statement and develop it slightly. --Most of the engineers whom I know are generally idealists. And most of the idealists whom I know are generally offended when any term is used outside the realm in which it was originally coined. A great example of this is the term "agile," which is now used to describe almost any type of planning for deadlines occurring in less than a year (i.e. not the original definition). The same will soon happen to "devops," if it has not already happened. Once a new term gets into the hands of recruiters, brand promoters, tweeters, etc. you can pretty much bet on it losing its original meaning; and trying to stop this by refusing to use the term is a lost cause. So, to all the idealists, I'd say, "Sorry; hope you enjoyed it while it lasted."

What does a devops engineer mean to me? It describes an engineer,

• who understands that systems operations is more than just tuning configuration files and getting certifications
  
• who has some capability developing software or complex scripts
• who appreciates metrics, monitoring, fault tolerance, high availability, etc.
• who wants to be part of the development and deployment process
• who respects all parts of the company, from concept to cash (tm)

--- BVE

--

[Jaime Gago]

About " who respects all parts of the company, from concept to cash (tm)" , imho that is just first step in the right direction, one must understand her organization as a whole, at the very least from a bird's view perspective, not just respect every bit as the next one.
At the root is what the preachers have been -quite fortunately- preaching latelly i.e. the "why" and system thinking, thank you John, thank you Damon, but I'm diverging.

To go back to job titles, Ernest Mueller wrote "21st Century SysAdmin" which to me is at the core of this discussion, i.e. the yet to be clearly *and* precisely defined role of a Systems Administrator,a Systems Engineer or a Systems Architect in the IT industry.
This echoes with the Large Installation Systems Administration 2011 (1) for which the main theme was DevOps, and during which -DevOps- keynote it was stated SysArchitect > SysEng > SysAdmin.
My point here is that since the DevOps movement clearly has been "questionning" the practice of Systems Administration maybe we should start by looking in that direction when it comes to job titles. Then we could have folks like Thomas Limoncelli jump into the debate?

Certainly we could use some *nix wizardy wisdom, right?

J.

(1) http://static.usenix.org/legacy/events/lisa11/tech/
The LISA '11 theme is "DevOps: New Challenges, Proven Values."

[James Holmes]

And I'll return volley with our real world example. 

We had exactly that situation (except for the sign). We brought the ops and the devs people together, had the ops people pair with the devs to impart Chef knowledge, built and migrated to an AWS infrastructure where everything is declared as code and then had the ops people start doing development work. Now we all develop and maintain the app and the infrastructure*. That, to me, is the devops mindset.

* yes, as a dev, I get to be woken up if the infrastructure breaks at 2AM. This is a great incentive to make sire the app works.

[John Vincent]

Ernest

--

 

I think by this point my opinion on the matter is pretty clear.  Patrick and I talked about this at one point and I posited that the intense debate over the use of the word was really to try and keep from debasing it.

I'm not claiming it's some sort of sacred word but it's about controlling the conversation. I'm a person who feels like words have real meaning. When you throw them around casually or allow them to be used in an improper context they eventually lose any sense of power. Essentially what Justin and Steve said. I don't WANT it to become meaningless. Part of that may be pride but part of it is that it's exactly what you said, Ernest - it's a "real thing that's had a transformative effect on the industry".

Damon hit the nail on the head for me on what my core argument has always been. A "DevOps Engineer" ostensibly should have no different concerns than a SysAdmin than a Developer than a QA engineer than a CTO than any other business unit when it comes to the business itself. We optimize for efficiency. We take enough pride in our craft to do a good job.

I don't remember where this came from but it's a good one - "devops - because prod-dev-qa-ops is just too long". That's kind of what I'm getting at.

--
John E. Vincent
http://about.me/lusis

[James Bailey]

We recruit for "Devops Engineers" and much to my chagrin, I keep getting introduced in meeting as our "Senior Devops Engineer" to clients and suppliers; even though I have asked senior management to stop it. My actual title is "Senior System Administrator". At the end of the day, sticks and stones will break my bones but names will never harm me".

Most of the company get at a gut level what devops is, as decent human beings and pretty smart cookies, we work without too many silos in pretty agile way. A few of us have actually studied devops and the wider business practices out side of our immediate sphere at a deeper level. I live in hope that more of my colleagues will read the "Phoenix Project" as an introduction to devops. We "Devops Types" usually get our way because our ideas and processes based on a critical understanding of Devops, OM and other modern technical and operational practices make sense and usually work.

I have learnt not to get hung up on semantics, I am in good position, with a good bunch of people, at decent company.

Jim

--

[Kief Morris]

Well before DevOps was a word, I found there are different flavours of sysadmin, in terms of their scope of experience and assumptions, not technologies. The majority seem to work in organizations which don't do any significant in-house software development, and where there is considerable silo-ization even within what we tend to call "ops". 

Recruiting people to build and run iinfrastructure to run software being continuously developed in-house meant filtering through loads of people who just didn't have the mindset. Someone who *expects* software to be "handed over", with detailed installation instructions, at infrequent intervals ("why couldn't they get it right in the last release?!") is going to suffer (and cause suffering) in the kinds of environments most of us on this list work in.

DevOps is a handy shibboleth. Someone who is attracted to the word is more likely to be enthusiastic about an environment where the lines between software and infrastructure are blurred, if they exist at all.

Many of us on this list take it for granted that working this way is just common sense, but in many environments, where your responsibility is running SAP, Exchange, or other packaged software, it's still alien.

Kief

[Graham Dunn]

Anecdotally, it means "Developer who will work for a sysadmin's salary" :)

On Wednesday, August 21, 2013 12:17:37 PM UTC-4, mpron wrote:

If you could make your own concrete list of skills and milestones that someone had to have before they could be considered a "DevOps Engineer" what would they be?  I'm just looking for straight opinions here. 

[James Bailey]

On 22 August 2013 14:41, Graham Dunn <g...@kurai.org> wrote:

Anecdotally, it means "Developer who will work for a sysadmin's salary" :)

Pay rise then.

Jim   :)

[Nathaniel Eliot]

The difference in salaries is part of the divide. Your anecdotal
company is in its dotage, if that's the closest it can come to doing
DevOps.

Definition dilution or not, right now DevOps means better than
standard developer salary, if you search around. There are enough
companies who do get the value of "a DevOps" that you shouldn't feel
beholden to those who don't.

Cheers,

--
Nathaniel Eliot
T9 Productions

[Héctor Rivas Gándara]

I want to quickly share my experience (I am getting a flight in 2h...).

I work for a big company that started a big project in a "agile" way. They hired a consultant agile company to start with it. The figure of the "DevOps Engineer" was introduced, and they hired me and others.  So, my Outlook account says that I'm a "DevOps Engineer".

Well, this help a lot to start fast the project, but the reality is that at the end we kinda end with a new silo, and some new problems.

In order to raise my concerns to management, I explain the situation using the presentation in the following link. You might find it interesting, and it shows the problems that might appear if you create a "devops team"

http://keymon.github.io/#/step-1

Sorry, for not elaborate more my mail, I just got to leave running... I'm happily leaving for holidays!

BTW, don't bookmark that link, I will one day get rid of it.

-- 
Héctor Rivas

[James Holmes]

Kent Beck et al have addressed this quite well:

https://www.facebook.com/publications/514128035341603

"Developers must also support the operational use of their software — a combination that’s become known as “devops.” This further motivates writing good code and testing it thoroughly. Developers’ personal stake in keeping the system running smoothly complements the engineering procedures and lets the system maintain quality at scale. Methodologies and tools aren’t enough by themselves because they can always be misused. Thus, a culture of personal responsibility is critical. "

--

Shu Ha Ri: Agile and .NET blog - http://www.bifrost.com.au/

Agile in 140 characters or less - https://twitter.com/James_R_Holmes

Whatever LinkedIn is for -  http://www.linkedin.com/in/jrholmes