4 ms·

I've always thought it interesting that there was a time when large(ish) websites were hosted using servers that would struggle to outperform a modern smart toa

by bonyt 5y ago

I've always thought it interesting that there was a time when large(ish) websites were hosted using servers that would struggle to outperform a modern smart toaster or wristwatch, and yet modern web applications tend to demand a dramatic distributed architecture. I like the examples in this article showing what a single modern server can do when you're not scaling to Google's level. As an aside, what about distributed derivatives of sqlite, like rqlite, as a response to the criticism that sqlite requires your database server to also be your web server. Could something like rqlite also provide a way for an sqlite database to grow into a distributed cluster at a later point? https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite

voidfunc 5y ago
It's mostly because there is a demand for HA which requires multiple replicas. The moment you start going down that route you increase complexity. Whether most things actually require HA is debatable, but a lot of businesses make it a core requirement and so it gets baked into the architecture. Personally I feel like most stuff would be better suited to having fast fail-over and recovery early on, but my advice rarely gets taken. Instead you end up with complicated HA architectures that nobody totally understands, which then (inevitable still) fall over and take hours to recover.
- lenkite 5y ago
  HA is generally needed because users of a SaaS can crash the instance especially in products that offer customisation abilities.
  - voidfunc 5y ago
    Sure, but that becomes a requirement at that particular design junction. A lot of stuff is built with HA that isn't even close to that complex.
freedomben 5y ago
I don't disagree with you, a single server can go a really, really long way in scale before you run into problems. I know because I've done it a few times. The problem to me isn't ability to scale on one server, it's the single point of failure. My biggest site is a wordpress box with one instance on a pretty big VPS. In the last year I've had several outages big enough to require a post-mortem (not complete outages, but periods with high levels of error rates/failures), and every time it has been because of internal data center networking issues at my preferred cloud provider (and thankfully their customer service is amazing and they will tell me honestly what the problem was instead of leaving me to wonder and guess). So the main incentive for me to achieve horizontal scalability in that app is not scaling, it's high availability so I can survive temporary outages because of hardware or networking, and other stuff outside of my control.
- jimmygrapes 5y ago
  I don't mean to be too glib, but to me this reads like: "I am concerned about SPOF so I outsourced that." Except now you are not in control of plugging the cable back in, and pay (less?) for that convenience.
  - freedomben 5y ago
    I'm not sure I understand your point? Even if I ran it on my own hardware, where I was responsible for plugging the cable in, it would still have the same single point of failure problem in the event that my ISP started suffering Network issues. I've never had an ISP that didn't have some sort of issues at some point. Alternatively, if you think I am blaming my cloud provider for being the single point of failure, please read again. I specifically mentioned that I want to fix up the application so that it is highly available. I entirely and completely blame myself for the current situation. I didn't build it (otherwise it would be 12 factor[1] from the start and horizontally scalable), but I maintain it now. [1]: https://www.youtube.com/watch?v=REbM4BDeua0 https://www.youtube.com/watch?v=REbM4BDeua0
- dmux 5y ago
  Wouldn't a snapshot mechanism plus load-balancer handle this case and still keep the architecture simple?
ljm 5y ago
Not even a decade ago we were hosting our web-facing services and our postgres DB on the same server. A lot of smaller projects had their own db and credentials on the same instance. The idea of having to spin up independent DB servers for each one seemed wasteful to us, since back then each box would cost at least £10/mo or more on Linode or Rackspace and it meant more secrets to keep, more stuff to secure, more stuff to maintain. It was only with the advent of heroku and the sudden shift to the cloud (AWS) that the DB stopped being software you ran on your box as a daemon, and became essentially a dedicated resource. Even for services running at a completely trivial scale.
WesolyKubeczek 5y ago
Consider, though, that in the days past (when your server would be probably on an equivalent of dual-socket Pentium 166-MMX), most clients would be coming from slow links like 33.4-56.1kbps dialup, and it wouldn't be a problem to serve them at all. Links were slow, users were patient, timeouts were high, webpages were sort of slim. Although if you ask me, they always have been heavy, just within the constraints of their time. Then, of course, there was ISDN and xDSL, which would give you true to god whopping 128 kbits/s for a while. 64 kpbs if you were cheap. It took a while to get to affordable multiples of Mbits per second. Now that there's at least 10 Mbps uplink from each residential subscriber, doesn't take long to DoS even a beefy server. And I'd say that server-side, things improved vastly with advent of FastCGI and its equivalents. Back in that heyday of your P166-MMX server, it was CGI with Perl, spawning a process for each incoming request, or "blazing-fast" Apache's server-side includes, or other things like that. Maybe mod_perl with its caveats on memory sharing. Anyway, you're right in that whenever you show them a wider pipe, they will find more stuff to congest it with.
usrbinbash 5y ago
> and yet modern web applications tend to demand a dramatic distributed architecture The dirty secret is: Most of them don't really need that architecture. Most, and I mean +95% of websites would run just fine on a single box, running the websrv, db and whatever script-interpreter the backend runs on. Sure, it may be a bit slower if its not hooked up to a global CDN, and if the box goes down the user gets 404. But its also alot easier for an admin to simply give the one box a good wallop and put it back online, since it so simple. https://idlewords.com/talks/website_obesity.htm#heavyclouds https://idlewords.com/talks/website_obesity.htm#heavyclouds
hinkley 5y ago
Edge networking should work for SaaS, especially if your tenants tend to be geographically clustered. Stand up stateless front end web servers in half a dozen regions, and have them talk back to a more central region, with caches and circuit breakers to control the amount of cross-region traffic. That geographical separation will also make diurnal traffic patterns more obvious because you need more servers later in the day in PST than in EST. You don’t have to distribute everything to scale pretty high.

by bonyt 5y ago

voidfunc 5y ago

It's mostly because there is a demand for HA which requires multiple replicas. The moment you start going down that route you increase complexity. Whether most things actually require HA is debatable, but a lot of businesses make it a core requirement and so it gets baked into the architecture. Personally I feel like most stuff would be better suited to having fast fail-over and recovery early on, but my advice rarely gets taken. Instead you end up with complicated HA architectures that nobody totally understands, which then (inevitable still) fall over and take hours to recover.

lenkite 5y ago
HA is generally needed because users of a SaaS can crash the instance especially in products that offer customisation abilities.
- voidfunc 5y ago
  Sure, but that becomes a requirement at that particular design junction. A lot of stuff is built with HA that isn't even close to that complex.

freedomben 5y ago

I don't disagree with you, a single server can go a really, really long way in scale before you run into problems. I know because I've done it a few times. The problem to me isn't ability to scale on one server, it's the single point of failure. My biggest site is a wordpress box with one instance on a pretty big VPS. In the last year I've had several outages big enough to require a post-mortem (not complete outages, but periods with high levels of error rates/failures), and every time it has been because of internal data center networking issues at my preferred cloud provider (and thankfully their customer service is amazing and they will tell me honestly what the problem was instead of leaving me to wonder and guess). So the main incentive for me to achieve horizontal scalability in that app is not scaling, it's high availability so I can survive temporary outages because of hardware or networking, and other stuff outside of my control.

jimmygrapes 5y ago
I don't mean to be too glib, but to me this reads like: "I am concerned about SPOF so I outsourced that." Except now you are not in control of plugging the cable back in, and pay (less?) for that convenience.
- freedomben 5y ago
  I'm not sure I understand your point? Even if I ran it on my own hardware, where I was responsible for plugging the cable in, it would still have the same single point of failure problem in the event that my ISP started suffering Network issues. I've never had an ISP that didn't have some sort of issues at some point. Alternatively, if you think I am blaming my cloud provider for being the single point of failure, please read again. I specifically mentioned that I want to fix up the application so that it is highly available. I entirely and completely blame myself for the current situation. I didn't build it (otherwise it would be 12 factor[1] from the start and horizontally scalable), but I maintain it now. [1]: https://www.youtube.com/watch?v=REbM4BDeua0 https://www.youtube.com/watch?v=REbM4BDeua0
dmux 5y ago
Wouldn't a snapshot mechanism plus load-balancer handle this case and still keep the architecture simple?

ljm 5y ago

Not even a decade ago we were hosting our web-facing services and our postgres DB on the same server. A lot of smaller projects had their own db and credentials on the same instance. The idea of having to spin up independent DB servers for each one seemed wasteful to us, since back then each box would cost at least £10/mo or more on Linode or Rackspace and it meant more secrets to keep, more stuff to secure, more stuff to maintain. It was only with the advent of heroku and the sudden shift to the cloud (AWS) that the DB stopped being software you ran on your box as a daemon, and became essentially a dedicated resource. Even for services running at a completely trivial scale.

WesolyKubeczek 5y ago

Consider, though, that in the days past (when your server would be probably on an equivalent of dual-socket Pentium 166-MMX), most clients would be coming from slow links like 33.4-56.1kbps dialup, and it wouldn't be a problem to serve them at all. Links were slow, users were patient, timeouts were high, webpages were sort of slim. Although if you ask me, they always have been heavy, just within the constraints of their time. Then, of course, there was ISDN and xDSL, which would give you true to god whopping 128 kbits/s for a while. 64 kpbs if you were cheap. It took a while to get to affordable multiples of Mbits per second. Now that there's at least 10 Mbps uplink from each residential subscriber, doesn't take long to DoS even a beefy server. And I'd say that server-side, things improved vastly with advent of FastCGI and its equivalents. Back in that heyday of your P166-MMX server, it was CGI with Perl, spawning a process for each incoming request, or "blazing-fast" Apache's server-side includes, or other things like that. Maybe mod_perl with its caveats on memory sharing. Anyway, you're right in that whenever you show them a wider pipe, they will find more stuff to congest it with.

usrbinbash 5y ago

> and yet modern web applications tend to demand a dramatic distributed architecture The dirty secret is: Most of them don't really need that architecture. Most, and I mean +95% of websites would run just fine on a single box, running the websrv, db and whatever script-interpreter the backend runs on. Sure, it may be a bit slower if its not hooked up to a global CDN, and if the box goes down the user gets 404. But its also alot easier for an admin to simply give the one box a good wallop and put it back online, since it so simple. https://idlewords.com/talks/website_obesity.htm#heavyclouds https://idlewords.com/talks/website_obesity.htm#heavyclouds

hinkley 5y ago

Edge networking should work for SaaS, especially if your tenants tend to be geographically clustered. Stand up stateless front end web servers in half a dozen regions, and have them talk back to a more central region, with caches and circuit breakers to control the amount of cross-region traffic. That geographical separation will also make diurnal traffic patterns more obvious because you need more servers later in the day in PST than in EST. You don’t have to distribute everything to scale pretty high.