Etcd, or, why modern software makes me sad • Hacker News Board

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

#411

Post by chris_wot » Tue, Jul 14, 2020, 11:05 PM UTC

neurostimulant wrote: post #312

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…

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.

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

#412

Post by pm90 » Tue, Jul 14, 2020, 11:08 PM UTC

Nextgrid wrote: post #377

pm90 wrote: post #362

Earlier quoted context omitted.

Almost everything in your comment is wrong. Kubernetes has enabled a whole host of observability tooling (eg opentracing), promoted a culture where app logs are easily and always accessible, enabled 0 downtime deployments for teams without dedicate infra specialists and so much more. It has made deploying reliable applications a lot more easier than ever before. Services today scale to handle a lot more users and tra…

Kubernetes does indeed have advantages but also brings a whole layer of complexity, overhead and moving parts. From my experience, in many cases the theoretical advantages don't end up being worth the tradeoff and/or don't even end up being implemented. Furthermore the particular things you mention (tracing, centralized logging & no-downtime deploys) can be done just as easily without Kubernetes. I disagree about not…

Your answer to everything I said is “actually, it’s not that hard without kubernetes”. Maybe it’s not for you. For most developers, it absolutely is. And that’s why kubernetes is popular.

Fads don’t form out of thin air. There’s always some value that they provide. To someone experienced with setting up infrastructure, the tasks may seem trivial, and the value add is low. For others who don’t, having a dead simple way of easily adding tooling around their applications is a godsend. Why is this so fucking hard for you to understand?

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

#413

Post by apta » Tue, Jul 14, 2020, 11:10 PM UTC

cmrdporcupine wrote: post #315

sercand wrote: post #267

Earlier quoted context omitted.

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

> By falsely representing a _remote_ resource as if it was a _local_ one we open a whole can of worms

I've heard this argument before, but how does gRPC itself cause this issue to manifest? I'm curious to hear what your opinions are on a better alternative, and how not to represent a remote resource as a local one.

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

#414

Post by tomc1985 » Tue, Jul 14, 2020, 11:10 PM UTC

icedchai wrote: post #254

gcbw3 wrote: post #238

Earlier quoted context omitted.

describe the steps to release the simplest ever code in javascript to production: write a js file, host it, done. The same thing in TS adds at least one step (not to mention the rest of the tooling you will want) So while a prefer it over JS, there's no arguing that it is more complex as now you require a build step for a language that only exist because people wanted a language without a build step.

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

Yeah, fuck those guys. script tags or GTFO of my project!!

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

#415

Post by icedchai » Tue, Jul 14, 2020, 11:15 PM UTC

coldtea wrote: post #347

throwaway744678 wrote: post #332

Earlier quoted context omitted.

Now, that is a bold claim. Are there any stats on that?

"Nobody" here means few, or more loosely, much fewer teams than before, not "literally 0 people/teams". And the group mentioned is (I deduce) not generally individual devs, enterprise devs building some internal thing, and so on but teams in companies doing public-facing SaaS, teams in startups, companies like Amazon/Google/Facebook/Apple all the way to AirBnB etc, and so on. So, you don't really need stats for that.

Yes, exactly. The larger the team, the more likely someone is a front end expert and wants to use latest cool framework, which will by its nature require a build step. Even for something simpler, you'll probably want it for cache busting, minimization, etc.

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

#416

Post by ZephyrBluu » Tue, Jul 14, 2020, 11:17 PM UTC

Nextgrid wrote: post #338

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…

A company I used to work for needed a website. They already had a backend and a REST API (served on the same domain as the website should be) and the old website was served directly by the backend that also served the API. I am not aware of why it was chosen to retire that and separate the website into its own service - maybe there was a good reason, so I won't comment on that. However the approach they (or rather so…

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.

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

#417

Post by threeseed » Tue, Jul 14, 2020, 11:18 PM UTC

umvi wrote: post #329

mst wrote: post #135

Earlier quoted context omitted.

I feel like the blog post could largely be summed up as "stop threatening to remove the normal HTTP API, some of us find that a lot easier to debug and ease of debugging is essential for a core operational component of a distributed system" - which is, I would argue, an entirely reasonable thing to want. I quite enjoyed the rantiness on a "being entertained" basis but it did rather work against effectively making the…

> stop threatening to remove the normal HTTP API, some of us find that a lot easier to debug I've seen the trend toward complexity in other projects too, and it harms not just ease of debugging, but ease of hacking. Take, for example, Swagger UI[0] v2 was so simple. It was vanilla JS using jQuery. I, as an embedded systems developer, was able to easily hack it so it could read in the OpenAPI JSON from a database and…

Complaining about an open source project changing technologies because you can't be bothered to learn them is a bit rich.

Fork Swagger v2 and make your own improvements. No one is stopping you and it's what open source is all about after all.

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

#418

Post by fightme » Tue, Jul 14, 2020, 11:19 PM UTC

mjw1007 wrote: post #183

I don't know anything about what's happened with etcd in particular, but I think there is a genuine problem in this area with the model of "the people doing the work get to make the decisions". If you have a piece of software which is basically finished, and a group of people come along who are interested in extending it far beyond its original purpose, then it's very easy for those people to end up as the official m…

Hi, thank you for admitting in your first sentence you're not qualified to comment on the subject at hand, yet felt compelled to share your two cents. Here's the context for your totally uninformed opinion:

I was a major contributor for etcd 2.3-3.2 at CoreOS. The people who extended etcd to support gRPC included the original etcd author (hi Xiang). gRPC support was necessary for good performance; we had benchmarks to justify the decision. Likewise, v3 brought about a key-value model change that was incompatible with v2 to better support binary data, ranging over the keyspace, transactions etc. A v2-style gateway for v3 with a pretty JSON API was planned but never completed due to lack of resources; the ugly gRPC json gateway turned out to be good enough for most people. Similarly I wrote a proxy to run v2 requests over v3 instances, which does support the v2 JSON API. This isn't as if a new group of people showed up and ruined the software without caring about existing users. None of us were "Xooglers".

It seems what you're proposing is what the author both argues against and wrongly believes is what happened. We constantly pushed back against k8s influence. If we didn't, etcd would be a k8s sub-project right now. I'd also like to point out that removing the people who do the difficult work of actually writing the software from the decision process is incredibly insulting and devalues their labor. How dare you.

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

#419

Post by wisty » Tue, Jul 14, 2020, 11:22 PM UTC

sfgweilr4f wrote: post #349

Gibbon1 wrote: post #244

Earlier quoted context omitted.

My first boss (rip) had a internship with a defense contractor his junior year in college. They gave him one project. Design a cover for the air intake for an APC or some such. Easy!!! No not actually easy because of all the constraints. It had to be stowable. So a hard cover was out. It couldn't produce toxic fumes if it caught fire. So most plastics were out. Cloth was a problem because it couldn't get sucked into…

Those constraints seem a lot more reasonable than what I've seen in other aspects of the business world. At least they are grounded in the realities of the actual purpose. Well, mostly anyway. I'll leave justifications for the $1000 left-handed hammers as an exercise for later. I've seen (and removed) plenty of requirements that were put in the specification just because . Because someone needed X amount of Y technol…

As I remember the actual story:

The the hammer was waaaaay more than $1000. But that's because the military said "We'll pay you a total sum of X, but to make it easier to fund the project we'll let you break it into n parts and pay X/n per part".

The contractor decided that to make their cashflow smoother, they'd include "manual impulse force generator" as one of the deliverable parts.

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

#420

Post by mumblemumble » Tue, Jul 14, 2020, 11:24 PM UTC

Twirrim wrote: post #348

greyhair wrote: post #203

Earlier quoted context omitted.

It makes me think of military contracting as a parallel example. (at least in the USA) The rules required to develop, build, and deliver military equipment to the US is exceedingly complex. And it isn't necessarily a benefit for the Pentagon, as much as it is for the established defense contractors. The barriers to entry in that industry are huge, purely based on the contracting requirements. So complexity (in tools…

> And it isn't necessarily a benefit for the Pentagon, as much as it is for the established defense contractors. As with many government related procurement systems, there is so much paranoia about abuse, and desire not to repeat various disasters from the past, that the system has by perceived necessity become complicated. Of course it makes it frightfully expensive to the degree that few companies can actually thro…

It's like a macro version of the story told in Capt. David Marquet's book Turn the Ship Around! Huge piles of bureaucracy, complexity, and waste build up in an organization risk avoidance is allowed to become the primary goal.