Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

news.ycombinator.com

Post reply on HN
Print view View original

211–220 of 268 posts

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#211

Post by byteshock »

byteshock wrote: post #209

Fascinating product! I was wondering if there are any other products that are similar to yours? Other than serverless platforms such as Cloudlfare Workers or AWS Lambda. I know Stackpath has been offering this kind of thing for a while. So how would your product compare to theirs? Since Stackpath has a well established cdn network already.

Adding onto my last comment, is Stackpath container pricing cheaper than yours at the moment?

I understand this might be due to Stackpath being a larger company and owning hardware instead of renting it. But the price for traffic and compute seem to be cheaper. There is also no mention of how much you charge for storage on the pricing page.

I’m looking to deploy my next app onto one of these platforms and would like to know the price differences!

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#213

Post by rsmets »

Neat idea and the ease of use is certainly attractive! I have a question though...

Couldn't one simply use a traditional CDN where ever their customers are which would then allow the inbound network requests to jump on private interface routing to where ever the app truly lives quicker - essentially making for a more responsive "business logic" app feel? If all infrastructure was on the same cloud provider, say AWS.

I understand this approach is less dynamic in nature but would have been a solution for the Ars Technica problem presented I feel. If not, what am I missing? Thanks!

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#214

Post by mrkurt »

rsmets wrote: post #213

Neat idea and the ease of use is certainly attractive! I have a question though... Couldn't one simply use a traditional CDN where ever their customers are which would then allow the inbound network requests to jump on private interface routing to where ever the app truly lives quicker - essentially making for a more responsive "business logic" app feel? If all infrastructure was on the same cloud provider, say AWS.…

That's actually a good, generic way to speed up the initial app connections. You can even do it with a CDN in front of a backend on a different network, since most CDNs pool connections.

The problem is that everything useful a server side application does still requires round trips. Even for the most boring content, an 800ms delay is pretty normal if you have a spread out audience.

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#215

Post by mrkurt »

byteshock wrote: post #211
byteshock wrote: post #209

Fascinating product! I was wondering if there are any other products that are similar to yours? Other than serverless platforms such as Cloudlfare Workers or AWS Lambda. I know Stackpath has been offering this kind of thing for a while. So how would your product compare to theirs? Since Stackpath has a well established cdn network already.

Adding onto my last comment, is Stackpath container pricing cheaper than yours at the moment? I understand this might be due to Stackpath being a larger company and owning hardware instead of renting it. But the price for traffic and compute seem to be cheaper. There is also no mention of how much you charge for storage on the pricing page. I’m looking to deploy my next app onto one of these platforms and would like…

Stackpath is cheaper on bandwidth, mostly because of scale. For video based applications, this is a big deal (and we work with video companies to try and get better bandwidth pricing). For typical web app servers, bandwidth is usually not a very large expense.

CPU based pricing is pretty close. We've heard our CPUs are higher performance, but haven't done any real testing. The people who run high CPU apps on us _tend_ to pay less because we scale up and down so quickly.

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#216

Post by byteshock »

mrkurt wrote: post #215
byteshock wrote: post #211

Earlier quoted context omitted.

Adding onto my last comment, is Stackpath container pricing cheaper than yours at the moment? I understand this might be due to Stackpath being a larger company and owning hardware instead of renting it. But the price for traffic and compute seem to be cheaper. There is also no mention of how much you charge for storage on the pricing page. I’m looking to deploy my next app onto one of these platforms and would like…

Stackpath is cheaper on bandwidth, mostly because of scale. For video based applications, this is a big deal (and we work with video companies to try and get better bandwidth pricing). For typical web app servers, bandwidth is usually not a very large expense. CPU based pricing is pretty close. We've heard our CPUs are higher performance, but haven't done any real testing. The people who run high CPU apps on us _tend…

Thank you for your reply. Your deployment seems to be a lot more streamlined and simpler than Stackpath at the moment. That just might be the deciding factor for me and other developers!

I wish you and your team the best of luck!

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#217

Post by mrkurt »

chrisweekly wrote: post #202

Hats off, @mrkurt. This is the kind of thing HN, and YC, are all about at their very best. Absolutely love the way this idea, executed right, helps improve the deployment topography landscape, so to speak. Between service workers, Cloudflare workers, and now fly.io nodes at the edge, the degree of control over where and how your application executes across the network in relation to clients is kind of exhilarating --…

Ahhhh thank you! That's an incredibly nice thing to say.

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#218

Post by anaganisk »

Let's Encrypt was introduced so that money will never be a barrier/excuse for https. In these days it must be a default feature. Pocketing half for something generated for free is not a good signal for me. Yes other half is donated but, isn't that supposed to be optional? Let's Encrypt is supported by huge organizations. And on fly.io, The customer is already paying for compute.

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#219

Post by mrkurt »

anaganisk wrote: post #218

Let's Encrypt was introduced so that money will never be a barrier/excuse for https. In these days it must be a default feature. Pocketing half for something generated for free is not a good signal for me. Yes other half is donated but, isn't that supposed to be optional? Let's Encrypt is supported by huge organizations. And on fly.io, The customer is already paying for compute.

This is a reasonable take. Let’s Encrypt is amazing and we don’t want to diminish their importance at all.

We charge for certificates because the infrastructure to make SSL work (even when the certificates themselves are free) is complicated.

Managing certificate creation can be tricky, we have to deal with all kinds of edge cases (like mismatched A and AAAA records breaking validation). We also generate both RSA and ECDSA certificates, have infrastructure for ALPN validation, and a whole setup for DNS challenges.

And then we have to actually use them. We run a global Vault cluster to store certificates securely, and then cache them in memory in each of our router processes.

The developers who use the certificates the most love paying us to manage certs, and one person who posted in the comments here was able to replace an entire Kubernetes cluster they were using to manage certificates for their customers.

When Let’s Encrypt invalidated millions of certificates a few weeks ago, none of our customers even noticed. That’s what they’re paying us for.

Post reply on HN