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

541–550 of 648 posts

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

#541

Post by Polylactic_acid »

dynamite-ready wrote: post #153
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…

Agreed. I saw it as a general lament against over-engineering. I don't think the point got lost in the super specific example... You could just as easily level similar rants against the likes of React and it's wider ecosystem, Tensorflow, Typescript (many will disagree), Docker... I'm sure others have their own bugbears. Much of this is subjective, of course. But to me, it feels like software development is trending…

I'm not sure how react fits in here. I have found it to be very simple to understand enough to be productive and upgrading to new versions has required next to no changes to our large codebase. Perhaps you mean SPA react apps which I agree are a bit more work than needed for a solo dev.

Docker seems to be optimal for medium size teams. Configuring a server the old way is easier than docker for 1 server but less so for when you have 10 or CI/review apps.

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

#542

Post by davedx »

adamsea wrote: post #211
dynamite-ready wrote: post #153

Earlier quoted context omitted.

Agreed. I saw it as a general lament against over-engineering. I don't think the point got lost in the super specific example... You could just as easily level similar rants against the likes of React and it's wider ecosystem, Tensorflow, Typescript (many will disagree), Docker... I'm sure others have their own bugbears. Much of this is subjective, of course. But to me, it feels like software development is trending…

React I have been thinking about, having worked with it a lot and also recently done a React / TS / GraphQL (GraphQL may have been the poorest choice I made; time will tell) project. I think React itself is awesome and I've always enjoyed it. While I'm not an expert, it's conceptual foundations and core abstractions felt right, and I do think it makes lots of frontend tasks simpler, especially for non-small projects.…

Full agreement with you on those technologies.

GraphQL is unfortunately still part of a low grade hype cycle where more and more companies are using it because "it's the next REST". But if you don't have a real need for the advantages it offers (for example a mobile app whose client side requests you can't easily change in sync with your API, or a data model that really is graph-like), it can be more cost than benefit.

React on the other hand: I've lost count of the number of small prototypes I've started in vanilla JS, thinking "this time I can just roll it myself", then ended up pulling in React. Even the simplest things are easier and simpler with it, and hugely complex applications are also easier and simpler with it. It has a fantastic API surface.

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

#543

Post by hoseja »

alexose wrote: post #524
bfb09 wrote: post #514

Earlier quoted context omitted.

Perhaps my beef with your cadre is assuming that questioning its merits is AFS propaganda coming from someone who’s never set foot south of Embarcadero and assuming everyone who mentions principals has an axe to grind. You’ve painted a lovely caricature of who you think your opposition is, but you’re looking in entirely the wrong direction. Hint: Two FAANGs. I don’t speak on the telephone with underhanded accusations…

Heh, ok. I know when I'm getting trolled. What was that main account of yours, again?

Guy is either a really weird troll or a proper schizo. He mentioned "sympathetic ears in the government" at least three times.

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

#544

Post by Polylactic_acid »

discordance wrote: post #465
dynamite-ready wrote: post #153

Earlier quoted context omitted.

Agreed. I saw it as a general lament against over-engineering. I don't think the point got lost in the super specific example... You could just as easily level similar rants against the likes of React and it's wider ecosystem, Tensorflow, Typescript (many will disagree), Docker... I'm sure others have their own bugbears. Much of this is subjective, of course. But to me, it feels like software development is trending…

I attribute this companies that can afford to keep way too many high skilled employees on the books while needing to keep them occupied

It seems to me the problem is all of our software is built by and for megacorps. In the context of what they need it for its the best tool for the job but it was never made for smaller orgs where 90% of the bells and whistles are not needed and end up as needless complexity.

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

#545

Post by neurostimulant »

chris_wot wrote: post #411
neurostimulant wrote: post #312

Earlier quoted context omitted.

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 wo…

I'm genuinely curious - do you really have to do all of that? Why not just ignore the frameworks and technologies that overcomplicate things and use what works best for you? I am wondering why someone just hasn't forked etcd if it is truly so awful now.

Unfortunately yes. I'm a freelancer so I have to keep up with the latest tech, at least just enough so I can debug issues when working on my clients' projects. You probably don't need to do this on your niche and can just keep using whatever stuff that works for you.

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

#546

Post by patrec »

ddevault wrote: post #113
zaphar wrote: post #110

Earlier quoted context omitted.

Bazel, gRpc, Guava, Go, Dart, I could go on but you technically only asked for one.

Bazel is fucking awful . Most miserable years of my career is when I was tasked with maintaining a build system based on it. Same for gRPC, which TFA also does a good job of shutting down. Google doesn't get credit for Go, Bell Labs does.

Blaze/Bazel has its flaws (including poor integration into the world outside google), but what are you comparing it against? Any general purpose build system I've seen that is not bazel based and not nix is a flaming pile of garbage: almost nothing else can even figure out a correct dependency tree, let alone which parts of it have changed and need recompilation. Bazel also uses a familiar, readable and yet concise subset of python for build description, whereas most other build systems use customer languages with syntaxes and semantics that are comically bad if you don't have to use them and tragically so if you do.

Again, gRPC has its flaws (and I'm not a fan of HTTP2), but what are you comparing it to? For internal services REST is acceptable for extremely simple, stable and low volume APIs. For everything else it is an obvious disaster: terrible CPU/network/memory performance, you need to write more code than you would have to with gRPC and get zero type safety unless you add some json schema monstrosity on top of it at which point your performance will likely take a further nose dive. Also, good luck evolving the protocol – gRPC is carefully designed to support this. Far from doing a good job, "TFA" quotes some extremely clueless article on why protobuf sucks that was ripped to shreds when posted on HN previously.

The only compelling alternative to gRPC I am aware of is capnproto (which is derivative, but in some ways nicer), but it has far less eco system maturity and mindshare.

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

#547

Post by coopierez »

chris_wot wrote: post #411
neurostimulant wrote: post #312

Earlier quoted context omitted.

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 wo…

I'm genuinely curious - do you really have to do all of that? Why not just ignore the frameworks and technologies that overcomplicate things and use what works best for you? I am wondering why someone just hasn't forked etcd if it is truly so awful now.

Being a complete newbie on the scene a few years ago, the choice of frameworks and tools was so incredibly overwhelming (coming from C/C++ land). There are strong opinion pieces both for and against basically everything too.

When you are still trying to figure out exactly what HTML and JS should be responsible for, having React, Vue, PHP, Elm and many more as options for "just making a simple web page" can slow down the learning process by an order of magnitude.

I'm not sure what the solution is here- clearly each of these tools has a niche which requires them, but making a basic webapp without a web-engineering degree is quickly becoming an impossibility.

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

#549

Post by red_admiral »

There may well be evil at google, but it's not here.

My take on this is that CoreOS and google have different use cases, and the beset solution would have been to fork the project. Since google is big [citation not needed], most development effort would probably end up there, but people who wanted the simple version could stick with it.

The difference between a HTTP API and gRPC is one of scale. If the HTTP one is a few bytes more per message, and takes a few more clock cycles to decode, then at google-scale that might mean extra energy use on the order of a small town. RPC makes complete sense for google here.

Then there's reliability. If something fails one in a million times, it's a minor inconvenience to someone who uses it once a day but if you're running it four billion times a day then you start to notice. gRPC is strongly typed so it actually removes the malformed HTTP failure mode - and you can bet that google's SREs are taking care of the other ones too. When the OP says "Quality is, alas, a dying art", I'm not sure whether that's an honest description of just how many "nines" the google SREs are building into their projects. It's not like they invented gRPC to make their systems less stable!

I can recommend rachelbythebay's comments on this, she's a SRE who has done the rounds in silicon valley - appropriate posts here are "Some Items from my Reliability List" [1] where she famously says "there is far, far too much JSON at $company" and ends that section with "Why aren't you using some kind of actual RPC mechanism? Do you like pain?" - at the scale she's operating, RPC is less pain it would seem.

In "We have to talk about this Python, Gunicorn, Gevent thing" [2] she criticises the use of a popular python framework at the scale she's operating at (I'm sure this was shared on HN in the past).

This doesn't mean that python, "RPC over HTTP", JSON or etcd are in any way bad. In fat their simplicity makes them great things for beginners to learn and medium to large companies to use - they're not just prototyping tools, people can and do build a lot of real stuff with them. It's just that at some point before you get to the ridiculous scale of google's infrastructure, there's a tipping point where going full RPC starts saving you a lot more than it costs; that's not a bad thing and it has nothing to do with trying to "capture the market" or anything like that. A corollary of this: precisely because google works at such a scale, there will be a lot more developers working on grpc-etcd than the "consumer" one.

Summary: developer builds great tool for A; big company has use case B.

[1] http://rachelbythebay.com/w/2019/07/21/reliability/ [2] http://rachelbythebay.com/w/2020/03/07/costly/

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

#550

Post by thyrsus »

I'll pile on: I'm working through Marko Luksa's "Kubernetes in Action", where he introduces this quaint line of code:

  etcdctl ls /registry
He notes in an aside that you may have to do

  etcdctl get /registry --prefix=true
for later versions of the protocol. But here I am with k8s 1.16, and etcd has been locked in a pod (seriously, why?) so before you contact it you need to "kubectl exec ..."

We're not finished. Apparently the pod was insufficiently secure, because now we need to decorate the etcdctl with a couple certificates, a key, and do SSL encryption to make contact, so in the end I have this wrapper (names changed to protect the guilty):

  $ cat ~/bin/etcdctl
  #!/bin/bash
  declare -A EtcdHost=(
    [clust_prodA]=clust1-leader
    [clust_prodB]=clust2-leader
    [clust_qualA]=clust3-leader
    [clust_testA]=clust4-leader
  )
  if [ ! -z ${EtcdHost[$cluster]:-} ]; then
    export KUBECONFIG=$HOME/.kube/$cluster
    exec kubectl exec etcd-${EtcdHost[$cluster]} -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl --endpoints https://${EtcdHost[$cluster]}:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key --cert /etc/kubernetes/pki/etcd/server.crt $*"
    exit 0
  else
    echo "No known etcd host for cluster $cluster";
    exit 1;
  fi
The entry points for beginners have been nearly barricaded, and the ladders charred and dangling high.
Post reply on HN