Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

481–490 of 648 posts

Re: Etcd, or, why modern software makes me sad

#481
post #47

I run k8s in production and I think this is a really bizarre axe to grind that sort of smells like someone who got upset by how steep the kubernetes learning curve is. Which, in a way, is understandable. > 1) Add hundreds of new failure modes to your software In my entirely anecdotal experience, it removes error modes. It turns out that just because k8s offers a feature (it offers many!) doesn't mean you're required…

the problem is that k8s is a half arsed implementation of borg/tupperware. Having supported a large team migrate from a custom system based on fleet (god know why they were allowed to waste two years on that) jump to k8s (around 1.2) it struck me how many features it actually lacked (like pod drain, although thats fixed now.) The worst offender in K8s world is the networking scheme. Its utterly batshit, and clearly d…

I worked as borg sre for 6 years and the idea that tweaking the thing every 6 months is a lot is utterly hilarious to me

Re: Etcd, or, why modern software makes me sad

#482
post #229

> In 2015, an unrelated tool called Kubernetes was released by Google (but, really, by Xooglers). I would go so far as to say that Kubernetes (or, as the "cool kids" say, k8s) is the worst thing to happen to system administration since systemd. This, I think, is the key to understanding this whole rant. It is entirely of a piece with the anti-systemd crowd, and I think understanding what was really going on there hel…

How about a new kind of free software, individual and small-organization supported free software?

Policy proposal: Accept contributions only from people who have not done paid work for a large organization in the last 24 months. Large organizations are entities with 50 or more paid engineers. Contributions include bug reports, feature requests, pull requests, and donations of money or equipment. Anyone may contribute documentation and training materials.

Re: Etcd, or, why modern software makes me sad

#483
Funnily enough, the part that this author seems to hate the most - moving to a well-defined protocol that has an actual typed description rather than some ad-hoc pseudo-plaintext format - is exactly what's wrong with systemd/kubernetes/etc - reinventing the wheel with new protocols rather than reusing what already exists. You don't have to like gRPC - I don't particularly like gRPC - but it gives you an interface in a well-defined format that's easy to play around with. That's head and shoulders above having to figure out the edge cases in yet another custom pseudo-plaintext protocol.

Re: Etcd, or, why modern software makes me sad

#484
My favorite excerpt from this article and one that sums it up nicely can actually be found in one of its footnotes:

> I am filled with rage just thinking about how we took a fundamental part of the Internet, simple enough that anyone can implement an HTTP server, and replaced it with this garbage protocol [HTTP/2] pushed by big megacorps that doesn't solve any real problems but will completely cut out future generations from system programming for the web.

Re: Etcd, or, why modern software makes me sad

#485

Earlier quoted context omitted.

I have that rant daily at this point. Dev A: I need an API to CRUD Me: But we've been doing CRUD for 30 years without an API this is a small project Dev A: But I don't know how, its not best practice, my team lead agrees, here is a medium article, get with the times, etc. Me: Ok so you don't know how to do your job. Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy... Me: But all…

A company I used to work for needed a website. They already had a backend and a REST API (served on the same domain as the website should be) and the old website was served directly by the backend that also served the API. I am not aware of why it was chosen to retire that and separate the website into its own service - maybe there was a good reason, so I won't comment on that. However the approach they (or rather so…

I made this same tech-stack decision while working for a company in the manufacturing industry. React, GraphQL, Node.js. There was a reason behind it.

The head of the company was pushing to modernize our process flow via software meant to drive manufacturing. We had contractors on site from three different companies who were each using us as a test-bed for their software/manufacturing integration. Every week or two they'd plot out some new data they'd need to move from sales to engineering, manufacturing, QC, etc.

In our case, having GraphQL as a translation layer for the sales website saved everyone involved time. However, I can also see many scenarios where that wouldn't have been the case.

It definitely comes down to using the right tool for the job. Knowing how to identify which tools fit and which don't is one of the skills it's very important to help new devs develop.

Re: Etcd, or, why modern software makes me sad

#487
post #252

Earlier quoted context omitted.

I love k8s, think it’s the best thing that happened to distributed computing since .. sliced bread? Anyway, it’s good, but I don’t disagree with the author I just have a different perspective. I see k8s as a vehicle for learning about distributed computing not just for me but the industry as a whole. Same thing about Linux, it’s just a stepping stone for node management and has served us well in figuring out a bunch…

I also love k8s and agree with the author. K8s gives us declarative infrastructure with eventual reconciliation. That's massive, and there's nothing else around that really does that. I have a hard time taking anyone sesriously that makes the case that k8s is bad that hasn't fully grokked the above.

Personally I see this as coming from K8s having effectively two parallel uses.

One is for making it easier to manage large, complex infrastructure. The other is as a quasi-OS for containerized software.

Instead of using a new technology to move infrastructure complexity away from developers we now run development environments on k8s, piling even more complexity and layers of abstraction on.

Re: Etcd, or, why modern software makes me sad

#488

Earlier quoted context omitted.

My first boss (rip) had a internship with a defense contractor his junior year in college. They gave him one project. Design a cover for the air intake for an APC or some such. Easy!!! No not actually easy because of all the constraints. It had to be stowable. So a hard cover was out. It couldn't produce toxic fumes if it caught fire. So most plastics were out. Cloth was a problem because it couldn't get sucked into…

> I think military tech has a problem that it's trying to keep out with commercial drive tech which operates on a scale that a 1000 timers larger. Military produces a few thousand artifacts to commercials few million artifacts. Not to excuse military contracting pork and cost padding, but this is a good point that a lot of people seem to miss. There's also the fact a military contract will be for a production run and…

Another huge factor is the service lifetime of military equipment.

There are aircraft that were designed and created in the 1970s that are still in use today. Sure, many of the components and internal systems have been modified and upgraded, but much of the original design is still there and operating.

>> a military contract will be for a production run and follow on support.

When "follow-on support" has to last for 50 years or more, it makes a big difference.

Re: Etcd, or, why modern software makes me sad

#489
Meh, author certainly has a point about K8s being overkill for 99.9% people out there.

Unless you need to operate at a certain scale (that most people never will) then Kubernetes is like taking an F1 car onto a regular road. Recipe for pain.

Re: Etcd, or, why modern software makes me sad

#490
post #47

I run k8s in production and I think this is a really bizarre axe to grind that sort of smells like someone who got upset by how steep the kubernetes learning curve is. Which, in a way, is understandable. > 1) Add hundreds of new failure modes to your software In my entirely anecdotal experience, it removes error modes. It turns out that just because k8s offers a feature (it offers many!) doesn't mean you're required…

the problem is that k8s is a half arsed implementation of borg/tupperware. Having supported a large team migrate from a custom system based on fleet (god know why they were allowed to waste two years on that) jump to k8s (around 1.2) it struck me how many features it actually lacked (like pod drain, although thats fixed now.) The worst offender in K8s world is the networking scheme. Its utterly batshit, and clearly d…

> Plus you have to continually upgrade, migrate and generally tweak the thing, every 6 months.

If you're AWS, Azure, or Google, this is a feature, not a bug. It makes it easy to sell k8s-as-a-service.

Post reply on HN