7 ms·

Your broader point is correct but I think you're mischaracterizing Devops (which isn't about developers doing this stuff, it's about a continuously improving cu

Your broader point is correct but I think you're mischaracterizing Devops (which isn't about developers doing this stuff, it's about a continuously improving culture + technology to support end-to-end delivery and operations) But more broadly, Kubernetes in the hands of most developers that are doing non-platform level work is a step backwards and will be disastrous. It's far too low level, it's like, hey this Python/Ruby/Java thing was great, but have you seen this new bytecode linker and assembler? New platforms and runtime built ON TOP OF Kubernetes are probably going to be fine. But that's going to take a while.

chris_mc 8y ago
>Your broader point is correct but I think you're mischaracterizing Devops (which isn't about developers doing this stuff, it's about a continuously improving culture + technology to support end-to-end delivery and operations) Everyone who comments about DevOps should have read "The Phoenix Project" first, so that they understand what you just said. It's not about consolidating workloads onto generalists, it's supposed to be about breaking down the silos in an organization, nothing more!
- zeckalpha 8y ago
  Which they barely did in Phoenix Project toward the end. The first part was building silos to slow the input and reduce work in progress.
fauigerzigerk 8y ago
>Your broader point is correct but I think you're mischaracterizing Devops You are right. What I should have said is that using DevOps as an excuse to make application developers do complex infrastructure design, automation and maintainance as a side-job is an unsustainable practice.
- halbritt 8y ago
  Indeed. That's why Google has SRE and Facebook has Production Engineering, and so on.
  - freeone3000 8y ago
    aka "ops" The idea that this will kill "devops" is ludicrious, because devops doesn't actually replace job titles. We have a "Devops engineer". He's an ops engineer, with "dev" in front of his title because he codes in perl and python (...like an op). Visual Studio is a "DevOps Environment". I don't know what this means. It likely means that it can provide end-to-end integration in your development environment, which was previously an IDE. The idea behind devops being a raised layer of abstraction is fine, but we don't really need a new word for it, and as history has shown, raised abstractions do not lower. We're going to end up with "devops" until we find a new buzzword.
    - halbritt 8y ago
      No disagreement here. There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people. This has been hashed about at length, but the inverse is also true. Developers must learn to operate their software in production.
      - mmt 8y ago
        > There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people. I very strongly disagree, unless what you mean by "no development abilities" is merely an inability (or refusal) to write or modify (maybe debug) code. There is here, what I believe, a very important distinction, that is routinely lost, and has all but totally devalued Ops skills in the minds of many tech hiring managers who have exclusively programming backgrounds. I was on a phone interview today, in fact, lamenting, along with my interviewer, that there exist such sysadmins who don't even write scripts or automation. He suggested that they've started to call themselves "IT", and, IMO, that may well be a more apt term even than "Ops". My own experience is that, back in the dark ages, a traditional sysadmin not only had to be proficient at scripting but also at some amount of C just to port open source tools between various proprietary Unix version, especially with new releases. That does not, however, bestow upon me, anything that I could call, with a straight face, "development abilities". I hold in my head none of the best practices having to do with programming that have accumulated over the 3 decades of my career, for example. Instead, I hold the Ops best practices. Being able to implement FizzBuzz in bash is neither necessary nor sufficient for software development. > Developers must learn to operate their software in production. I disagree here, as well, on behalf of developers. I think you'll find having to learn what is, essentially, a completely separate, new, engineering discipline, in addition to software development, severely cuts into their productivity. Unless I bring production to the developers, almost like bringing the upstairs downstairs in the cartoon pushbutton house[1]. I do actually feel it's a responsibility of Ops as part of Devops culture to create as frictionless (for their needs) a simulation of production as possible for developers. The practice has all sorts of benefits, including eliminating "works on my machine" debugging issues, that has been one of the rallying cries for containers. [1] https://answers.yahoo.com/question/index?qid=20080403063620AADzOBE https://answers.yahoo.com/question/index?qid=20080403063620A...
- twblalock 8y ago
  I've only seen devs doing that stuff at very small startups.

chris_mc 8y ago

>Your broader point is correct but I think you're mischaracterizing Devops (which isn't about developers doing this stuff, it's about a continuously improving culture + technology to support end-to-end delivery and operations) Everyone who comments about DevOps should have read "The Phoenix Project" first, so that they understand what you just said. It's not about consolidating workloads onto generalists, it's supposed to be about breaking down the silos in an organization, nothing more!

zeckalpha 8y ago
Which they barely did in Phoenix Project toward the end. The first part was building silos to slow the input and reduce work in progress.

fauigerzigerk 8y ago

>Your broader point is correct but I think you're mischaracterizing Devops You are right. What I should have said is that using DevOps as an excuse to make application developers do complex infrastructure design, automation and maintainance as a side-job is an unsustainable practice.

halbritt 8y ago
Indeed. That's why Google has SRE and Facebook has Production Engineering, and so on.
- freeone3000 8y ago
  aka "ops" The idea that this will kill "devops" is ludicrious, because devops doesn't actually replace job titles. We have a "Devops engineer". He's an ops engineer, with "dev" in front of his title because he codes in perl and python (...like an op). Visual Studio is a "DevOps Environment". I don't know what this means. It likely means that it can provide end-to-end integration in your development environment, which was previously an IDE. The idea behind devops being a raised layer of abstraction is fine, but we don't really need a new word for it, and as history has shown, raised abstractions do not lower. We're going to end up with "devops" until we find a new buzzword.
  - halbritt 8y ago
    No disagreement here. There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people. This has been hashed about at length, but the inverse is also true. Developers must learn to operate their software in production.
    - mmt 8y ago
      > There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people. I very strongly disagree, unless what you mean by "no development abilities" is merely an inability (or refusal) to write or modify (maybe debug) code. There is here, what I believe, a very important distinction, that is routinely lost, and has all but totally devalued Ops skills in the minds of many tech hiring managers who have exclusively programming backgrounds. I was on a phone interview today, in fact, lamenting, along with my interviewer, that there exist such sysadmins who don't even write scripts or automation. He suggested that they've started to call themselves "IT", and, IMO, that may well be a more apt term even than "Ops". My own experience is that, back in the dark ages, a traditional sysadmin not only had to be proficient at scripting but also at some amount of C just to port open source tools between various proprietary Unix version, especially with new releases. That does not, however, bestow upon me, anything that I could call, with a straight face, "development abilities". I hold in my head none of the best practices having to do with programming that have accumulated over the 3 decades of my career, for example. Instead, I hold the Ops best practices. Being able to implement FizzBuzz in bash is neither necessary nor sufficient for software development. > Developers must learn to operate their software in production. I disagree here, as well, on behalf of developers. I think you'll find having to learn what is, essentially, a completely separate, new, engineering discipline, in addition to software development, severely cuts into their productivity. Unless I bring production to the developers, almost like bringing the upstairs downstairs in the cartoon pushbutton house[1]. I do actually feel it's a responsibility of Ops as part of Devops culture to create as frictionless (for their needs) a simulation of production as possible for developers. The practice has all sorts of benefits, including eliminating "works on my machine" debugging issues, that has been one of the rallying cries for containers. [1] https://answers.yahoo.com/question/index?qid=20080403063620AADzOBE https://answers.yahoo.com/question/index?qid=20080403063620A...
twblalock 8y ago
I've only seen devs doing that stuff at very small startups.