Live data from Hacker News

Simple Systems Have Less Downtime (2020)

gkogan.co

41–50 of 220 posts

Re: Simple Systems Have Less Downtime (2020)

#41
post #18

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…

> a single server suffices A genuine question that I wonder about: How does a single server protect you against someone in your DC pulling a plug by mistake or your cloud provider being unreliable? If it’s a database it seems like a huge potential for going out of business. I guess if you are running single-server databases you better have a good backup strategy anyway, but is that a risk people and businesses just a…

> How does a single server protect you against someone in your DC pulling a plug

That’s why you have redundant power supplies with separate power cables.

Re: Simple Systems Have Less Downtime (2020)

#42
post #40
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…

Would turning that font rendering into a web service an accidental complexity, or an essential one?

Accidental, of course. There is never a need to introduce latency in text delivery, simply a long line of unmitigated wants.

Re: Simple Systems Have Less Downtime (2020)

#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.

Re: Simple Systems Have Less Downtime (2020)

#44
post #11

I think a better point would be "simple systems are quicker to fix" or, more concise, "avoid unnecessary complexity". In some way, complexity allows flaws to get in, but that does not mean it's unnecessary. Take, for example, website hosting. You can put your full page on a single server, but then you're prone to the machine going down, the disk having errors etc.. A more complex system, like Kubernetes, will be far…

Until recently even the huge airliners had physical strings going from the rudder all the way to the wing and tail control surfaces. Precisely because more complex systems were less reliable.

Also, even with fly by wire there’s sometimes (or often, or always, no idea) a backup, eg a direct electric / hydraulic link.

Re: Simple Systems Have Less Downtime (2020)

#46

People don't go out of their way to build complex systems. What happens is that it starts simple and becomes complex as more features are added often with limitations attached e.g. time, money etc. So yes this guy migrated from Marketo to Hubspot and it was simple. But the idea it will simply remain that way is laughable.

That's not always true. Developers like to well, develop, and so they like to implement all of these things irrespective of the fact if those things are actually needed.

That happens way more often that people think. Developers do indeed like to develop things.

We frequently run into customers who want to implement some feature or system, which really should just be handled by their load balancer, database system or some standard Unix tool.

I currently work with a customer who have an... interesting approach to api-gateways. We already ripped out 75%, because it either does NOTHING or have been replaced by rules in ha-proxy, which we use anyway. The last bit of code can just be integrated directly into the single remaining service behind the gateway.

The same client is running Redis, which seems innocent enough. Fairly simple, easy to manage, but it only hold ONE item. A 150kb JSON document... That's can just go in the memory of the signle process which needs it and which is responsible for refreshing the document anyway. Worst case is that it takes 60 seconds more to restart the service.

Re: Simple Systems Have Less Downtime (2020)

#47

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.

It seems like it should be objective, but it isn't. Because you get people writing ridiculous "clever" one-liners that are difficult to parse and understand. That clever one-liner could be re-written to do the exact same thing and be much more clear and readable, but it would take, say, 8 lines instead of 1.

Then there's the subjectiveness of what you actually consider a "line".

Re: Simple Systems Have Less Downtime (2020)

#48

“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

He also have the quote: "Simplicity is prerequisite for reliability."

Re: Simple Systems Have Less Downtime (2020)

#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 much fun setting this all up, the ballooning complexity of all this outpaced the benefits and it felt more fragile than where I came from. I decided to just scale vertically and keep it simple.

Most of my refactoring these days is coming up with more simple, more manageable solutions.

Re: Simple Systems Have Less Downtime (2020)

#50
post #42
post #40

Earlier quoted context omitted.

Would turning that font rendering into a web service an accidental complexity, or an essential one?

Accidental, of course. There is never a need to introduce latency in text delivery, simply a long line of unmitigated wants.

Thai reduces a number of companies, eg Slack, to an “accidental complexity” then.
Post reply on HN