Introducing Fly Edge Apps
fly.io
fly.io
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
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.
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.
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.
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.
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. :)
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)
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.
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.
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.
Hmmm...
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.
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. :)
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?
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?
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.
(Disclosure: I'm the tech lead for Workers.)
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!