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

The Big DevOps Misunderstanding

wolfoliver.medium.com

Post reply on HN
Print view View original

71–80 of 321 posts

Re: The Big DevOps Misunderstanding

#71

Post by 123pie123 »

sharken wrote: post #28
cortesoft wrote: post #17

As someone who has lead a devops team, and still has a devops team reporting to me, I have also struggled with the idea of having a team called devops, since it does go against the devops philosophy of devs owning their software in production. However, in our case (and probably many others), our devops team is responsible for creating and maintaining the tools and processes that allow the dev teams to manage their sy…

The DevOps team can often be the team that handles Compliance, Security and Audit for the platform. Then there is the infrastructure/deployment team and finally the developers. At least in larger organizations i think that is a common way of doing things.

in my experience with in enterprise businesses the DevOps people are almost the worst people to handle Governance, not too great at end to end Security (I've no idea about Audit)

IMHO I would guess they're too close to the dev people to care about the bigger picture

Re: The Big DevOps Misunderstanding

#72

Post by cloudcalvin »

lukevp wrote: post #64
manish_gill wrote: post #54

I had to basically give up my full time role as a Data Engineer who is supposed to solve "big data" problems (Storage, Streaming, Machine Learning pipelines) etc, and had to solely focus on DevOps because there was no other expert in the team. We (a colleague and I) basically learned Terraform, then Kubernetes, and then Helm in an extremely stressful environment. I wouldn't recommend that to most people. (Also, I can…

If you haven’t heard about cdktf, check it out! It lets you do infrastructure as code but in full programming languages like Python, C# and TypeScript. It’s by hashicorp, and under the covers it runs Terraform, so you have the whole set of terraform providers at your disposal.

If you havn't heard, check out Pulumi..

Re: The Big DevOps Misunderstanding

#73

Post by hermanradtke »

recursivedoubts wrote: post #18

I'm frankly astounded at the complexity around modern development due to dev ops and how much worse developer experience is because of it. I used to develop in a great IDE with debugging, right click re-run failed tests, I could follow the console right there in a nice, clean window integrated with my IDE, click on stack traces, etc. Now I'm running my app via multiple docker images, trying to get a buggy remote debu…

What you just described is not really related to devops. I agree that a complicated dev environment is bad. However, that isn’t a devops thing. You can have devops with a monolith that is statically compiled into a single binary. I’ve built it and done it. It is quite nice.

Re: The Big DevOps Misunderstanding

#75

Post by manish_gill »

StreamBright wrote: post #70
manish_gill wrote: post #54

I had to basically give up my full time role as a Data Engineer who is supposed to solve "big data" problems (Storage, Streaming, Machine Learning pipelines) etc, and had to solely focus on DevOps because there was no other expert in the team. We (a colleague and I) basically learned Terraform, then Kubernetes, and then Helm in an extremely stressful environment. I wouldn't recommend that to most people. (Also, I can…

You are on the right track. I have exactly the same story, data engineer, working on automation a lot. YAML, JSON and HCL should be purged from IaC asap. Luckily Dhall can be integrated everywhere we need YAML otherwise we would go nuts. The bigges failure of k8s is to understand that YAML does not scale to teams and beyond 100 lines, especially not good to nest it (hello ArgoCD). A type safe not accidentally Turing…

Dhall looks interesting. Thanks!

I went into the rabbithole of terraform/HCL and came up with Terragrunt to do dynamic code generation. Combining it together with generous use of `make` keeps me sane, but it's not a long term solution.

Even now, there are things within the system where the boundaries should be separate, but they aren't.

We literally got exhausted and burned out writing our automation, and decided to leave it as it is and then slowly build it up over the next few months. :/

PS: You're 100% right re K8s/YAML. It feels like everything in the Kubernetes world is optimized for writing the code just once. Which, of course, is easy if you already know how all the various bits fit together (true in any system).

But Reading/Debugging kubernetes world is a dreadful experience.

Edit: typo

Re: The Big DevOps Misunderstanding

#76

Post by midrus »

mac-chaffee wrote: post #25

> This trend is also supported by Kubernetes as this is a technology which is hard to master. Maybe this is rich coming from a Kubernetes person, but sounds like the tide is turning against this viewpoint. Running Kubernetes itself is definitely hard to master, but you can take a Kubernetes can be the new PaaS (if you have someone else running the control plane and maybe a monitoring stack). But there's not a PaaS on…

Are you comparing the cost of learning kubernetes to the cost of learning heroku? Or even AppEngine? Those are totally different leagues.

Also, with heroku, AppEngine, etc you have tons of documentation (official and unofficial) and resources. It is well tested and the exact same service runs thousands of businesses.

While kubernetes is like the react of the infrastructure world: you won't find two similar implementations. You need thousand tools configured around it to make it usable, and of course you might have docs about the individual pieces but you never have it for the big picture.

Re: The Big DevOps Misunderstanding

#77

Post by anticristi »

dijit wrote: post #69
mac-chaffee wrote: post #25

> This trend is also supported by Kubernetes as this is a technology which is hard to master. Maybe this is rich coming from a Kubernetes person, but sounds like the tide is turning against this viewpoint. Running Kubernetes itself is definitely hard to master, but you can take a Kubernetes can be the new PaaS (if you have someone else running the control plane and maybe a monitoring stack). But there's not a PaaS on…

> but you can take a Genuinely I believe that good QuickStarts are the cause of so many expert beginners. What I mean is: there is a person on an adjacent team who truly believes he is very competent in nearly all technologies. He is able to deploy a k3s cluster no problem. He is absolutely unable to debug that cluster, or use it in a way which is reliable (local persistent volumes means you are dependent on the node…

> What I mean is: there is a person on an adjacent team who truly believes he is very competent in nearly all technologies. He is able to deploy a k3s cluster no problem.

Aren't you confusing two roles, Kubernetes application developer and Kubernetes administrator? The Kubernetes application developer should focus on their application, NodeJS, Java, DotNET, whatever. Helm install (actually helm update --install) is all they should know/care when it comes to Kubernetes.

K3s deploy and local storage providers? Let those be the Kubernetes administrator's headaches.

Re: The Big DevOps Misunderstanding

#78

Post by thrower123 »

jordanbeiber wrote: post #12
brightball wrote: post #2

He’s not wrong. Over complicating DevOps does take the control away from developers but I think a lot of the Ops part of DevOps is to create an internal PaaS that your devs can deploy to themselves.

Yes, many enterprise devs I know are completely uninterested in infrastructure. This is also a great way of scaling teams - keeping a path of least resistance that is secure and compliant while giving observability and conventions.

Infrastructure in enterprises is usually completely uninteresting, to be fair. You need like eight different people on a call in order to stand up a VM, install a service, and configure a database connection.

Re: The Big DevOps Misunderstanding

#79

Post by dvtrn »

geodel wrote: post #53
zthrowaway wrote: post #30

My DevOps team are actually SREs, and our SRE team are just webdevs who are on call. It’s pretty ridiculous.

Could be that someone in management understood site reliability as website reliability and decided to put web devs on call.

As an SRE, I’m starting to think the misunderstanding of SRE tradecraft is probably more pronounced than the misunderstandings of Devops tradecraft. The risks definitely feel higher.

I’m six months into a new SRE role and it really feels like instead of doing any kind of engineering I’m instead just getting “overflow pipeline work from the rest of engineering that the Devops team was too busy for” and I’m already looking for the door.

Re: The Big DevOps Misunderstanding

#80

Post by urthor »

jordanbeiber wrote: post #46
cortesoft wrote: post #17

As someone who has lead a devops team, and still has a devops team reporting to me, I have also struggled with the idea of having a team called devops, since it does go against the devops philosophy of devs owning their software in production. However, in our case (and probably many others), our devops team is responsible for creating and maintaining the tools and processes that allow the dev teams to manage their sy…

Last couple of places we’ve called it “dev platform” or “dev tooling” team. I use to say that it’s like one of the business domain development teams, it’s just that the domain is “dev”. The businesses devs are the stakeholders, and the tooling/platform team members are usually already domain experts that write code. Having a “devops” team would feel like having a team called “agile team” or something - you do “devops…

Exactly. Just call it the platform/tool team.

Realistically though, I'm 100% sure that absolutely nothing will stand in the way of the DevOps job title being denigrated.

Companies have for a very long time used title inflation to bait and switch the unwary software engineer into editing enterprise software configs, and will continue to do so for all of time..

Post reply on HN