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).
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.
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?
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.
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.
I would recommend that you go with something like Hugo[1], throw it on an S3(-compatible) bucket and be done with it.[2]
[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
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
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.