4 ms·

> Typing apt-get install mongo / mysql / rethinkdb after the droplet is really all there is to it. It's clear that the author was overspending—even a small dy

> Typing apt-get install mongo / mysql / rethinkdb after the droplet is really all there is to it. It's clear that the author was overspending—even a small dyno with a resource-hungry language like Rails can do a lot of traffic—but there's a lot more than just installing a web server, DB. Firewalls? WAL-E backups? Monitoring (of any kind)? A correct TLS setup? DB security? Setting those up—in a way that you can replicate if the box is hosed—is a whole 'nother side project unto itself. Learning Ansible, Salt, etc. is great, but if your goal is to build X thing as a side-project, you'll never get anything done in a timely manner if you start reinventing wheels.

overcast 11y ago
Sure, but most (all) virtual setups have automatic snapshots, and backups for a few bucks a month. The rest you mentioned, you SHOULD learn if you're getting your hands into web services. What happens when something goes wrong, who is fixing it if you have no idea how any of it is running? I guess I'm old school. You learn the basics first, and build upon it. It's not reinventing any wheel.
- waffle_ss 11y ago
  Before I quit using DigitalOcean, I enabled backups and found they were very spotty - occurring roughly weekly, but not on a predictable schedule (8 days, 6 days, 4 days, seemingly random). Not something to rely on in place of a real database backup policy (more like an emergency backup of last resort). Plus, they recommend against[1] enabling backups for I/O heavy VMs (so, databases) because of the copy-on-write implementation and its effect on I/O performance. I ended up going to AWS because I was tired of having to string together a web of iptables rules (e.g. when you provision a new webserver VM you have to iterate over your Postgres, Redis, HAProxy, Elasticsearch, etc. VMs to poke holes in their firewalls), setup WAL-E and monitoring it / testing backups, setup 3rd party monitoring VM resources for issues (CPU/memory/disk space), having to manage package updates and security fixes, aggregating logs to a 3rd party with rsyslog, all that stuff. Unless your app is a complete throwaway that you don't care about getting hacked or losing all your data, you quickly have to start worrying about this stuff and it becomes a huge burden to roll it yourself on VPS providers. [1]: https://www.digitalocean.com/community/tutorials/understanding-digitalocean-droplet-backups https://www.digitalocean.com/community/tutorials/understandi...
  - overcast 11y ago
    I'm not in any way pushing the DigitalOcean setup. It was just cheap, easy to use, and offered FreeBSD as a host. I don't get spammed by them, no reliability issues, so I really don't have a reason to move at this time. If a project of mine gets too big, I'll evaluate then. But they are good for iterating lots of new ideas quickly.

overcast 11y ago

Sure, but most (all) virtual setups have automatic snapshots, and backups for a few bucks a month. The rest you mentioned, you SHOULD learn if you're getting your hands into web services. What happens when something goes wrong, who is fixing it if you have no idea how any of it is running? I guess I'm old school. You learn the basics first, and build upon it. It's not reinventing any wheel.

waffle_ss 11y ago
Before I quit using DigitalOcean, I enabled backups and found they were very spotty - occurring roughly weekly, but not on a predictable schedule (8 days, 6 days, 4 days, seemingly random). Not something to rely on in place of a real database backup policy (more like an emergency backup of last resort). Plus, they recommend against[1] enabling backups for I/O heavy VMs (so, databases) because of the copy-on-write implementation and its effect on I/O performance. I ended up going to AWS because I was tired of having to string together a web of iptables rules (e.g. when you provision a new webserver VM you have to iterate over your Postgres, Redis, HAProxy, Elasticsearch, etc. VMs to poke holes in their firewalls), setup WAL-E and monitoring it / testing backups, setup 3rd party monitoring VM resources for issues (CPU/memory/disk space), having to manage package updates and security fixes, aggregating logs to a 3rd party with rsyslog, all that stuff. Unless your app is a complete throwaway that you don't care about getting hacked or losing all your data, you quickly have to start worrying about this stuff and it becomes a huge burden to roll it yourself on VPS providers. [1]: https://www.digitalocean.com/community/tutorials/understanding-digitalocean-droplet-backups https://www.digitalocean.com/community/tutorials/understandi...
- overcast 11y ago
  I'm not in any way pushing the DigitalOcean setup. It was just cheap, easy to use, and offered FreeBSD as a host. I don't get spammed by them, no reliability issues, so I really don't have a reason to move at this time. If a project of mine gets too big, I'll evaluate then. But they are good for iterating lots of new ideas quickly.