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

Etcd, or, why modern software makes me sad

roguelazer.com

Post reply on HN
Print view View original

381–390 of 648 posts

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

#381

Post by StillBored »

cbsmith wrote: post #325
mvanga wrote: post #133

This is one weird comment section. There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes. The key point of the article is not really being addressed here: vested interests from large companies are able to introduce huge complexity into simple, well-designed projects. While the complexity may be good for some end that said vested interest has in mind, they are al…

A lot of the complexity is just intrinsic to working on distributed systems, and if you're doing that kind of work, then these products really can help reduce overall complexity by giving you an admittedly complex solution that is at least robust and pretty well tested; that tends to be better than constructing your own. I think where a lot of the pain comes from, and the article hints at this, is there are a LOT of…

Yes distributed systems are complex, but IMHO at least a large part of that complexity is caused by people who think they understand the problem, and go off and create some "great" new technology. Which then gets a lot of press, and other people building systems on it, only to discover that the edge case being ignored as inconsequential starts to create lots of failure modes. Sometimes these critical problems are "human factor" ones like with kubernetes configuration, or they are just a lack of proper engineering hygiene. Then you get another layer of crap on top. Repeat that a few times and what you actually have is a giant mess that frequently only works through the sheer effort of a large operations team.

To put this another way, if you read the Jepsen reports overwhelmingly what comes across is a lot of hubris. Its overwhelmingly old stodgy technology these new systems are meant to replace (posgres for example) that are satisfying the promises being proclaimed on high by $NEW_TECHNOLOGY.

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

#382

Post by KaiserPro »

derefr wrote: post #217
KaiserPro wrote: post #190

Earlier quoted context omitted.

HTTP2 fails for mobile clients. it shoves everything down a single TCP connection. This means that if you loose a packet (and 4g is lossy) it stalls the _entire_ queue. Instead of addressing the main complaint (that multiplexing everything down a single TCP connection is a fundamentally stupid idea) they come up with an entirely _new_ protocol. It also fails to understand what HTTP2 has turned into: a file transport…

To be clear, it's not like there are any HTTP/2- only servers in the world. HTTP/2 is something a client connection upgrades to. One might think of HTTP/2 and HTTP/3 not precisely as versions of HTTP, but rather as variants —HTTP/2 is "optimized binary HTTP, fixed-station profile" and HTTP/3 is "optimized binary HTTP, mobile-station profile." (Mind you, they are versions relative to each-other , because HTTP/3 is str…

> HTTP/2 is something a client connection upgrades to.

to which I as a normal person on a normal phone has no control.

> Also, a design hint, if you actually want to try to build something competitive to HTTP/3

I'd need to control a major browser's code base.

Lets get one thing clear, HTTP is, has never been and almost never will be efficient. The entire HTML/JS/HTTP web is never going to be efficient. If the web was a meritocracy based on protocols, HTTP would have died a death at CERN.

> perspective of e.g. an internet backbone ops engineer.

They'd terminate the connection as close to the client as possible and palm it off to the local FAANG pop and make it someone else's problem. That and adding pop's for porn hub and torrent filters will knock out >70% of your precovid interconnect traffic.

> If you think you're so smart, write an RFC

I already work for a FAANG during the day, I'm not going to put free hours in at night. And I'm certainly not going to get involved in cross company politics.

> a point when explicit OSI-style encapsulating layering

OSI has never been correct, its a fib told to students to make them think there is any kind of order past tcp/udp. I'm talking about not putting control signals in the same TCP connection that you are shoving tonnes of data down. That's never going to scale past 70-100ms. yes its very neat, but

> zero-copy binary serialization protocols like Capn Proto from a process with direct userland Ethernet access

from the protocol level, its not actually that much different, unless you are doing some sort of multiplexing down a single TCP pipe.... now, if you trying to balance throughput and latency on the same connection, thats can be really tricky. An answer is not to use the same connection. You do what FASP does which is use UDP for bulk and TCP for control/accounting.

> like generating and streaming a JSONL

you can easily use TCP at one packet a minute, or maxing out a 10 gig link. (I know, I've written a FASP replacement.)

> semantics such that it can be downgraded to HTTP/1.1

you can downgrade 10gig-t to 10m/s that has no bearing on its performance, unless you terminate it badly. Its just a preamble, then for the life of the connection, an utter irrelevance.

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

#384

Post by KaiserPro »

neurostimulant wrote: post #366
KaiserPro wrote: post #202

Earlier quoted context omitted.

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…

> The worst offender in K8s world is the networking scheme. Its utterly batshit, and clearly designed by people who've never had to support anything out of hours. (statically assign 254 IPs to each host, or fuck with the routing table.) Hmm, I thought you could specify larger node cidr at cluster creation time so you can have >254 ip addresses on each node? The default is /24 but you should be able to specify a large…

Thats the point!

The network provides simple and easily controllable ip allocation. You don't need to do any of it, just offload it to AWS/GC/Azure.

Slam another network card/VLAN, give it a seperate ip range from the control network, and everything is handled for you, quickly, securely and efficiently.

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

#385

Post by Jeff_Brown »

js8 wrote: post #319
mvanga wrote: post #133

This is one weird comment section. There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes. The key point of the article is not really being addressed here: vested interests from large companies are able to introduce huge complexity into simple, well-designed projects. While the complexity may be good for some end that said vested interest has in mind, they are al…

> It's almost like there's no good representation in the open-source world for the solo developer or small team. IMHO, there is a simple solution to this - release the software under the GPL license. Then no corporation will want to touch it.

If your project is sufficiently popular, that's safe; otherwise maybe not.

As someone else mentioned, when a giant corp absorbs a free project, you can reasonably expect them to maintain it. If you GPL the project, that won't happen. But if it's a popular project, then if it's GPL it will attract more maintenance from people who can't free-ride on the corp's efforts.

(Note that the relevant measure of "popular" is not number of users, but number of people enthusiastic enough to actually contribute.)

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

#386

Post by Foxboron »

GekkePrutser wrote: post #373
Foxboron wrote: post #352

Earlier quoted context omitted.

> As such I found it sad when even Arch fell to the systemd camp. And it's one of the few things it really enforces, it supports 6 different network initialisation methods for example, where all other distributions just pick one and go with it. Arch has only supported one init system at all times. We could still have stuck with the sysvinit with hacks to look like openrc, but nobody liked that. The initscripts where…

I agree sysvinit was no longer sufficient for today's needs. The issue I have with systemd was mainly related to its heaviness not really fitting in with Arch's simplicity. And with the products of corporatism seeping through even one the most noncommercial variants of Linux. Basically what cwyers mentioned above. I've been putting up with systemd as all the distributions I use have moved to it, but I never really li…

>The issue I have with systemd was mainly related to its heaviness not really fitting in with Arch's simplicity.

Arch is a pragmatic distribution first and foremost. If we can build systemd, and ship it as-is to have a complete init, and more features along with it, that is much more enticing then the alternative.

> I think it (openrc) would have been a good choice for Arch, for me it would have been better than systemd.

It would still entail maintaining some form of initscripts. I don't think most users realize how much of a burden this is, they don't really deal with that part of the system.

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

#387

Post by secondcoming »

derefr wrote: post #92
tannhaeuser wrote: post #33

> HTTP/2 a.k.a. SPDY is a comically bloated Layer 4/5/7 mega-combo protocol designed to replace HTTP. It takes something simple and (most importantly!) comprehensible and debuggable for junior programmers and replaces it with an insanely over-complicated system that requires tens of thousands of lines of code to implement the most minimal version of, but which slightly reduces page load time and server costs once you…

> HTTP/2 can only bring advantages if you actually go all the way to push/bundle resources into responses Compared to well-optimized HTTP/1 (e.g. using minified CSS and sprite-sheets), sure. Compared to most HTTP/1 deployments, though: no. HTTP/2 gives you tons of advantages "for free" that you need build-time processes to attain in HTTP/1. With HTTP/2, you can do "the naive thing" that'd you'd have done on the 1995…

What have CSS and sprite-sheets go to do with the HTTP protocol?

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

#388

Post by bandrami »

pm90 wrote: post #360
bandrami wrote: post #57

Earlier quoted context omitted.

Revisit this comment of yours in a decade.

A decade is a long time in software engineering. Kubernetes would be obsolete by then. What do I need to revisit?

It is and it isn't. I remember the first time I thought "this software is just X that everybody forgot about, reinvented again". That was 2005. Not coincidentally that was a decade after I started working as a sysadmin.

Venkatesh Rao says that there comes a point in your life when you realize things you thought were permanent are temporary, and things you thought were temporary are permanent; he uses "40" as a good rubric for that developmental stage. IT goes through many pendula, whether it be containerization vs. amalgamation, or thin clients vs. thick. What, over time, you learn to hold on to is the tools that have lasted decades and will probably continue to. Right now the pendulum is starting to swing back towards amalgamation, and it will probably swing back towards containerization again in another decade. Whatever the tech is at the time, it can be good to reconsider whether your views will have changed not on the technology, but on the larger pendulum it's riding.

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

#390

Post by xorcist »

Karrot_Kream wrote: post #335
what-the-grump wrote: post #307

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…

So how would you operate each of these bespoke services? One service uses TCP, one uses UDP, one uses SCTP. What happens if your buffer sizes are incorrect? What about if your keep alives are too aggressive? What happens if a problem in your TCP connection pool makes it seem like there's a networking issue and so you play around with your network settings only to have all your other protocols dive in performance? I s…

That's a very good argument against the modern framework-conatiners-k8s stack. We used to be able to keep an organization wide track of things such as tcp services, buffer sizes, timeouts etc. but now it's all a black box deployed by a guy who cut and paste some yaml from a Medium article, at best.

It's probably acceptable to not learn the details of what you're doing, as hardware is cheap and all that, but it also constitutes a glass ceiling for how much the organization learns. That's a bigger problem in the long run.

Post reply on HN