
Introducing Fly Edge Apps - nzoschke
https://fly.io/articles/fly-edge-applications-global-javascript/
======
myoffe
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?

~~~
mrkurt
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.

~~~
zmmmmm
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?

~~~
bharatkhatri14
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/](https://www.openfogconsortium.org/)) (2)
Edge Computing
([https://en.wikipedia.org/wiki/Edge_computing](https://en.wikipedia.org/wiki/Edge_computing))

~~~
Brometheus
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.

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

------
igammarays
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.

~~~
jeromegn
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](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](https://github.com/superfly/onehostname)

------
dgreensp
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. :)

~~~
mrkurt
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)

~~~
dgreensp
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.

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

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

~~~
fungi
mainland china on the roadmap?

------
pcx
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!

------
napoleond
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?

~~~
mrkurt
Sure! You can even pick apart the code if you want:
[https://github.com/superfly/fly](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.

~~~
napoleond
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.

~~~
mrkurt
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.

~~~
napoleond
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...

------
pabl0rg
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](https://cloud.google.com/appengine/docs/locations)

------
ngz00
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.

~~~
mrkurt
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. :)

~~~
zng00
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?

------
srhyne
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?

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

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

~~~
mrkurt
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.

~~~
johnhenry
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?

------
nivertech
Is this something like AWS Lambda@Edge?

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

~~~
kentonv
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.)

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

------
fenaer
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!

