[mrkurt]

Well that's nice of you to say. Would you believe we also have negative views of the cloud?

You're right, we kind of glossed over how to do that. People usually just keep two Redis connections in their code, something like `regionalRedis` and `globalRedis`. It's cheap to keep Redis connections around.

I can't really think of a better way to handle it, it's kind of a weird problem because not _all_ writes need to go a certain place, just writes you deem global.

[alberth]

Since I personally believe fly.io has the most potential in redefining how apps are deployed (though, with no disrespect I don’t believe it’s quite there yet) … is there any plans to providing a PaaS like offering where I can deploy my favorite web framework to your edge network and you handle the OS, Database, App server, etc.

Said another way, I just write my web app code and fly.io handles literally everything else. (I don’t even mess with docker etc. Just my app code and be done)

[mrkurt]

Yes, this is the dream. We're definitely not there yet.

This is especially important for DBs. What I'd really love is for us to work with DB "owners" to jointly provide managed DBs. One thing I hate about AWS is that they have a lopsided, parasitic relationship with the people who build interesting databases.

[alberth]

Even though people love to hate PHP, people have been able to achieve that dream of only writing code and a hosting provider takes care of the rest for almost 20 years now.

I recall in thr early 2000s having a personal VPS account with Dreamhost and doing just that since they managed the OS, Database and Apache/nginx.

It’s amazing how in many ways - deploying code over the years has only become radically harder than simpler.

[ElevenLathe]

I worked for a Dreamhost competitor for years. These "managed VPS" accounts with providers like that are definitely not something where you can just throw your code over the wall. There were and are whole teams of unix weenies like me responding to the myriad ways that software or customers would bork their VPS install.

The situation on "shared hosting" was IMO much better in terms of reliability, since customers didn't have root, but these servers were definitely still pets and not cattle.

Basically, these companies are a way to outsource sysadmin labor to sweaty cubicle farms rather than a way to actually reduce the amount of labor that is needed. Arguably the same is true for cloud but I think in general the cloud paradigm is actually more labor-efficient. As a thought experiment, imagine if AWS tried to serve their current customer base with the techniques of Dreamhost-style hosting companies. They'd need to employee 1000x as many people! And it would still be worse!

[code_duck]

Once my PHP app became mildly popular, I quickly learned the limits of shared hosting. At that point I was forced to learn all of the things that people avoid by deploying apps on someone else’s PHP server.

[motogpjimbo]

But your app reached the point of popularity before you started needing to worry about provisioning and maintaining the infrastructure for it? That sounds like a win to me.

[code_duck]

It took about a month to reach that point and I had all sorts of confusing performance problems and errors (process per user limits, script execution time limits, inability to manage extensions, lack of access to logs and configuration) from the shared hosting infrastructure. I would have been better off if I realized from the beginning that shared hosting would never be adequate and just started it on a VM in Python.

[stef25]

The easiest, and also most terrible, way to deploy was FTP I guess - just drag the entire folder's content over. During the copying process you'd get errors and downtime of course.

With my current stack I provision a VPS with Forge and deploy the repo with Envoy (zero downtime). It's pretty easy and feels very solid.

[tomjen3]

I will be happy if you just get to the point where I can upload a docker compose file and then run that. Not only would it make deployments/development much easier, but it would fit most companies better than maintaining their own cluster.

[indigodaddy]

> Yes, this is the dream. We're definitely not there yet.

So kind of like, the "Netlify" of edge dynamic app-hosting?

[vlmutolo]

Just holding the two Redis connections makes sense. I remember the Postgres post said something about modifying HTTP headers (a solution I liked), and I didn't know if this would be something similar.

Actually, I just looked back, and that was to solve the problem of only being able to write to a single postgres instance of the globally distributed cluster. For just caching, with every instance writeable, that probably wouldn't apply here.

[mcintyre1994]

I think the main difference is that by making replicas writable you lose the ability to have redis throw an error like Postgres does when you try to write to a replica. The upside is that you can write to replicas when you don’t need a global write without rerouting the request somewhere else, the downside is that your app has to have that knowledge about which one to use in which situations. It’s definitely an interesting set of trade offs for the two use cases!