3 ms·

How in the world is this considered something new? It was in fact the default mode of operation for small to midscale webhosting that rendered pages dynamically

How in the world is this considered something new? It was in fact the default mode of operation for small to midscale webhosting that rendered pages dynamically in the dotcom bubble burst era (late 1990-ies). You'd upload your HTTP attached executables to cgi-bin or similar, register other stuff in crontab and usually also got access to a MySQL or PostgreSQL. Some hosters were actually fancy and deploy your stuff on a MOSIX cluster; but simply load balancing toward the httpd machines and your application talking to a dedicated DB machine worked as well.

subway 10y ago
Load balancing? Heh, that's a good one. My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php. Generally if you were in a shared hosting environment, your DB and webapp lived on the same physical server (Probably a Cobalt RAQ or Netra T1, but maybe a Sun Ultra AXi in an ATX case on a bread rack). Rarely was there any form of multi-host redundancy for a given application. If something broke, you're down while the hosting company swaps disks to a new chassis, and down even longer when the disks die and you need to reproduce the app config/state changes that happened in the 2 days since the last server backup happened. So yeah. This is a slightly different model.
- datenwolf 10y ago
  > My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php. At the core of it this is not so different. > So yeah. This is a slightly different model. No, not really. What's changed is our understanding of how to run this kind of infrastructure. And we now have a little bit more sophistication in how we organize process runtime environments (sandboxes, cgroups on Linux, jails on FreeBSD). But if you tear down all the PR and get past the nice decoration it boils down to a glorified shell access. Back in the boom it sucked because nobody knew then, how to do these things properly.

subway 10y ago

Load balancing? Heh, that's a good one. My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php. Generally if you were in a shared hosting environment, your DB and webapp lived on the same physical server (Probably a Cobalt RAQ or Netra T1, but maybe a Sun Ultra AXi in an ATX case on a bread rack). Rarely was there any form of multi-host redundancy for a given application. If something broke, you're down while the hosting company swaps disks to a new chassis, and down even longer when the disks die and you need to reproduce the app config/state changes that happened in the 2 days since the last server backup happened. So yeah. This is a slightly different model.

datenwolf 10y ago
> My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php. At the core of it this is not so different. > So yeah. This is a slightly different model. No, not really. What's changed is our understanding of how to run this kind of infrastructure. And we now have a little bit more sophistication in how we organize process runtime environments (sandboxes, cgroups on Linux, jails on FreeBSD). But if you tear down all the PR and get past the nice decoration it boils down to a glorified shell access. Back in the boom it sucked because nobody knew then, how to do these things properly.