Live data from Hacker News

DevOps is broken

blog.massdriver.cloud

331–340 of 363 posts

Re: DevOps is broken

#331

Earlier quoted context omitted.

I think the difference is the interface. The interface to the shared-use datacenter, if you're lucky, is a spreadsheet that declares the static resources you own and a remote hands guy that can tackle things beyond the capabilities of your remote KVM. If you need more capacity you need to work with the datacenter folks to order physical machines that might show up in a few months. The interface to the in-house cloud…

I still think that's a bit "rewriting the history". E. G. Vmware enabled fast self-provisioned VMs and nobody called them cloud. Heck in 1999ish or so, while at university and way before I was an IBMer, I could sign up to some ibm development program as a student, get an account, and provision Linux VMs on mainframe. Not to say your scenario isn't valid and real, but I live that scenario every day today with in house…

> Vmware enabled fast self-provisioned VMs and nobody called them cloud

Because it’s missing all the glue. I need to self-service the VMs, the database, the load balancer, the dns records, certs, and hook them all up so I can receive production traffic all via an API I could theoretically do in Terraform.

Re: DevOps is broken

#332

Funny, I thought DevOps was introduced as a way of having the specialists be part of the same team, so that the dev side would keep ops in mind and the ops side would be getting dev help in automating. Creating a separate DevOps team seems like a manager reading an article and implementing without understanding. The problem in a lot of orgs is having various priesthoods that have their own goals that aren't aligned w…

> Creating a separate DevOps team seems like a manager reading an article and implementing without understanding.

You need more than one specialist because they need to be allowed to get sick and take vacation. And once you have multiple dev teams it’s not economical to staff each team with multiple expensive specialists. So you put them on their own team and structure it organizationally so the devops team is an extension of every team. The devops team keeps up with all the work every team is doing and reacts accordingly as well as being a resource each team can tap.

Crucially, you don’t put any kind of ticketing system or similar in between.

Re: DevOps is broken

#333
post #36

Well, to be fair, most of the engineering is bullshit.

Software. Not engineering. Software. "The best minds of my generation are thinking about how to make people click ads." https://quoteinvestigator.com/2017/06/12/click/

yes, yes, absolutely. Sorry for not being explicit.

Re: DevOps is broken

#334

Earlier quoted context omitted.

"Sysadmin" got rebranded as "DevOps", because "techsupport" got rebranded as "sysadmin".

Yerp. As a former *nix admin, around the time that "DevOps" became a term, I read it as "system administrator, who also now has to fix developer code." Which, honestly, was already part of the job at a lot of places I've worked, owed to the age old problem of people who "test" something on their weird personal desktop environment, then hand it off and shrug off any questions with "well, it works on my desktop". That…

It’s a tough place to be when the bar is perfection

Re: DevOps is broken

#335
post #284
post #114

Over the last ten years, the market has tried to kill off the hardware, systems, network and security people, and mostly succeeded. As a result, it's relatively easy to find someone who advertises as "full stack devops" who has never actually operated any infrastructure more complex than a LAMP webserver cluster. And it's hard to find a senior sysadmin who has enough years of experience to understand and troubleshoot…

Based on my own experiences, one of the most disappointing elements of devops is their lack of understanding how things work. They run to GitHub and pull other peoples recipes to build out certain environments. Even when they build automation from scratch, they miss tons of core OS level tunables and rather than adjusting those, they'll just add more servers to the mix. I worked at a place that had an elastic search…

You could replace "devops" in your first paragraph with "developers" and it would still make sense. Everybody is out there grabbing stuff from GitHub and shoving it into their projects. Most technical folks today don't really know how a computer works, they poke at it until it does what they want and call it a day.

And I would say that your specific example is a failing of that team, not "DevOps" as a whole.

Re: DevOps is broken

#336
post #221
post #17

I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…

I don't understand how seemingly 90% of developers, can't do anything outside of their narrow scope of experience. Writing a shell script? Throw a temper tantrum, that's devops job! Have to work with legacy code? I can't believe this! Especially seniors and beyond. They force leetcode interviews they somehow pass or are grandfathered through and gatekeep "trash devs" by slamming gotchas about how the whiteboarded cod…

To be fair, shell scripts are pretty horrible to write and maintain from a programmer's point of view. They're good in that they're portable, but they're not a good programming language. I don't object to writing them, but I'd rather there be an alternative.

Anyway, it sounds like you've worked in some really shitty companies / shitty people.

Re: DevOps is broken

#337
post #220

Earlier quoted context omitted.

I think it is because of what is described through Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.[2][3] — Melvin E. Conway The problem isn't necessarily software itself, but how we organize people (more than 2 or 3), how we communicate, how we mirror opera…

Small teams have honestly always been successful to the flaw that they outgrow themselves constantly in my experiences.

Small teams can be super productive, but unless the people in it are there for the full run of a product, you'll end up with a problem; taking over the work for one developer will take more than one developer.

I'm sure - but haven't witnessed this myself yet, so take it with a grain of salt - that if one productive developer builds an application in a year, it needs a team of 5-10 to continue development at a similar level, and even then it may not make it.

Companies need to focus on keeping software as simple as possible, well documented, and transferable. Unfortunately this also means curbing people's enthousiasm.

Re: DevOps is broken

#338
post #317

This echoes the philosophy of Google Site Reliability Engineering, which (this is key) is an engineering discipline. The job of DevOps is not to close tickets. That'd be like driving a car by shouting directions at someone lying on the floorboards holding a wrench to the steering pinion. The job of DevOps is to build a steering wheel (and ideally, teach SWEs how to drive... at least enough that they understand what a…

Well they explicitly use the term SRE and not DevOps and I think that's very intentional and related the gist of the article. DevOps was never meant to be a role played by a person or a team. It's meant to reflect aligned incentives of dev and ops. Whether you have an SRE team or a platform team or a bunch of kitchen sink teams.

I much prefer the SRE distinction, it gives more focus and especially combined with the book and other materials, a much more professional workspace.

You want us to run and manage your software? Sure, here's a checklist of what it has to conform to. Oh it's unstable? We will no longer run it for you, here's the pager back.

Re: DevOps is broken

#339

I'm not sure if having two teams is always going to be better than having one DevOps team, but my experience in having two teams is that it's rare to have the incentives aligned. The author of the post pointed out that dev teams will cut corners and throw broken applications over the wall to ops to deal with. When ops gets woken up at 2am because someone in dev cut corners, what happens? Does dev feel the pain? Almos…

Reminds me of that time when my team was called into a meeting where the CTO "advised" us that "code does not have to be perfect", when all we wanted to do was review the code for a PoC that we were ordered to "own" and deploy to production (even the creator said he cannot guarantee the code he copied from Stack Overflow for the PoC is production-ready).

In the same meeting, the CTO was ranting about the instability of a service (which was also a PoC that was pushed to production before we were _also_ made to "own" it, yet never given the budget to even get acquainted to the codebase), claiming the reason for that because we devs are lazy and unprofessional.

I highly doubt making people who _responds_ to the incentives to "feel the pain" will fix much. I suspect things are more likely to get fixed if the people who _creates_ the incentives are the one "feeling the pain".

As they say in Hunger Games, "remember who the real enemy is".

Re: DevOps is broken

#340

Earlier quoted context omitted.

> I don’t hire devops, I hire infra engineers, build engineers, release engineers and: backend engineers. This is a great way to do it. There seems to be a correlation between unnecessary product complexity and unnecessary corporate complexity. Being direct about roles goes a long way towards simplifying corporate complexity.

Roles are muddy because life is muddy...and because people can do more than one thing at a time. Also because save for a few roles, businesses rarely need people 100% allocated to one role or task. Responsibilities are nice, and job titles mean people mostly do x or y. My favorite example is that of a restaurant. You hire waitors, diswashers, bartenders, line cooks, prep cooks, hosts and hostesses, and managers. And…

Communication with the other roles you work with is key though in that case, otherwise you'll have chaos - e.g. because the waiters don't know that the bartender took the table, or because the cooks need things the next morning that aren't where they're supposed to be.
Post reply on HN