Live data from Hacker News

Efficiency trades off against resiliency

blog.nelhage.com

61–66 of 66 posts

Re: Efficiency trades off against resiliency

#61
post #12

Now apply this same reasoning to, say, hospital capacity. Some things need to optimize for the ability to absorb peak load, not steady-state operating costs.

Even hospitals make that trade-off. Every hundred years there are at least a few events that overload steady-state hospitals. The important part is not building the capacity in, it's remaining flexible and adapting to what happens.

>The important part is not building the capacity in, it's remaining flexible and adapting to what happens.

At some point, flexibility requires extra capacity. You can't improvise when you're spending 100% of your resources on operations.

Re: Efficiency trades off against resiliency

#62

Earlier quoted context omitted.

In some applications, this is true. I think 15% is pretty extreme, though, unless what you're doing is something like parsing/ creating data feeds (where the serialization is the point). In those cases, it's probably a good idea to have your own format. Still, JSON would be a lot worse for these cases than protobufs or flatbuffers. Also, are you sure you aren't compressing them if you're using 15% CPU?

Yeah, you almost got it :) It's a simple backing store for a few jobs that create data feeds. Agreed that JSON would be much worse. We have a hard requirement that all services must be Java based, and protobuf outperforms Gson and Jackson by miles. I have been trying to find the cheapest serialization/deserialization I could find for cache purposes. So far, the best option is a Guava/Caffeine cache, because we skip t…

If you are willing to do some DIY-ing, using finance-like encodings may be for you: See "Simple Binary Encoding" (https://www.fixtrading.org/standards/sbe/). The encoding scheme basically just uses structs with version numbering and IDs. There may be some Java code out there for SBE if you want to pull it off-the-shelf.

Re: Efficiency trades off against resiliency

#63

Earlier quoted context omitted.

Yeah, you almost got it :) It's a simple backing store for a few jobs that create data feeds. Agreed that JSON would be much worse. We have a hard requirement that all services must be Java based, and protobuf outperforms Gson and Jackson by miles. I have been trying to find the cheapest serialization/deserialization I could find for cache purposes. So far, the best option is a Guava/Caffeine cache, because we skip t…

If you are willing to do some DIY-ing, using finance-like encodings may be for you: See "Simple Binary Encoding" ( https://www.fixtrading.org/standards/sbe/ ). The encoding scheme basically just uses structs with version numbering and IDs. There may be some Java code out there for SBE if you want to pull it off-the-shelf.

Fantastic! Thank you, this is really useful!

Re: Efficiency trades off against resiliency

#64
post #3

Maximally efficient is minimally robust.

Catastrophic failure is pretty bad for efficiency. Over any serious time horizon, being maximally efficient means finding the optimal level of robustness, given the likelihoods and consequences of possible failures and the costs involved in preventing or mitigating them.

> Catastrophic failure is pretty bad for efficiency.

For the system, but not necessarily for any individual actors in that system.

There is no inherent force that automatically keeps those incentive aligned.

Everybody knows that the supply chains are brittle. Covid, earthquakes, war, etc. all can disrupt them. Yet, do you see anybody holding inventory? Do you see any diversification occurring (very minimally--and mostly to shift from cheap Chinese labor to cheaper Vietnamese/Indonesian labor)? Do you see anybody buying personal protective equipment domestically in the US (nope, everybody went back to buying cheap Chinese crap)?

Re: Efficiency trades off against resiliency

#65

Earlier quoted context omitted.

This is extremely interesting! I have been trying to move away from dumb rate limiting to a more holistic approach that allows us to make smarter decisions with traffic. Your overview made me intrigued. Do you have any references you like to use? I am looking at the Wikipedia page, but it's so removed from practical aspects.

I don't. There simply isn't any tooling or literature to speak of. I have some experience using control engineering in my electronics projects and that's how I came up with the idea to use it for backend systems. I have researched and developed everything myself. I have used "Modern Control Engineering" by Katsuhiko Ogata, but really, mostly I just learned from the Internet. My initial motivation was to remove config…

If one day you'll write a blog post / article about what you're doing, it'd be interesting to read :- )

(What if you start collecting email addresses to people who want to read such an article? And if one day you write one, then you can email them? — My email is in my profile, if you'd like to add it to such a list)

Re: Efficiency trades off against resiliency

#66

Earlier quoted context omitted.

I don't. There simply isn't any tooling or literature to speak of. I have some experience using control engineering in my electronics projects and that's how I came up with the idea to use it for backend systems. I have researched and developed everything myself. I have used "Modern Control Engineering" by Katsuhiko Ogata, but really, mostly I just learned from the Internet. My initial motivation was to remove config…

If one day you'll write a blog post / article about what you're doing, it'd be interesting to read :- ) (What if you start collecting email addresses to people who want to read such an article? And if one day you write one, then you can email them? — My email is in my profile, if you'd like to add it to such a list)

Dunno... most people I meet seem to be put off by my software development ideas. I stick to them because they seem to work very well even if it initially creates a lot of friction between me, the team and the management.

Where to start... I think test driven development and unit testing is not giving promised value and instead wastes time and makes software more difficult to refactor and I think functional end to end testing to be much more effective and cost effective. I think code reviews are bad because they don't deliver on promised value and individual craftsmanship (peoples ability to deliver on their own) and pair programming are better. I think microservices to be a wrong approach for 99.9% projects and fixed a bunch of projects by rolling the software into monolyths. I believe bugs can only be truly reduced by taking responsibility for writing correct code in the first place and anything afterwards is expensive and not effective (you can only remove bugs that manifest themselves, everything else stays). I don't compile/run my code multiple times a day -- I write it all in one go, sometimes for weeks, then run it. If it works it means I know what I am doing and if it doesn't -- it is the failure of my process. Where most devs just fix the bug and restart the app I will start an investigation into why my process failed and how I need to fix it -- NTSB-style. I believe that nobody understand what Agile is and the way it is applied is damaging to software industry. I don't believe in linear development progress -- I design my apps top down and at the same time program them bottom up until top down and bottom up meet together. I structure my development process around rewriting the software -- I write the first version and then I will refactor/rewrite to remove any unnecessary complexity until I am happy with it. There is no working software for a long time and then suddenly it is complete. And when it is complete there is no more testing stages, bugs to fix -- it is truly complete.

So you see, I am probably too alien a developer to give advice to general population of developers.

And when I do talk about my ideas it usually ends in flame wars or drowns being downvoted to hell because people tend to downvote anything and everything that does not confirm their existing worldviews.

Post reply on HN