[xmonkee]

Every day I need to add a new feature to my app, I am grateful I picked fly (serverful) rather than Vercel. The fact that as far as I'm concerned, it's just a computer, is incredibly useful. We've added long-running tasks, background jobs, scheduled tasks, side-car processes, custom-code execution, etc etc. Then, the fact that I can run something like Redis or Metabase within the same VPN with just a dockerfile is incredibly empowering. And just giving up basic things like SSH access to your server seems like an incredibly short-sighted thing to do. Maybe I'm too old, I just don't get it.

[lmm]

It's not "just" a computer, a computer is a whole bunch of complicated stuff that I don't want to have to care about. 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. 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.

[xmonkee]

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

[lmm]

> You always "need" to care about the abstraction that your infrastructure is providing to you.

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.

[nicoburns]

The big advantage of Docker based solutions is that they're portable between providers. And you can ramp up the complexity as you need. Just need a language runtime? Then you can have a single-line Dockerfile. Need to support a native dependency? Then you might need to install it, but at least it will be possible to do that.

[lmm]

I can do all that with puppet without the extra complexity of containers.

[hntorpldisb]

> 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?

Do lambdas not fail to run / error out? I’m not following.

[lmm]

> Do lambdas not fail to run / error out? I’m not following.

You generally have some kind of monitoring/alerting built in. With cron the usual behaviour is to email root@localhost using local sendmail, which generally achieves nothing except for filling up /var.

[maxbond]

Here's a thought experiment people may or may not find helpful. If you're writing say a Flask app, what Flask is doing for you is routing a request to a function. That's where the core kernel of value is; the rest of what's going on is overhead you pay to wire your function up to what it needs, like a database connection pool and such.

So if you were AWS and you saw everyone running an instance of Flask, you might think to yourself, I could run one really big instance of Flask that everyone could share, and the economies of scale would mean I could charge a cheaper price.

And you as the software developer might think, well, I get paid to execute these functions, not to run Flask, so I might as well rent a spot in the big Flask. Then I won't have to spend time updating and maintaining the framework, I can focus on writing my functions.

This may or may not work out for a specific use case, eg maybe that database connection pooler that we threw out was load bearing and moving to serverless overwhelms our database or causes us to spin up more database servers and costs more money. YMMV.