4 ms·

I'm sure the tech is really neat, but after the last CloudFlare debacle, piping all your HTTP requests through a for profit company just seems like it's ripe fo

I'm sure the tech is really neat, but after the last CloudFlare debacle, piping all your HTTP requests through a for profit company just seems like it's ripe for abuse. This is not meant to slander Fly, and I'm sure the devs have all the best intentions in the world, but the internet will only become more brittle the more services like this or CloudFlare become the arbiters of vast swaths of TCP packets.

mrkurt 10y ago
This is a real concern. We think about it a lot. In fact, we have a fairly nice way of isolating customers who can afford global server installs from other customers on shared infrastructure. Unfortunately, setting servers up across the world is really complicated and expensive. There's a definite trade off — we want to make this kind of power accessible to every developer, and running shared infrastructure is the only way we've found to do it. I do think apps are more secure by default running through fly than most load balancer services. Traffic between visitors and our edges is SSL (unless a customer opts out, at which point we nag them), application processes establish a secure tunnel back to our edge nodes to handle traffic. There are no network hops between fly and customer apps that happen in the clear. Replicating this with a normal load balancer setup means handling SSL termination for visitors and terminating SSL with client cert verification between load balancers and app servers. It's a pain, and most people don't get it right because it's too finicky. But I don't want to disregard your concern either. It's definitely something we think about a lot. We would like to figure out a way to offer all of this power easily, cheaply (for developers), and in a way that is entirely opaque to us. As soon as we figure out how, we will.
- secstate 10y ago
  Thanks for the thoughtful reply :) At the end of the day, I suppose there's a certain inevitability to the sort of service you're providing, and I'd rather there were 20 smaller companies, than just CloudFlare. So carry on, and I'll check out your tech when I have a chance!
markbnj 10y ago
Aren't virtually all of us doing this anyway? Who doesn't pipe all their http requests through a for profit company? Given that such a large percentage of web-accessible applications are on the cloud these days, most people are probably using some sort of managed ingress solution from their provider.
jjoe 10y ago
It's interesting you're bringing this up. I've been working on a private CDN that one can run on their own infrastructure (currently in closed beta). Is this kind of deployment more appealing now that CF bled sensitive data? On the other hand I've also built Cachoid ( https://www.cachoid.com/ https://www.cachoid.com/ ), which is somewhat federated like Fly's but for website acceleration and performance for WordPress, Drupal, landing pages etc. We do have the option to spin a dedicated routing layer with Cachoid, which sort of addresses the shared/neighbor bleeding issue CF suffered from. But I still don't think decentralized is the ultimate answer to security. Although I realize that the impact could be minimized greatly.

mrkurt 10y ago

This is a real concern. We think about it a lot. In fact, we have a fairly nice way of isolating customers who can afford global server installs from other customers on shared infrastructure. Unfortunately, setting servers up across the world is really complicated and expensive. There's a definite trade off — we want to make this kind of power accessible to every developer, and running shared infrastructure is the only way we've found to do it. I do think apps are more secure by default running through fly than most load balancer services. Traffic between visitors and our edges is SSL (unless a customer opts out, at which point we nag them), application processes establish a secure tunnel back to our edge nodes to handle traffic. There are no network hops between fly and customer apps that happen in the clear. Replicating this with a normal load balancer setup means handling SSL termination for visitors and terminating SSL with client cert verification between load balancers and app servers. It's a pain, and most people don't get it right because it's too finicky. But I don't want to disregard your concern either. It's definitely something we think about a lot. We would like to figure out a way to offer all of this power easily, cheaply (for developers), and in a way that is entirely opaque to us. As soon as we figure out how, we will.

secstate 10y ago
Thanks for the thoughtful reply :) At the end of the day, I suppose there's a certain inevitability to the sort of service you're providing, and I'd rather there were 20 smaller companies, than just CloudFlare. So carry on, and I'll check out your tech when I have a chance!

markbnj 10y ago

Aren't virtually all of us doing this anyway? Who doesn't pipe all their http requests through a for profit company? Given that such a large percentage of web-accessible applications are on the cloud these days, most people are probably using some sort of managed ingress solution from their provider.

jjoe 10y ago

It's interesting you're bringing this up. I've been working on a private CDN that one can run on their own infrastructure (currently in closed beta). Is this kind of deployment more appealing now that CF bled sensitive data? On the other hand I've also built Cachoid ( https://www.cachoid.com/ https://www.cachoid.com/ ), which is somewhat federated like Fly's but for website acceleration and performance for WordPress, Drupal, landing pages etc. We do have the option to spin a dedicated routing layer with Cachoid, which sort of addresses the shared/neighbor bleeding issue CF suffered from. But I still don't think decentralized is the ultimate answer to security. Although I realize that the impact could be minimized greatly.