Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Eulogy for DevOps

matduggan.com

Post reply on HN
Print view View original

151–160 of 175 posts

Re: A Eulogy for DevOps

#151

Post by giantg2 »

sgarland wrote: post #146
wild_egg wrote: post #40

Earlier quoted context omitted.

_should_ know is different than _do_ know. Most engineers have little to no understanding of those systems topics and the only DB knowledge they've picked up is what leaks through their ORM A person who competently knows all those topics _and_ how to write application code is worth their weight in gold

> A person who competently knows all those topics _and_ how to write application code is worth their weight in gold IFF the company consistently values those skills. IME, they’ll say upon interviewing or hiring that those aren’t necessary for their workload, until they suddenly are, where you’re lauded as a hero. Predictably, the memory of hero status fades when promo season comes around, because those “aren’t core s…

'fades when promo season comes around, because those “aren’t core skillsets,” or something similar.'

Exactly what I'm going through right now with a potential PIP. Last year I was told there was a solid basis for me being the getting the highest rating, but only if my core work was faster. Now they want to PIP me like nothing else I contribute to matters.

Re: A Eulogy for DevOps

#152

Post by nunez »

llama052 wrote: post #62
weitendorf wrote: post #52

Earlier quoted context omitted.

It's basically a prototype that industry ran away with. It leaks implementation details everywhere and pushes way too many config options up to the developer. Because industry ran away with it before it could be good, it takes projects like Cilium to push it in the right direction, but those take forever to get adopted and are really hard because they don't live in the product itself. You'd need like 10 more Ciliums…

Can you clarify what you mean by "leaks implementation details everywhere"? I like to think of kubernetes as a big orchestration platform that you can choose to use what you need. If an ingress and pods work then use that, otherwise extend an throw an operator up for what you need (it likely already exists). Cilium for instance is great for that, so is Istio and the like. They aren't hard you just have to understand…

Just look at the release notes for every major release. They focus on what's new within Kubernetes architecture instead of what's new that benefits users.

Things like having to remove finalizers appended onto resources when you delete them and they hang.

Damn near everything about Custom Resources.

This isn't a dig at Kubernetes; I love using it. However, I agree that it leaks implementation everywhere.

Re: A Eulogy for DevOps

#153

Post by llama052 »

hitsurume wrote: post #105
llama052 wrote: post #54

I'll start by saying that I think knowledge for knowing layers underneath the application is fading in some circles, and that makes me sad. Having been a frontend guy some 10+ years ago, into a network engineer, then infrastructure engineering and now SRE. The amount of people on both sides of the developer circle and operations circle that do not want to understand what's going on is mind boggling. I was around when…

I'm interested in knowing more about how you guys implemented the operator model and decided on those tools. Was there a book or anything that was helpful in all of this?

Nothing specific I've read that helped us with this, our goal was finding the easiest path to entry to get the tooling we desire in our platform.

I've debated writing it up and posting it somewhere, maybe I should. There's so many ways of doing things now that it's quite overwhelming sometimes.

Re: A Eulogy for DevOps

#154

Post by johnny22 »

ozim wrote: post #130

I think author is just wrong. I see it has a lot of upvotes so there are people who share view with author. But every single idea I read in that post is just wrong. Like author never worked in siloed team where you had to wait blocked for a week so DBA guy picks up your change request. Then if something went wrong on prod you had to wait for SysAdmin to basically be your typist because you did not have access right.…

the author is talking about how things got perhaps overcorrected, not that something shouldn't be done about problems you're talking about.

Re: A Eulogy for DevOps

#155

Post by hitsurume »

llama052 wrote: post #153
hitsurume wrote: post #105

Earlier quoted context omitted.

I'm interested in knowing more about how you guys implemented the operator model and decided on those tools. Was there a book or anything that was helpful in all of this?

Nothing specific I've read that helped us with this, our goal was finding the easiest path to entry to get the tooling we desire in our platform. I've debated writing it up and posting it somewhere, maybe I should. There's so many ways of doing things now that it's quite overwhelming sometimes.

Yea exactly, thats why I asked haha.

Re: A Eulogy for DevOps

#156

Post by bigstrat2003 »

whoknowsidont wrote: post #107
zer00eyz wrote: post #43

Earlier quoted context omitted.

Its not. The whole ecosystem around it is an example of Conways law and and a Google product. None of the people using it are google. Google, also, runs its own hardware. Shockingly it is a great product if you rent hardware, autoscaling is autospending. No one knows what a feature costs any more because its all just a big bucket your pouring money into for amazon to have 30 percent margin on. We need operations peop…

>The whole ecosystem around it is an example of Conways law This is such an inaccurate take. >we need to stop using containers as bags Containers and container orchestration are a NEEDED and REQUIRED piece of the technology stack in the current reality. That doesn't mean people need to be ignorant of the details that make them work. As someone who's been around for a while we are in a better place than when we had "d…

> Containers and container orchestration are a NEEDED and REQUIRED piece of the technology stack in the current reality.

That is not remotely true. Containers (and their orchestration) are a choice. Obviously people have their reasons for making that choice, but it is in no way a requirement. To say otherwise is either profound hyperbole or ignorance.

Re: A Eulogy for DevOps

#157

Post by bigstrat2003 »

udev4096 wrote: post #115
sadops wrote: post #68

Earlier quoted context omitted.

This is the elephant in the room: all "new" technology isn't fundamentally new. Terraform is just curl with state management for lots of different websites, Andible is just a YAML to Bash converter, and so on. If you have good fundamentals, not only are these things easy, they're also incredibly frustrating, because you can easily see their limitations. You can always tell how experienced someone is by how well they…

Ansible is a lot more than just "YAML to Bash". For instance, Bash scripts are not idempotent. Ansible playbooks are. Sure, you can hack together a way to ssh and run commands very easily but it will break at some point

Bash scripts are as idempotent as you want to make them, so I think the comparison holds.

Re: A Eulogy for DevOps

#158

Post by bigstrat2003 »

sgarland wrote: post #143
sadops wrote: post #68

Earlier quoted context omitted.

This is the elephant in the room: all "new" technology isn't fundamentally new. Terraform is just curl with state management for lots of different websites, Andible is just a YAML to Bash converter, and so on. If you have good fundamentals, not only are these things easy, they're also incredibly frustrating, because you can easily see their limitations. You can always tell how experienced someone is by how well they…

> There's no substitute for skill and experience, despite what the modern tech discourse says. "Anyone can program!" I’m told this is gatekeeping. Yes, and…? I’ve always found it amusing that I see little to no anger being directed at kernel devs for their gatekeeping. Almost as if deep down, people know that they shouldn’t be fucking with the thing that runs the world unless they are actually good at it. Or maybe th…

I agree that "gatekeeping" gets a bad rap. Sure, it can be taken too far. But at the end of the day, one needs to actually be qualified. And if they aren't, well sorry but you aren't good enough for the job. It doesn't make you a bad person, it just means you need to work on your skills before you're a fit.

Re: A Eulogy for DevOps

#159

Post by sgarland »

giantg2 wrote: post #151
sgarland wrote: post #146

Earlier quoted context omitted.

> A person who competently knows all those topics _and_ how to write application code is worth their weight in gold IFF the company consistently values those skills. IME, they’ll say upon interviewing or hiring that those aren’t necessary for their workload, until they suddenly are, where you’re lauded as a hero. Predictably, the memory of hero status fades when promo season comes around, because those “aren’t core s…

'fades when promo season comes around, because those “aren’t core skillsets,” or something similar.' Exactly what I'm going through right now with a potential PIP. Last year I was told there was a solid basis for me being the getting the highest rating, but only if my core work was faster. Now they want to PIP me like nothing else I contribute to matters.

I’m very sorry. I quit a job once because they couldn’t follow their own rubric for promos.

“We’ve written down objective guidelines for what constitutes your relative performance.”

“Great, looks like I’m a shoe-in.”

“Well… there are intangibles.”

“Then why have the rubric?”

Re: A Eulogy for DevOps

#160

Post by bradknowles »

fragmede wrote: post #138
signal11 wrote: post #110

Earlier quoted context omitted.

We have environments with thousands of services and it scales fine. Why would dev (or your lowest integration environment) be broken most of the time? > except that means the Kafka team That (a Kafka team, or a DB2 team) is a bit of a red flag for me. Many (but not all) “tech” teams like that are part of the problem. Cross functional delivery teams work much better, because running tech X in isolation is often not va…

Where are you that has thousands or services and it scales fine? Twitter and Facebook famously both don't have a separate staging environment because they have thousands or services and it doesn't scale fine. They do canary releases and feature flags so as to do gradual deployment and testing in prod. If they can't solve the problem but you're somewhere that has, my next question is are you hiring? Dev is broken beca…

I worked at AWS. Each team/service had their own alpha/beta/delta/gamma development environments, as well as one-box and blue/green production deployment environments, and deployed to waves of regions from smaller groups at the start to bigger groups at the end.

That all seemed to work reasonably well.

Post reply on HN