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

161–170 of 321 posts

Re: The Big DevOps Misunderstanding

#161

Post by sjtindell »

pm90 wrote: post #144
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…

I’ve seen this and I empathize. I’ve seen it lead to a sort of learned helplessness in developers who are supposed to own their whole stack. I do think it’s unavoidable though. No company will have a truly open stack. There will be customized versions of everything, with caveats only the infrastructure team or developer-tools team are aware of. Naturally these teams become the go to folks to ask questions and resolve…

Agreed. In my experience there are only a handful of companies (Netflix for example) where the pipeline is truly hands off and any developer can deploy to production at any time. We’re talking about the people who literally built Spinnaker, and most teams aren’t that.

Re: The Big DevOps Misunderstanding

#162

Post by sjtindell »

As I learn I’m realizing that what a lot of people miss is the rigor required once you pass a certain company/infra size. The same stack and processes that worked to get you to $X million is not the one that will allow you to scale software deployments to support $X billion worth of business. Documentation, real ci/cd with multiple environments, strong access controls. It’s so easy to gloss over these when you’re small. You have someone on the team who is “the expert”, you don’t have the money to do a real blue/green setup, you don’t have the time on an incident to give someone the proper access so you just give them a shared ssh key…success at scale requires discipline that makes the work hard and not fun. But it’s the key. Once you have dozens of infra engineers and many microservice teams, this laziness (that’s what it is, I know because I’m lazy) doesn’t work.

Re: The Big DevOps Misunderstanding

#163

Post by erulabs »

avip wrote: post #32

Personally I think it's pretty great that I can write Dockerfiles, run them locally, and call it the day because this is also what runs in production. So basically I have no clue what the dude is talking about - we have a great setup which is x10 better than what we had before. No?

Agreed. Dockerfiles beat ansible scripts which in turn beat that-bash-script-that-PXE-ran. Skaffold and kubernetes are amazing tools, but just tools.

So much easier to be cynical about new tools than to investigate and understand the pros and cons.

Re: The Big DevOps Misunderstanding

#164

Post by digianarchist »

mrweasel wrote: post #24
hnthrowaway0315 wrote: post #14

One thing I really hate about a dedicated ops team (DevOps that is independent of devs) is that they have to use just one hammer for all kinds of nails. It's simply impossible for a small team to maintain multiple hammers. So somehow the tools and workflow are exactly same for an app that has millions of external users and an internal app that only 10 people use. You still have to go through a whole stacks of K8S/doc…

As an ops guy: You’re absolutely right. For better or worse I’m constantly annoyed by developers trying be “special”. Most projects involve stuffing things into a database, calling a webservice and reading stuff back. Don’t try to be clever about it, just stick to one type of database and Springboot so we can all go home and sleep with no incidents. But there are projects which really do need to be different, and we…

Nothing better than a team that doesn't use the internal platform. They go and write their own scripts, tools and terraform only for the developers responsible to leave the company.

They found another way to skin the cat purely because they didn't like the existing approach and didn't want the hassle of getting changes integrated upstream.

Re: The Big DevOps Misunderstanding

#165

Post by dorongrinstein »

We built the https://controlplane.com platform to let developers focus on the Dev and get best practices Ops so they can deliver many times faster. Our customers get 99.999% availability and ultra low latency no matter where users are. Check it out and I'd love to hear your feedback on the Ops part in DevOps with Control Plane.

Re: The Big DevOps Misunderstanding

#166

Post by LilBytes »

dsr_ wrote: post #121
waynesonfire wrote: post #95

Earlier quoted context omitted.

> sysadmin would write the tooling to ensure the payment code could work Uhh if by tooling you mean a bash script to deploy ssh keys to prevent team A from accessing a machine owned by team B. You really have no idea what you're saying.

Dijit is completely correct. A junior sysadmin executes checklists, writes simple scripts, reads logs, and solves common problems, all while learning the complex supersystem of their workplace. They learn configuration of systems in use and how infrastructure is arranged and commonly changed. A sysadmin helps to create checklists, writes more complex code to work in an automation system, and generally solves problems…

You've nailed it.

DevOps guys are senior sys admin in the cloud (and that last caveat isn't mandatory). People shit on sys admins all the time but the only real difference between senior sys admins and DevOps engineers is pay packet, tools and responsibility.

Re: The Big DevOps Misunderstanding

#167

Post by 2fast4you »

ethbr0 wrote: post #155
capn_duck wrote: post #152

Earlier quoted context omitted.

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…

I think the above is what happens when a devops tools team doesn't do discovery and user interviews. We've been at a point of software and development where we can build pretty much anything. But people are still making the same mistakes in figuring out what we should build. Fix the cause, not the symptom. Edit : And because I know it's coming... if IT security (or insert other org here) is the reason things can't be…

Do you have good resource in how to discovery/user interviews? I’m on a DevOps team working to mature the first few tools we made

Re: The Big DevOps Misunderstanding

#168

Post by [deleted] »

cortesoft wrote: post #17

As someone who has lead a devops team, and still has a devops team reporting to me, I have also struggled with the idea of having a team called devops, since it does go against the devops philosophy of devs owning their software in production. However, in our case (and probably many others), our devops team is responsible for creating and maintaining the tools and processes that allow the dev teams to manage their sy…

[deleted]

Re: The Big DevOps Misunderstanding

#169

Post by totetsu »

manish_gill wrote: post #54

I had to basically give up my full time role as a Data Engineer who is supposed to solve "big data" problems (Storage, Streaming, Machine Learning pipelines) etc, and had to solely focus on DevOps because there was no other expert in the team. We (a colleague and I) basically learned Terraform, then Kubernetes, and then Helm in an extremely stressful environment. I wouldn't recommend that to most people. (Also, I can…

any suggestions on learning materials?

Re: The Big DevOps Misunderstanding

#170

Post by chazu »

kqr wrote: post #22
cortesoft wrote: post #17

As someone who has lead a devops team, and still has a devops team reporting to me, I have also struggled with the idea of having a team called devops, since it does go against the devops philosophy of devs owning their software in production. However, in our case (and probably many others), our devops team is responsible for creating and maintaining the tools and processes that allow the dev teams to manage their sy…

This describes what I've heard referred to as an internal platform team.

Agreed - this idea is often cited by fans of the book 'Team Topologies'. Its important here to distinguish between the idea of _an_ internal platform team and a _platform engineering_ team. A platform team is any team which provides services to internal clients - one such team would be the one (or ones) supporting whatever platforms-as-a-service are being used to deploy software to production.
Post reply on HN