Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

631–640 of 648 posts

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

#631

I really dislike articles like these. I don't think the author is interested in having any kind of productive discussion or criticism. There's a million reasons to hate Kubernetes, the author couldn't be bothered to venture beyond the lowest hanging fruit (yaml)? If I could downvote this I would.

why does everything with a negative valence attract this criticism? surely there are plenty of times in one's life where he or she says negative things about something (a coworker, a boss, a partner, an acquaintance) without any intent to foster a "productive discussion". as though that is something owed to products / services / people / experiences / whatever that we hate for whatever reason. as though those things would somehow magically improve with any amount of "productive discussion". how about not everyone take it personally when someone dislikes something purely because of the experience that they have had with it? given the comments section, the only way for this "discussion" (some call it a post) to have engendered this tone of discussion while still being on the front page is either (1) everyone disagrees with the post, but hate-upvotes it anyway or (2) the points being made strike a chord with people. and regardless of which it is, this whatever the opposite of saber rattling is that causes this kind of reaction clearly misses the point.

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

#632
post #149
post #112

Earlier quoted context omitted.

But it's not about kubernetes. It's about simple API's becoming complicated for no reason (according to the author, I have no experience on etcd) using etcd as an example

The author doesn't detail _what_ is more complicated about the gRPC API, other than the fact that it's gRPC. One could implement the exact same API in HTTP or with gRPC; so without specific examples, it's kind of a meaningless critique. Surely, most consumers of a database like etcd are using a client library, in which case why does it matter if the API is HTTP or gRPC? Tangential: after reading some of the comments,…

"detail what is more complicated"...

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

#633
post #357

Earlier quoted context omitted.

Almost nobody does Javascript without a build step these days, unfortunately. I miss those simpler days.

You might like deno ( https://deno.land ) then! It’s native typescript.

Except for the core which was recently reverted to ES6 due to Typescript's slugguish compilation and inefficiencies.

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

#634

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…

I made that comment once about "Soylent". (Remember Soylent? The nutritional drink?) That company made a big deal about their "tech stack". Not for manufacturing or quality control, but for ordinary web processing. Their order volume was so low that a CGI program on a low-end shared hosting system could do the job. But they were going to "scale", right? Amusingly, they eventually did "scale". They started selling thr…

That's an amusing story. I suppose the Soylent board met a good salesperson, and the pitch worked. So when the team landed the contract, they had to justify their costs some way... I suspect almost every software project in existence is in some way a victim (or beneficiary...) of fanatical marketing.

I remember working on an simple CMS site, amongst other things, for a pretty large company. When we begun the project, we were tasked with re-purposing an overworked Plesk instance to host the site. We eventually managed to do it, but then found the small amount of disk space that was left to us was getting chewed up by logs.

So I reported this to my project manager, suggesting that we procure more HD space. I think I said something about us 'running out of memory on our hard drive'. The PM promised to feed this back to the client... A week later, our PM said that he and the client had resolved the issue. The client will pay for a new server with a stonking 96GB of RAM!!!

That ought fix our 'memory' issue, right!!?

I mean, it also came with a 1TB HD, a second box for redundancy, dev time for migration, and additional dev time for a switch to Journald, or Logrotate, so I wasn't rushing to point out the misunderstanding... Working with the second box over RedHat Pacemaker was all new to us though, and a complete PITA.

But it was also another 'feature' to sell back to the client. They loved the sound of that. A site that couldn't go down... We made it work, but there was absolutely no real technical need for a Pacemaker cluster and 96GB*2 of RAM. It was just a simple CMS backed site.

Occasionally, that's where such complexity comes from. Not the developers themselves, but some loose cannon of a saleperson. That said, these 'sales people' may even be developers themselves. I often think that's a large part of how and why questionably complicated software exists...

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

#635
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…

> introduce huge complexity into simple, well-designed projects

why does cmake come to my mind?

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

#636
As systems get more complex, whether they need to be or not, the issue I believe is no one takes the time to explain or document why. They just plow ahead building complex stuff at times seemingly so they can say “look at this complex system I built to solve that really hard edge case”. When 99% of the use cases were already solved.

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

#637
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 work in TensorFlow with some regularity, and I've seen explicit examples of what the author of the article talks about where Googlers get used to their own stack (See eg: https://github.com/abseil/abseil-py/issues/99#issuecomment-4... vs what is considered standard Python practice https://github.com/tensorflow/tensorflow/issues/26691#issuec... )

That said, I also see the opposite when this gets some traction with "normal users". The Abseil issue was fixed, and the TensorFlow 2.0 release did make TensorFlow more usable by smaller teams in many situations.

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

#638

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…

To your point: it's situations like this that could (likely) be mitigated if they would have just upheld backwards compatibility: keep HTTP, add gRPC as alternative, 1st class ways of interacting with the tool. I haven't used etcd directly beyond K8, so I don't know if the new versions inherently invalidated the use of HTTP. But seems to me this is just another example of breaking changes...well...breaking stuff.

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

#639
post #258

Earlier quoted context omitted.

> towards unecessarily complicated development processes and architectures please note that what's "unnecessary" for you is not necessarily unnecessary for others. this is an important point. i guess what these projects need is a way to communicate explicitly the costs of maintenance and developer mind-share when adding more complex features to their product. Because especially as small dev team it is difficult to fi…

I think your point is slightly off in its 'angle'. Consider that "unnecessarily-complicated" and "unnecessary" do NOT mean the same thing -- particularly in this case.

that depends on the interpretation.

most people don't mean there is a simpler implementation that has the same feature set and execution properties.

Most people mean it has features i don't need, hence it is too complicated

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

#640

Earlier quoted context omitted.

Yeah, GraphQL seems like a cool piece of tech that's overkill for 90% of the places it's used. I'm a bit confused as to how it's become so popular for normal development when it seems to have a lot more boilerplate and setup than a simple REST API.

I feel like GraphQL is the new NoSQL. Not just that it's mistakenly adopted, but also that it is quite valuable for the right use cases, but the public doesn't seem to understand what those are. Do you really, _really_ need to support queries? 99/100, I'd guess no, and thus constraining people to a more defined interface and access pattern is simpler.

Oh... you need to fill your RDMS with a bunch of JSON responses from your 3rd party API. So you can then decode them in memory because I actually need to select * where identifier = 'banana' to do analytics.

Meanwhile the API returns highly structured data perfect for a RDMS, but we dont know how to query SQL without an API in the frontend. So welcome to my hell.

Post reply on HN