Skip to main content

Launch HN: Fly.io (YC W20) – Deploy app servers close to your users https://ift.tt/33rnswx

Launch HN: Fly.io (YC W20) – Deploy app servers close to your users Hello Hacker News! We're Kurt, Jerome, and Michael from fly.io ( https://fly.io/ ). We're building a platform to run Docker applications close to end users. It's kind of like a content delivery network, but for backend servers. I helped build Ars Technica and spent the majority of my time trying to make the site fast. We used a content delivery network to cache static content close to anonymous readers and it worked very well for them. But the most valuable readers were not these, but the ones who paid for subscriptions. They wanted personalized content and features for interacting with the community – and we couldn't make those fast. Content delivery networks don't work for Ars Technica's best customers. Running Docker apps close to users helps get past the "slow" speed of light. Most interactions with an app server seem slow because of latency between the hardware it's running on (frequently in Virginia) and the end user (frequently not in Virginia). Moving server apps close to users is a simple way to decrease latency, sometimes by 80% or more. fly.io is really a way to run Docker images on servers in different cities and a global router to connect users to the nearest avaible instance. We convert your Docker image into a root filesystem, boot tiny VMs using a project called Firecracker (recently discussed here: https://ift.tt/32XLUFu ) and then proxy connections to it. As your app gets more traffic, we add VMs in the most popular locations. We wrote a Rust based router to distribute incoming connections from end users. The router terminates TLS when necessary (some customers handle their own TLS) and then hands the connection off to the best available Firecracker VM, which is frequently in a different city. Networking took us a lot of time to get right. Applications get dedicated IP addresses from an Anycast block. Anycast is an internet routing feature that lets us "announce" from multiple datacenters, and then core routers pick the destination with the shortest route (mostly). We run a mesh Wireguard network for backhaul, so in flight data is encrypted all the way into a user application. This is the same kind of network infrastructure the good content delivery networks use. We got a handful of enterprise companies to pay for this, and spent almost a year making it simple to use — it takes 3 commands to deploy a Docker image and have it running in 17 cities: https://ift.tt/2wlngCT . We also built "Turboku" to speed up Heroku apps. Pick a Heroku app and we deploy the slug on our infrastructure .. typical Heroku apps are 800ms faster on fly.io: https://fly.io/turboku/ We've also built some features based on Hacker News comments. When people launch container hosting on Hacker News, there's almost always a comment asking for: 1. gRPC support: apps deployed to fly.io can accept any kind of TCP connection. We kept seeing people say "hey I want to run gRPC servers on this shiney container runtime". So you can! You can specify if you want us to do TLS or HTTP for an app, or just do everything yourself. 2. Max monthly spend: unexpected traffic spikes happen, and the thought of spending an unbounded amount of money in a month is really uncomfortable. You can configure fly.io apps with a max monthly budget, we'll suspend them when they hit that budget, and then re-enable them at the beginning of the next month. One of the best parts of building this has been seeing the problems that developers are trying to solve, often problems we didn't know about beforehand. My favorite is a project to re-encode MP3s at variable speeds for specific users (apparently the Apple Audiobook player has no option for playback speed). Another is "TensorFlow at the edge" — they trained a TensorFlow model to detect bots and run predictions before handling requests. We're really happy we get to show this to you all, thank you for reading about it! Please let us know your thoughts and questions in the comments. March 18, 2020 at 04:15AM

Comments

Popular posts from this blog

Launch HN: Simmer (YC W19) – Reviews for Delivery Dishes https://ift.tt/2Y4sD67

Launch HN: Simmer (YC W19) – Reviews for Delivery Dishes Hi HackerNews community! We’re Vaibhav and Richard, founders of Simmer ( https://usesimmer.com ). Simmer aggregates dishes from DoorDash, Caviar, GrubHub, and basically every other delivery platform out there, and tells users the best dishes across the board. We do this by providing dish-level reviews. Users find highly reviewed dishes on Simmer, choose the delivery platform of their liking, and we deep link them into their chosen delivery app. We essentially lead gen to delivery. We started working on Simmer because we loved trying new restaurants, but never knew what to order. Especially, when there’s a 5 page menu. We always asked ourselves, “Why aren’t there ratings for individual dishes?” We launched our app with this restaurant-centric use case (reviews for every dish at every restaurant), but when we rolled out delivery integrations, we realized that users resonated most with the delivery angle. They found it particularly ...