5 ms·

I run everything directly on VPSs and deploy via rsync. Every now and then I have long discussions with friends who swear on containerizations. All the benfit

by TekMol 6y ago

I run everything directly on VPSs and deploy via rsync. Every now and then I have long discussions with friends who swear on containerizations. All the benfits they mention are theoretical. I have never run into one of the problems that containerization would solve.

compsciphd 6y ago
you have never made an overwriting change that broke your system in a way that made rollback difficult?
- TekMol 6y ago
  Not that I remember, no.
- john-shaffer 6y ago
  > At Viaweb, as at many software companies, most code had one definite owner. But when you owned something you really owned it: no one except the owner of a piece of software had to approve (or even know about) a release. There was no protection against breakage except the fear of looking like an idiot to one's peers, and that was more than enough. I may have given the impression that we just blithely plowed forward writing code. We did go fast, but we thought very carefully before we released software onto those servers. And paying attention is more important to reliability than moving slowly. Because he pays close attention, a Navy pilot can land a 40,000 lb. aircraft at 140 miles per hour on a pitching carrier deck, at night, more safely than the average teenager can cut a bagel. > This way of writing software is a double-edged sword of course. It works a lot better for a small team of good, trusted programmers than it would for a big company of mediocre ones, where bad ideas are caught by committees instead of the people that had them. http://www.paulgraham.com/road.html http://www.paulgraham.com/road.html
  - hamburglar 6y ago
    The idea that Navy pilots don't crash because they have minds like steel traps is absurd. They have a ton of process and redundancy to reduce human error to a minimum, and they follow tedious checklists religiously. Even private pilots have this rigor. If you applied the amount of process pilots use to software deployment, you'd improve ops by orders of magnitude.
    - blaser-waffle 6y ago
      And they sometimes can't land those planes on the pitching decks at night, and have to redirect or ditch. Source: old man was in Carrier Ops, talked about it constantly.
Wandfarbe 6y ago
That sounds like a very small setup you run with very limited requirements if you run this successful. The benefits they are mentioning are theoretical for you and i personally have not worked in a professional env where VPSs and rsync would be enough at all.
- TekMol 6y ago
  You sound exactly like my friends. Except that they know that my systems are several orders of magnitude bigger then theirs. So they don't argue with the present "This cannot work" but with the future "This will lead to catastrophic failure at some point!". This has been going on for years now.
  - Wandfarbe 6y ago
    What is your rough setup then?
- mattbillenstein 6y ago
  These things can all be managed an automated using ansible/salt/etc -- containers just add another layer of abstraction to manage/maintain/understand/etc.
- joepie91_ 6y ago
  > That sounds like a very small setup you run with very limited requirements if you run this successful. No, not necessarily. Computers are fast, and if you don't add complexity until you need it, you can do a hell of a lot with a half-decent VPS and some rsyncing. For context: a couple of years ago I ran a website that was in the Alexa top 1K for a while (back when that was still relevant), and that was heavily visited and used for the time during which it was relevant. If you worked at any news organization anywhere, it was probably on your daily list to check. Yet it was relatively crappy PHP, not even very optimized aside from some very naive memcache caching, and ran off a random VPS with 2GB of RAM - and that included the database. The biggest challenge wasn't scaling or deployment processes, but fighting off constant DDoS attacks. Of course, the key difference between that deployment and a typical startup deployment is that it wasn't built like a startup. It wasn't "measuring engagement", it wasn't doing "big data", it wasn't collecting data for targeted advertising - it just did one thing and it did it well, with the only complexity involved being that which was actually necessary for that purpose. Over the years I've looked at a lot of complex "devops" setups for other people, and almost without exception the vast majority of the resource requirements and complexities originate from data collection that approaches kleptomania, and their choice of tooling - which ostensibly was chosen to better handle complexity. It's just a self-fulfilling prophecy that way. Most people don't actually have this degree of complexity to manage. That's not to say that there's no organizations or projects at all that would benefit from automated cluster orchestration (with or without containers). But it's very much a "prove that you need it" kind of thing, not a "you need it unless..." kind of thing. (I do think that there's inherent value in deterministic deployments. But that's separate from whether you need multi-system orchestration tooling, it can be achieved without containers, and even then the deployment process should be trivial enough to make it worth your while.) Edit: To be clear, this is not an argument to prioritize performance over everything else or avoid dependencies/tools, at all. Just an argument to not add moving parts that you don't actually need. For anything you add, you should be able to answer "what concrete problem does this solve for me, and why is it worth it?".
heavyset_go 6y ago
> I have never run into one of the problems that containerization would solve. You've never had to migrate your app to another host, or manage dependencies for an app?

by TekMol 6y ago

compsciphd 6y ago

you have never made an overwriting change that broke your system in a way that made rollback difficult?

TekMol 6y ago
Not that I remember, no.
john-shaffer 6y ago
> At Viaweb, as at many software companies, most code had one definite owner. But when you owned something you really owned it: no one except the owner of a piece of software had to approve (or even know about) a release. There was no protection against breakage except the fear of looking like an idiot to one's peers, and that was more than enough. I may have given the impression that we just blithely plowed forward writing code. We did go fast, but we thought very carefully before we released software onto those servers. And paying attention is more important to reliability than moving slowly. Because he pays close attention, a Navy pilot can land a 40,000 lb. aircraft at 140 miles per hour on a pitching carrier deck, at night, more safely than the average teenager can cut a bagel. > This way of writing software is a double-edged sword of course. It works a lot better for a small team of good, trusted programmers than it would for a big company of mediocre ones, where bad ideas are caught by committees instead of the people that had them. http://www.paulgraham.com/road.html http://www.paulgraham.com/road.html
- hamburglar 6y ago
  The idea that Navy pilots don't crash because they have minds like steel traps is absurd. They have a ton of process and redundancy to reduce human error to a minimum, and they follow tedious checklists religiously. Even private pilots have this rigor. If you applied the amount of process pilots use to software deployment, you'd improve ops by orders of magnitude.
  - blaser-waffle 6y ago
    And they sometimes can't land those planes on the pitching decks at night, and have to redirect or ditch. Source: old man was in Carrier Ops, talked about it constantly.

Wandfarbe 6y ago

That sounds like a very small setup you run with very limited requirements if you run this successful. The benefits they are mentioning are theoretical for you and i personally have not worked in a professional env where VPSs and rsync would be enough at all.

TekMol 6y ago
You sound exactly like my friends. Except that they know that my systems are several orders of magnitude bigger then theirs. So they don't argue with the present "This cannot work" but with the future "This will lead to catastrophic failure at some point!". This has been going on for years now.
- Wandfarbe 6y ago
  What is your rough setup then?
mattbillenstein 6y ago
These things can all be managed an automated using ansible/salt/etc -- containers just add another layer of abstraction to manage/maintain/understand/etc.
joepie91_ 6y ago
> That sounds like a very small setup you run with very limited requirements if you run this successful. No, not necessarily. Computers are fast, and if you don't add complexity until you need it, you can do a hell of a lot with a half-decent VPS and some rsyncing. For context: a couple of years ago I ran a website that was in the Alexa top 1K for a while (back when that was still relevant), and that was heavily visited and used for the time during which it was relevant. If you worked at any news organization anywhere, it was probably on your daily list to check. Yet it was relatively crappy PHP, not even very optimized aside from some very naive memcache caching, and ran off a random VPS with 2GB of RAM - and that included the database. The biggest challenge wasn't scaling or deployment processes, but fighting off constant DDoS attacks. Of course, the key difference between that deployment and a typical startup deployment is that it wasn't built like a startup. It wasn't "measuring engagement", it wasn't doing "big data", it wasn't collecting data for targeted advertising - it just did one thing and it did it well, with the only complexity involved being that which was actually necessary for that purpose. Over the years I've looked at a lot of complex "devops" setups for other people, and almost without exception the vast majority of the resource requirements and complexities originate from data collection that approaches kleptomania, and their choice of tooling - which ostensibly was chosen to better handle complexity. It's just a self-fulfilling prophecy that way. Most people don't actually have this degree of complexity to manage. That's not to say that there's no organizations or projects at all that would benefit from automated cluster orchestration (with or without containers). But it's very much a "prove that you need it" kind of thing, not a "you need it unless..." kind of thing. (I do think that there's inherent value in deterministic deployments. But that's separate from whether you need multi-system orchestration tooling, it can be achieved without containers, and even then the deployment process should be trivial enough to make it worth your while.) Edit: To be clear, this is not an argument to prioritize performance over everything else or avoid dependencies/tools, at all. Just an argument to not add moving parts that you don't actually need. For anything you add, you should be able to answer "what concrete problem does this solve for me, and why is it worth it?".

heavyset_go 6y ago

> I have never run into one of the problems that containerization would solve. You've never had to migrate your app to another host, or manage dependencies for an app?