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

91–100 of 321 posts

Re: The Big DevOps Misunderstanding

#91

Post by jbverschoor »

cortesoft wrote: post #88
shrimpx wrote: post #62

Earlier quoted context omitted.

Devops is having an identity crisis, but what you describe is what I call devops. It's the subset of engineering that supports engineering by defining/inferring workflows and building systems and tools to codify them. But I've seen it called ops, sysops, internal platform, and even infrastructure -- in some companies, devops and infra are the same people.

Yeah, I am not sure how typical this is, but my company has DC (data center) ops, NetOps, SysOps, and DevOps… DC ops is in charge of the physical system, from racking and stacking to hardware replacements. NetOps handles the networking stack, managing the routers and switches, vlans, announcements, IP block management, network access requests, etc. SysOps handles provisioning systems, working with dc ops to get syste…

It is the J2EE role "Application Deployer"

Re: The Big DevOps Misunderstanding

#92

Post by jjtheblunt »

StreamBright wrote: post #70
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…

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…

"turning complete" : typo?

Re: The Big DevOps Misunderstanding

#93

Post by benlivengood »

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…

I've been in two production environments where IaC was done with Turing-complete languages (Google and Facebook). It's really not better (it just lets the truly impossible/unmanageable become possible) because they were both dynamically typed.

If anything, Terraform comes the closest to being a good IaC language because providers form an API to production resources as opposed to unstructured code/config like Helm or Jenkins/Puppet/Chef. Production in reality is well-typed, and unstructured configuration makes static analysis very difficult and makes diffs only a guess at what will actually be changing when code changes are applied.

What I'd like to see is Haskell (or similar) typeclasses as production API; make it impossible to construct malformed configurations in the first place but allow expressive functions to replace the limited templating functionality that current languages have (why can't helm templatize inside values.yaml? Why can't Terraform templatize backends and why aren't providers first-class objects?). It's very difficult to keep current IaC DRY, and if it's not DRY then it has bugs and there are misunderstandings about how environments are actually configured.

Re: The Big DevOps Misunderstanding

#94

Post by jordanbeiber »

thrower123 wrote: post #78
jordanbeiber wrote: post #12

Earlier quoted context omitted.

Yes, many enterprise devs I know are completely uninterested in infrastructure. This is also a great way of scaling teams - keeping a path of least resistance that is secure and compliant while giving observability and conventions.

Infrastructure in enterprises is usually completely uninteresting, to be fair. You need like eight different people on a call in order to stand up a VM, install a service, and configure a database connection.

Broken processes and missing self-service, as you point out, is why creating a platform team is important for these types of places. They might not know it yet, although some are trying.

It doesn’t make the infra technology more or less interesting?

Re: The Big DevOps Misunderstanding

#95

Post by waynesonfire »

dijit wrote: post #61
netizen-936824 wrote: post #47

Earlier quoted context omitted.

This is my observation as well. Sysadmins writes scripts or small programs for automation but its mostly using those tools for the operation of larger systems developed elsewhere (including other internal depts)

A sysadmin wouldn’t write payment code. A sysadmin would write the tooling to ensure the payment code could work (failover databases, redundancies) and put safeguards in place so that it does not get traffic that is not intended for it. Sysadmins used to write the code that touched thousands of machines at once, developers used to write the more complex code which were the bread and butter of the company. But where I…

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

Re: The Big DevOps Misunderstanding

#96

Post by quickthrower2 »

PaaS is easier and I prefer it for personal projects. I don’t want to use the terminal or shell at all and have minimal yaml files.

For work though kubernetes means portability and not having the rug pulled from under you, you can move clouds more easily if necessary.

Re: The Big DevOps Misunderstanding

#97

Post by sofixa »

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…

> The YAML (or heaven forbid, jsonnet) does not help. TBH, I'm convinced if the IaC bits were done in a regular Java/Go/Rust SDK style instead of mixing and matching YAML glued together via labels and tags, I would have had a much easier time.

I have mixed feelings about this. I've seen some absolutely atrocious Python and JavaScript code, and i wouldn't want to use either of them, and the flexibility ( to shoot yourself in the foot) they provide. Go is better. On the other hand, YAML is just terrible.

I think DSLs such as HCL are better than either option, as long as they're flexible enough while staying limit in order not to get illegible/unmaintainable.

Re: The Big DevOps Misunderstanding

#98

Post by jbverschoor »

jordanbeiber wrote: post #12
brightball wrote: post #2

He’s not wrong. Over complicating DevOps does take the control away from developers but I think a lot of the Ops part of DevOps is to create an internal PaaS that your devs can deploy to themselves.

Yes, many enterprise devs I know are completely uninterested in infrastructure. This is also a great way of scaling teams - keeping a path of least resistance that is secure and compliant while giving observability and conventions.

Or any CS field for that matter.

Re: The Big DevOps Misunderstanding

#99

Post by throwawayboise »

throwDec19 wrote: post #60
mrweasel wrote: post #15

> You build it, you run it While I do like that definition, it also means that most companies/organisation cannot do DevOps, as software development is often bought as projects, and operations is a recurring cost.

We get heavily clamped down on access to production by our auditors for Sarbane Oxley reason. Technically we aren't even allowed production data in our dev environment. I dont understand why any organization would allow it. Seems the tech world is still ripe to get sued.

Organizations did (do?) allow it because it's easy. It's also a way to test/debug production problems with actual production data instead of spending time trying to make up data that you hope covers all the actual use cases.

Re: The Big DevOps Misunderstanding

#100

Post by gobins »

I have been working in Infra Automation and deployment automation for a while now. As much as there are complaints about having a dedicated team called "Devops", one thing that this change has really done is that CI/CD is almost a non-negotiable of application delivery now. I am sure there are a lot of teams and orgs still starting out in this transformation but its no longer something I have to explain to application teams now.
Post reply on HN