Hacker News Reader

Comment by gnur | Hacker News Reader

It's mostly a rant about someone not accepting that extra performance can come at the cost of complexity.

While I could argue with all the points that he's making, my main counterpoint is this: junior devs don't care that their http/2 server uses way more "complex" code then their http/1 server, it's just a flag away (or in most cases, automatic). Senior devs worth their salt also don't care, if I design an application that is going to run on kubernetes I now know it will run in the big cloud providers and on premise without major changes. It forces you to accept that your app will die and needs to be able to run from a cold start without any issues. I can't count the number of machines I've encountered over the years that couldn't be rebooted because the maintainers monkeypatched the crap out of it while running EoL distributions, libraries and web servers.

And now I've realized I've become a geek yelling at the cloud as well.

View on HN

The performance benefits are aimed squarely at the large, entrenched interests who can absorb the increased costs as a rounding error. HTTP/2 and SPDY/QUIC look, to me, to be about decreasing costs and increasing efficiency for large web hosts and erecting barriers-to-entry for competitors.

I mean, who are these newcomers we're talking about? There's basically never a reason to roll your own web server. I guess if you want to compete with Nginx, sure, the barrier of entry is a higher now? But that's an incredibly niche case.

Where's the barrier to entry?

HTTP/2 is more complex to implement from scratch (but still quite doable, even as an individual), but it has built-in support in every language & framework worth its salt now, so you don't need to do that.

If you're using an existing implementation, that's usually just as easy to do as HTTP/1.1, because they have almost exactly the same semantics (that's an explicit goal from the spec), and so most implementations have almost exactly the same API.

In practice, it's a syntax & connection management change on the wire that's mostly invisible as a developer building on top of it, plus a set of optional extra features (like Server Push) that you can use if you want or ignore if you don't.

Can't speak for QUIC/HTTP3, since I haven't touched them yet, but I'd be a surprised if that's a hugely different story.

I must have read an entirely different article. The one I read was about simple tools being redesigned for environments most people don't work in.

I also disagree with much of the rest of that, but the clouds are getting sick of me today.

etcd never was simple.

if you wanted simple, there was redis or memcached.

it's an arbitrary cutoff to call etcd simple (it implements Raft, for fuck's sake, it implies a distributed system, multiple odd number of nodes to avoid split-brain!)

systemd is simple, fixed config format, comes with every distro, default works, has extensive documentation, compared to undocumented distro-specific init scripts written in sh (or bash, or worse).

sure, if someone just wants to hack on their 8bit toaster, then they might find a simple shell script simpler.

but the post is not lamenting that.

Heroku also forces you to accept your app will die and needs to run from a cold start. Surely there's more to this k8s thing than "it's cheaper than heroku" ?

Remember that the author is talking as a sysadmin, not as a dev

Reply on news.ycombinator.com