Live data from Hacker News

DevOps is a culture, not a role

dev.jlelse.eu

71–80 of 139 posts

Re: DevOps is a culture, not a role

#71

I've seen two prevalent definitions of devops: 1. It's a culture where dev and ops work together (as per TFA); 2. It is the application of software engineering practises (such as version control and test automation) to ops. I prefer the second definition because it's the only one that's got anything to do with new developments in infrastructure-as-code and isn't just a new name for what competent teams were always do…

> and isn't just a new name for what competent teams were always doing anyway

That's interesting. I see that the opposite way: weren't competent ops teams already doing the things you listed in #2? Does keeping up with new developments in operations tooling need a new name? Shouldn't that just be part of doing ops well?

Re: DevOps is a culture, not a role

#72
post #34

Earlier quoted context omitted.

And how these affect operator's workflow? That is, the ways an operator interacts with the tools? The facts that Java is garbage collected or that it runs on virtual machine don't fundamentally change how programmers write code in it compared to e.g. C++. It's the same type of tool ("paradigm"). Erlang, however, is substantially different.

You are comparing apples to oranges (in my opinion of course). I would say it's often hardly about just "operating" the machine. You need to know how the machine works how it can affect other machines and what can you do if parts of the machine break. Not only that but also how many operators you can find, how many additional modules (libs) are there and how often you need to oil the wheels. Sure the implementation o…

> I would say it's often hardly about just "operating" the machine. You need to know how the machine works how it can affect other machines and what can you do if parts of the machine break.

So, in terms from programming analogy, you need how your runtime operates, how it can affect neighbour processes/services, and what can you do when the runtime breaks down. This still does not affect how you structure your code (at least usually, when you don't work closely with the OS, which I bet is majority of code in the wild).

> Not only that but also how many operators you can find, how many additional modules (libs) are there and how often you need to oil the wheels.

How does workforce availability affect the way you work with your system?

How does availability of libraries affect the way you work with your system, apart from amount of code for you to write (libraries have to come from somewhere)?

The architecture and strategies stay exactly the same. With this regard, there's very little difference between CFEngine, Puppet, and Chef.

> Sure the implementation of the known algorithms will be similar in Java and C++ but the overall usage and how it connects with everything (aka the workflow) will be very different.

It will hardly affect how you think about the system and how you approach it. It will only affect where you get your code from. Unless you think about yourself as a guy who only puts together different libraries/modules and never ever writes own code, then of course it's a new paradigm, but I don't think you had this scenario in mind.

Re: DevOps is a culture, not a role

#73

Yes yes, we get it, it's a mindset not a role. Now could we hire a DevOps guy to setup that CI/CD pipeline, ChatOps stuff, Kubernetes and dev/staging/prod flow so the coders can ship. ;) The original thought was beautiful but the way I see it: DevOps is a branch where you specialise. After school people might learn front/back/db stuff and then specialise to "DevOps stuff" -- or then you have more sysops kind of peopl…

I hate specialization, and I want the person who develop something to think about how that stuff will be deployed and kept online. In particular, some tradeoffs have to be made between the development side and the production side, and I want the same person to see both side and decide with a technical criterion (or just choose one option, and later reverse course and change it), not on a "it's not my problem" criteri…

There is too much. It's specialization out of necessity. I know enough "DevOps" to be dangerous, but in addition to having a deep knowledge of our product's codebase, the multiple features of our product, configurations, etc. there are not enough hours in the day to master (not simply be familiar with) Jenkins pipeline, Docker, AWS, Ansible, Zookeeper, etc, etc.

99% of the people who could claim to have knowledge of all the above in their organization either have a very shallow (read: not useful) knowledge, OR their product itself is simply the gluing together of various DevOps technologies listed, so there is little more to know outside that.

Re: DevOps is a culture, not a role

#74
post #42
post #31

Earlier quoted context omitted.

> In 2017, there's literally _no_ difference between the outcomes expected from a "Systems Engineer" and a "DevOps Engineer" I don't find the title 'Systems Engineer' to be in widespread usage at tech startups in SV, so I'm not sure what to expect from one. To be honest, I would expect Systems Engineers to be working on hardware. The infrastructure automation work done at modern tech startups is best described by the…

"Systems Engineer" seems to be an overloaded term. In the area I work in (applied R&D, East coast) the role is a mix of the software architect and QA, but encompassing both hardware and software. Some science background (whichever science is relevant to the project) but mostly a lot of experience in general engineering practices (what generally works, how things break, what is sufficient to test to feel good that a u…

I've also heard "Systems Engineer" used as a synonym for "Sales Engineer". That term is too overloaded to be useful.

Re: DevOps is a culture, not a role

#75
post #61

First, let me say I totally agree with the premise here--that all parts of a software engineering organization need to be on board with DevOps, buying in to the vision, learning the full stack, taking responsibility. However, this article does serve as a good example of one of the big problems with most DevOps/SRE evangelism: It's usually coming from the Dev- perspective, rather than the -Ops perspective (or better,…

Speaking as someone who once had to patch up a legacy system, I appreciate items 1, 5, 8 and 10 far more than I did before.

Number 11 is championing 1, 5, 8, and 10, to management and other developers. Number 12 is stealing developer time for 1, 5, 8, and 10.

Re: DevOps is a culture, not a role

#77
post #47

"DevOps Engineer" is simply just title inflation. In 2017, there's literally _no_ difference between the outcomes expected from a "Systems Engineer" and a "DevOps Engineer" - both are expected to produce HA, Automated, Well Documented Infrastructure, to allow developers to run their code. Anyone not doing that is just a _bad_ "Systems Engineer" Developers don't call themselves "Agile Developers" because they started…

> both are expected to produce HA, Automated, Well Documented Infrastructure, to allow developers to run their code Wait have I been using the wrong definition? I thought DevOps were devs that also setup/maintain their own infrastructure

Yeah, please stop using that definition immediately. It's incredibly unhelpful, and just encourages management to understaff.

Re: DevOps is a culture, not a role

#78
post #43

Earlier quoted context omitted.

It is not the engineers that call themselves 'Devops'. It's the recruiters and managers. Every engineer that I know that holds the 'Devops' title hates it, but has no choice in it.

I've observed this, but it depends on experience level. Folks with <5 years experience, tend to enjoy the DevOps portion of their title. Whereas, neckbeards with a deep background tend to dislike it.

That is because DevOps is basically what 'a good sysadmin' always did, only now it has a title, and those in the sysadmin role now 'don't have relevant experience' because 'devops' is not on their resume, and 'systems administrator' has been re-associated with 'server tech' as a result..

Re: DevOps is a culture, not a role

#79

Earlier quoted context omitted.

As a relatively old guy, I always thought that DevOps was just the new name for what people have always been doing. It is literally just now that I've realised that other people think it is different :-) Possibly younger people don't understand what system administrators used to do...

"Possibly younger people don't understand what system administrators used to do..." System Administrators used to blame developers. Developers used to blame System Administrators. Devops is in part an attempt to mediate between "silos".

Bad System Administrators used to blame developers. Bad Developers used to blame System Administrators. Real Systems Administrators attempt to mediate between "silos".

therego...

Re: DevOps is a culture, not a role

#80

Having worked on over 100 DevOps initiatives, I'm inclined to disagree. 8 years into DevOps, automation, cloud computing etc, it's time to accept that DevOps is a specialism and a function that companies - especially big ones - need to put into place in order to adopt the principles. See here for further thoughts - https://devops.com/im-happy-devops-engineer-job-title/

If you have the job title "DevOps X", then you've missed the point of DevOps. The entire thing was brought in to remove the silos between SysOps and Dev. If you have people in the "DevOps" role, then you've just created a new silo, which means you just have traditional SysOps with a new and fashionable, but less meaningful name.

You are conflating bad sysadmins with systems administration itself, and blaming bad cultures (typically managment driven) on the employees..
Post reply on HN