3 ms·

DevOps is just a buzzword. Implementing it wrong is the deafult and only possibility. For real it means that the devs and ops collaborate. Leaving aside that w

DevOps is just a buzzword. Implementing it wrong is the deafult and only possibility. For real it means that the devs and ops collaborate. Leaving aside that we don't need a term for that, it cannot be a strategy. It's something that evolves in years between decent people. You cannot hire devops. You cannot train devops. There is no such thing.

Bombthecat 7y ago
There was a podcast or a book?can't rember, but they talked about the high performer teams and they had one thing in common : the devops mentality, work together, solve together (swarming) deeply together, learn and move on etc etc etc. Not Tools or processes..
- thegabez 7y ago
  Sure for a small individual team or org. But getting this to scale isn't feasible. As companies grow they tend to hire based on specific skill sets. Thats when you start seeing the split into either dev or ops, which brings us back to the need for a small high performing with devops mentality...the devops team.
  - _betty_ 7y ago
    Why not hire "devops" skill into each team instead of creating a silo? Massive reason behind devops is to get Dev teams to take more ownership of ops so they improve their Dev practises, I don't see a dedicated team being able to improve the code base in the same way.
    - thegabez 7y ago
      There are many ways to implement "devops", this is one of them.
  - dragonwriter 7y ago
    > Sure for a small individual team or org. But getting this to scale isn't feasible. Based on...what? > As companies grow they tend to hire based on specific skill sets By which you probably mean they tend to prefer hiring more narrowly specialized individuals. That may be a common trend, but to the extent it stops you from hiring or training for devops across your technical organization, it's incompatible with any meaningful devops implementation. DevOps doesn't work as a silo, any more than (as an enterprise I know pretends to do) can you do kaizen by way of an isolated “Kaizen team” reporting to a senior executive. Some things are definitionally not siloes and “doing” them in a silo is a failure to do (or even understand) them at all.
  - z3ncyberpunk 7y ago
    Maybe not everything is about scaling it up?
- jcelerier 7y ago
  Fifteen years ago this was called agile
alexandercrohde 7y ago
Eh, I don't really agree with "you can't hire devops." You can hire somebody with extensive experience in jenkins, and building and integrating tests, deploying, logging, diagnosing production issues, systems/performance-experience, DBA skills, secret management, etc. And many companies do. If you don't think hiring a specialist in those things should be called "hiring devops" what realistically should we call it?
- sciurus 7y ago
  Hiring operations engineers?
  - robbyt 7y ago
    Hiring operations engineers with updated and relevant skills?
jayd16 7y ago
You can still hire someone who knows how to collaborate and teach devs how to ops and teach ops how to dev. But I think the article does point out the many ways "hiring devops" can go wrong.
0xbadcafebee 7y ago
> For real it means that the devs and ops collaborate Yes. The most simple, boiled-down definition is that: collaboration. But how the f%&k do you do that? You might say, "Oh I dunno, they'll just figure it out." But guess what? People have spent their entire lives trying to figure out how to get random teams to collaborate better. It's hard. It's harder than coding, harder than supporting an app in production. It's not something you get good at by just doing engineering and hoping for the best. And that is the entire reason DevOps was invented. A bunch of engineers basically got together and said, "Shit. We need to collaborate better. And we've known that for a while, but it's just not happening. What can we actually _do_ to collaborate better, and produce better outcomes?" Over the past decade, there has been a lot of collaboration on how to do better collaboration. This topologies page is a very small example of what they've found. I think that to engineers, DevOps can seem like a buzzword because there's all this stupid-sounding "business stuff" that people keep tacking onto DevOps. But the reason that happens is there are people whose job it is to help people collaborate better, and produce better outcomes, who have spent their lives working on these problems, and are trying to apply them to technology-related businesses. A lot of the things they've figured out are built on other things that have proven successful in the past, such as Lean manufacturing/software, Agile software development, and all the many other business strategies developed and practiced over the last century. Many companies, both large and small, have applied these ideas and seen real results from them. > DevOps is just a buzzword. "Cloud" is also a buzzword, as well as "Agile", but they are real things that real people use every day. Misunderstood? Absolutely; but definitely real.
- LIV2 7y ago
  Collaboration requires empathy, which rarely happens when developers think ops are subhuman filth. In my last Organization the devs largely treated ops like trash, it was only the dev teams on the most business critical and performance sensitive apps that really worked well with ops because it necessitated a close working relationship through the good times and through the hard times & they natuarally came to respect each other's skills

Bombthecat 7y ago

There was a podcast or a book?can't rember, but they talked about the high performer teams and they had one thing in common : the devops mentality, work together, solve together (swarming) deeply together, learn and move on etc etc etc. Not Tools or processes..

thegabez 7y ago
Sure for a small individual team or org. But getting this to scale isn't feasible. As companies grow they tend to hire based on specific skill sets. Thats when you start seeing the split into either dev or ops, which brings us back to the need for a small high performing with devops mentality...the devops team.
- _betty_ 7y ago
  Why not hire "devops" skill into each team instead of creating a silo? Massive reason behind devops is to get Dev teams to take more ownership of ops so they improve their Dev practises, I don't see a dedicated team being able to improve the code base in the same way.
  - thegabez 7y ago
    There are many ways to implement "devops", this is one of them.
- dragonwriter 7y ago
  > Sure for a small individual team or org. But getting this to scale isn't feasible. Based on...what? > As companies grow they tend to hire based on specific skill sets By which you probably mean they tend to prefer hiring more narrowly specialized individuals. That may be a common trend, but to the extent it stops you from hiring or training for devops across your technical organization, it's incompatible with any meaningful devops implementation. DevOps doesn't work as a silo, any more than (as an enterprise I know pretends to do) can you do kaizen by way of an isolated “Kaizen team” reporting to a senior executive. Some things are definitionally not siloes and “doing” them in a silo is a failure to do (or even understand) them at all.
- z3ncyberpunk 7y ago
  Maybe not everything is about scaling it up?
jcelerier 7y ago
Fifteen years ago this was called agile

alexandercrohde 7y ago

Eh, I don't really agree with "you can't hire devops." You can hire somebody with extensive experience in jenkins, and building and integrating tests, deploying, logging, diagnosing production issues, systems/performance-experience, DBA skills, secret management, etc. And many companies do. If you don't think hiring a specialist in those things should be called "hiring devops" what realistically should we call it?

sciurus 7y ago
Hiring operations engineers?
- robbyt 7y ago
  Hiring operations engineers with updated and relevant skills?

jayd16 7y ago

You can still hire someone who knows how to collaborate and teach devs how to ops and teach ops how to dev. But I think the article does point out the many ways "hiring devops" can go wrong.

0xbadcafebee 7y ago

> For real it means that the devs and ops collaborate Yes. The most simple, boiled-down definition is that: collaboration. But how the f%&k do you do that? You might say, "Oh I dunno, they'll just figure it out." But guess what? People have spent their entire lives trying to figure out how to get random teams to collaborate better. It's hard. It's harder than coding, harder than supporting an app in production. It's not something you get good at by just doing engineering and hoping for the best. And that is the entire reason DevOps was invented. A bunch of engineers basically got together and said, "Shit. We need to collaborate better. And we've known that for a while, but it's just not happening. What can we actually _do_ to collaborate better, and produce better outcomes?" Over the past decade, there has been a lot of collaboration on how to do better collaboration. This topologies page is a very small example of what they've found. I think that to engineers, DevOps can seem like a buzzword because there's all this stupid-sounding "business stuff" that people keep tacking onto DevOps. But the reason that happens is there are people whose job it is to help people collaborate better, and produce better outcomes, who have spent their lives working on these problems, and are trying to apply them to technology-related businesses. A lot of the things they've figured out are built on other things that have proven successful in the past, such as Lean manufacturing/software, Agile software development, and all the many other business strategies developed and practiced over the last century. Many companies, both large and small, have applied these ideas and seen real results from them. > DevOps is just a buzzword. "Cloud" is also a buzzword, as well as "Agile", but they are real things that real people use every day. Misunderstood? Absolutely; but definitely real.

LIV2 7y ago
Collaboration requires empathy, which rarely happens when developers think ops are subhuman filth. In my last Organization the devs largely treated ops like trash, it was only the dev teams on the most business critical and performance sensitive apps that really worked well with ops because it necessitated a close working relationship through the good times and through the hard times & they natuarally came to respect each other's skills