4 ms·

Fly is the only company that consistently makes me want to reconsider my negative views on "the cloud", and it's absolutely 100% due to their incredible blog po

Fly is the only company that consistently makes me want to reconsider my negative views on "the cloud", and it's absolutely 100% due to their incredible blog posts. As for this particular post, it's great as always, but I would have liked to see more specifics on how applications might write to the main replica vs their local Redis instance.

mrkurt 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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.
      - CamTin 5y ago
        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 5y ago
        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 5y ago
        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.
- vlmutolo 5y ago
  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 5y ago
    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!

mrkurt 5y ago

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 5y ago
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 5y ago
  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 5y ago
    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.
    - CamTin 5y ago
      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 5y ago
      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 5y ago
        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.
vlmutolo 5y ago
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 5y ago
  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!