Are You a DevOps Engineer If You Aren’t Writing Code? | Hacker News Reader

Are You a DevOps Engineer If You Aren’t Writing Code?

blog.boot.dev

28 pointswagslane19 comments

This blog entry is an advertisement for boot.dev's backend training product.

Author here, I prefer the term "content marketing" xD

Jokes aside, there is a small plug at the end of the article, but the article itself is not an ad. I have a lot of thoughts on the current state of "DevOps" and enjoy writing about it

Includes a small ad (as well as free alternative resources) but the article isn't just that.

what even is devops in the first place? Like is it just IT for deployments with a bunch of management lingo tacked on?

like how are there people in the industry working on this sort of thing who can't code?

It just bugs me, I talked with someone from work whose job title was System Engineer; I asked them if they do systems programming or something... and they said they don't know how to program (even after getting some kind of tech degree!!)

I'm still trying to figure out if there's a difference between DevOps and SRE.

There is and isn't. SRE is Google's more strictly defined DevOps, basically - after DevOps started to get slapped across everything (classic sysadmins, CI/CD tooling people, etc.), Google came out with something that basically defines, more narrowly, something very similar to the DevOps role (as originally intended), in a lot of detail.

There is a slight difference in focus though, because DevOps also focuses on the role's interactions with development, while SRE focused on the role itself and using metrics and data to be able to do the work required (SLOs, etc.).

I personally prefer the SRE term, because it's usually better understood and has a narrower meaning. DevOps can mean a lot more different things.

> what even is devops in the first place?

Cloud engineer. Must write Cloudformation templates if AWS, know many resource types and properties, know linux and networks. Python is a plus for fringe cases automation, when there is no clear cloud vendor solution.

PS: Did not read TFA

I spoke to another person calling themselves 'Full Stack Engineer", but couldn't even explain the OSI model.

What's your point? Titles rarely match competences and responsibilities.

The “stack” in full-stack engineering used to refer to the software stack, not the network stack.

The old-school eponymous LAMP stack used to be Linux, Angular, MySQL, and PHP. You wouldn’t necessarily have had to have known the OSI model to be proficient in those technologies.

s/Angular/Apache/

LAMP was a term from the 1990's.

And the stack is still used today by plenty of people around the world, what's the problem?

Is that really a relevant question? A full-stack title usually means web front-end, mobile, web back-end (or API), and database. Its a generalist title. You work mostly with HTTP, but even then an API framework may hide that.

If you're deploying to a PaaS you may never care about or notice lower layers. If not, your team may have a specialist (DevOps, platform engineer, network engineer) who manages network configuration, DNS, load balancer, connection pooling, firewalls, VPN, and other details.

I mean, in full stack engineering (from my exp) you work primarily with rest and don't ever make use of lower level networking details.

maybe it's different for someone working in networking or a more specific subfield. It might've been different in the past, idk

a sysadmin who codes, or a programmer who has learned systems.

it was supposed to be a culture and set of tools to close the gaps between developers and operations but its more building automations that make ops disappear because docker hard or some other nonsense.

deployment in a microservices environment is absolutely more difficult than in a monolithic environment.

That's the entire thing, the complexity moves into the orchestration.

95% of companies can solve all their DevOps problems with code that’s already written on GitHub.

The trick is finding the right code, and making it work with the rest of the system.

I'm pretty sure if you take a year, you can evaluate enough repos to find one to match your circumstance.

Or, take a week and slam it out.

The trick is deploying that code repeatably to production with IAM/RBAC, Code Scanning, monitoring, alerting etc.. Most companies suck at that.

Reply on news.ycombinator.com