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

71–80 of 220 posts

Re: Simple Systems Have Less Downtime (2020)

#71

Post by chousuke »

Puts wrote: post #25

When people face a new problem they intuitively try to find something they can add as a solution, not thinking about what they can remove to prevent the problem from occurring in the first place. This becomes apparent in the way marketing works. You sell products by promising they will solve a problem. You don't sell things by telling people what they really need to hear, that they just need less of everything. Simpl…

Part of this seems to be that people are afraid of removing parts of a system. It's easier to add stuff because you "know" you aren't removing some important bit, so it's "safer", even though the new stuff is likely to interact with the old stuff in unexpected ways and break things anyway.

Re: Simple Systems Have Less Downtime (2020)

#73

Post by sdevonoes »

mschuster91 wrote: post #55
sdevonoes wrote: post #31

Earlier quoted context omitted.

I would go one level up and ask "do we actually need Jira, Confluence, GitLab, Jenkins, whatever on premise?". The question then is not "K8s or manual way", but "Do we actually need K8s?"

Many companies in the EU actually blanket ban any storage of their sensitive information in the cloud, especially the Atlassian cloud after the Australian espionage law change.

That's a good point! Then we raise the question one level up: "does the current law regarding storage of sensitive information make sense?" It's a never ending story for those who like to delve in these sort of things.

Re: Simple Systems Have Less Downtime (2020)

#74

Post by eatonphil »

bob1029 wrote: post #65
kaba0 wrote: post #36

Earlier quoted context omitted.

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…

> 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't normalize. But normalizing creates its own problems too you may need to think about.

Re: Simple Systems Have Less Downtime (2020)

#75

Post by chousuke »

lmilcin wrote: post #15

It should really say "overcomplicated system tend to break more frequently". It is not simplicity that makes for less downtime, it is unnecessary complication that does the opposite. I spend time to complicate my applications a little bit to make sure there is no downtime, something pretty important when one of the largest banks on Earth will stop along with your application. The simplest solutions would typically no…

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 downtime".

What I think is important most of the time instead of zero downtime is predictable behaviour when failures occur, so that your system doesn't end up in an undefined state where you don't know if you can recover without data loss.

Re: Simple Systems Have Less Downtime (2020)

#76

Post by dredmorbius »

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 Economist (Jan 18, 1958, volume 186 https://books.google.com/books?id=aDsiAQAAMAAJ&q=%22complexi...).

That in turn was referencing the UK's Annual Report of the Chief Inspector of Factories for the Year 1956, which had been published in late 1958. Among the factors assessed was factory and equipment reliability, which scaled precisely inversely with the number of components in equipment.

https://www.worldcat.org/title/annual-report-of-hm-chief-ins...

Software isn't quite the same as mechanical equipment where individual components may wear, but each software component does exist and interact in relation to others. And eventually that complexity comes home to bite.

A full definition of "simplicity", as with "complexity", lies somewhat in the eye of the beholder. But extraneous components are a problem.

(I cannot find either reference online, presently, though I've copies of both documents. I'd tracked the Economist issue through Google Books, and received a copy of the report through a friend. 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.)

Re: Simple Systems Have Less Downtime (2020)

#77

Post by karmicthreat »

bob1029 wrote: post #65
kaba0 wrote: post #36

Earlier quoted context omitted.

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…

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

Going to high levels of normalization also makes the code harder to understand. It's very extensible, but every system that I have dealt with that had high levels of normalization was a huge pain to figure out.

Re: Simple Systems Have Less Downtime (2020)

#78

Post by scythmic_waves »

bob1029 wrote: post #65
kaba0 wrote: post #36

Earlier quoted context omitted.

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…

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

I'm curious, can you recommend an open source example that implements these ideas? My first reaction when I read

> You just need to tack SQLite onto whatever preferred language you use today and model all your business logic as SQL queries over properly-normalized tables.

was to think "well that can't work for _all_ my business logic". But I'd like to see how this idea works in practice before I jump to that conclusion.

Re: Simple Systems Have Less Downtime (2020)

#79

Post by ehnto »

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…

I wrote a piece about that some time ago. The vast majority of the complexity in my professional career now is extra curricular complexity and that wasn't true a decade ago. It's build processes, it's CI, it's containers, it's a dozen arbitrarily different frameworks, microservices, dependency management, it's all of that stuff.

The trope I see all the time is enterprise tooling in small projects. Small teams basically moon-lighting as devops 50% of their time and reducing their capacity to solve the actual domain problems significantly.

The domain complexity is something you can't remove, but complexity you've chosen to introduce through tooling should be hard thought about, and the less time you spend thinking about stuff outside the problem you're actually trying to solve the better.

Re: Simple Systems Have Less Downtime (2020)

#80

Post by ubermonkey »

A pattern I see with some companies -- usually, but not always, companies with little turnover, which leads to internal stagnation -- is the foundational belief that THEY ARE VERY SPECIAL and need things done a CERTAIN WEIRD WAY that is not supported by any commercial offering.

Often, this leads to homegrown solutions that are never at feature-parity with COTS options, but have the benefit of costing more.

If they buy something instead, they festoon it with a bunch of customization and external, parallel tools that must be kept in sync at the data and configuration level for everything to "work".

What they NEVER do is re-examine their assumptions about how they must work, or interrogate why they can't go the same route as the bulk of the market on these points and thus have a simpler, more maintainable, less frustrating system in place.

It's not quite this bad, but it's ALMOST like a company insisting that "well, here, for historical reasons, 2 and 2 are 5, not 4, so we have to do . . . . "

It's exhausting, but OTOH, well, to the extend that my employer is involved, we tell them our recommendations but ultimately bill by the hour.

Post reply on HN