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

91–100 of 220 posts

Re: Simple Systems Have Less Downtime (2020)

#91

Post by 0xbadcafebee »

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…

Actually I think Djikstra's comment still applies. A lot of time the essential complexity is due to design. That design may have said essential complexity because the design is poor, when a different design would have less essential complexity. But as Djikstra says, the design with more essential complexity often sells better.

Re: Simple Systems Have Less Downtime (2020)

#92

Post by Retric »

eatonphil wrote: post #87
naasking wrote: post #81

Earlier quoted context omitted.

The question to ask is whether building a cache of normalized data will be more efficient than addressing the complexities of non-normalized data, eg. duplication, renaming, integrity problems, etc.

Totally. All I mean to say is that "everything should always be normalized" doesn't necessarily make sense. You need to consider your situation.

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.

Re: Simple Systems Have Less Downtime (2020)

#93

Post by eatonphil »

reilly3000 wrote: post #89
eatonphil wrote: post #74

Earlier quoted context omitted.

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

Use a columnar database for this. Use materialized views. Don’t do this on the prod DB for the CRUD app. Simple :)

That sounds good!

Re: Simple Systems Have Less Downtime (2020)

#95

Post by naasking »

AllegedAlec wrote: post #3

I disagree with the notion that a container ship is a simple system because 13 people can man it. It just means that the complexity is hidden in deeper layers.

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.

Re: Simple Systems Have Less Downtime (2020)

#96

Post by dredmorbius »

naasking wrote: post #85
dredmorbius wrote: post #76

One of my hobbies is tracking down the origin of concepts and phrases. One such phrase is "complexity is the enemy", which I'd first encountered through the Jargon File, though it appears elsewhere, e.g., http://www.neugierig.org/software/blog/2011/04/complexity.ht... Tracing that trough Google's Ngram Viewer, I found the extended form, "complexity is the enemy of reliability " in a short item in a 1959 issue of The…

> A full definition of "simplicity", as with "complexity", lies somewhat in the eye of the beholder. Perhaps "somewhat", but not entirely or arguably even mostly: http://curtclifton.net/papers/MoseleyMarks06a.pdf

Simplicity is simple to define for simple problems, but complex to define for complex ones.

Re: Simple Systems Have Less Downtime (2020)

#97

Post by throw0101a »

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 education to appreciate it.

Also true with personal finance:

* https://canadiancouchpotato.com/2016/01/25/why-simple-is-sti...

Re: Simple Systems Have Less Downtime (2020)

#98

Post by postfacto »

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…

Truest comment I’ve read so far.

If simplicity is always the right solution, then why do so many programming languages have dedicated parsing libraries for .csv, which has to be the world’s most simplest data format ever?

Re: Simple Systems Have Less Downtime (2020)

#99

Post by zinekeller »

dredmorbius wrote: post #76

One of my hobbies is tracking down the origin of concepts and phrases. One such phrase is "complexity is the enemy", which I'd first encountered through the Jargon File, though it appears elsewhere, e.g., http://www.neugierig.org/software/blog/2011/04/complexity.ht... Tracing that trough Google's Ngram Viewer, I found the extended form, "complexity is the enemy of reliability " in a short item in a 1959 issue of The…

> I'm told that the UK generally has excellent availability of government publications, though none of https://www.gov.uk, the National Archives, nor the British Library seem to turn up the Factories report presently.

Since this is from 1956, its copyrights have already expired (or waived, as the case may be, see https://lists.wikimedia.org/pipermail/wikipedia-l/2005-May/0...), so scanning it is a fair game, but if the British government (probably the National Archives) scanned the document, it would add another 25 years* to the digital version (unless released under OGL).

* At least in Britain, in the US simple photographic copies are not considered as derivative works and therefore not in copyright.

Re: Simple Systems Have Less Downtime (2020)

#100

Post by cbushko »

threeseed wrote: post #23
stingraycharles wrote: post #8

Earlier quoted context omitted.

While what you’re saying is, of course, fair, the other side is also true: people often choose to complex a technology “because it’s future-proof!”, while they need just a simple system. There are tons of examples: CQRS over simple databases, Hadoop while a single server suffices, or even people choosing JIRA over a simple trello board. As such, the obvious answer is “it depends”, and making the right trade-off is ra…

> CQRS over simple databases, Hadoop while a single server suffices, or even people choosing JIRA over a simple trello board I've heard this from many engineers over the years. But what I've often found is that they were never involved in the decision making process and so aren't aware of all of the business requirements. Once they are made aware usually they agree with the choice. Common example being the business r…

It seems to me that the concepts of high availability, scalability and resilience are things that are just not taught or emphasized at most companies average at all. As Ops, this is a daily battle of education and prod readiness checklists.

It is even the simplest things that are ignored such as:

  - what happens to your db query when you have 1 million records?
  - what happens when the cache goes away?
  - do you even use a cache?
  - why are you treating your cache as a DB?
  - can we run 2 copies of your service?
  - can your service scale up and down?
  - does your service have state?
Kubernetes has been a boon for us in this department. Since pods can be moved/deleted at a moments notice we have had to make our software resilient and stateless. Yes, kubernetes is complex at first but it pays off hugely when you are no longer getting paged because 'server X hung and needs to be rebooted'.
Post reply on HN