In defense of simple architectures • Hacker News Board

Re: In defense of simple architectures

#21

Post by ChrisMarshallNY » Wed, Apr 06, 2022, 8:38 PM UTC

snvzz wrote: post #15

trasz wrote: post #12

Earlier quoted context omitted.

Also, those complicated architectures are often quite unreliable anyway - just in ways that don't show in metrics. Slack comes to mind: not only its functionality is poor compared to eg IRC, but it fails in hilarious ways, eg showing duplicated messages, or not showing them at all. Another example is YouTube - the iOS app gets confused when displaying an ad, which results in starting the playback at a wrong time offs…

Slack comically uses gigabytes of RAM and plenty of CPU time in the client side.

Obligatory I Am Developer toon: https://twitter.com/iamdevloper/status/1072503943790497798/p...

Re: In defense of simple architectures

#22

Post by WJW » Wed, Apr 06, 2022, 8:39 PM UTC

snvzz wrote: post #15

trasz wrote: post #12

Earlier quoted context omitted.

Also, those complicated architectures are often quite unreliable anyway - just in ways that don't show in metrics. Slack comes to mind: not only its functionality is poor compared to eg IRC, but it fails in hilarious ways, eg showing duplicated messages, or not showing them at all. Another example is YouTube - the iOS app gets confused when displaying an ad, which results in starting the playback at a wrong time offs…

Slack comically uses gigabytes of RAM and plenty of CPU time in the client side.

Wtf are you doing with it? My slack instance (on linux) is resting around 300 MB resident set size and 0% cpu. 300 MB is still a lot for a chat app, but it is definitely not gigabytes.

Re: In defense of simple architectures

#23

Post by [deleted] » Wed, Apr 06, 2022, 8:42 PM UTC

zrail wrote: post #19

surfer7837 wrote: post #5

Just boils down to not optimising until you need to. Start with a 3 tier web app (unless your requirements lead you to another solution), then start with read replicas, load balancing, sharding, redis/RabbitMQ etc

Realistically almost every web app can start as a one-tier web app that uses SQLite as a data store and serves mostly HTML.

[deleted]

Re: In defense of simple architectures

#24

Post by [deleted] » Wed, Apr 06, 2022, 8:45 PM UTC

bob1029 wrote: post #9

I think the biggest problem for most developers is not understanding what one computer can actually do and how reliable they are in practice. Additionally, understanding of how tolerant 99% of businesses are to real-world problems that could hypothetically arise can help one not frustrate over insane edge case circumstances. I suspect a non-zero number of us have spent time thinking about how we could provide determi…

[deleted]

Re: In defense of simple architectures

#25

Post by hajhatten » Wed, Apr 06, 2022, 8:46 PM UTC

adra wrote: post #20

bob1029 wrote: post #6

Earlier quoted context omitted.

Trap or integrated win-win? We use one of these "aggressively simple" architectures too. At this point, I would quit my job instantaneously if I had to even look at k8s or whatever the cool kids are using these days.

Man, kubernetes is so much easier than the smattering of crap that you have to jungle together before it. Puppet and co? No thanks. Terraform? It's fine, but only a part of a CI/CD picture. If you think the alternatives are better, I really have to wonder how much of the trenches crap that people in your org deal with regularly that you're insulated from. That, or you're a release-quarterly kinda company?

We're using Nomad + Consul + a custom little cli and I would never go back to K8s from this.

Not a yaml document in sight.

Re: In defense of simple architectures

#26

Post by calpaterson » Wed, Apr 06, 2022, 8:49 PM UTC

> GraphQL libraries weren’t great when we adopted GraphQL (the base Python library was a port of the Javascript one so not Pythonic, Graphene required a lot of boilerplate, Apollo-Android produced very poorly optimized code)

What do people use instead of Graphene? Strawberry?

Re: In defense of simple architectures

#27

Post by scrubs » Wed, Apr 06, 2022, 8:49 PM UTC

Nah, I don't much like the tone of this article. Not at all.

The engineering message should be: keep your architecture as simple as possible. And here are some ways (to follow) on how to find that minimal and complete size 2 outfit foundation in your size 10 hoarder-track-suite-eye-sore.

Do we really need to be preached at with a warmed over redo of `X' cut it for me as a kid so I really don't know why all the kids think their new fangled Y is better? No we don't.

If you have stateless share nothing events your architecture should be simple. Should or could you have stateless share nothing even if that's not what you have today? That's where we need to be weighing in.

Summary: less old guy whining/showing-off and more education. Thanks. From the Breakfast club kids.

Re: In defense of simple architectures

#28

Post by spicybright » Wed, Apr 06, 2022, 8:50 PM UTC

exfascist wrote: post #18

joshlemer wrote: post #14

Earlier quoted context omitted.

How could you say that Slack has poor functionality compared to IRC?

When you type something into IRC that message shows up in the log and every online users client pretty reliably. Furthermore the high degree of diversity among clients provides a pretty extreme amount of client side functionality that Slack completely lacks (scripting is a huge one.)

I love irc, but is is just silly.

Slack has much better history because you don't need to have been online when messages are sent to log them. Slack is absolutely more reliable in this regard.

IRC is easy to script because the protocol is so simple. But you leave so much on the table for that cost.

Obviously if your use case is text only that you don't care about being persistent and you lean heavily on scripting to get things done then IRC will do the trick. Otherwise it's such a crutch to do anything besides beyond that.

Re: In defense of simple architectures

#29

Post by endisneigh » Wed, Apr 06, 2022, 8:50 PM UTC

How far can you get with a single Postgres instance on a single machine? I know things like cockroach and citus existence but generally Postgres isn’t sharded as far as I know.

Re: In defense of simple architectures

#30

Post by ryukafalz » Wed, Apr 06, 2022, 8:51 PM UTC

exfascist wrote: post #18

joshlemer wrote: post #14

Earlier quoted context omitted.

How could you say that Slack has poor functionality compared to IRC?

When you type something into IRC that message shows up in the log and every online users client pretty reliably. Furthermore the high degree of diversity among clients provides a pretty extreme amount of client side functionality that Slack completely lacks (scripting is a huge one.)

The versatility of clients is indeed a huge benefit of IRC. I used to use IRC at work and always had my Weechat window split with a small pane up top showing either my highlights or a channel I needed to monitor at the time. With Slack, you can’t do that, which means you have to repeatedly click between channels if you need to pay attention to multiple at a time.