I don't think this is true at all. Which is not to defend or even endorse the Kubernetes wank, "devops" is also "hey, we have codified what our systems look like in code (with Chef/CloudFormation/etc.)." Which is a hell of a step up from what existed prior. That I occasionally have to then go debug why AWS's Xen network drivers are spitting the bit or why this application's disk access patterns are making EBS sad certainly keeps me very firmly in the details of the systems in question, too.

(As an aside: I mentally replace the words "hipster software" whenever I see it with "things I don't understand" and the sentences never seem to change their meaning.)

> Which is a hell of a step up from what existed prior.

Not accurate. A lot of new-stuff is just old-stuff we've had forever with a new name and branding. Worse, a lot of "new" stuff is too low quality to be reliable and/or gonna die/be obsoleted very soon.

Old shops who took development seriously have developed internal tooling, customized to their internal needs. It can be surprising how well it can hold the comparison against new hype software.

"A lot of" old stuff is low-quality--but it's what we've got and the creator works here and he likes it, so we use it. See? I can generalize too.

And, friendly advice: I assure you that you meant to write "I disagree", not "not accurate". Don't be That Guy. Never be That Guy.

If old and new both suck. There is no gain in migrating to newer ;)

But they don't both suck. Newer tools reflect the needs of newer problems. Like, I can point to exactly what I get from my Chef/Cfer stack--I can wrangle hundreds of concurrent machines that need to update to a policy while also getting, in a standardized and predictable format, a full itemization of all changes applied to all systems. I can leverage the community, too, to help me bootstrap new features and functionality because we're speaking a shared language.

They might be new tools to you, and being skeptical of new stuff is fine (even healthy), but there's a point at which skepticism turns into Ludditism and it's well before the point where one starts to bloviate about "hipster software".

It's funny you'd quote Chef (or puppet), because they've been replaced by Ansible/Salt.

I spend a lot of time evaluating new tools, possibly more so than anyone else in this tread. There are very few novelties which solve a problem notably better than what existed before AND are reliable enough for serious usage AND don't come with so many drawbacks that it nullify their interests.

Chef hasn't been replaced by Ansible or Salt. Each tool has a different value prop that makes sense in different contexts. I might use Ansible in some environments where I wouldn't use Chef--there aren't a ton of these environments, IME, but I've chosen to use Ansible in the past despite it not being my favorite for reasons like this. I would use Chef in other contexts where Ansible's ecosystem or tooling is lacking--I find that chef-zero and berkshelf are a better way to self-bootstrap on AWS when using CloudFormation, for example--or where I desire the greater flexibility and expressiveness of a Ruby-based DSL.

The black-and-white thing you're painting is, if I'm gonna be frank...a little messed up. I mean this in the best of ways: please enhance your chill. It's not that bad out here.