Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Big DevOps Misunderstanding

wolfoliver.medium.com

Post reply on HN
Print view View original

231–240 of 321 posts

Re: The Big DevOps Misunderstanding

#231

Post by StreamBright »

thamer wrote: post #111
StreamBright wrote: post #70

Earlier quoted context omitted.

You are on the right track. I have exactly the same story, data engineer, working on automation a lot. YAML, JSON and HCL should be purged from IaC asap. Luckily Dhall can be integrated everywhere we need YAML otherwise we would go nuts. The bigges failure of k8s is to understand that YAML does not scale to teams and beyond 100 lines, especially not good to nest it (hello ArgoCD). A type safe not accidentally Turing…

Dhall or other typed languages like Cue definitely help a lot. It seems to me that the only acceptable amount of YAML you could have in deployment config is for a setup small enough that it doesn't warrant using Kubernetes, so any use case where Kubernetes is a good fit quickly becomes a major pain to maintain. That said, you wrote: > drop k8s like its hot [...] We have phased it out everywhere we could. Could you el…

AWS Lambda, EC2, Nomad, depending on the usecase.

Re: The Big DevOps Misunderstanding

#232

Post by ghosty141 »

solatic wrote: post #218

Ayyy, even the author gets it wrong. DevOps is not about letting developers own services in production. This is the common misunderstanding that has lead to DevOps teams be platform teams. DevOps is about helping separate Development and Operations teams work better together so that the organization, which needs both, can benefit from their harmony. The simple fact of the matter is that the modern stack is too big .…

Exactly, this is a huge problem.

A lot of developers are exactly that, developers. Sure if you have somebody who is very motivated he might know a thing or two about DevOps etc. but hiring becomes almost impossible if you expect a candidate to be a good developer + a good knowledge of devops.

It's just too much to handle for one person.

Re: The Big DevOps Misunderstanding

#233

Post by Fiahil »

cortesoft wrote: post #143
Fiahil wrote: post #136

Earlier quoted context omitted.

I worked with a client and a devops team before, I still thinks having a separate devops team is not the right approach. In my case, the team « responsible for creating and maintaining the tools and processes that allow the dev teams to manage their systems in production », was just a regular OPS team. So they built tools that were not working properly and they struggled to focus on the most valuable parts because th…

This makes sense for a smaller org, but what do you do when there are dozens of dev teams? You can try to make every team a full stack team and have a devops engineer embedded with every team, but you will end up with a different process and set of tools for every team. I feel like having a dedicated devops (or tools or platform or whatever you want to call them) is needed in a large org.

I do work with large orgs almost exclusively. I have no problem with individual devops engineers going back to their team after X weeks or at the end of the project. This way they can integrate avances with other teams and share knowledge.

I just don't want them to stay in their ivory tower and keep breaking my balls with their broken terraform templates.

Re: The Big DevOps Misunderstanding

#234

Post by pas »

solatic wrote: post #218

Ayyy, even the author gets it wrong. DevOps is not about letting developers own services in production. This is the common misunderstanding that has lead to DevOps teams be platform teams. DevOps is about helping separate Development and Operations teams work better together so that the organization, which needs both, can benefit from their harmony. The simple fact of the matter is that the modern stack is too big .…

Letting/making devs own the services they deploy/develop is not the full picture, nor is it a real goal, but still it sums up the problem and solution space concisely.

Yes, specialization is a must for productivity, but that's a given already in the old model. What the DevOps effort tries to cut through is the trust barrier between the two. Sure, it's communications engineering too, but it's easy to weasel out of any real change with that phrasing.

Re: The Big DevOps Misunderstanding

#235

Post by pas »

autophagian wrote: post #7

I've also become a little disillusioned with the 'DevOps means developers create their infra/deploy their applications' mantra too, especially when you see several years of accumulated infrastructure spun up by developers that don't really care about its quality. Then again, having a dedicated ops team can lead to siloing and learned helplessness on the part of devs too. It's a bit cyclic.

If they don't care about the quality ... do they suffer from it when its problems and enjoy its fruits? It seems they either don't have the time/resource/ownership/change budget to make it better, or the team is so dysfunctional that they need to be pumped full of new blood from top to bottom. stat.

Re: The Big DevOps Misunderstanding

#236

Post by gravlaks »

hodgesrm wrote: post #40

> This trend is also supported by Kubernetes as this is a technology which is hard to master. So people start splitting up responsibilities again. One part of the team developing the application the other part of the team managing the infrastructure. Kubernetes administration is hard to master. It's analogous to running VMware in production, or any cloud technology for that matter. None of them is easy, and they all…

Yeah I don't really get the hate on Kubernetes. Run it managed with EKS, GKE or similar, set it up with the needed controller (ingress, external secret, whatmpt). The development afterward is as you say straight forward.

Re: The Big DevOps Misunderstanding

#237

Post by pas »

nimbius wrote: post #209

seems to me the real point of devops was employers trying to mash together two expensive categories of labor in a desparate effort to control overhead in a nation that spent 40 years prioritizing blind consumerism, reality television and talent shows over public education and STEM. mashing together devs and ops inevitably results in schisms of devsecops and netops and ^ops because developers have enough shit to worry…

yes but no. the problem was that in mostly big financially privilegized companies both ops, dev, net, itsec were it's own little fiefdoms. and there was no incentive to get shit done. because that would have required working with the enemy. that gets you nowhere on your way up the corporate ladder in your guild.

lack of education never helps, but it's laughable to point at that as a serious causally significant factor. outsourcing, communication barriers, trust barriers, organization barriers, ossification of the business structure led to serious loss of productivity of the whole enterprise.

the answer is the cross-functional team. agile. scrum. (and many names and many crazy offshoots) but the core recipe is good and sane: people above process. trust (and self-check) instead of mandatory responsibility separation to check each other. empower engineers to be able to do the right thing by default, engineer tools for everything, don't let non-tooled non-integrated handoff points develop, because that leads to fiefdoms and communication bottlenecks.

Re: The Big DevOps Misunderstanding

#238

Post by INTPenis »

capn_duck wrote: post #152
INTPenis wrote: post #103

Earlier quoted context omitted.

Being a devops guy these last 2 years I have noticed that besides doing what you just mentioned, I am basically end user support for developers. And through this I've noticed that developers can be just as bad at communicating issues as any end user I've ever dealt with. Just because they've written the system end users use, does not mean they're better at reporting problems to me, because their problems are about th…

In my experience, its because the tools that are given to the dev team are opaque, poorly documented, made for a general case that rarely is sufficient, and usually locked down with some role based access control to the point where, even if I can figure out whats wrong with some pipeline, I rarely have the access to change something. I have an AWS Codepipeline that I can see running, but the logs from each step are s…

Yeah that's also part of our job, to expose the right info to developers so they don't have full access to everything but can still do their job. In my case that involves shipping logs to Grafana so they can view them there. In AWS it wouldn't be hard to create a policy for IAM users so the devs can view logs in the AWS console.

Re: The Big DevOps Misunderstanding

#239

Post by INTPenis »

Pxtl wrote: post #172
INTPenis wrote: post #103

Earlier quoted context omitted.

Being a devops guy these last 2 years I have noticed that besides doing what you just mentioned, I am basically end user support for developers. And through this I've noticed that developers can be just as bad at communicating issues as any end user I've ever dealt with. Just because they've written the system end users use, does not mean they're better at reporting problems to me, because their problems are about th…

> And through this I've noticed that developers can be just as bad at communicating issues I swear to god the next guy who sends me the screenshot of an error log...

Or another example from last week, a java developer sends me 50 lines of exception text when even I know that ONE of those lines is all you need to explain the problem.

And this particular developer is my main problem in that project. So it's not all developers who are bad, it's about the same percentage as regular end users I'd say.

Re: The Big DevOps Misunderstanding

#240

Post by netfortius »

Why are we stuck on [made up] words? Jobs shall evolve alongside technology, and shall be carried out as needed to attain objectives. I've been in the IT field (mostly infra and security) for over 25 yrs, with the last ten including the public cloud, and I have witnessed solutions and JDs changing accordingly, including birth of DevOps, NetDevOps, NetSecOps, etc., etc., but in the end all that mattered was what one needed to achieve, by using what specific tools, within which boundaries one had to work, and what was to be delivered.

As my first boss in IT told me, in 1995, when he promoted me as Manager Infrastructure & Security Services: ": You could call yourself anything you want, including Vice President of Ice Cream, and I will order business cards for you as such, but here is what I expect from you in this role, and here is how much I am going to pay you, to see it done."

Post reply on HN