Comment by StevePerkins | Hacker News Reader

Comment by StevePerkins | Hacker News Reader

Parent Full thread

The name and job title churn in this space over the past five years is breathtaking, almost JavaScript-ian.

I've been at my current company for 6 years now. When I first started, those guys were "Operations", and the job title was "Admin". We used Google App Engine, and they mostly clicked buttons in the GCP web console.

One year in, they re-branded as "DevOps". They were all "DevOps Engineers". They wrote a lot of hacky Python scripts, using the "gcloud" utility, to manage our new Docker-based services on Google VM's.

A year or two later, they decided to become "Platform Services". They changed their titles to "Platform Engineers". They saw us developers using Jenkins for our CI/CD pipeline, and decided to re-implement all of their Python scripts as Jenkins jobs.

Earlier this year, they became "The SRE Group". They are "Site Reliability Engineers" now. We eliminated their Python scripts, by migrating our microservices to Kubernetes and using managed databases. So now they're back to clicking buttons in the Google Cloud Platform web console again.

You speak of them with such disdain. Is that a common attitude in your company?

I can understand such disdain. I am a software engineer currently working in a DevOps team (yes, team, you’ve heard it right). I’d say that 90% of DevOps engineers I’ve met don’t even know what a linked list is, and they themselves talk with disdain about developers.

So much for DevOps philosophy.

I wouldn’t mind so much if they at least knew what terraform was.

if they at least knew what terraform was

Any real, experienced DevOps engineer will reply “a steaming pile of shit”.

Sure, it's got its problems, but please show me a better alternative.

On AWS, Boto. On Azure, DSC (Powershell) and ARM templates.

You will need to maintain separate TF codebases for each one anyway, but with the native solutions you get easy access to all features of the platform and don't have to spend most of your time jumping through stupid hoops to try and pretend that one tool can do everything.

No-one would write code worrying if it was valid in both Java and C# but that is the same level as what TF claims to do. It's complete shit, ditch it and you will be 10x happier, I guarantee it.

Sounds to me like using a single tool instead of a bunch of separate ones with different functionality is a win to me, but we are each entitled to our opinions.

Boto doesn’t seem comparable to terraform at all, unless you enjoy building state management yourself.

Terraform has been better than anything else I’ve tried so far.

They are worthy of disdain because they never took a CS class?

No one is worthy of disdain due to unfamiliarity. I have explained why a software engineer that cares about the infrastructure might feel disdain after reading about and agreeing to the DevOps philosophy and switches to a DevOps role only to find out that the vast majority of new teammates lack comprehension of the most basic software engineering principles and don’t find value in them. It is incredibly frustrating.

Now, it is also true that most developers are just content with clicking around in their Jetbrains IDE without bothering about resources or even knowing what a file descriptor or system call is. Those so called senior Java engineers that I had to explain the basics of garbage collection to them. Those also make operations harder than it should be.

But that’s another story. We’re taking about the dissonance between what gets advertised as DevOps and what truly is, which seems to be the norm in our industry and is leaving a significantly amount of people unhappy and dissatisfied.

I’m a developer who runs an infrastructure team. Have for years. And most developers I know don’t know why you’d log in JSON unless I was the one to explain it to them (patiently, while remembering the times they acted frustrated at my guys for not doing all the magic and just some).

So much for DevOps philosophy, indeed.

Have to agree with the comment below, DevOps folks/teams I've worked with seem to have both a superior attitude and an inferior knowledge of good practice and good habits when compared to developers.

They seem to have bought into their own myths.

Gee, I don’t know. When developers are constantly flinging half-tested and wholly unoperationalized things over the wall, perhaps it’s normal to develop local-maxima defensive practices.

I am a software developer and yet when I hear a developer open their mouth to complain about nearly any other aspect of a product team, be it QA or infra or UX, it has this weird tendency to resolve to Anybody But The Developer causing an issue.

Then perhaps you ought to sit with the folks I'm consulting for at the moment, who have a DevOps team who have failed to deliver a reproducible system for over two years and still have the attitude that they're the superior race.

I’m sorry to hear that, but have you considered the possibility that the team you work with is not emblematic of the entire industry?

Indeed, that's just my current experience.

That said, they are highly paid, London financial world folks, so you'd hope they'd be good.

I also hear from a developer I work with who has recently defected back from devops style roles to devs that this is not atypical. He seems to place blame at least partially on "The Phoenix Project" for the attitude!

> You speak of them with such disdain.

Nonsense. They're smart professionals, and probably the hardest workers in the company. Certainly the ones subject to the highest degree of pressure, which they always handle with grace.

I "speak" of the absurdity of our industry's superficial hype cycles, and forever-swinging pendulums. After you've been in the game for 20+ years, you will recognize a number of cycles and pendulums yourself. You'll go along with it, because that's part of being a professional. But you'll wonder why we're collectively unable to step back, and recognize more of these things, and not pointlessly churn so much.

However, I could write a similar comment about engineering managers and SDLC methodology trends. A similar comment about testers and quality assurance. And yes, probably a dozen similar comments about language fads and architecture patterns and trends related to developers.

I don't think any of those comments would come from a place of disdain for workers themselves. I just think that culture has shifted, and anything short of unqualified gushing praise registers as offense for many younger people. Maybe that pendulum will swing again too?

I'm pretty sure SRE is a very old title at google.

I love the incredibly vague job title "Member, Technical Staff" I had at Sun. It could cover anything from kernel hacking to HVAC repair!

At least I had root access to my own workstation (and everybody else's in the company, thanks to the fact that NFS actually stood for No File Security).

[In the late 80's and early 90's, NFSv2 clients could change their hostname to anything they wanted before doing a mount ("hostname foobar; mount server:/foobar /mnt ; hostname original"), and that name would be sent in the mount request, and the server trusted the name the client claimed to be without checking it against the ip address, then looked it up in /etc/exports, and happily returned a file handle.

If the NFS server or any of its clients were on your local network, you could snoop file handles by putting your ethernet card into promiscuous mode.

And of course NFS servers often ran TFTP servers by default (for booting diskless clients), so you could usually read an NFS server's /etc/exports file to find out what client hostnames it allowed, then change your hostname to one of those before mounting any remote file system you wanted from the NFS server.

And yes, TFTP and NFS and this security hole you could drive the space shuttle through worked just fine over the internet, not just the local area network.]

Considering yall ran sendmail, I had root on your workstation if i wanted it :) it was a different world then.

When the Morris worm went around, one of the ways it got in was through sendmail, using the "DEBUG" command. Right after it happened, some wise-ass sent around an email telling everybody to edit their sendmail binary (with Emacs of course), search for "DEBUG", and replace the "D" will a NULL, thus disabling the "DEBUG" command.

What that actually did was change the "DEBUG" command into the "" command.

At the time I was running a mailing list from the University of Maryland, and often had to check Sun email addresses by telnetting to sun.com port 25, pressing return a couple of times to flush the telnet negotiation characters, then going "EXPN some-email-address".

So the day after the Morris worm, I go "telnet sun.com 25", hit return a couple of times, then "EXPN foobar", and it dumps out a huge torrent of debugging information, because I had accidentally switched it into debug mode by entering a blank line!

I reported it to postmaster@sun.com, and they fixed it. But it's kinda silly that they would have applied such a ham fisted patch to their sendmail demon like that, based on an email that some dude on the internet sent around!

https://www.rapid7.com/db/modules/exploit/unix/smtp/morris_s...

http://www.cs.unc.edu/~jeffay/courses/nidsS05/attacks/seely-...

https://spaf.cerias.purdue.edu/tech-reps/823.pdf

Reply on news.ycombinator.com