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

101–110 of 321 posts

Re: The Big DevOps Misunderstanding

#101

Post by hnthrowaway0315 »

stepbeek wrote: post #23
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…

Given the second principle of devops is amplifying feedback loops, I think a more charitable view could be "the common misunderstanding of DevOps has lead to a terrible dev environment". Fwiw, I'm fully onboard with you, but really love the core message of books like the phoenix project and don't really want it to be lost because of overzealous use of docker.

OMG, I read the sample chapters from Amazon about the Phoenix project and that was a really really good read, thank you!

Re: The Big DevOps Misunderstanding

#102

Post by mindwok »

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…

Sounds like what you're really angry at here is a case of micro-services taken to the extreme.

Re: The Big DevOps Misunderstanding

#103

Post by INTPenis »

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…

Being a devops guy these last 2 years I have noticed that besides doing what you just mentioned, I am basically end user support for developers.

And through this I've noticed that developers can be just as bad at communicating issues as any end user I've ever dealt with.

Just because they've written the system end users use, does not mean they're better at reporting problems to me, because their problems are about the pipelines, the kubernetes clusters, the containers, anything outside of their programming code basically.

So I still need to use all the communication skills I learned decades ago when I was doing end user support for people who didn't even work in IT.

Re: The Big DevOps Misunderstanding

#104

Post by throwawayboise »

GiorgioG wrote: post #65

Kubernetes is a cancer for 99% of companies. Most companies need little more than docker compose/swarm. Kubernetes is the antithesis to KISS. If you’re Google, then you need something like K8s. Most orgs using it are pretenders or trend followers. Sadly it has become the “standard” way to deploy apps.

Most people just need lxc-create or virsh create, honestly. It's the only things I have been able to get to work reliably. All the docker and k8s stuff is unnecessary complexity if you just need to run a container or VM.

Re: The Big DevOps Misunderstanding

#105

Post by stickfigure »

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…

To adapt Greenspun's tenth rule:

You have a dedicated team building an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Google App Engine (or Heroku, or Digital Ocean App Platform, etc).

Re: The Big DevOps Misunderstanding

#106

Post by atmosx »

> You build it, you run it

For any set of non-trivial apps the cognitive load is simply too big. Assuming the engineer can handle it, eventually more time will be spent in keeping up with the current system(s) than writing code/promoting the business logic.

A company could chose to use ready-made tools but all them get expensive pretty quickly and make their own assumptions about workflows, view-points, etc. The assumptions might fit the use case or not. Lock-in then becomes another problem. There's no easy way out, it's trade offs all the way :-)

Example: The Haskell lead engineer for App1 has all the necessary knowledge to understand how the base-metal NixOs fleet is configured because there's deep familiarity with Nix. At some point the infra team will start making decisions and assumptions to automate _this_ or _that_. The engineer now will have to spent time understand what changed since last time, making sure nothing is broken while performing changes.

Re: The Big DevOps Misunderstanding

#107

Post by flas9sd »

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…

could you give me a hint why you didn't like jsonnet? I dreaded k8s yaml when needing to (write) and use helm packages and think of indenting levels, but jsonnet via grafanas tanka gave me the option to be concise, writing functions and creating reusable bits. Of course then you're not far away from using a real language "sdk style".

As you so aptly put, k8s learning curve is beginner hostile and needs system knowledge before you go at it, so I'm not sure if this was also with being more familiar with the abstractions - after having looked at k8s for 2-3 years, jsonnet made me finally like interfacing with the k8s apiserver.

Re: The Big DevOps Misunderstanding

#108

Post by StreamBright »

jjtheblunt wrote: post #92
StreamBright wrote: post #70

Earlier quoted context omitted.

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…

"turning complete" : typo?

Yes, thanks.

Re: The Big DevOps Misunderstanding

#109

Post by girvo »

benlivengood wrote: post #93
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…

I've been in two production environments where IaC was done with Turing-complete languages (Google and Facebook). It's really not better (it just lets the truly impossible/unmanageable become possible) because they were both dynamically typed. If anything, Terraform comes the closest to being a good IaC language because providers form an API to production resources as opposed to unstructured code/config like Helm or…

In terms of “Haskell type classes as production API”, I assume you’ve come across Dhall?

https://dhall-lang.org/

Re: The Big DevOps Misunderstanding

#110

Post by kazen44 »

cortesoft wrote: post #88
shrimpx wrote: post #62

Earlier quoted context omitted.

Devops is having an identity crisis, but what you describe is what I call devops. It's the subset of engineering that supports engineering by defining/inferring workflows and building systems and tools to codify them. But I've seen it called ops, sysops, internal platform, and even infrastructure -- in some companies, devops and infra are the same people.

Yeah, I am not sure how typical this is, but my company has DC (data center) ops, NetOps, SysOps, and DevOps… DC ops is in charge of the physical system, from racking and stacking to hardware replacements. NetOps handles the networking stack, managing the routers and switches, vlans, announcements, IP block management, network access requests, etc. SysOps handles provisioning systems, working with dc ops to get syste…

this seems to be roughly the division i have seen at most companies.

Sometimes, automation and tooling are written by seperate teams, or are done by teams of different disciplines of operations/engineering.

I have almost never seen a network and system groups NOT being seperate. Mind you this is in DC/ISP's environment, where the complexity of networks is usually the mainstay or a heavy dependency of the business.

Post reply on HN