| > I want to write some code and have it run and I don't want or need to care about the details of how that happens as long as it works reliably I'm sorry, this is an incredibly stupid take. You always "need" to care about the abstraction that your infrastructure is providing to you. Vercel also provides a abstraction in terms of serverless functions. >I want to write some code and have it run and I don't want or need to care about the details of how that happens as long as it works reliably. Yeah, same. As long as it works, I have no problem. Now add background tasks or streaming responses or a cron job. Oh, guess what, you have to suddenly care about the options your provider is giving you, or go out and buy some stupid cron-as-service or ssh-as-service because you don't have any control over your infrastructure. And now suddenly your infra is way more complicated than mine. I am still one that single dockerfile. >Being able to ssh into your server is giving you more tools to fix problems, sure, but mostly problems that you created for yourself by having a server in the first place. How is running a clean-up script anything to do with having a server? That is the most common use-case for ssh-ing into your server. In fact I am wracking my brains right now to come up with anytime I had a problem because of having a server and coming up short. Fly.io (or AWS, or GCP) has problems, for sure, but none of them are because I am running a server. |
Sure. But as long as it implements something reasonable, you don't care about the details of how. "Runs version x of this programming language" is generally an easier abstraction to run business functionality on than "it's an x86-compatible computer".
> Now add background tasks or streaming responses or a cron job. Oh, guess what, you have to suddenly care about the options your provider is giving you, or go out and buy some stupid cron-as-service or ssh-as-service because you don't have any control over your infrastructure.
Cron is a terrible model for actually solving business problems with. Do you know what happens when a cron job fails to run/errors out?
Running your own unix system gives you a bunch of options that a higher-level abstraction doesn't, sure. But those options are rarely worth the cost, IME. (And like I said, if you're actually getting a unique value-add from running the whole server, then do it!)
> And now suddenly your infra is way more complicated than mine. I am still one that single dockerfile.
I guarante you that anything Docker-based is more complicated than what I'm doing. Docker is the worst kind of layer; it doesn't provide a consistent abstraction of its own, you still have to know all the ins and outs of how the unix system it's running on works, it just adds a whole bunch of extra concepts on top that you have to learn. And then sometimes breaks the usual rules of the platform it's running on as well! (e.g. silently bypassing your iptables rules).
> In fact I am wracking my brains right now to come up with anytime I had a problem because of having a server and coming up short.
- Your program runtime crashing because of mismatched system library ABIs
- A dependency you didn't expect is suddenly available because it got installed by the base system
- /var filling up because of out of control logs or the like
- Any other disk filling up for whatever reason
- Log collectors going AWOL
- Directory traversal order differing because two servers are using different filesystems
- Upgrade changed the network management commands and now all your traffic is being blocked
- Buggy RAID controllers
- Thermal throttling kicking in when it shouldn't because of a broken temperature sensor
- Power outages
All this stuff still needs to be fixed, but it's great to have it be someone else's problem and get on with your program.