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

51–60 of 321 posts

Re: The Big DevOps Misunderstanding

#51

Post by vanusa »

g051051 wrote: post #13
dijit wrote: post #9

I made a similar ranty blog post about devops. I was surprised by the amount of history and misconception that exists around the term. The term was originally intended as “Agile Systems Administration” but came about at the same time as a talk titled 100 deploys a day. So people conflated the two, and it didn’t help that the conference was a portmaneau of “Developers, Operations days” to encourage it being a conferen…

> The term was originally intended as “Agile Systems Administration” That explains why it's such a terrible idea.

Exactly. One meaningless definition attempts to justify its existence by referencing another.

Re: The Big DevOps Misunderstanding

#52

Post by [deleted] »

ltbarcly3 wrote: post #5
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.

Except then it's not DevOps. If you have people working on 'DevOps' 100% of the time, that means they aren't working on Dev, and are only working on Ops. The idea behind DevOps is that Dev(elopers) do their own Op(eration)s, rather than throwing stuff over the wall for a separate team to manage. Not only has the industry done the opposite in many cases, they kept the name DevOps, meanwhile the full time operations st…

[deleted]

Re: The Big DevOps Misunderstanding

#54

Post by manish_gill »

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 hear "you don't need k8s", but tbh, it makes the difficult things possible, and that's what we needed).

I've done Ops in bare-metal environments before, and at least there, even if there were new skills to learn, the environment just wasn't so hostile for beginners, and the learning curve was simpler.

The YAML (or heaven forbid, jsonnet) does *not* help. TBH, I'm convinced if the IaC bits were done in a regular Java/Go/Rust SDK style instead of mixing and matching YAML glued together via labels and tags, I would have had a much easier time.

The positive side of that is that now the IaC bits are mature enough that even the Data Scientists in our team write their own Terraform code, and I've upskilled myself quite a lot. I'm slowly going back to solving Storage/Data/ML issues, which I enjoy a lot more.

Maybe I'm just becoming a cranky Software Dev as I enter my 30s. I do _not_ enjoy reading YAML.

Re: The Big DevOps Misunderstanding

#55

Post by excuses_ »

ltbarcly3 wrote: post #5
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.

Except then it's not DevOps. If you have people working on 'DevOps' 100% of the time, that means they aren't working on Dev, and are only working on Ops. The idea behind DevOps is that Dev(elopers) do their own Op(eration)s, rather than throwing stuff over the wall for a separate team to manage. Not only has the industry done the opposite in many cases, they kept the name DevOps, meanwhile the full time operations st…

I agree that the term was kinda stollen and in many places Ops became DevOps while still doing Ops stuff 100%.

I think there is a place for both. Going into DevOps does not mean you need to get rid of your Ops team.

I like the approach when Ops are handling the backbone infrastructure of the organization while individual teams work in DevOps methodology meaning they are responsible for building necessary application infra, programs, as well as bringing it to production and monitoring.

Re: The Big DevOps Misunderstanding

#56

Post by emptysongglass »

DevOps was always about de-siloing. In that, it is a culture but you need people to "be the change" and that's how I've played a DevOps Engineer for the last five years (well now SRE) and how I believe DevOps Engineers (and SREs by extension) ought to be playing their role today.

Corporate management is always surprised when my first move is to go sit with the developers and ask how I can unblock their workflow, reduce pain and tighten their development loop. Most SREs and professional DevOps people I've met do not do this and insist that their function is to tell the developers how they'll build their app and in which way AKA the same shit from the 90s.

The portmanteau should be a dead giveaway that the number one priority of this job is building cooperation between these divisions. And often, it's not a technical solution.

Re: The Big DevOps Misunderstanding

#57

Post by anticristi »

Kind of weird to blame Kubernetes.

As long as the application team operates their application and the platform team operates their platform, I would argue that you do DevOps. It's just that one team consumes services from another team. Kubernetes just happens to be a damn good "API" between the platform and the application team.

Indeed, the application team is likely to build using code, whereas the platform team is likely to use scripts and configuration. But each runs the stuff they build.

Re: The Big DevOps Misunderstanding

#58

Post by OriPekelman »

jyrkesh wrote: post #26
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…

It wasn't necessarily the standard or even the majority, but we had that with Sysops whenever "the build team" or "the deployment team" was building self-serve tools. And I definitely agree with the article here that if you're using PaaS, you don't need a DevOps team. And there's certainly a better feedback loop there. But many will argue that PaaS _still_ isn't there yet for highly complex applications. Unless you g…

Evidently any PaaS has to have _some_ opinions on the kind of apps it is going to run. You trade some assumptions against magic (and time you won't spend on making decisions that are very possibly trivial). You could very probably design some pretty complex applications on any PaaS worth its salt.. as long as you accept its assumptions, opinions . But when you do you might very well end up with the only actually achievable form of the original DevOps. Weirdly if Devs actually touch Ops it's probably no longer DevOps ... just people being cheap and asking other people to have two jobs for the price of one...

Re: The Big DevOps Misunderstanding

#59

Post by marvinblum »

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…

Did it? I'm using GoLand and have exactly the experience you described. I can debug, rerun tests, terminal integrated, ... It's just a decision you took or someone else took for you.

I prefer to be able to fully run my application locally, with all databases required, and test everything on my machine. DBs and other tools like a simple SMTP server run in Docker, yes, but that's just a decision I took and I could easily run these tools without containerization.

Maybe I'm just in a lucky position to be able to decide this by myself, but I think we can get back there.

Re: The Big DevOps Misunderstanding

#60

Post by throwDec19 »

mrweasel wrote: post #15

> You build it, you run it While I do like that definition, it also means that most companies/organisation cannot do DevOps, as software development is often bought as projects, and operations is a recurring cost.

We get heavily clamped down on access to production by our auditors for Sarbane Oxley reason. Technically we aren't even allowed production data in our dev environment. I dont understand why any organization would allow it. Seems the tech world is still ripe to get sued.
Post reply on HN