Hacker News new | ask | show | jobs
by itslennysfault 1519 days ago
DevOps is a methodology.
2 comments

I think you're mistaken. DevOps is a very specific team allowed to touch the Jenkins box, and is the old branding for what is now SRE which are both just rebranded names for Systems Administration, but with Cloud certifications instead of Cisco and Dell.

I kid. But this is just as much the meme I've encountered as Agile. Some successful company releases a book about something they do that's fundamentally different, and almost instantly enterprises across the globe have a department for that thing with that name. Progress.

SRE jokingly stands for "SysAdmin, Really Expensive"
Real SREs are great. Who wouldn't want a Systems Engineer that codes and can interrogate kernel issues or a Software Engineer capable of writing their own compiler running your operations?

Most companies, even if they hire these people, don't know how to use or listen to them though. What usually happens is they get lumped in with a bunch of Application Operations folks and it sours the idea entirely.

Yeah, this. There's a gulf between people like Brendan Gregg (my go-to example of a "Real SRE") and those I've actually worked with, who anointed themselves with the same title...

As a side-note, is any tech group more keen on title inflation than SREs? In the time I've been a developer / software-engineer I've seen sys admin, DevOps, Cloud Ops, SRE... it's literally the same people.

> As a side-note, is any tech group more keen on title inflation than SREs? In the time I've been a developer / software-engineer I've seen sys admin, DevOps, Cloud Ops, SRE... it's literally the same people.

That's not the fault of people doing the work, that's what the industry is doing to us.

I get increasingly irritated with the myth that 'DevOps' are any different than the sysadmins of 10 years ago.

"But DevOps can code", yes, so could sysadmins, in fact, terraform, ansible, vagrant, saltstack, chef, puppet etc;etc;etc are all made by people who held the title of sysadmin when they were written.

In fact the term "DevOps" was originally from a conference, where the idea was that "we can do systems administration in an agile way" -- NOTHING to do with coding, everything to do with getting developers and sysadmins working closely together in an iterative fashion.

I would personally be very happy being called a sysadmin, but doing so is career suicide, because we as an industry have decided that sysadmins are somehow braindead, and that you really need "SREs" or "DevOps" -- despite the fact that these are the same people.

What gets my goat even more is that people hate on sysadmins because of corporate culture, echos of centralised IT organisations that said no to everything.

But we're doing exactly the same thing with these new titles now. It's a joke.

Your comments really come off as bitter. I think this maybe just says more about the companies you've worked for than anything else. SRE is a methodology and a pretty-well understood methodology at this point.[1] The actual title is less important than the practice. It also goes by different names at different companies, example at FB it's called Production Engineer.

By the way Brendan Gregg is a Performance Engineer not an SRE. I believe that's been his title for close to 20 years, according to the the bio in his books. I don't believe he has ever had the title SRE.

[1] https://cloud.google.com/blog/products/devops-sre/how-to-sta...

> Your comments really come off as bitter.

That wasn't my intent. I have done my share of DevOps, it's not for me. Maybe SRE would be.

> I think this maybe just says more about the companies you've worked for than anything else.

Yes, it does :)

> The actual title is less important than the practice. It also goes by different names at different companies, example at FB it's called Production Engineer.

Absolutely. I'm just saying that I've worked with people titling themselves SRE who aren't doing the stuff of that methodology. When last years DevOps team starts styling themselves as SREs but nothing else changes, then they have definitely missed the point about the methodology being the thing that matters!

It's not just those teams, of course! There are plenty of "fullstack engineers" who wrote a Node function one time.

> By the way Brendan Gregg is a Performance Engineer not an SRE. I believe that's been his title for close to 20 years, according to the the bio in his books. I don't believe he has ever had the title SRE.

This seems to be true, but he's spoken at SRE events on "my SRE work at Netflix".

Well, I was trying to clarify this statement from OP:

> DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issue tracking and the CI/CD.

It reads to me like this: "We don't use DevOps features in Gitlab, but we use CI/CD pipelines in Gitlab". So it is contradicting. As they responded, CI/CD is a subset of DevOps methodology.

I've used Gitlab and didn't know there were more DevOps tools other than their CI/CD features and runners.

I am still slightly confused.

DevOps is whole set of tools. Gitlab includes features like monitoring, code scanning, Kubernetes integration, docker registry, cloud security and protections. And those are $1188 per year per person. By CI/CD I mean good old Jenkins that runs on a computer in the office that builds iOS Apps and uploads them to Apple AppStore (of course current generation of CI/CD is much better). Gitlab CI/CD and runners were there much before this "Gitlab is the one DevOps platform" saga.

Everyone in our company including HR, marketing, design people were also using Gitlab for task tracking. Therefore we need those fancy issue tracking features for better management. This features are in the tier that $1188/year per person. For the features we don't use is not something that we could afford.

Ah got it, thanks. I wasn’t aware that they’ve built all this stuff.
I thought the OP was maybe referring to Gitlab's "AutoDevOps" features which were introduced a few years ago. From their site:

>"GitLab Auto DevOps is a collection of pre-configured features and integrations that work together to support your software delivery process."

I remember upgrading a Gitlab instance at that time and ended up with an issue that was the result of the AutoDevOps feature set. It seemed that AutoDevops was turned on by default. My issue was easy to resolve but I remember thinking at the time it was rather opinionated.

[1] https://docs.gitlab.com/ee/topics/autodevops/