4 ms·

Not even the kubernetes cluster, the author eventually is just running multiple processes in a single VM it seems, and scaling vertically using the VM, which of

Not even the kubernetes cluster, the author eventually is just running multiple processes in a single VM it seems, and scaling vertically using the VM, which of course could have been done on DigitalOcean. However, people do seem to love the fly.io developer experience. It's a testament to fly.io that the auther seemed to enjoy spinning up on fly.io. It's also a testament to DigitalOcean that it wasn't painful or expensive to partially migrate away from their services.

bsnnkv 4y ago
> Not even the kubernetes cluster, the author eventually is just running multiple processes in a single VM it seems, and scaling vertically using the VM This is an excellent summary! > ... which of course could have been done on DigitalOcean. > However, people do seem to love the fly.io developer experience. It's a testament to fly.io that the auther seemed to enjoy spinning up on fly.io. It could have been done, but it would have required me to introduce more moving parts and complexity to handle deployments of updates (do I keep the same VM and SSH in to update? Do I build a fresh VM with the latest version and then cut over the traffic? etc.) It's pretty hard to beat "fly deploy" in my opinion. Similarly, the vertical scaling story is much more streamlined on Fly.io - it's also pretty hard to beat "fly scale vm". I've mentioned in another comment on this post about how great the monitoring goodies that Fly gives you for free are. Another point that I didn't highlight in the article itself is that Fly.io is currently not collecting bills less than $5/month (this might change in the future, I don't know), and if you have a resource-efficient service (or services), with the numbers that most solo devs working on side projects are talking about, it's not difficult to stay under $5/month and have the excellent developer experience to boot. > It's also a testament to DigitalOcean that it wasn't painful or expensive to partially migrate away from their services. No complaints on this point; I'm also still very happy with Digital Ocean's managed database services.
- indigodaddy 4y ago
  I’m thinking about a simple blog. Someone convince me that I should use fly.io and caddy and how/why deployment and subsequent blog/post updates would be easy and uncomplicated.
  - bsnnkv 4y ago
    I'm afraid I couldn't make that argument with a straight face. I would recommend that you go with something like Hugo[1], throw it on an S3(-compatible) bucket and be done with it.[2] [1] https://gohugo.io/ https://gohugo.io/ [2] This is what I have been doing for my personal blog and for my wife's professional website for many years and I am very content with it
    - veidr 4y ago
      I did that too, but would never use Hugo for any website again! Instead, I would now use Astro[1] for any static site or blog. YMMV, but if you don't already love golang and their weird template language, Astro is just HTML and TypeScript and is overall simpler and less time-consuming to understand. (I mean it will get hella complicated if you want it to, and let you integrate React or Svelte or blah blah, but out of the box it works great for generating static sites like blogs, or just regular-ass websites.) [1]: https://astro.build https://astro.build

bsnnkv 4y ago

> Not even the kubernetes cluster, the author eventually is just running multiple processes in a single VM it seems, and scaling vertically using the VM This is an excellent summary! > ... which of course could have been done on DigitalOcean. > However, people do seem to love the fly.io developer experience. It's a testament to fly.io that the auther seemed to enjoy spinning up on fly.io. It could have been done, but it would have required me to introduce more moving parts and complexity to handle deployments of updates (do I keep the same VM and SSH in to update? Do I build a fresh VM with the latest version and then cut over the traffic? etc.) It's pretty hard to beat "fly deploy" in my opinion. Similarly, the vertical scaling story is much more streamlined on Fly.io - it's also pretty hard to beat "fly scale vm". I've mentioned in another comment on this post about how great the monitoring goodies that Fly gives you for free are. Another point that I didn't highlight in the article itself is that Fly.io is currently not collecting bills less than $5/month (this might change in the future, I don't know), and if you have a resource-efficient service (or services), with the numbers that most solo devs working on side projects are talking about, it's not difficult to stay under $5/month and have the excellent developer experience to boot. > It's also a testament to DigitalOcean that it wasn't painful or expensive to partially migrate away from their services. No complaints on this point; I'm also still very happy with Digital Ocean's managed database services.

indigodaddy 4y ago
I’m thinking about a simple blog. Someone convince me that I should use fly.io and caddy and how/why deployment and subsequent blog/post updates would be easy and uncomplicated.
- bsnnkv 4y ago
  I'm afraid I couldn't make that argument with a straight face. I would recommend that you go with something like Hugo[1], throw it on an S3(-compatible) bucket and be done with it.[2] [1] https://gohugo.io/ https://gohugo.io/ [2] This is what I have been doing for my personal blog and for my wife's professional website for many years and I am very content with it
  - veidr 4y ago
    I did that too, but would never use Hugo for any website again! Instead, I would now use Astro[1] for any static site or blog. YMMV, but if you don't already love golang and their weird template language, Astro is just HTML and TypeScript and is overall simpler and less time-consuming to understand. (I mean it will get hella complicated if you want it to, and let you integrate React or Svelte or blah blah, but out of the box it works great for generating static sites like blogs, or just regular-ass websites.) [1]: https://astro.build https://astro.build