3 ms·

I've seen two prevalent definitions of devops: 1. It's a culture where dev and ops work together (as per TFA); 2. It is the application of software engineerin

I've seen two prevalent definitions of devops: 1. It's a culture where dev and ops work together (as per TFA); 2. It is the application of software engineering practises (such as version control and test automation) to ops. I prefer the second definition because it's the only one that's got anything to do with new developments in infrastructure-as-code and isn't just a new name for what competent teams were always doing anyway.

notamy 9y ago
Alternative third definition: Make the devs also be the ops guys
- devoply 9y ago
  you mean the ops guys. and yeah it's just an easy way to take nerds and make them do more stuff so you can save that extra 85-100k salary. More profit for the shareholders, what's not to love.
  - provl 9y ago
    ok
  - notamy 9y ago
    I did indeed. Good catch.
- yourapostasy 9y ago
  I've been on the sysadmin/ops end, trying to teach devs how to apply their software engineering to ops. It's not a short ramp, unfortunately; the various ops stacks now are as broad and deep as software development stacks. Worse yet, it is not Yet Another Imperative Programming Language for them to pick up. Even declarative configuration management systems embed a lot of hidden, assumed sysadmin/ops experience/skills that many devs don't arrive on the scene with, and in the vast majority of cases it was like training someone from scratch to become a sysadmin, and then start devops training. Add in cross-platform ops, and it gets more challenging. Add in enterprise demands and integration points, and it becomes a multi-year effort. More unfortunately, it is also a long ramp up time to bring sysadmins who don't know programming up to speed on software development. I'd like to know what others are doing to quickly build a devops team if they are doing that, other than "find highly-skilled senior sysadmins who already know software development", because that's my go-to approach for the time being, as it is way faster to teach someone like that Ansible if they already use Chef, for example, than pick up sysadmins or devs and cross-train them into the other field.
- Randgalt 9y ago
  I'm good at writing code, developing libraries, architecture, etc. I'm not very good at operations - mostly because I don't enjoy it and haven't spent much time applying it. Not everyone is the pitcher, the catcher, the first baseman, etc. We specialize because that's how humans work best together. Everyone should not need to know how to do everything. Developers must work with operations - of course. The way and the what developers build must be able to be deployed in an agile manner. But, that does not mean that developers must become operations engineers as well. Leave that to the specialists in that role.
  - cat199 9y ago
    > Not everyone is the pitcher, the catcher, the first baseman, etc. In soccer, this argument holds less weight. I prefer soccer.
    - Nadya 9y ago
      Okay, so not everyone is a sweeper, fullback, goalie, wingback, midfielder, striker, or forward.
- edgan 9y ago
  That is NoOps.
sanderjd 9y ago
> and isn't just a new name for what competent teams were always doing anyway That's interesting. I see that the opposite way: weren't competent ops teams already doing the things you listed in #2? Does keeping up with new developments in operations tooling need a new name? Shouldn't that just be part of doing ops well?

notamy 9y ago

Alternative third definition: Make the devs also be the ops guys

devoply 9y ago
you mean the ops guys. and yeah it's just an easy way to take nerds and make them do more stuff so you can save that extra 85-100k salary. More profit for the shareholders, what's not to love.
- provl 9y ago
  ok
- notamy 9y ago
  I did indeed. Good catch.
yourapostasy 9y ago
I've been on the sysadmin/ops end, trying to teach devs how to apply their software engineering to ops. It's not a short ramp, unfortunately; the various ops stacks now are as broad and deep as software development stacks. Worse yet, it is not Yet Another Imperative Programming Language for them to pick up. Even declarative configuration management systems embed a lot of hidden, assumed sysadmin/ops experience/skills that many devs don't arrive on the scene with, and in the vast majority of cases it was like training someone from scratch to become a sysadmin, and then start devops training. Add in cross-platform ops, and it gets more challenging. Add in enterprise demands and integration points, and it becomes a multi-year effort. More unfortunately, it is also a long ramp up time to bring sysadmins who don't know programming up to speed on software development. I'd like to know what others are doing to quickly build a devops team if they are doing that, other than "find highly-skilled senior sysadmins who already know software development", because that's my go-to approach for the time being, as it is way faster to teach someone like that Ansible if they already use Chef, for example, than pick up sysadmins or devs and cross-train them into the other field.
Randgalt 9y ago
I'm good at writing code, developing libraries, architecture, etc. I'm not very good at operations - mostly because I don't enjoy it and haven't spent much time applying it. Not everyone is the pitcher, the catcher, the first baseman, etc. We specialize because that's how humans work best together. Everyone should not need to know how to do everything. Developers must work with operations - of course. The way and the what developers build must be able to be deployed in an agile manner. But, that does not mean that developers must become operations engineers as well. Leave that to the specialists in that role.
- cat199 9y ago
  > Not everyone is the pitcher, the catcher, the first baseman, etc. In soccer, this argument holds less weight. I prefer soccer.
  - Nadya 9y ago
    Okay, so not everyone is a sweeper, fullback, goalie, wingback, midfielder, striker, or forward.
edgan 9y ago
That is NoOps.

sanderjd 9y ago

> and isn't just a new name for what competent teams were always doing anyway That's interesting. I see that the opposite way: weren't competent ops teams already doing the things you listed in #2? Does keeping up with new developments in operations tooling need a new name? Shouldn't that just be part of doing ops well?