Congratulations to Chris McCord and Fly.io!

Haven’t been on Twitter in ages… then see this at the top :003:

https://twitter.com/chris_mccord/status/1428821074553315332?s=21

Congrats Chris, and thanks Fly.io for supporting Chris’s work on Phoenix :023:

If you have any questions about fly.io please start a thread in the Phoenix Questions section, and please feel free to use this thread to congratulate Chris : - )

73 Likes

Woahhhhh this is fantastic news! Congrats!

1 Like

For some background on fly.io there is an episode of thinking elixir with Kurt Mackey:

What do you think is the vision of this “fusion”?
What can the lead of the best™ web-framework and a revolutionary (it is, I think) hosting service do together?

I’d start with (If I understood the tweet correctly):

  • automatically connected nodes (via PubSub), publish in Ohio, consume in Frankfurt or Tokio.
6 Likes

I’ve been using fly.io for my playing around (aka ‘learning’) with Elixir / Phoenix, and I’m certainly impressed with it, but for my toy (and unstressed!) apps I guess that’s a low bar.

What sets a high bar is how they make it truly painless to push distributed nodes close to users, something any Australian like me is going to be sensitive to (200+ ms pings to US hosts, more to Europe).

The fly.io blog is terrific.

Chris McCord joining them is I think very good news for the Elixir/Phoenix ecosystem.

7 Likes

First of all this is awesome for Chris, I’m happy for him! Fly seems like a really cool company and product.

He seems to indicate that he will continue to work on Phoenix partly for work, so I wonder if they want to make a big push to make Phoenix deployments seamless with Fly, or if they have a larger play here where they want to incorporate some of Elixir/Phoenix/LiveView/distributed PubSub into their own stack.

4 Likes

Thanks everyone! I’m extremely excited about what Fly unlocks for the Elixir/Phoenix community. Fly went off and built the perfect platform for Phoenix a few years ago, and we only recently just found each other. I’ll have some in depth thoughts to share about this soon, but in short – Fly provides turn-key geographic deployments that puts servers close to your users, and it networks them securely together. What this means for Elixir is all the distributed features of the platform just work on a global cluster, securely. What this means for Phoenix is all the tools you’re already using like Phoenix.PubSub, Presence, Just Work™ across the globe, and LiveView applications now run close to your users, so latency is optimized wherever you would like to best serve users. For example, the code you already write today for PubSub will just work when deployed to Atlanta, Tokyo, and Sydney. With LiveView processes literally running close to end-users, LiveView apps in the wild on Fly will provide equal and often better experiences compared to SPAs for many applications. I’m excited to help make this future the norm for Phoenix projects. The community is going to be able to build things that simply aren’t easily possible on other platforms :hatched_chick::fire::fire::fire:

Yes, Fly will support the majority of my time working on Phoenix and related libraries. Outside of oss work, I’ll spend my time ensuring smooth Fly deployments for Elixir/Phoenix applications and publishing content around using Fly + Phoenix. For example, now that turn-key geo distributed deployments are “solved” at the infra level, the focus can shift to resources around building geo distributed applications, and what patterns and architecture decisions arise out of this new world.

78 Likes

Super exciting stuff here Chris, can’t wait to see what comes from it! Best of luck, and congrats!

2 Likes

Well, I guess I’m going to have to checkout fly.io pretty soon.

3 Likes

Ooooh, nice. Can you push them to invest in developing an implementation of Wireguard in Erlang, please :slight_smile:

Curious to see how cross data center Erlang meshes work out. I’d be less worried about security(my understanding is fly.io creates networks for your nodes through wireguard) and more about users not designing for the more frequent splits they’ll see.

My initial reason for wishing there was a Wireguard Erlang implementation (like there is a Go one) was for Nerves. Not sure if there would be any actual benefit to fly.io if there was one, just know they are invested in Wireguard and now Elixir :slight_smile:

5 Likes

This is really exciting. Latency around the globe seems to be a common thing that is brought up in criticism of LiveView (or at least as an excuse not to use it). I always found this odd as, most of the time, a new business will only market to a specific area/country. If they are so lucky to expand internationally, they are probably going to spread their app out on servers around the world whether they are using LiveView not.

Anyway, this is really awesome and you guys keep delighting me with the problems you keep choosing to solve. Congrats!

4 Likes

Congratulations, Chris! :hatched_chick: :fire:

3 Likes

Congrats! @chrismccord

1 Like

That’s brilliant news. Congrats Chris :slight_smile:

I’ve been dabbling with Fly.io on my elixir projects, it certainly has the hallmarks of a company I can get behind. (Technology is at the right level of sophistication and abstraction for me, and they have excellent docs and developer outreach in general). I was getting excited about Elixir + Fly but never fully comitted because it was always a little bit complicated or awkward to set up.

I’m super happy to hear that you’ll be spending some time making that process smoother, and I’ll be digging into Fly again as soon as I need to set something new up.

3 Likes

Yay! I get to have @chrismccord as a co-worker!

Also, tomorrow the Thinking Elixir Podcast is releasing an interview with Chris about his move to Fly.io, what it means for Phoenix development and about the new Phoenix 1.6 release!

19 Likes

110% Awesome sauce!

Looking forward to listening to this one!

5 Likes

That’s awesome!

1 Like

First, Congratulations Chris!

+1 for mix phx.deploy fly :smiley:

6 Likes