131–140 of 320 posts
After all the chatter this week, I've come to the conclusion that Heroku froze at the perfect time for my 4 person company. All of these so called "features" are exactly what we don't want or need. 1. Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. 2.…
I'm so glad you pointed this out. Cloud-native development is an important factor in newly architected systems. Defaulting to an S3 API for persistent I/O brings loads of benefits over using traditional file I/O, and brings significant new design considerations. Until a majority of software developers learn exactly how and why to use these new designs, we'll be stuck with outmoded platforms catering to old designs.
Can someone explain what fly.io actually is for someone with an AWS background?
Hope that helps!
Earlier quoted context omitted.
> Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. Guess what? fly.io offers a turnkey distributed/replicated Postgres for just this reason. You use an HTTP header to route writes to the region hosting your primary. https://fly.io/docs/getting-started/m…
> Guess what? fly.io offers a turnkey distributed/replicated Postgres for just this reason. You use an HTTP header to route writes to the region hosting your primary. Doesn't this take away a lot of the benefits of global distribution? For example if you pay Fly hundreds of dollars a month to distribute your small app in a few datacenters around the globe but your primary DB is in California then everyone from the EU…
On top of that, most replication systems are brittle and create logistical and administrative headaches. If you can get by with just rsync, do.
Earlier quoted context omitted.
Can you not ssh into a fly instance and then pull?
No. Flyctl SSH does not allow this functionality.
I don’t feel that way at all. Every time I’ve tried Fly (trust me I’ve wanted to love it), there’s always a rough edge or the service breaks for me. First time I tried it, the web panel wasn’t even loading. Second time, months later, everything was 500ing and I couldn’t find a way to SFTP into a disk (!!!). Total dealbreaker. This was easily done in Render.com with an even more magical experience. Deploy from a GitHu…
We've been kicking around ideas for managing files on volumes. This is a common problem – it's actually more difficult than you'd expect because "securitah". Once your volume is mounted in one of your VMs, we can't run tools outside the VM to let you manage the file system. On something like k8s with vanilla Docker, we could. But no one should run multitenant Docker. It's not really an excuse, just a reason it's taki…
Was there a reason for not using something similar to kata containers where you run a microvm but still use containers inside them? It seems like it would make such things easier while getting the isolation of a VM.
Earlier quoted context omitted.
Does Fly let you run multiple commands in separate Docker images? That's usually the pattern on how to run a web app + worker with Docker, as opposed to creating an init system in Docker and running (2) processes in 1 container (this goes against best practices). The Fly docs only mention the approach of using an init system inside of your image and also tries to talk you into running a separate VM[0] to keep your we…
It sounds like you're asking if we offer some alternative between running multiple processes in a VM, and running multiple VMs for multiple processes. What's the third option you're looking for? Are you asking if you can run Docker inside a VM, and parcel that single VM out that way? You've got root in a full-fledged Linux VM, so you can do that.
On a single server VPS I'd use Docker Compose and up the project to run multiple containers.
On a multi-server set up I'd use Kubernetes and set up a deployment for each long running container.
On Heroku I'd use a Procfile to spin up web / workers as needed.
The Fly docs say if you have 1 Docker image you need to run an init system in the Docker image and manage that in your image, it also suggests not using 2 processes in 1 VM and recommends spinning up 1 VM per process.
I suppose I was looking for an easy solution to run multiple processes in 1 VM (in this case multiple Docker containers). The other 3 solutions are IMO easy because once you learn how they work you depend on the happy path of those tools using the built in mechanisms they support. In the Fly case, not even the docs cover how to do it other than rolling your own init system in Docker.
If you have root, can I run docker-compose up in a Fly VM? Will it respect things like graceful timeouts out of the box? Does it support everything Docker Compose supports in the context of that single VM?
Earlier quoted context omitted.
I've got a small amount of dynamic content
DigitalOcean App Platform has a $5/month flat rate for dynamic stuff on top of two static sites hosted for free... if something goes crazy and you end up using a wild amount of outbound data, it looks like the next jump up is only to $12
Their app platforms' bandwidth pricing is pretty painful at 0.10$/GB. With these prices and considering the app platform lacks functionality like multi-regional droplets or VPC integration, they are a subpar choice even compared to Firebase or Amplify.
After all the chatter this week, I've come to the conclusion that Heroku froze at the perfect time for my 4 person company. All of these so called "features" are exactly what we don't want or need. 1. Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. 2.…
I strongly agree with your last paragraph. I used Heroku for my wedding website and I would 100% use it again on a project site. In about 15 minutes I was able to take my site from localhost to a custom domain with SSL with just a little more than a git push. I can't think of many solutions that are simpler than that.