It's been fascinating to watch this startup pivot to find product-market fit over the past year. First I heard from them, fly.io billed themselves as a way to avoid multiple subdomains (blog.yourcompany.com, app.yourcompany.com, etc.), and now they're doing serverless edge deployments. This actually makes me trust them more, as they seem dedicated to build something that provides value.

Thanks, that's appreciated!

It's not such a huge pivot. The "one hostname" was checking for interest in this area and it worked well. Putting stuff under a single hostname seems to be something people want to do.

At its core, the previous product was a flexible, globally distributed, load balancer. We built all these middleware, features we wanted and people might also want. In the end it was untenable: supporting such a large variety of small building blocks was going to be hard. Building new middleware all the time was also becoming a pain, changes were required in multiple components for each middleware.

This new "edge app" product gives the same flexibility, but puts the power (and burden) into the developer's hands. You could build our entire previous product on this new platform.

Note: https://onehostname.com still exists and runs on our new platform. However, the article it points to is for the old product. The source for it is available here: https://github.com/superfly/onehostname

I don't fully get it. What does the "edge" here means? How is it like a CDN? How is this different than Heroku/GCloud?

We're still learning how to best describe this.

Edge is a bit of a marketing term, we all might end up using something else to describe this down the road. Edge normally means "servers that are very close to your users".

CDNs are specialized edges for caching HTTP content. Edge Apps are a lower level concept than CDNs, but you can picture the same thing. We have servers all over the world, we distribute your code to them, your users connect to whichever is closest to them.

Heroku, and most of gcloud, are location specific. You deploy code, it runs in Ashburn Virginia, your users traverse the internet to connect to your apps (which adds latency).

Our Edge Apps are most likely to replace a CDN, not replace your app hosted on Heroku. Lots of our customers run centralized apps and then write JavaScript to enhance them by caching partials close to users, or optimizing content as it gets shipped to users.

I got most of the way through the page assuming it was something to do with Microsoft edge. Perhaps worth at least one line early on in the page to give a bit better idea what it is?

Edge, the term, is really popular in IIoT/5G space. It's now a continuum of services - Cloud, Fog/Edge, Mist, Dew. I agree that some of it is just marketing jargon but Fog/Edge as a concept is now well understood. References: (1) Open Fog Consortium (https://www.openfogconsortium.org/) (2) Edge Computing (https://en.wikipedia.org/wiki/Edge_computing)

I don't know it. So others who might otherwise be interested might not know it as well. So it would be nice to provide a small hint. That should'nt be that hard. As a startup, you cannot afford arrogance, if you want to succeed.

Definitely not meant as arrogance. We'll make it clearer, it seems like there's a bit of that confusion here.

I was also convinced that it referred to Microsoft Edge applications, definitely worth a little explanation.

> Edge normally means "servers that are very close to your users".

In the circles I'm in, that's definitely not true. Purely anecdotal of course, but Edge definitely refers to a browser made by Microsoft around here.

I think it would make more sense to people who work on a CDN everyday.

This may sound like FUD but I'd strongly encourage people to stop spending too much time on edge or internet explorer. Just do the bare minimum and focus on Chrome/Firefox. It is better for everyone. I am very disappointed that Microsoft decided to bundle edge with Windows showing yet again they don't get it. Microsoft should be able to update edge separately of Windows. Without this, corporate users (pretty much the only reason to support ie/edge) will still be behind the curve for a long time.

Heroku runs your code on one set of colocated or near-located servers, usually behind a load balancer. There may be a database involved as well. You rent a VM for a certain amount of time and pay for that VM.

Fly Edge, Cloudflare Workers, AWS Lambda@Edge all take your code, deploy it atomically to 50+ datacenters located in almost every continent / developed-ish country, and run it in a "serverless" mode in response to HTTP requests on the closest edge to the request. They run your code in an on-demand container mesh that loads it up when there's actually a request for it, so you just pay for the total amount of time that your code runs.

Agreed. At first I thought it was something related to MS Edge. Even when I figured out it was something else and searched for both "edge apps" and "edge applications," all I found was MS Edge related links.

Sounds great.

When I think about using this, the main question that comes to mind is about the scale and scope of your infrastructure, compared to Cloudflare, for example, which recently came out with a way to run JavaScript at the edge, and has more "edge chops," as a company, than I could ever ask for. I say this having started a YC company that advertised "scalable" hosted apps, but planned to deal with the actual scaling as it came up. With start-ups, you never know when you are just using an MVP, you know?

This is a new enough type of thing (edge apps) that it's not going to become a commodity overnight, but it seems like the kind of business where, once there's competition, small customers will care about developer experience, but larger customers will care more about price and performance. This is the problem with "easy-to-use" developer tools and services; customers with money can burn a few extra developer hours getting a more complicated service configured.

All that said, Fly sounds legit and innovative. :)

Oh definitely, we have a huge credibility grind to get through. We have the benefit of a successful exit doing hosted DBs at scale, at least, and I'm not sure I ever would have jumped into something like this otherwise. It's big hairy infrastructure, and really expensive to even get started.

For bigger companies, one of my pet theories is that they're going to want to run private edges. Shared infrastructure at every other level is passé, the trend is really to "own" the OS on up. This is part of why our runtime is open source, it's a reasonably good way to get into bigger companies thinking about these problems that don't want to be exposed in the next "bleed" event.

We're running in 15 datacenters at the moment which is (a) way more than most companies can manage and (b) not nearly as many as Fastly/Akamai/CloudFlare/*CDN. So I think we're in a good spot to win devs and startups over. And again, open source. We all love our OSS runtimes. :D

(note: I was a tremendous Etherpad fanboy)

Interesting to hear!

Thanks for the EtherPad love. (I'm finally working on my next app!) There's something a bit AppJet-like about Fly. I also really think this model could be the future; do you even need an "application server" if you have Fly and a datastore? I'm really looking forward to what you come up with for persistence. At AppJet, we had something called "magic storage" where you could access the "database" via proxy objects, with no explicit database calls. I wouldn't do it quite the same way now, but I can imagine some really neat JS persistence APIs that strip away the usual impedance mismatches between application logic and database, especially if the data is "right there" at the edge.

When you say "it's everything you need to build your own CDN", you mean "in pure software, with infrastructure provided by Fly", right?

Yes that's it. You write a caching service, we run it all over the world. That's probably worth its own article.

mainland china on the roadmap?

We moved to use Fly.io over CloudFlare for providing SSL on custom domains for our customers. CloudFlare gave us a quote of over $2500/month and Fly.io was free of cost. The onboarding was spot-on, we got to talk to one of their engineers to understand how their system worked. Setting it up and going live was a breeze. Has been working flawlessly since then. Kudos to the team! I strongly recommend them!

This is really neat--congrats on the launch. Can you tell us a bit about the infrastructure behind it? Is there any spin-up time, like AWS Lambda has? Presumably "fly.cache" persists between requests, but is other memory shared between requests?

Sure! You can even pick apart the code if you want: https://github.com/superfly/fly

There's no warmup time. We spent some time with various OSS FaaS tools and that was pretty killer. When you deploy, we build a v8 snapshot of your code, then push it out to all the Edge Servers. It's already in memory and ready to rock when a request comes in — less than 1ms to get to your code for most apps.

fly.cache does persist, although it will vary per region (that's a surprising thing we learned about CDNs, cache contents vary per region quite a lot). It's volatile so you shouldn't rely on it for durable data storage, but you also pay for what you use so we have a strong incentive to not evict cache data any more than you request. :)

The global context _can_ be shared between requests but you can't really count on it. There's no guaranty that one request will run in the same context (or isolate or server) as a previous one.

We have some ideas for more durable and structured storage down the road. Building APIs that are location agnostic is fun, but a little mind bending.

What do you mean by "It's already in memory"? If I build an app now and abandon it, will it always be in fly edge memory? I'm sure that's not the case so can you explain that further

Cool! There's obviously some competition coming from the various CDNs and cloud providers, but it's an interesting space and I wish you guys the best. I haven't really wrapped my head around the use cases yet (almost need a distributed edge database before it really ramps up the value) but I'll be playing with this for sure.

We're still discovering the use cases ourselves! We totally agree about an edge db, though.

Right now it's _best_ suited for building proxy-like applications. Aggregating APIs, speeding up existing apps without touching them, user aware caching, etc.

But we're getting constant pressure to expand the scope of what they do, too, which is pretty exciting.

Thinking about this some more: it would be very straightforward to implement a leveldown API on top of fly.cache. That, paired with something like PouchDB, would give you an edge database. You could have one big centralized CouchDB server with a bunch of PouchDB clients at the edges.

Hmmm...

This + persistence (even a simple key/value store with range queries on the index) would be awesome. I use Lambda+DynamoDB for small projects and it feels like driving to the grocery store in a steam roller.

That is a fabulous analogy. I think we'll have something interesting in the next few months, maybe we'll even get the honor of popping up on HN again!

Hey Kurt - Fly user here, I’m definitely a fan of your toolset. It has made last mile/server availability management really simple for us. Above, when you mentioned toying around with various oss faas tools, which ones did you all try out? Any lessons learned to share?

How does Fly compare to the forgotten grandfather of serverless ... Google App Engine?

Edit: just read that GAE only runs apps in one region [1]. That’s odd because it seems one benefit of tying an app to GAE’s cloud storage API would be the ability to leverage google’s distributed data preeminence.

1: https://cloud.google.com/appengine/docs/locations

Very cool to see this catching on, similar to the Edge features rolling out of Cloudflare and Fastly. I’ve been doing similar things with Nginx + LUA, and I’m curious about the performance of your V8 runtime. Also, where are y’all located? I’m looking for a change and this is a domain I’m highly interested in.

We actually started experimenting with nginx + Lua way at the beginning. It was a great way to build a poc.

v8 is fast, surprisingly so. In an http request/response cycle you can write and awful lot of JavaScript logic in v8 without adding perceptible latency.

We have a small office in Chicago, but are mostly distributed. :)

I just watched your presentation at NWCJS. I was aware that Node was just the ES api implementations on top of v8 and libuv, but your presentation elucidated the exact mechanisms behind the Fly runtime and actually the Node runtime as well.

Seems like y'all are in a good position to expand the native bindings and add some of the more experimental ES proposals faster than Node. Got any details on the Fly roadmap?

Congrats Fly.io! I really like your new direction.

Could you help share how this will differ from Clouflare’s Web Worker’s implementation?

I like what CF is doing but it feels more limited. Your example shows using modules. Do you support a number of modules like webtask does?

Great team! Just checked y'all out and looks like I know half of you from Mongo / Rethink world!

Would this be similar to CloudFlare's ServerWorker concept at the edge?

Yes, definitely similar in some ways. Very different in others! We're both running v8 "at the edge", and I expect you'll see Fastly et all do the same soon. And we've both implemented standard JavaScript libraries where it makes sense (fetch, streams, stuff you'd use in Service Workers). And, as far as I can tell, we started working on it at about the same time they did.

The big differences are: ours is a full blown open source runtime runtime; you can run it locally to build + test apps, deploy it somewhere else if you want, and we have more useful APIs (imo) for doing interesting stuff (specifically caching and image/dom manipulation and a few more things cookin') way out at the edges.

Thanks for all the good work -- I look forward to trying this soon. I wonder if you might be willing to expand on the differences further between Fly Edge Apps and Cloudflare Workers, (and whatever Fastly is working on) in a blog post in the near future?

Is this something like AWS Lambda@Edge?

is there support for websockets? (something which is missing from Cloudflare workers)

FWIW, CF Workers do support proxying of WebSockets (e.g. with URL and header rewrites), and termination of WebSockets is on the road map.

(Disclosure: I'm the tech lead for Workers.)

Great! Looking forward. Is there any rough estimate when the termination could be supported?

This seems really interesting as someone who is currently going through the pain that is Java android development.

Unfortunately at my stage, the difference between "free" (excluding Google developer fee) and paid usage is a significant enough difference. I'm probably not the target market though.

This looks really cool, good job!