Live data from Hacker News

DevOps is broken

blog.massdriver.cloud

191–200 of 363 posts

Re: DevOps is broken

#191

> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.

It's always been like this. I'm a backend engineer that also does cloud operations / systems administration / network engineering / "devops" work. The job titles have changed, but the truth remains: (most) developers want to develop, not deal with infrastructure.

Agreed. I get a rush from designing a system from the ground up and bringing it to life with all the infra, but only when that's necessary. If it's just a basic CRUD app without any major performance or resiliency requirements, I'm more than happy to do as little of that infra work as is necessary to get it into production and move on with my life.

Re: DevOps is broken

#192
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…

The extent of devops for your developers should be: 1. Push code to an automated pipeline 2. I understand that the automated pipeline may need input from me in order to run successfully. Beyond that, you need other people building the "platform" that they're deploying to (for the most part). Probably the ideal example here is Heroku. Your devs shouldn't be required to do all of the actual ops stuff. They need access…

Highly dependent on the product. Anything infrastructure related you’ll have a really bad time with that model

Re: DevOps is broken

#193

Earlier quoted context omitted.

>>the only alternative is to start making CPUs by hand Agreed. For some applications the cloud difference is significant; for many (most?) others though, "Cloud" is just rebrand of "Hosted". And even for more cloudy offerings, while I'm in a very specific and different part of IBM, some of the old timers/architects/powers-that-be keep trying to explain "We had that in 1969 !!!" :-D Agreed also at rewriting of history…

> My dad has been IT director and he chuckles when I talk to him about "new and exciting paradigms" which he of course sees as turning a circle to what they had in 70's and 80's :) As someone with 20+ years in IT, I agree - a lot of these "new and exciting paradigms" are not new at all. My personal favourite is how many large multi-nationals are now building in-house clouds? WTF is the difference between an "in-house…

> WTF is the difference between an "in-house cloud" and a shared-use datacenter from the 1990's?

Can't call a mainframe a bunch of buzzwords like "Hyper-converged, high availability, on-premise software as a service cloud platform".

Re: DevOps is broken

#194

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.

> There seems to be a correlation between unnecessary product complexity and unnecessary corporate complexity. That's Conway's law. "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." https://en.m.wikipedia.org/wiki/Conway%27s_law

Totally agree. The best succinct summary of Conway’s Law I've heard is “you ship your org chart.”

Re: DevOps is broken

#195

> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.

Where and how it runs can get incredibly complicated. It isn't a matter of not caring about where it runs, but having a finite amount of time

Re: DevOps is broken

#196
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 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.

That depends on the complexity of the development lifecycle, doesn’t it? If a single person can maintain it, having three different roles would mean unnecessary corporate complexity.

Re: DevOps is broken

#197

Earlier quoted context omitted.

I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code. There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and…

It just doesn't work for the most part. Maybe as an Ops person, I just want to do Ops, I don't want to have to understand your code, but Lambda has specific limitations on how long code can run for. I can't allocate CPU and Memory resources in Kubernetes without a deep understanding of the application. S3 has limitations on how files can be distributed and accessed. Integrating with CI gets complicated quickly and re…

This makes me wonder if ops allocating compute resources is really a good use of time if you're needing precise details of an app (which can and do evolve). This isn't a slam against ops, either, it's a knock against the tech itself that it forces all this incidental complexity on you.

Re: DevOps is broken

#198
DevOps is still a great idea, just like Lean and Agile are a great idea. But a great idea isn't enough. A million people have "great ideas" for businesses all the time. How many of those succeed? You can't just have a great idea, you have to execute really well on the great idea.

Most people don't know what DevOps is. Of the very very few that do know what it is, they are powerless to get other people onboard with the idea, because people are lazy and don't want to learn things or change how they work. Even if DevOps is great, if the executives in your company don't force it down everyone's throat with business policies, training, etc, nobody will ever actually do it, because nobody really wants to.

Platform engineering is not gonna solve what DevOps is failing to solve. It's just another silo. "Let's empower developers" sounds great. But developers still lack most of the knowledge to maintain a complex system. Give them a million super-powered tools and they will still screw things up. Most developers I meet today don't even understand the concept of DNS. That's not exaggeration - they literally don't understand how hostnames work, record types, zone delegation, authoritative records, ttls, much less propagation or transfers. And you want to, what, give them a fancy tool to change the system that they don't understand? You still need operations, in any business, not just tech. Somebody has to be paid to care about the boring shit that keeps the business working. There is no way to automate away that responsibility, in any complex system in the world. A platform eng team is just adding another team on top of the Ops team you will always need.

What would actually solve a lot of this - and nobody is going to like this - is boring-ass business management best practice from the 50s. W.E. Deming. Lean. Six Sigma. The stupid shit that MBAs nerd out over? That stuff works. High-performing businesses that don't just pay it lip service, but actually do PDSA, actually train their workforce, actually continuously improve their process, and make better business outcomes. But who among the tech nerds wants to listen to that? They just want to play with their toys and have no responsibility. "Build me a platform so I don't have to use my brain."

People have been studying businesses for the better part of a century. There is no easy way out of the morass. No single team or tool or paradigm will make things better. Until you consider everything, holistically, and put into place a barrage of different solutions, and actually teach people to do their jobs better, the actual outcomes of the work won't improve.

Re: DevOps is broken

#199

Earlier quoted context omitted.

>>the only alternative is to start making CPUs by hand Agreed. For some applications the cloud difference is significant; for many (most?) others though, "Cloud" is just rebrand of "Hosted". And even for more cloudy offerings, while I'm in a very specific and different part of IBM, some of the old timers/architects/powers-that-be keep trying to explain "We had that in 1969 !!!" :-D Agreed also at rewriting of history…

> My dad has been IT director and he chuckles when I talk to him about "new and exciting paradigms" which he of course sees as turning a circle to what they had in 70's and 80's :) As someone with 20+ years in IT, I agree - a lot of these "new and exciting paradigms" are not new at all. My personal favourite is how many large multi-nationals are now building in-house clouds? WTF is the difference between an "in-house…

  “There aren’t any new problems. Just new engineers”
  - A sig I read a long time ago

Re: DevOps is broken

#200

> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.

I absolutely care where and how my code runs. And yet I don't give a damn about writing terraform, managing IAM, VPCs, keeping up with backups, upgrades, etc. I want specialists who know what they're doing to deal with that stuff.

I'm also not convinced that the average junior or mid level application dev needs to know where or how their stuff beyond some high level concepts (i.e. our app uses auto scaling).

Post reply on HN