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

311–320 of 648 posts

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

#311

Post by merb »

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…

well you do not upgrade your http/1.1 connection. http/2 works by using ALPN on TLS connections, that actually try to get the right protocol. yeah there is h2c, which does upgrade the connection, but that only works in backend scenarios without tls.

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

#312

Post by neurostimulant »

cmrdporcupine wrote: post #274
bfb09 wrote: post #146

Earlier quoted context omitted.

It's a shot across the bow at the Kool-Aid which everyone here has imbibed to some extent. Of course they're going to shoot the messenger. When I clicked this thread I said out loud to my team, "oh, this should be good," and I hadn't even fathomed precisely how predictable the discussion would be. It's so far removed from any consideration that it lands something like explaining to an American that they're a subject…

I think it's pretty drastic to say "everyone here has imbibed" that Kool-Aid; I work in embedded, and am not super familiar with the frameworks he's complaining about, but I found the blog post entertaining nonetheless. Sometimes I feel like the people who are deep down in this "full stack developer" land should come up for air and look around at the bigger picture. There's a much bigger world of software development…

You should come join the fun!

In order to deploy a web app in 2020, one must write his frontend using react and typescript that would transpile the code into a nicely bundled and minified javascript and css files along with thousands of your 3rd party dependency libs. Yes, you heard that right! I just counted the number of libs on the node_modules in one of my small side project and it's over 1000s. You might also wonder why the typescript code would produce css when transpiled. That's because in 2020 we no longer write stylesheet directly into a css file. That's so 90s! We write the css as javascript objects now, then let the transpiler generate css from that. Isn't that neat?!

For the backend, you can choose one of the many cool frameworks and languages. Heck, why not use 5? In 2020 the backend should be written as a collection of microservices that talk to each other over grpc. Of course you still need http or how else would your react frontend talk to your microservices? So your microservices now talks multiple protocols, which is very cool!

Now pack each of those service into a collection of docker images, then write 4000 lines of yaml files to orchestrate them on kubernetes, and you're ready to go! Now you have a glorious, scalable app with 99.999% sla that can withstand your show hn frontpage traffic thanks to kubernetes, until you eventually screw up that yaml config and the whole house of cards collapse, but that's on you because you're bad at kubernetes orchestration!

I think we're indeed in a deep trench but damn it's quite an impressive trench we got here!

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

#313

Post by tanseydavid »

013a wrote: post #248
pessimizer wrote: post #209

Earlier quoted context omitted.

> maintaining large open source software projects is soul crushingingly, destructively, enormously hard. Are you making a case in this package that complex open source projects are impossible unless completely controlled by very large, highly opinionated companies? That can be proven wrong by endless examples. > Did the author join in on the discussion when these changes were made? Did they voice their concerns? Or d…

No. I'm making the case that nebulous philosophical reasons for why technology is the way it is are nearly always unproductive, and is certainly unproductive in this case, which involves a very liberally-licensed open and libre-source project. Its startlingly easy to write five-hundred words. Its startlingly difficult to accomplish what the etcd team has; I therefore give the benefit of doubt to etcd. I don't fully u…

You said: "Its startlingly easy to write five-hundred words. Its startlingly difficult to accomplish what the etcd team has; I therefore give the benefit of doubt to etcd."

That's a VERY confusing comparison and conclusion to draw from it.

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

#314

Post by flatline »

nikitaga wrote: post #296
flatline wrote: post #233

Earlier quoted context omitted.

What is unnecessarily complex about TypeScript? It's JavaScript, with static typing plus type inference, and pretty nice generics. The ecosystem of modern JS surrounding it is horribly complex but TypeScript itself seems like a fairly straightforward programming language.

Offtopic but what's nice about Typescript generics? Typescript doesn't even let you specify variance. It's one of the unsound parts of the language's type system in fact.

It is not the most feature-rich generic system but it's come a long way since the earliest revisions and does have some niceties: https://www.typescriptlang.org/docs/handbook/advanced-types....

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

#315

Post by cmrdporcupine »

sercand wrote: post #267
brabel wrote: post #246

Earlier quoted context omitted.

> gRPC uses HTTP/2 ... while on a typical JSON API which probably uses http/1.1, you can't. What are you actually talking about? An HTTP API by itself doesn't actually care about which http version is used, that's something only the HTTP server that serves the API should care about (nowadays, pretty much any http server in any language supports HTTP/2 and 1.1). > Bi-directional streaming e.g. Kubernetes controllers u…

By using gRPC, we get much more without thinking too much. Also, bi-directional streaming is instantaneous and it is not like afterthought long polling. For example, whole etcd API is located at https://github.com/etcd-io/etcd/blob/4c6881ffe4b3bae257c0720... It is pretty straightforward and not too hard to understand the API. Designing APIs with protobuf makes things convenient and it brings lots of already written t…

"we get much more without thinking too much" is precisely one of the reasons for the original push to REST (and against RPC at that time SOAP and CORBA and RMI etc.) was made in our industry 10-15 years ago. By falsely representing a _remote_ resource as if it was a _local_ one we open a whole can of worms; not just performance, but resilience, infrastructure issues, etc. Transferring documents over HTTP with a common language of HTTP's verbs was supposed to get programmers to model their applications as the sets of resources that they are, discourage them from making excessive round trips, make debugging easier, and make use of standard HTTP load balancing hardware.

Yes it's easy to make that RPC call. But should you?

I've been off doing other things in the intervening period, but while I had my back turned the industry seems to have turned its back on REST and gone whole hog on RPC. Again.

At first I was thinking this was just internally here at Google, where protobufs and gRPC reign supreme. But it seems to have taken hold everywhere.

What did I miss? Why have we swung this way. Again. Is the pendulum going to go back?

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

#316

Post by twic »

dekhn wrote: post #101
ddevault wrote: post #86

Earlier quoted context omitted.

Go was made by a small group of smart people with debatable loyalty to Google. Google just ran with it, and they haven't done a great job with it since.

I'm not sure what you mean by debatable loyalty. The creators of the language have all worked at the company for more than 10 years and support the product for internal users. Can you put your grinding axe away and stick entirely to facts and technical merits?

> support the product for internal users

That right there is evidence they don't have Google's best interests at heart.

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

#317

Post by wrsh07 »

lemmsjid wrote: post #289
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…

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…

I agree with you. I like grpc.

But I also think that the original author has a point: for many solo developers it's an extra dependency that they have to learn, and they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound.

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

#318

Post by dnr »

bfb09 wrote: post #279
cmrdporcupine wrote: post #274

Earlier quoted context omitted.

I think it's pretty drastic to say "everyone here has imbibed" that Kool-Aid; I work in embedded, and am not super familiar with the frameworks he's complaining about, but I found the blog post entertaining nonetheless. Sometimes I feel like the people who are deep down in this "full stack developer" land should come up for air and look around at the bigger picture. There's a much bigger world of software development…

Rest assured that I am firmly in your camp, and I've been tirelessly making the argument to policymakers that Big Web is not the resident innovative force in computing any more, despite the Obama administration's rapid adoption of their ideals and philosophy to salvage Healthcare.gov. In both the legislative and executive branches I have found many, many sympathetic ears who have been burned by ballooning budgets to…

What would you say is the "resident innovative force in computing" now?

I'm a little confused by the reference to healthcare.gov: if Big Web is not the right paradigm to handle a... big web site, then what is?

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

#319

Post by js8 »

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.

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

#320

Post by merb »

regularfry wrote: post #98
jonfw wrote: post #70

Earlier quoted context omitted.

What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.

Spending 6 hours tracking down a `loadBalancerIp` that should have been a `loadBalancerIP` feels like a problem that shouldn't have happened.

actually k8s validates the yaml, welp it doesn't it validates the json. basically yaml is only the format the operators get, internally it uses json.
Post reply on HN