5 ms·

I love Fly.io and use it in production, but unless I'm missing something the author would have been better off just running their kubernetes cluster locally on

I love Fly.io and use it in production, but unless I'm missing something the author would have been better off just running their kubernetes cluster locally on a $6 VPS on digital ocean. That would also obviate the need for the procfile hack and tailscale.

DeathArrow 4y ago
If you can host your app on a $6 VPS, using a Kubernetes cluster seems like adding a little bit of overhead for no gains.
radicaldreamer 4y ago
A lot of super sophisticated engineering goes into solving problems which were created by the engineers themselves and obviously didn't need to be. I remember hearing that Oscar (a health insurance startup whose main differentiation was having a decent app) ran their own mesos cluster for some reason creating tons of cost and complexity with little to no reason (also operated tons of microservices with startup headcount).
- riwsky 4y ago
  Context (I work at Oscar): Oscar (no longer a startup; IPO'd last year) ran their own mesos cluster for the same reasons anyone uses k8s today: to help teams deliver in parallel. "Startup headcount" can mean different things to different people, but the company employs hundreds of software engineers, and has been around for over a decade. Kubernetes was not an option when they hit those scaling constraints—but now that k8s has established itself so firmly, Oscar's moving to a managed k8s setup. My experience before Oscar was mainly in a Spring monolith—which, yes, made some microservice overreaches pretty clear in my team's corner of the codebase—but even so, it'd be madness to coordinate all the org's development through e.g. a Jenkins instance and a bunch of ansible.
  - dalyons 4y ago
    Agreed - 100s of engineers is an absolutely reasonable level at which to invest in k8s (or a precursor). At that size I would be very concerned if you weren’t, it would be hindering delivery in a modern software org. It really annoys me on HN how people can be so judgmental about something they know so little about.
- bsnnkv 4y ago
  The larger story that I will be telling through this series of posts is the re-integration of the cast that powers Notado back into a monolith; hopefully it's something you and other readers will find interesting!
jonas21 4y ago
Alternatively, they could have just left things alone and paid the $100/mo. It's odd because this blog post also announces the end of the free beta for the service. It goes in depth about how they jumped through a bunch of hoops and introduced more complexity to the service because they were annoyed that DigitalOcean raised their prices. And at the end they're asking you to pay $5.99/mo for it?
- bsnnkv 4y ago
  So interesting to see how different people interpret complexity.
bsnnkv 4y ago
I don't think I'd enjoy managing my own single-node Kubernetes deployment, monitoring, upgrades etc., but some might! The other point that I didn't really cover in this article was all the monitoring goodies you get for free with Fly; definitely not something to be overlooked as a solo dev. The medium-term plan is to move the database to Fly as well, but I wanted to share a way for people to do a partial migration to Fly if they are not quite ready for a full database migration. As for using a Procfile manager being a "hack", once we are freed from the constraints of Docker containers and back in the realm of VMs, I think running multiple processes again becomes the norm. I don't quite agree with the "one machine (or machine-like abstraction) => one process" thinking in this regard.
skrtskrt 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, 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.

DeathArrow 4y ago

If you can host your app on a $6 VPS, using a Kubernetes cluster seems like adding a little bit of overhead for no gains.

radicaldreamer 4y ago

A lot of super sophisticated engineering goes into solving problems which were created by the engineers themselves and obviously didn't need to be. I remember hearing that Oscar (a health insurance startup whose main differentiation was having a decent app) ran their own mesos cluster for some reason creating tons of cost and complexity with little to no reason (also operated tons of microservices with startup headcount).

riwsky 4y ago
Context (I work at Oscar): Oscar (no longer a startup; IPO'd last year) ran their own mesos cluster for the same reasons anyone uses k8s today: to help teams deliver in parallel. "Startup headcount" can mean different things to different people, but the company employs hundreds of software engineers, and has been around for over a decade. Kubernetes was not an option when they hit those scaling constraints—but now that k8s has established itself so firmly, Oscar's moving to a managed k8s setup. My experience before Oscar was mainly in a Spring monolith—which, yes, made some microservice overreaches pretty clear in my team's corner of the codebase—but even so, it'd be madness to coordinate all the org's development through e.g. a Jenkins instance and a bunch of ansible.
- dalyons 4y ago
  Agreed - 100s of engineers is an absolutely reasonable level at which to invest in k8s (or a precursor). At that size I would be very concerned if you weren’t, it would be hindering delivery in a modern software org. It really annoys me on HN how people can be so judgmental about something they know so little about.
bsnnkv 4y ago
The larger story that I will be telling through this series of posts is the re-integration of the cast that powers Notado back into a monolith; hopefully it's something you and other readers will find interesting!

jonas21 4y ago

Alternatively, they could have just left things alone and paid the $100/mo. It's odd because this blog post also announces the end of the free beta for the service. It goes in depth about how they jumped through a bunch of hoops and introduced more complexity to the service because they were annoyed that DigitalOcean raised their prices. And at the end they're asking you to pay $5.99/mo for it?

bsnnkv 4y ago
So interesting to see how different people interpret complexity.

bsnnkv 4y ago

I don't think I'd enjoy managing my own single-node Kubernetes deployment, monitoring, upgrades etc., but some might! The other point that I didn't really cover in this article was all the monitoring goodies you get for free with Fly; definitely not something to be overlooked as a solo dev. The medium-term plan is to move the database to Fly as well, but I wanted to share a way for people to do a partial migration to Fly if they are not quite ready for a full database migration. As for using a Procfile manager being a "hack", once we are freed from the constraints of Docker containers and back in the realm of VMs, I think running multiple processes again becomes the norm. I don't quite agree with the "one machine (or machine-like abstraction) => one process" thinking in this regard.

skrtskrt 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, 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.