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

491–500 of 648 posts

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

#491

Post by lowiqengineer »

013a wrote: post #328
abernard1 wrote: post #259

Earlier quoted context omitted.

> gRPC wasn't added for no reason, or because politics; its a sister CNCF project, and would increase the performance of the API surface, which greatly benefits all of its users. gRPC (Google RPC) was absolutely added because of politics. Yes, it's performant, but let's not kid ourselves that gRPC wasn't picked because it falls nicely into the orbit of Kubernetes and the Google ecosystem. It's also why etcd can even…

I feel as if I have to repeat this during most discussions about Kubernetes and its halo technologies: Kubernetes is not developed by Google. gRPC is not developed by Google. etcd is not developed by Google. These are all projects under the Cloud Native Computing Foundation; its Platinum-level sponsors include: Alibaba, AWS, Apple, ARM, Cisco, Dell, Fujitsu, Google, Huawei, IBM, Intel, JD, Microsoft, NetApp, Oracle,…

I noticed you named the engineers that worked at Google, but not the top contributor, Gyuho Lee. Is that because he works at AWS?

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

#492

Post by EdwardDiego »

abernard1 wrote: post #327
lemmsjid wrote: post #289

Earlier quoted context omitted.

The problem, I think, is that the article presents all of its views as almost self evidently true. If you distill it down, the complaint is that etcd added gRPC. I think it was a good move for an infrastructure piece like etcd to add gRPC. Now I can just grab a generated client in a language of my choice. There's certainly valid critiques of gRPC / protocol buffers but I've found things like gRPC and Thrift to reduce…

> Now I can just grab a generated client in a language of my choice. But you can't curl the state of your infra component without creating a program and downloading the client artifacts. This is a very big step backward from an operability standpoint. > because there's a thousand interpretations of REST out there ...but there weren't a thousand different interpretations of the etcd API out there: there was exactly on…

> But you can't curl the state of your infra component without creating a program and downloading the client artifacts.

You can if you enable server reflection[1] and use a tool like grpcurl[2].

[1]: https://github.com/grpc/grpc-java/blob/master/documentation/... [2]: https://github.com/fullstorydev/grpcurl

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

#494

Post by akhilcacharya »

secondcoming wrote: post #378
013a wrote: post #328

Earlier quoted context omitted.

I feel as if I have to repeat this during most discussions about Kubernetes and its halo technologies: Kubernetes is not developed by Google. gRPC is not developed by Google. etcd is not developed by Google. These are all projects under the Cloud Native Computing Foundation; its Platinum-level sponsors include: Alibaba, AWS, Apple, ARM, Cisco, Dell, Fujitsu, Google, Huawei, IBM, Intel, JD, Microsoft, NetApp, Oracle,…

This [0] guy is going to burn himself out, going by his contribution chart recently. [0] https://github.com/gyuho

That looks like a person gunning for an L6 promo!

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

#495

Post by cwyers »

mleonhard wrote: post #482
cwyers wrote: 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…

The counterpoint is that there's a lot of people and organizations out there that are happy to take advantage of the labor of these large organizations, and view loss of control over some of these things as a valid price to pay for all of the contributions in code that they get. So the people left to contribute to this are a small portion of the overall base, and quite frankly often don't agree on much except their dislike for BigCo decisions. (systemd was able to consolidate its position as the top Linux init system by adoption; the contention for the number-two spot is split between sysvinit holdouts, OpenRC, runit, S6, GNU Shepherd, and probably others I'm forgetting.)

So you end up in a situation where package and distro maintainers face some work to support systemd, and because everybody else is supporting it it lessens the burden. There's this sort of gravity to these big projects that's hard to escape, and frankly a lot of people don't feel the need to; they view it as something they can get in a stable orbit around, not as something they're being sucked into.

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

#496

Post by dutch3000 »

i always cringe when the tech megacorps buy out an up and coming start up that shows promise. good for the start up employees as they cash in, but i can’t help but think that overall these actions stiffle future innovation moments that could have been if the start ups matured more on their own.

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

#497

Post by melq »

kelnos wrote: post #470
zaphirplane wrote: post #423

Earlier quoted context omitted.

There is complexity in the type system with signatures like ``` function partialCall (f: (...args: [...T, ...U]) => R, ...headArgs: T) { `

It's funny that you consider that complex; I consider that a pretty normal, expressive type signature that gives the compiler critical information about how I expect to use that function, which in turn allows it to completely squash several classes of bugs I might write. But I love strong type systems; people who prefer weak type systems would likely consider things like this to get in their way.

Could you elaborate on this point for someone who isn't familiar with typescript (or javascript, for that matter). I'm no stranger to strongly typed languages but that function signature seems pretty complex to me. By elaborate I mean explain what's going on in that signature, and what the critical information it supplies is?

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

#498

Post by Animats »

Google rolling their own replacement for TCP and HTTP is a disappointment. Their own benchmarks indicate they get maybe 10% more performance on a good day. All this comes with a huge increase in complexity. Which means more bugs.

The "solution" to bugs today is forced updates. Vendors love being able to forcibly impose whatever they want to do on the user. Turn off features, put in more ads, whatever. If software was reliable enough, nobody would upgrade, which damages the business model. It's so convenient that software seems to need constant "security updates".

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

#499

Post by Karrot_Kream »

adev_ wrote: post #374
Karrot_Kream wrote: post #335

Earlier quoted context omitted.

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…

>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? Such bullshit. Since when we use UDP for a CRUD service ? Since when SCTP is even considered outside of the telecom world? HTTP and Rest-like API have been able to handle properly simple CRUD API since 20 years without problems, way before gRPC was even a thing.…

> Such bullshit. Since when we use UDP for a CRUD service ? Since when SCTP is even considered outside of the telecom world?

You're making a strawmam out of this. I'm responding to the following:

"while I have developers that have written full Node.js sites and dont know that IP or a Port, or TCP, UDP, is..."

But thank you for the insult.

> HTTP and Rest-like API have been able to handle properly simple CRUD API since 20 years without problems, way before gRPC was even a thing.

Hm, what are you talking about? Are you talking about the client? Are you talking about a load balancer? I don't think anyone is proposing that a simple static blog use gRPC to serve content to its users.

> But in 99% of the case, yes it's an overkill.

Compared to what? I'd argue that CRUD over HTTP is wrong. In fact, folks have been writing CRUD over TCP for ages. Why do we need to massage CRUD syntax over HTTP when we can just stream requests and responses over TCP? In fact, TCP predates HTTP by 20 years, so if you're using the historical argument, raw TCP is even older. How much bullshit is there around AJAX and Websockets and HTTP multipart and HTTP keep-alive when we're just trying to recreate TCP semantics?

So why are you drawing the line at HTTP? Seems arbitrary to me.

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

#500

Post by yc12340 »

EdwardDiego wrote: post #492
abernard1 wrote: post #327

Earlier quoted context omitted.

> Now I can just grab a generated client in a language of my choice. But you can't curl the state of your infra component without creating a program and downloading the client artifacts. This is a very big step backward from an operability standpoint. > because there's a thousand interpretations of REST out there ...but there weren't a thousand different interpretations of the etcd API out there: there was exactly on…

> But you can't curl the state of your infra component without creating a program and downloading the client artifacts. You can if you enable server reflection[1] and use a tool like grpcurl[2]. [1]: https://github.com/grpc/grpc-java/blob/master/documentation/... [2]: https://github.com/fullstorydev/grpcurl

> tool like grpcurl

Not available in any repositories and largely unknown to general masses (much like gRPC itself).

Personally I like gRPC and sometimes use it in projects. But the author is right — attempting to gradually replace an existing HTTP API via gRPC API is like replacing horses with genetically modified cows. You need a very... corrupt mindset to ever attempt anything like that.

Post reply on HN