6 ms·

So, you’re explaining a stack with: - application instances - load balancer - database - cache - search cluster if application search is necessary Sounds

by hw 3y ago

So, you’re explaining a stack with: - application instances - load balancer - database - cache - search cluster if application search is necessary Sounds like any cookie cutter application to me, even modern ones. How is that complicated?

kgeist 3y ago
Sometimes I think, maybe our complex cluster which runs PHP software (load balancer, app instances, cache etc.) can be replaced with a single performant machine running something like Rust
- hsn915 3y ago
  It can. You don't even need to go all the way to Rust. I'm doing it with Go, which has a GC and a runtime. A single executable on a single machine can handle millions of users per month.
hsn915 3y ago
It's way too complicated. But if this is all you have ever seen and if you've been designing such systems for a decade, this seems like normal to you. Here's an alternative stack that can handle over 99% of websites: - Self contained executable - One-file database - Cache is memory - Text search is a library function - Indexing is a library function - Serving http is a library function Such a stack can handle > 20k concurent connections (per second). The code doesn't need to be "optimized"; just non-pessimized. You can scale "vertically" for a very long time, specially in 2020 and beyond, where you have machines with over 64 CPU cores. That's almost a cluster of 64 machines, except in one single machine. If you _must_ scale horizontally for some reason - maybe you are Twitter/Facebook/Google - then you can still retain the basic architecture of a single executable but allow it to have "peers" and allow data to be sharded/replicated across peers. Again all the coordination you need is just a library that you embed in the program; not some external monster tool like k8s.
- kgeist 3y ago
  There are several reliability issues: 1) a single panic/exception/segfault in the executable brings down the whole website and so it will be unavailable until the executable restarts 2) entropy *always* increases (RAM usage, memory corruption, hardware issues, OS misconfiguration etc.) so eventually the application will break and stop serving traffic until it's repaired/restarted (which can take time if it's a hardware issue) 3) deployments are tricky if there's nothing before the executable (stop, update, restart => downtime) 4) if cache is in-process, on a restart it will have to be repopulated from scratch, leading to temporary slowdowns (+ and maybe a thundering herd problem) which will happen *every time* you deploy an update I think much of it is ignoreable if the site is just a personal blog or a static site. But if the site is a real time "web application" which people rely on for work, then you still need: 1) some kind of containerization, to deal with inevitable entropy (when a container is restarted, everything is back to the initial clean state) 2) at least two instances of the application: one instance crashes => the second one picks up traffic; or during rolling updates: while one instance is being killed and replaced with a new version, traffic is routed to another instance 3) persistent data (and sometimes caches) need to be replicated (and backed up) -- we've had many hardware issues corrupting DBs 4) automatic failover to a different machine in case the machine is dead beyond repair >not some external monster tool like k8s What can you use instead of k8s for this kind of scenario? (an ultra reliable setup which doesn't need a whole cluster)
  - hsn915 3y ago
    Re: Crashes. If there's a bug that brings the server down, it will happen in all instances and repeatedly no matter how many times you restart. Specially when the users keep repeating the action that triggered the crash. Re: Entropy. Entropy increases with complex setup. The whole point of not having a complex setup is to reduce entropy and make the system as whole more predictable. Re: caches. There are two types of caches: indicies that are persisted with the database, and LRU caches in memory. LRU caches are always built on demand so this is not even a problem. Plus modern CPUs are incredibly fast and can process several GBs of data per second. Even in the worst cases, you should be able to rebuild all your caches in a second.

by hw 3y ago

kgeist 3y ago

Sometimes I think, maybe our complex cluster which runs PHP software (load balancer, app instances, cache etc.) can be replaced with a single performant machine running something like Rust

hsn915 3y ago
It can. You don't even need to go all the way to Rust. I'm doing it with Go, which has a GC and a runtime. A single executable on a single machine can handle millions of users per month.

hsn915 3y ago

It's way too complicated. But if this is all you have ever seen and if you've been designing such systems for a decade, this seems like normal to you. Here's an alternative stack that can handle over 99% of websites: - Self contained executable - One-file database - Cache is memory - Text search is a library function - Indexing is a library function - Serving http is a library function Such a stack can handle > 20k concurent connections (per second). The code doesn't need to be "optimized"; just non-pessimized. You can scale "vertically" for a very long time, specially in 2020 and beyond, where you have machines with over 64 CPU cores. That's almost a cluster of 64 machines, except in one single machine. If you _must_ scale horizontally for some reason - maybe you are Twitter/Facebook/Google - then you can still retain the basic architecture of a single executable but allow it to have "peers" and allow data to be sharded/replicated across peers. Again all the coordination you need is just a library that you embed in the program; not some external monster tool like k8s.

kgeist 3y ago
There are several reliability issues: 1) a single panic/exception/segfault in the executable brings down the whole website and so it will be unavailable until the executable restarts 2) entropy *always* increases (RAM usage, memory corruption, hardware issues, OS misconfiguration etc.) so eventually the application will break and stop serving traffic until it's repaired/restarted (which can take time if it's a hardware issue) 3) deployments are tricky if there's nothing before the executable (stop, update, restart => downtime) 4) if cache is in-process, on a restart it will have to be repopulated from scratch, leading to temporary slowdowns (+ and maybe a thundering herd problem) which will happen *every time* you deploy an update I think much of it is ignoreable if the site is just a personal blog or a static site. But if the site is a real time "web application" which people rely on for work, then you still need: 1) some kind of containerization, to deal with inevitable entropy (when a container is restarted, everything is back to the initial clean state) 2) at least two instances of the application: one instance crashes => the second one picks up traffic; or during rolling updates: while one instance is being killed and replaced with a new version, traffic is routed to another instance 3) persistent data (and sometimes caches) need to be replicated (and backed up) -- we've had many hardware issues corrupting DBs 4) automatic failover to a different machine in case the machine is dead beyond repair >not some external monster tool like k8s What can you use instead of k8s for this kind of scenario? (an ultra reliable setup which doesn't need a whole cluster)
- hsn915 3y ago
  Re: Crashes. If there's a bug that brings the server down, it will happen in all instances and repeatedly no matter how many times you restart. Specially when the users keep repeating the action that triggered the crash. Re: Entropy. Entropy increases with complex setup. The whole point of not having a complex setup is to reduce entropy and make the system as whole more predictable. Re: caches. There are two types of caches: indicies that are persisted with the database, and LRU caches in memory. LRU caches are always built on demand so this is not even a problem. Plus modern CPUs are incredibly fast and can process several GBs of data per second. Even in the worst cases, you should be able to rebuild all your caches in a second.