4 ms·

This is very common in almost all web companies since around 2015. I've never seen a company with a simple infrastructure, no matter how simple their actual ap

by hsn915 4y ago

This is very common in almost all web companies since around 2015. I've never seen a company with a simple infrastructure, no matter how simple their actual application actually is. If you choose a slow dynamic language (Ruby/Python) your deployment has to be massively complicated; you have no choice about it. For one simple reason: you will need a multitude of separate components to be made to work together. You need many application instances because there's no way one machine can handle all your traffic: Ruby is just too slow. A sharded database cluster as a source of truth: You went through the effort of making several applications instances with a load balancer: you don't want a single database server to be a single point of failure. A distributed redis/memcache index to accelerate queries and lower the pressure on the real database. You might have several index-type engines for different types of quries. Most people use ElasticSearch in addition to Redis. You need some system to manage all this complexity: monitor it, deploy new versions, rollback to a previous version, run migrations and monitor their state, etc etc. This is the bare minimum. Most people have a setup that is way more complicated than this. I don't even know how they come up with these complexties, but they not only come up with frequently: they love it! To them it's a feature, not a bug.

hw 4y 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 4y 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 4y 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 4y 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 4y 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)
bayesian_horse 4y ago
You are making a lot of assumptions and many of those are not universal problems or even at all. Compiled languages eventually need a complicated setup for the very same reasons. There is no such thing as "scales" and "doesn't scale". Even Go or C++ webapps have to be scaled up. If you can get away without complexity on Go or whatever, good for you. Most companies don'T.

by hsn915 4y ago

hw 4y 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 4y 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 4y 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 4y 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 4y 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)

bayesian_horse 4y ago

You are making a lot of assumptions and many of those are not universal problems or even at all. Compiled languages eventually need a complicated setup for the very same reasons. There is no such thing as "scales" and "doesn't scale". Even Go or C++ webapps have to be scaled up. If you can get away without complexity on Go or whatever, good for you. Most companies don'T.