Live data from Hacker News

Simple Systems Have Less Downtime (2020)

gkogan.co

1–10 of 220 posts

Re: Simple Systems Have Less Downtime (2020)

#2
So true. I am working with a system currently with tons of "moving parts", once it's up it's neat, but there's always at least 3 things broken every time I install it. The person who created it is the de facto expert, and everyone else just relies on them to fix it or extend the more tricky bits.

It does leave one wonderful if the niftiness is worth the pain, or if there is a way of getting the good bits without the complexity.

Re: Simple Systems Have Less Downtime (2020)

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

Re: Simple Systems Have Less Downtime (2020)

#6
To add a point: "simple" can also mean "standardized".

Self-hosted or cloud-hosted Kubernetes is a highly complex system. But using it to power your internal tooling (e.g. Jira, Confluence, GitLab, Jenkins, whatever) over classic, manually-installed-on-VMs deployment has the advantage that you can drop in anyone with experience in Kubernetes to manage your workloads.

Re: Simple Systems Have Less Downtime (2020)

#7

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.

Yes! In the future, a whole car factory will have only one employee. His job: feed the dog. The dog’s: keep humans away from the machines.

Just as a ship with dozens of people got replaced by 13: the complexity was encapsulated in simpler interfaces.

Diesel motors: just change this lever. Up is fast, down is slow. But it took a century to refine this absurdly complex device until this simple interface became possible.

I think the point here is: don’t build your own diesel motors. It’s unlikely you’ll beat a good model and your interface to it will probably be worst. Remember: people take years learning from their own mistakes to hide the complexity under simpler interfaces layers.

Unless your company IS building diesel motors.

Re: Simple Systems Have Less Downtime (2020)

#8

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.

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 rarely properly captured in a single rule of thumb such as “always choose simple”.

Re: Simple Systems Have Less Downtime (2020)

#10
post #7

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.

Yes! In the future, a whole car factory will have only one employee. His job: feed the dog. The dog’s: keep humans away from the machines. Just as a ship with dozens of people got replaced by 13: the complexity was encapsulated in simpler interfaces. Diesel motors: just change this lever. Up is fast, down is slow. But it took a century to refine this absurdly complex device until this simple interface became possible…

So what happens to your simple encapsulated system when the diesel motor breaks down, or one of your hydraulic lines breaks? Does your simple encapsulated system them also say "we have no downtime, because we have a simple system"?
Post reply on HN