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

121–130 of 220 posts

Re: Simple Systems Have Less Downtime (2020)

#121

Post by Zababa »

trasz wrote: post #86
mcphage wrote: post #83

Earlier quoted context omitted.

Are you saying that you think Slack's primary challenge is font rendering?

No, it’s providing a web service to do something that would work (and used to work) much better without it. Their primary challenge is making money, and that part probably is better as a web service, but it makes it worse from technical point of view. Just like with hypothetical FaaS - worse technically, but you can have adds.

I'll bite, what exactly worked much better than Slack without the web?

Re: Simple Systems Have Less Downtime (2020)

#122

Post by Jtsummers »

Buttons840 wrote: post #43

I'm going to make a controversial claim for the sake of argument. We can and will debate what programs are "simpler" all day, it's all subjective... except for one metric: line count. Line count is objective. Take pause before rejecting any change that uses fewer lines of code. It takes an awfully good abstraction to beat simply having less code.

Kolmogorov complexity is close to what you're getting at, but is about total string length of the program which is more useful than line count when line count can be gamed. That is, a shorter program is "simpler" than a longer program. In quotes because it's not necessarily true (see code golfing, the language itself may become very complex to permit such a short program and the requisite knowledge and competency then increases the total complexity to achieve, or even understand, the simpler result). A similar technique that doesn't discount meaningful variable names might use syntactic token count. That way:

  printf("Hello, World!\n");
and:

  Put("Hello, World!\n");
Can be treated as the same complexity (the difference is 3 characters, and they are otherwise equivalent).

There are also analysis methods (names escaping me, and Google fu is weak today) that look at loops, procedure calls, dependency graphs, and other things to attempt to discern (should be treated as guidelines and not rules) the complexity of a program using objective metrics.

https://en.wikipedia.org/wiki/Kolmogorov_complexity

Re: Simple Systems Have Less Downtime (2020)

#123

Post by dominotw »

api wrote: post #52
adevx wrote: post #49

I fell for the everything must be a microservice / distributed across as many servers as possible trap. Even though I've read so many warnings about it here on HA and knew upfront I might have to rewind everything. The setup : - Distributed file system using GlusterFS - DNS load balancing using Amazon Route 53 - PostgreSQL HA clusters using Patroni - A WireGuard mesh topology between all instances. Even though it was…

> Even though it was so much fun That’s the root of quite a bit of evil in software. A closely related motive is a desire to show off. Play is good for learning but not for production systems. You’ll regret it later when you are up at 4am on a Sunday morning troubleshooting some Byzantine stack. The antidote is the realization that simplicity is harder than complexity. Simple but highly effective systems are the ones…

> That’s the root of quite a bit of evil in software. A closely related motive is a desire to show off.

Yes but its also driven by keeping oneself employable.

" I built a simple system to do X" is not a winning conversation in an interview. GP's complex system is what ppl say they built.

Re: Simple Systems Have Less Downtime (2020)

#124

Post by Zababa »

ocdtrekkie wrote: post #114
citrin_ru wrote: post #63

Earlier quoted context omitted.

> A simple system such as a hand-written web server is very likely to crash. > Kubernetes is complex, and it definitely gives us less downtime than simple scripts we have written before we use Kubernetes There is a point in between 100LoC hand-written web server and K8s cluster. E. g. you need to serve static files and load is small to moderate (say 1. Create a K8s cluster where HTTP traffic will be dynamically proxi…

My single Intel NUC in my basement on residential cable serves cloud services at higher reliability than Office 365. Sure, it doesn't do it for millions of people, but it's drastically less failure-prone, despite the lack of resilient design. What boggles the mind is people are often sold the cloud even though their org isn't serving millions of users, and could just as easily operate as a box in a closet.

> What boggles the mind is people are often sold the cloud even though their org isn't serving millions of users, and could just as easily operate as a box in a closet.

Capex vs opex may play a part here. Also, companies in general seems to have transitioned to using services in general. 20/30 years ago companies had cleaners in them. Now everyone uses a cleaning service.

Re: Simple Systems Have Less Downtime (2020)

#125

Post by im_down_w_otp »

I'm very confused by the OP.

There's legitimately nothing "simple" about the massive container ship system described in the OP. It's a complicated semi-autonomous cyber-physical system with multiple complex failure modes possible in the software, electrical, hydraulic, and/or mechanical domains. The reason said system has both the superficial appearance of simplicity to its operators and the high-probability of low-downtime is because its very complex systems and subsystems were fastidiously designed and built using tools, processes, and practices which helped manage and understand all that complexity. Not because it is "simple".

Re: Simple Systems Have Less Downtime (2020)

#126

Post by Zababa »

Jtsummers wrote: post #122
Buttons840 wrote: post #43

I'm going to make a controversial claim for the sake of argument. We can and will debate what programs are "simpler" all day, it's all subjective... except for one metric: line count. Line count is objective. Take pause before rejecting any change that uses fewer lines of code. It takes an awfully good abstraction to beat simply having less code.

Kolmogorov complexity is close to what you're getting at, but is about total string length of the program which is more useful than line count when line count can be gamed. That is, a shorter program is "simpler" than a longer program. In quotes because it's not necessarily true (see code golfing, the language itself may become very complex to permit such a short program and the requisite knowledge and competency the…

> There are also analysis methods (names escaping me, and Google fu is weak today) that look at loops, procedure calls, dependency graphs, and other things to attempt to discern (should be treated as guidelines and not rules) the complexity of a program using objective metrics.

Cyclomatic complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity might be what you're thinking about.

Re: Simple Systems Have Less Downtime (2020)

#127

Post by s_dev »

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…

>without taking into account the difference between accidental and essential complexity.

This is acutely summarized by Larry Wall's "Waterbed Theory of Complexity" which is basically Einstein's "Make things simple as they have to be but not any simpler than that". i.e if complexity is like water -- not very compressible. If you compress that complexity (a part of the bed) -- it will manifest elsewhere in the bed as more awkward/expanded because it's all connected.

Many discussions on complexity do make this distinction.

Re: Simple Systems Have Less Downtime (2020)

#128

Post by naasking »

10000truths wrote: post #116
Retric wrote: post #92

Earlier quoted context omitted.

Premature optimization is the root of all evil. It’s unlikely normalizing data is going to be an actual problem you can’t solve via caching.

I hate how this quote has been perverted. “Premature optimization” was meant to apply to people making their programs an unreadable/unmaintainable mess to save a couple of CPU instructions. Figuring out how to organize your data is not premature optimization, it’s literally one of the first things you have to tackle when starting a project, because trying to change it down the line is going to be miserable, especiall…

Yes, and I think the parent was pointing out that denormalization is often a premature optimization that makes the data schema an unreadable/unmaintainable mess to save a few CPU instructions. The normalized schema is answering the question of "how to organize your data". Denormalizing that schema is an attempt at optimization.

Re: Simple Systems Have Less Downtime (2020)

#129

Post by ocdtrekkie »

Zababa wrote: post #124
ocdtrekkie wrote: post #114

Earlier quoted context omitted.

My single Intel NUC in my basement on residential cable serves cloud services at higher reliability than Office 365. Sure, it doesn't do it for millions of people, but it's drastically less failure-prone, despite the lack of resilient design. What boggles the mind is people are often sold the cloud even though their org isn't serving millions of users, and could just as easily operate as a box in a closet.

> What boggles the mind is people are often sold the cloud even though their org isn't serving millions of users, and could just as easily operate as a box in a closet. Capex vs opex may play a part here. Also, companies in general seems to have transitioned to using services in general. 20/30 years ago companies had cleaners in them. Now everyone uses a cleaning service.

I have read about a dozen and a half articles about capex vs. opex, and it still makes absolutely no sense to me why companies prefer paying over double for opex what they'd pay for equivalent capex over the same lifecycle.

Either corporate accounting is some mystical art that makes money appear where there isn't if certain practices are followed, or there's some collective mass delusion that opex is just better? I don't know, it's a concept that truly baffles me.

Re: Simple Systems Have Less Downtime (2020)

#130

Post by naasking »

AllegedAlec wrote: post #103
naasking wrote: post #95

Earlier quoted context omitted.

But the question is, is the 13 manned ship still simpler than one that requires people doing all of those jobs? ie. is maintaining the machinery less complicated than maintaining the equivalent number of people that would be required to do the same jobs? Arguably yes.

I'm doubtful. You might be able to get to harbor more easily if something breaks down along the way, but actually getting the ship fixed afterwards might take longer, because the apparent simplicity is built using highly complex systems. You see the same thing in modern cars, which are often a real pain to fix, because it's all computers and complex parts, rather than one axle going from the steering wheel directly t…

> because the apparent simplicity is built using highly complex systems.

More complex than humans, with wives, kids, need for downtime, hazard pay, insurance requirements, mental and physical limitations, and so on? A lot of the complexity of humans is invisible to us because we're just used to it.

Post reply on HN