Comment by onion2k | Hacker News Reader

Comment by onion2k | Hacker News Reader

Parent Full thread

I do. It was a good time. Yes, I am old.

I do remember. I've been doing web stuff for a little over 20 years. It was not a good time.

1. If a file upload failed your site was broken until you managed to upload it again.

2. Deploying something that required a database migration had to be done out of hours, or the site had to be taken offline to do it.

3. Recovering from a disaster was hard, and pretty much always resulted in significant data loss.

4. Moving a site from one server to another was awful, because it meant SSH'ing (or telnet'ing...) on to the box and compiling things from source. If you got anything in the environment wrong the site didn't work and you had to start again.

5. If you worked on anything that ran on multiple servers you pretty much had to script it all anyway. Essentially there were thousands of different (much worse) build-and-deploy processes people had stuck together with various different tools. Going to a new company meant learning a completely new set of processes. Today's processes are just an industry-standard best-in-class approach to doing the same thing.

I'll take Webpack to compile a site and terraform/compose/puppet to deploy the infrastructure over old way of doing things every time.

> 1. If a file upload failed your site was broken until you managed to upload it again.

I don't think an scp ever went wrong for me. But maybe your lan network is different.

> 2. Deploying something that required a database migration had to be done out of hours, or the site had to be taken offline to do it.

Does webpack handle db migrations too? I didn't know. I was talking about js/html/css assets. Not the backend.

> 3. Recovering from a disaster was hard, and pretty much always resulted in significant data loss.

I don't know your specifics, but recovering from a disaster in this case is getting up an other server (or serverS) and copy the files over.

> 4. Moving a site from one server to another was awful, because it meant SSH'ing (or telnet'ing...) on to the box and compiling things from source.

That's the nice thing about mod_pagespeed: you don't compile anything.

> 5. If you worked on anything that ran on multiple servers you pretty much had to script it all anyway.

What's wrong with scripting everything? I like automation.

I don't think an scp ever went wrong for me. But maybe your lan network is different.

When I started doing web things rcp (or scp, or rsync, etc) access was quite unusual. You had FTP and that was it. It failed a lot.

Does webpack handle db migrations too? I didn't know. I was talking about js/html/css assets. Not the backend.

Fair enough. I don't really see the front end asset pipeline as being separate to the backend. It's all just stuff you build and deploy.

That's the nice thing about mod_pagespeed: you don't compile anything.

Well, you do, but you're happy just accepting the mod_pagespeed defaults are doing a great job (which they are). I want a bit more control over things, and I want to do things that mod_pagespeed can't do, which is why I use Webpack instead. A trivial example: mod_pagespeed doesn't do subresource integrity hashes. Webpack has webpack-subresource-integrity as a plugin that can automatically write hashes to your html. That's useful to me. It's good that there are different options for different things, and better that the industry is coalescing around small number of different tools so there aren't too many different ways of doing things.

What's wrong with scripting everything? I like automation.

Nothing at all. Automate all the things! My point is that back in the olden days of making web things we didn't automate things, so it was much, much harder. Today's tools (eg things like Webpack) make automating your build process pretty trivial. It's far better now.

There was also a risk, with things like mod_php and the like, that a user could hit your app in the middle of an upgrade. Commonly in those days (for many, not all), the app was tied rather tightly to the webserver. That is no longer the norm, it's more typical to reverse proxy to an app server or something like that.

And sure, staging then copying everything would be faster and safer than deploying straight on top of the old version, but that's still a not-insignificant amount of time when the app is in a transient, partially-upgraded state. And that would only get worse as your app grew.

I suppose to way around that would be to deploy twice and use a load balancer that you could temporarily disable, upgrade one deployment, point the load balancer only to there, upgrade the other one, then re-enable load balancing between them.

Man, that's a lot of work, though.

I'll agree that maybe it's a relatively minor complaint, because there are likely plenty of solutions I just never needed to find, but I really do like avoiding anything that can and should be avoided. I'd rather have a "Please wait while we upgrade" page than risking something going south due to some kind of race condition.

The r-services were used a lot on and between Unices.

FTP did fail a lot indeed. That is why scene (FTP / FXP) used .rar, .sfv and Usenet .rar, .par(2). Download clients had resuming support but did not attempt verification. That's why checking checksum is important (Sfv is just CRC32 and Par is Reed Solomon, other examples are MD5 and SHA1).

Later on scene used so-called auto traders, which utilized FXP and automatically verifying checksums plus anticipating on errors (such as dupes). The I know was called Preee (Windows only, worked in Wine). Later protocols like BitTorrent implemented checksum verification within the protocol.

Reply on news.ycombinator.com