Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

461–470 of 648 posts

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

#461

Earlier quoted context omitted.

He is talking in absolutes (Kubernetes being the worst piece of software, etc) and trying to convince reader that "megacorporations" are the faceless evil enemy and they are making everything worse for everybody. Either you are with him or against him (servant of the evil megacorps' interest), there is no middle ground. This person is not looking for a conversation, but looking for a fight. He seems to be angry and c…

Sorry but even though I disagree with most of the points from the article, I prefer to read this instead of a shy and unconfident rant from someone that's afraid of insulting your favorite tech.

What about a third option, where the author makes focused criticisms supported by clear explanations instead of the shy and unconfident strawman you've constructed?

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

#462
post #412

Earlier quoted context omitted.

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

I am approaching this from a developer's perspective. Kubernetes and similar (even local Docker) introduces an extra layer of indirection that you often have to fight with. Sometimes it's worth it, sometimes it's not. For me, if my application is misbehaving in production, I prefer being able to just SSH into the machine and figure out what's wrong than fight with the container layer, its authentication system, command-line syntax just to obtain a shell inside the container. When I am developing locally, I prefer having all my files on the local filesystem instead of having to worry about volume redirection and "docker exec".

I am not an expert in setting up infrastructure by any means. In fact if I were I would probably use and promote these technologies. But in my opinion, adding another layer of abstraction doesn't magically solve the problems of the underlying stack (it won't protect you against obscure Linux kernel behavior, but now you have yet another moving part and potential variable which you need to account for when troubleshooting) but still gets in the way when you're trying to do something simple that doesn't even require any of the advantages the container technology is offering.

When it comes to "adding tooling around their applications", I am not sure what you mean but I will assume you refer to your previous examples, in which case I do not see how container technologies change the game at all. Tracing and centralized logging require your application to talk to a centralized log server (for logs, you can also output to stdout and have systemd/syslog collect and send them to the logging server) and container technologies don't change anything here.

I am not saying that container orchestration technologies provide no value. I am saying that they are often overkill for the task at hand and introduce extra complexity, moving parts and management overhead.

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

#463

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…

Because IBM was there 20 years ago and not only left behind a pure-IBM stack, but got their RUP requirements written into the policy manual as a barrier to entry for any non-IBM vendor to take over.

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

#464
post #318
post #279

Earlier quoted context omitted.

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?

Perhaps I disagree with the implied assumption that a big web site was the answer. I don’t have an answer for you beyond that, because step one is challenging the increasing belief that Big Web has computing figured out and we need not evaluate the decisions and foundational technologies and delivery models that have led to where we are. Step one is a mountain, as you can imagine, and it’s possible to start the conversation of climbing it with only a handful of ideas of what could be over it. Many smart people with quadruple my intelligence and foresight have toed these waters throughout computing’s history. They just lose to hype and marketing.

I realize that’s an underwhelming answer, but if we asked that everyone who disagreed with the status quo simultaneously proposed a perfect solution to fix it, we would be nowhere in any sense. I assure you that thinking about the answer to your question is a significant part of my life, and talking to people who use computers to shape that thinking is key. Government was largely responsible for setting the computing agenda and spurring all of the right technologies in the beginning, and I believe there is merit to revisiting that thinking rather than ceding computing to engineers on the West coast.

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

#465
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 attribute this companies that can afford to keep way too many high skilled employees on the books while needing to keep them occupied

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

#466
post #433

Earlier quoted context omitted.

> They increase attack surface by supplying a vector to any neighbour Could you explain what you mean by this? I'm still not getting it. Here's the example I have in mind: I have one application listening on a TCP port, and another one listening on a different port. I don't want the first application to talk to the second application. If they're just two processes on the same machine, they can both see each other, an…

Trusting the isolation like this is absolutely misguided, to the extent that it’s in conflict with understanding how computers work. Those who do not remember rowhammer or spectre and their kin are doomed to repeat them. As for your example, there’s no difference between that and OS mediated mandatory access controls, separation of uids, chroot etc. Those capabilities are present irregardless of whether you’re using…

I feel like you are several metaphors removed from me right now. Rowhammer? Spectre? I am just trying to serve a couple of websites here! I'm not going to buy another rack of servers just to isolate the two. Have you seen how expensive those things are?

> Anyone selling you on containers as a security measure is pitching snake oil. They are a resource allocation & workload scheduling tool.

I agree with both of these statements — and I suspect this is where it all falls down. When you put all your applications in containers, you are not done with security, no. Nevertheless, I've found great value in having one file per version per application, being able to upgrade my dependencies one-by-one, automatically rolling back in case of failure, and taking advantage of the tools in the container ecosystem. With all that, the security features such as isolating filesystems and network ports are just the cherry on top. Before containers, I was thinking about how to give my applications limited filesystems to work with, but along came Docker, and I didn't have to think about it anymore, because I'd already done it.

This is why I feel so out-of-touch with many of the commenters here. I'm surrounded by people decrying containers for security reasons, I want to defend them because of the many benefits they have given me, and I think the people preaching some kind of True Security (where everything is 100% perfectly isolated) aren't taking this into account. I feel like I could take your comment — "Trusting the isolation like this is absolutely misguided" — and apply it to any part of the stack. You have to stop somewhere.

I've seen the salespeople. They definitely exist, but I don't think they're here on HN, and they're more likely to be learning than lying.

And developers making flawed assumptions? You know this didn't start happening with containers!

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

#467

Earlier quoted context omitted.

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.

It's a combination of resume-driven development and premature optimization.

The former doesn't need explaining but the latter can be explained as developers being concerned about requiring the benefits of GraphQL in some uncertain future and decide to include it from the start, even though in most cases they end up never actually reaping the benefits while still being plagued by the extra overhead of using that technology.

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

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

I think a large problem is open source projects actively marketing themselves, and seeking large user bases. This leads to a wasteland of zombie frameworks, and developers selling out (so to speak) in exchange for the reputation.

It is important to note, too, that etcd is permissively licensed and anyone can run the old version in whatever way they please.

The final, and biggest, takeaway? Hackernews apparently has drank the koolaid and will reach for any convenient justification to write off an opinion they disagree with. Stockholm syndrome all through the comments. Conservatism and pragmatism apparently are no longer current in the cloud economy.

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

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

> There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes.

That's not really surprising, and maybe should be a lesson to the author. If you want to make a particular point, you shouldn't make inflammatory/controversial statements about other, only-tangentially-related things. It distracts from and dilutes your point.

For my part, I know one of the CoreOS founders, and while I have no opinion on CoreOS itself, it's really off-putting to see some random armchair quarterback on the internet shitting on the work of someone you know. While I more or less agree with the actual real point of the article, the unnecessary attacks really divided my attention.

The article starts off with a cheap potshot at CoreOS, followed by a screed about Kubernetes, and then finally, more than half-way through, we get an admission that the author has "digressed", and we get to the actual point. Certainly the point required some background about Kubernetes, but I can understand why people focus on the negative CoreOS and Kubernetes aspects of the post, since they consist of more than half of the content.

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

#470

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.

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.

Post reply on HN