[parasubvert]

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]

>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]

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]

>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]

Indeed. That's why Google has SRE and Facebook has Production Engineering, and so on.

[freeone3000]

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]

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]

> 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=20080403063620A...

[cthalupa]

>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.

Not everyone does the same job you do, even if they might share the same job title. I'm proficient in bash and python, have been learning rust, and know enough c to get around, but there have been many years in my career where my actual sysadmin duties required little more than being able to do 'while true; do x; done'

That's very much not been the case over the past half decade, but there were times in the 2000s where nothing was necessary beyond some basic bash scripts. No writing, modifying, or debugging of anything I would actually call code was needed.

I've also done hundreds of interviews for sysadmin positions. I'd say the minority of them were proficient beyond the very basics of bash. Most of them seemed to be doing well enough in their existing roles to not have been fired.

shrugs

[halbritt]

Development abilities would entail having the ability to take a task, or feature, write code around that task or feature including tests, and then submit a PR.

As someone doing the hiring for such things, people looking to get hired seem to have a different view of things. I don't need someone with an advanced degree in CS and mastery of algorithms to produce API endpoints and orchestration bits.

As for having software developers handing off their software for someone else to operate, well, that's an anti-pattern that inhibits throughput and software quality. There's quite a bit of data around this topic. I would encourage you to read this book:

https://itrevolution.com/book/accelerate/

I'll grant you that it's difficult to get there in a traditional IT org, but once you do get there, the results are glorious.

[nasalgoat]

I've been doing Ops for 20 years and even back in the 90's I barely had to understand what a Make file was doing. I've certainly never had to do much actual dev work.

My main worry is that specialization won't return soon and my Ops skills won't be enough to keep me employed.

[twblalock]

I've only seen devs doing that stuff at very small startups.