Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple Systems Have Less Downtime (2020)

gkogan.co

Post reply on HN
Print view View original

151–160 of 220 posts

Re: Simple Systems Have Less Downtime (2020)

#151

Post by chousuke »

lmilcin wrote: post #134
chousuke wrote: post #75

Earlier quoted context omitted.

Regarding "no downtime", there are very few applications where that's actually a good goal to have at all. Quite often, simple systems can provide you high availability where your downtime is a few seconds or minutes at most (during larger maintenance operations), and in many cases you can hide those blips by simply retrying (with proper backoff). There aren't many systems where you actually need to guarantee "no dow…

There is more systems that can't tolerate downtime than you think. And this is mostly because you treat it as fabric of everything around you and you only notice when it fails. Mobile networks? Power delivery (basically all utilities)? Broadband internet? Factories? Payment systems? Air traffic control? Any internet services at all? One can think that only Google or Facebook need to maintain high availability, but ba…

Of what you listed, only the telephone network is one where I don't recall experiencing downtime; probably because it degrades gracefully to reduced functionality if something fails. Can't say much about air traffic control, but I imagine they have failures too and just have backup protocols in place when primary systems fail. A payment system is probably the closest to a computer system where you really don't want to drop any incoming requests, though after the initial payment event has been recorded, the behind-the-scenes processing can tolerate quite a lot of delay in the worst case.

Networks certainly fail all the time, and power delivery issues aren't uncommon either; the downtime just tends to be localized and if you depend on your internet connection or power, you have backup links and UPS systems that reduce or avoid the impact of downtime.

I never said you shouldn't strive for high availability, especially if you're moving vast amounts of customer traffic, I specifically made the argument against "no downtime", because people often seem to think that if your system doesn't have five nines of uptime it's unsuitable for handling "real" traffic, and that to achieve enough high availability you somehow need a highly complex system.

Re: Simple Systems Have Less Downtime (2020)

#152

Post by bob1029 »

eatonphil wrote: post #74
bob1029 wrote: post #65

Earlier quoted context omitted.

> accidental and essential complexity I feel like I am turning into a bot for posting the Out of the Tar Pit paper: http://curtclifton.net/papers/MoseleyMarks06a.pdf This changed my understanding of computer science and our product virtually overnight. We are using a hybrid model of Functional Relational Programming (see section 9 in the paper). This is in production right now and its clearly the right answer for man…

The problem is that performance and normalization do not (always) go well together. Let's say you have billions of rows of event data you want to perform summary counts for by a few different key columns. Doing this up front as the events are ingested is going to allow for much more efficient querying on an already grouped table than having to group on your billions of events in each SELECT query. I'm not saying don'…

> The problem is that performance and normalization do not (always) go well together.

Absolutely agree. That is why we use in-memory SQLite projections of business state that are scoped per-user-session so that row counts never exceed double digits in any given table.

For us, adding indexes to these special database instances would actually make things go slower.

Re: Simple Systems Have Less Downtime (2020)

#153

Post by Aqueous »

Jtsummers wrote: post #147
henning wrote: post #145

Not building what doesn't need to exist won't get you promoted. You don't get promoted by avoiding entire classes of problems with a simple, reliable system. You get promoted by pulling heroics to build some absurdly complex cloud Kubernetes bullshit, and then pulling more heroics to fix the endless stream of production issues that will result from your overengineered nightmare.

http://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_... I've posted this here before, though got no comments. But yes, firefighter/arsonists get more promotions and kudos than careful thinkers who don't bother setting fires to fight. EDIT: One past discussion here (2015): https://news.ycombinator.com/item?id=8940820

It is very bad. I spent the last year or so rebuilding a system with a fundamental architecture error that it would likely be fighting against for decades. My reward? The refactor was so difficult to do that I ended up getting dinged on timeline. And promotions got delayed The incentive structures at big companies are out of whack. Instead of the original developer, who was promoted to staff engineer, gettting dinged for making the mistake, I got dinged for not fixing it fast enough, and my career slowed down as a result.

The refactor was incredibly difficult and launched without issue and I am probably back on track for a promotion, but I have started to make noise about the incentives being askew

Re: Simple Systems Have Less Downtime (2020)

#155

Post by DanielBMarkham »

majormajor wrote: post #132
DanielBMarkham wrote: post #88

Earlier quoted context omitted.

>> I think every talk on complexity is meaningless, without taking into account the difference between accidental and essential complexity. Yeah. This is both true and pointless. Nobody codes things too complex on-purpose, at least not normal people. So it's not the difference in types of complexity, it's the difference in our ability to understand accidental and essential complexity. I find that I do a really poor j…

I've worked with a lot of people who'd never thought about the difference between accidental and essential complexity. This resulted in them coding things too complex unintentionally , so while not on-purpose, it was absolutely a useful conversation to have. It's a good starting point. I don't have a good single rule for a "second step," though. It's going to depend on the details of your project, by and large, thoug…

Yup. They don't think about it, but the mind is a funny thing. If you ask them why they've done something a certain way (without bringing up the topic of complexity), folks usually have some good reasons for the things they do.

However, if you bring up the topic, then take a look at some code or architecture? Then suddenly we're talking about all the ways we might have done it better/less-complex if things had been different.

Most every coder I know understands the topic, and most are even willing to go on at length about how important it is, including me! (grin). It's the actual application where things fall apart.

>> I don't have a good single rule for a "second step," though.

I do. It was bugging me so I spent a couple of years coming up with one. Seems to work great for me. YMMV. I do not believe it is as context-dependent as most in our industry seem to think. (It's very much problem dependent, though. It's just vastly more related to the business problem than the technical considerations. [Discussion goes here about tech-related problems not related to the solution foisted on the solutions team])

Re: Simple Systems Have Less Downtime (2020)

#156

Post by dean177 »

nodejs_rulez_1 wrote: post #57
zgniatacz wrote: post #24

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” – Edsger W. Dijkstra

I remember one dev kept talking about simplicity, even made a session about it and then just lumped business logic, data access and transfer layer mapping into a single API file...

Whats the problem?

Re: Simple Systems Have Less Downtime (2020)

#157

Post by the_af »

kaba0 wrote: post #36
zgniatacz wrote: post #24

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” – Edsger W. Dijkstra

I think every talk on complexity is meaningless, without taking into account the difference between accidental and essential complexity. There are problem domains where there is simply a minimal complexity required implicitly. You can’t write an insanely simple program that will render vector fonts, simply because the problem inherently has to have a fixed amount of complexity. Anything more (accidental complexity) i…

> keep believing that it could be made simpler. One really bad example is this list: http://harmful.cat-v.org/software/

That's indeed a pretty bad example, regrettably of a website often shared in programming circles. The author simply listed his beliefs about stuff he doesn't like vs stuff he likes, and never bothered to justify them. In many places the list is obsolete, too.

Re: Simple Systems Have Less Downtime (2020)

#158

Post by eatonphil »

bryanrasmussen wrote: post #140
BoiledCabbage wrote: post #82

Earlier quoted context omitted.

> The problem is that performance and normalization do not go well together. > Let's say you have billions of rows of event data you with to perform summary counts for by a few different key columns. Guess what? 99% of people on here don't have billions of rows of event data they need to regularly aggregate. Problem solved. Such a terrible tradition in our industry in focusing on outlier cases, or on what FB/Google/.…

>Guess what? 99% of people on here don't have billions of rows of event data they need to regularly aggregate. Problem solved. having built a real time analytics solution a few years ago because we wanted one we controlled for our startup, it doesn't take much to get to billions of rows of event data in the modern web.

Yup. How many variations of analytics startups/companies exist out there? How many customers do they each have with how many events happening per customer?

Analytics on large-ish data is definitely a common challenge. And sure, CRUD is even more common. But knowing what your options are for each challenge makes sense.

Re: Simple Systems Have Less Downtime (2020)

#159

Post by [deleted] »

jjice wrote: post #110
zgniatacz wrote: post #24

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” – Edsger W. Dijkstra

> And to make matters worse: complexity sells better Well said Dijkstra. Some of the my favorite algorithms are beautifully simple, mostly in the way of being naturally recursive. My compiler course in university involved a lot of recursion, but everything just flowed. Sometimes I'd mindlessly write some code and just assume I'd recurse down the AST, and everything just worked. Obviously simplicity isn't always achie…

[deleted]
Post reply on HN