- Fly.ioは2023年7月、A16Zと既存投資家のIntel Capital、Dellなどから約2,500万ドル（$25m）を調達した後、EQT Ventures主導で追加の約7,000万ドル（$70m）を確保
- 中核的な課題は、アプリはユーザーの近くで実行するほど良くなる一方で、一般的な開発者にとって複数都市へのデプロイを2時間以内に把握するのが難しいことにある
- Fly.ioはグローバルデプロイだけでなく、オンデマンドVM、リアルタイム機能、ユーザーのpresence、暗号化・シークレット、クラスタ型データベース、ハードウェアアクセラレーション推論も同じ2時間問題だと見ている
- 調達資金は自社のハードウェアフリート、より多くのリージョン、サポートと安定性、高度なストレージ・セキュリティ機能・新しいハードウェア実験に使われる予定
- Fly.ioはオンライン登録後にすばやく試せて、
flyctlコマンド1〜2個とコンテナのパッケージングだけでアプリを動かせる開発者フレンドリーなプラットフォームという方向性を維持
Fly.ioの資金調達
- Fly.ioは2023年7月、A16Zと既存投資家であるIntel Capital、Dellなどを含む投資家から2,500万ドルを調達
- その後、EQT Venturesが主導した追加の7,000万ドルの投資を確保
- 投資発表の現実的な目的の1つは顧客獲得
- 小規模なFly.ioと取引しやすい顧客もいるが、EQT Ventures主導の7,000万ドルの追加調達を受けたFly.ioだからこそ安心する顧客もいる
- Fly.ioは数年にわたりコミュニティでユーザー、ファン、批判者と議論しながら、自分たちが構築しようとしているプラットフォームのビジョンを磨いてきた
「2時間問題」とグローバルデプロイ
- 2020年のFly.ioの基本的な信念は、アプリはユーザーの近くで実行されるほど、より良く動作するというものだった
- 動画やリアルタイムpresenceのようなアプリは、物理的な近接性なしには実現しにくい種類に分類される
- 初期のHNローンチスレッドでは、WebRTC、エッジキャッシュ、ゲームサーバーが主要な話題になると予想していたが、実際の関心はデータベース側に流れた
- Fly.ioが見落としていたのは、特定の「エッジ型」アプリだけがグローバルデプロイを必要とすると考えていた点
- 実際には、ほとんどのアプリもエッジで実行されることを望んでいるが、それが十分に簡単な場合にだけ試みる
- ゲームサーバーはエッジデプロイが必須なので、チームは問題が解決されるまで押し進める
- オンライン書店のようなCRUDアプリは、約2時間試しても明確な道筋が見えなければ別の作業へ移る
現在のインターネット配備方式の限界
- 世界中のCRUDアプリの多くが、Amazon
us-east-1のあるVirginia州Ashburn近郊にホスティングされている状況が問題として提示される
- 多くの開発者はユーザーの近くで動かす方が良いことは理解しているが、一般的なツールでは複数の都市で同時にアプリを運用する方法を2時間以内に把握するのが難しい
- Fly.ioの賭けは、適切なプラットフォームとツールチェーンがあれば、書店、サンドイッチ評価アプリ、音楽レコメンダー、教会のメーリングリスト管理ツールのようなアプリも世界中で高速に動かせるということ
- 対象地域はAshburn周辺にとどまらず、Chicago、Sydney、Singapore、São Pauloのような都市まで含む
- 複数都市で同時に高速動作する能力は、アプリ品質を引き上げる重要な機能と評価される
Fly Machinesと他の「2時間機能」
- サンドボックス化、コードエディタとREPL、CI/CDアプリケーションは、いずれも信頼できない顧客コードを実行する必要がある
- こうしたシステムは、必要なときにロックされたコンテナを起動する方法をそれぞれ解決してきた
- しかしオンデマンドVMは、さまざまなアプリにとって価値の高い機能であるにもかかわらず、2時間の調査だけでは実装への道筋が明確にならない
- そこでFly.ioはFly Machinesを作り、VMを起動する作業を関数呼び出しのように単純にしようとしている
- 今後の対象も同じパターンに属する
- リアルタイム機能とユーザーpresence
- 暗号化とシークレット保存
- クラスタ型データベース
- ハードウェアアクセラレーション推論
- 分散データベース、データlocality、ストレージ、AI、アプリフレームワーク分野の他社も、開発者の「2時間の窓」問題を解こうとしている
- Fly.ioが意図どおりに機能すれば、そうしたプラットフォームがその上に新しい基本要素を作り、ユーザーに新しいアイデアをより速く届け、アプリ品質を高められる
投資資金が必要な理由
- Fly.ioは、こうしたプラットフォームを作るには資本集約的な要素が必要だと見ている
-
自社ハードウェアフリート
- Fly.ioは常に自社ハードウェア上で動作してきた
- 汎用クラウドの上に積み上げるのではなく、ハードウェアを自らラックに設置することには、技術的理由とコントロールの観点からの理由がある
- 中核的な理由は経済性
- 人々にこのプラットフォーム上でアプリを作ってもらうには、10年後にも存在している可能性を示す必要があり、ハードウェアが必要なマージンを可能にすると見ている
-
より多くのリージョン
- Fly.ioは19リージョンで始まり、個々のアプリケーション開発者だけを対象とするなら十分な数だと見ていた
- しかし、マネージドデータベースや開発者ツールのような他のプラットフォームもFly.io上で動くことを望んでいる
- そうした企業は、より多くのリージョンを必要とする
- Fly.ioは現在33リージョンまで増え、新しいリージョンを有効化する速度もさらに速くなっている
-
サポートと安定性
- Fly.ioはプラットフォームの安定性に関する課題が大きいことを認識している
- それを巧妙な方法だけで解決できる問題とは見ていない
- 高度なストレージ、セキュリティ機能、新しい種類のハードウェアにもさらに賭けていく考え
変わらないプラットフォームの方向性
- Fly.ioが目指すプラットフォーム企業としての方向性は、2020年以降変わっていない
- 志向しているのは、オンライン登録後5分以内に試せるプラットフォーム
- 反対側には、オンライン登録後に営業担当者が連絡して価格を提示し、デモを設定するプラットフォームがある
- マニュアルを読まなくても理解できるプラットフォームを望んでいる
- 反対側には、使い方の本が競うように出され、アプリを起動するのに専門認定が必要なプラットフォームがある
- Python、Rust、Juliaのコードを自然に実行できる必要がある
- コードをJavaScriptへ再コンパイルしなければならない方式とは対照的
- Fly.ioの機能はたいてい
flyctlコマンド1〜2個で利用でき、コンテナとしてパッケージ化できるアプリなら動作する
- すでに動作するDockerコンテナがあれば、Fly.io上ですぐ試せる
- ゼロから始めても一桁分の分以内にFly.io上で動かせるべき
- すべての大陸で動かすには、そこからさらに1〜2分ほどかかる可能性があると見ている
1件のコメント
Hacker Newsのコメント
「多額の資金を調達した」という表現は、今ではあるサービスの顧客の立場からすると、まず不安を感じる
その会社がベンチャーキャピタルの資金だけで回っていて、自分が使ったり支払ったりしている価格が現実的な将来コストではなく、売上と無関係にプラットフォームだけが拡大し続ける構造のように見える
顧客としては、運営と有料顧客基盤によって収益性があるという話を聞くほうが、安定性への信頼につながる
記事そのものに反対しているわけではないが、もはや顧客視点では前向きなシグナルとは見なしにくい
そしてある日、自分は素晴らしいプラットフォームを無料で使っているのだからと、価格をとんでもなく変えてくる
芝刈り業者を雇ったら、数年後には乗用芝刈り機を3台持ち込んできて、提供しているサービスのコストを賄うには値上げが必要だと言い出すようなものだ
10エーカーの芝生を持つ顧客向けに事業を拡大しておいて、自分にも同じレベルのサービスが必要だと勝手に想定したのは彼らなのに、結局芝生の手入れを失うのは自分だ
投資家ならベンチャーキャピタル依存を心配するのも分かるが、ユーザーとしては Hello Fresh のようなサービスで投資金による補助を受けた安い食事を得られるのは別に悪くなかった
そう遠くないうちにイグジットのために売却される気はするが、独立企業として続ける痛みに耐える気力があるなら、とても歓迎したい
製品は検証済みで、競合より成功する可能性が高く見え、当面は消えなさそうで、製品改善もさらに速くなるだろうと期待できる
「世界中の CRUD アプリが Loudoun County, VA、つまり Amazon us-east-1 の Ashburn に載っていて、その街には Rails アプリが多すぎて、そのうちの1つが郡監督委員会に当選した」というジョークは、正しすぎて痛い
考えてみると、リージョンというパラダイム自体が全体としてかなり古びて見える。AWS もいくつか動きを見せてはいるが、結局はコントロールプレーンなどで依然としてリージョンの概念に縛られており、VPC の奇妙さ、分かりにくい課金、可用性の問題、複数リージョン/AZ を扱うためのあらゆるハックやスタックや努力がついて回る
Fly や Cloudflare のような後発組は、リージョンの概念なしにエッジで計算を実行するアプローチによって、徐々にクラウド領域を支配するようになり、AWS のリージョンベースのアプローチは、その中に閉じ込められたレガシーアプリケーション向けとして残るのではないかと思う
リージョンベースのアプローチは「本当のクラウド」というより、ホスティング型の弾力的データセンターに近い。本当のクラウドは、どこにでもあって意識する必要すらない形であるべきだ
その結果、ブランドマーケティングに非の打ちどころがない。ブログのどの記事も明快で、少し皮肉っぽい声で語られている
有名なハッカーになりたいなら、業界で少し有名な書き手でもあるべきだ
こうした自己認識的な論評は、めったに使わないからこそ効果があるが、今回の記事では非常によく効いている
こうした発表にある傭兵的な動機、暗黙の偽善、自己顕示を認めつつも、重要な情報をすべて伝え、プラットフォームが解決する現実の問題を簡潔に説明している
投資資金の正当な使い道も明確で、「なぜ」と「どれくらい」に関する疑問に答えている
「なぜスタートアップはこういう発表を書くのか？」について、何度も資金調達を経験してきた会社では、100% メディア露出のための口実だった
「CEO が横領と嫌がらせで同時に逮捕された」でない限り、技術系メディアに記事を載せてもらう口実を作れれば無料広告になる
対象顧客が技術系メディアを読んでいるならなおさら良い。悪いことではないが、傭兵的な理由を認めつつ最もよく見た理由を外していたのは意外だった
記者たちは読者をよく分かっていて、投資発表の付いた記事だけがクリックを集めると解釈していた
そのため私たちは資金を調達した後、最大6か月は静かにして、新機能や製品リリースに合わせて発表することがよくあった
資金調達発表のない技術記事にももっとクリックが集まるなら、この循環は変わるかもしれないが、今のところ一種の囚人のジレンマのように見える。そういう記事は書かれず、クリックも集まらず、だからまた書かれない
たいていは記事で説明されているように、特定のメッセージや印象を残そうとする傭兵的な目的のためだ
もちろん会社名を知らしめる目的もあり、それは記事であまり触れられていない傭兵的動機かもしれない
記憶では技術的には公開情報だった気がする。会社を創業したときにそう説明を受けたが、かなり前の話だ
自分で発表しなければ他人が発表するのだから、先に出して、人々にそちらの記事ではなく自分の記事を読ませるほうがはるかにいい
1億ドルを調達したなら、10億ドルのイグジットを目指さなければならない。今の勢いを維持するには研究開発費がものすごく増えるはず
スタック全体を自前で作り、最終的には全部を非常に堅牢にしなければならないので、巨大なエンジニアリング作業になる
Fly は計算資源に課金し、ハードウェアと帯域幅が安いので、帳簿上は収益性があるように見えるかもしれない
しかし実際のコストは研究開発、マーケティング、株式報酬であり、これらのコストはどんな規模でも収益性を妨げうる。一時的な費用ではなく、継続的に使い続ける必要があり、使わなければ顧客は離れていく
Heroku だけの話ではなく、プラットフォーム/インフラ系スタートアップの悲劇だ
小さなクラウドプロバイダーをあまり見かけないのには理由があり、経済性は規模があって初めて成り立つ
Fly はソフトウェアエンジニアリングについて本当に素晴らしくモダンな見方を持っているようで、働くにも良さそうに見えたが、マーケティングと製品の間に大きな不一致を感じる
マーケティングやドキュメントは、世界中に分散したアプリサーバーを非常に簡単に立ち上げることに焦点を当てているが、実際に世界分散アプリサーバーを必要とする顧客は、すでに世界分散データストアまで備えた成熟したプラットフォームを持っている可能性が高く、アプリサーバーを立ち上げること自体は気にしないのではないかと思う
なので、自分はインターネットアプリケーションアーキテクチャについて何か根本的なことを誤解している気がする
複数リージョンで動かせるのは便利だ。Splatoon コミュニティは一か所に集まっておらず世界中に散らばっているので、米国だけにホスティングすると日本のプレイヤーには遅く、その逆も同じだ
プロジェクトがうまくいかなくても、後で学校を出たあとにかなり役立つ経験になると思う
今は米国東部、Amsterdam、Tokyo で月約10ドルで動かしている
その対象が Kubernetes、シングルページアプリ、GraphQL、エッジデプロイへと変わるだけだ
ゴールドラッシュではシャベルを売ればいい
「Python、Rust、Julia のコードをうまく動かせるプラットフォーム企業と、それを JavaScript に再コンパイルする方法を探させるプラットフォーム企業がある」という一文は、Cloudflare と Deno を冗談っぽく小突いているように見える
Fly が Docker コンテナに加えてWASM コンテナのホスティングまでやるようになれば面白そうだ
Cloudflare を小突いたのは「営業担当から電話が来るようにする」の部分だと思う
Fly がゲームやエッジキャッシュなどに使われるのかと思っていたが、実際にはみんなが Rails+PostgreSQL の CRUD アプリをデプロイする新しい Herokuのように使っていると認めていたのが良かった
理解したところでは、次の目標は Rails+PostgreSQL アプリをエッジ化することを些細なこと、つまり「2時間で解ける問題」にすることだ
かなり大胆だ。歴史的には「このドメインモデルをどうシャーディングするのが最適か」のような、アプリケーション/フレームワーク/ドメイン特化の結合が必要だった
PaaS/IaaS で解決するというのは、実質的には分散 Cloud SQL/Aurora を書いて運用することに近い
ただ、Aurora クローンや Neon のようなものをスタック内でシームレスに動かす程度なら実現可能で、製品価値もかなり大きそうだ
SMB/趣味向けクラウドのマージンが相対的に低いことを考えると、fly.io がどうやって収益性を確保するのかよく分からない
世界中を無料ティアに載せることはできるかもしれないが、EQT が回収しなければならなくなったとき、何が起きるのだろうか
企業が本気で選ぶだけの十分な機能を作れるのだろうか。自分が在籍していた会社では、5人未満のチームで拡張の必要がまったくない場合でなければ、使うのも推すのも難しそうだ
私たちはユニットエコノミクスが良い。私たちがやった中で最もリスクが高く怖かったのは、自前ハードウェアで始めたことだ
開発者中心のインフラでは、多くの開発者を引き付け、彼らに職場へ私たちを持ち込んでもらい、その雇用主が長期にわたってより良いものを作れるよう支援しなければならない
購買プロセスのある企業は、スタートアップから中核インフラを買わないように設計されているため、これは非常に長い時間がかかる
まだ全員に合うわけではないとしても、今のところ私たちには機能している
[0] https://community.fly.io/t/funding-and-longevity/1957
fly.io がアプリ全体、動的コンテンツまで CloudFront や他の CDN の前段に置くやり方とどう違うのか、あるいはなぜ優れているのか気になる
CDN はクライアントに近いので、低レイテンシな SSL セットアップを提供し、この差はかなり大きいことがある
アプリサーバーをエッジに押し出すわけではないが、そうしても Virginia のバンカーにあるデータベースを叩くレイテンシコストは依然として払うことになる
多くのアプリは1回の Web リクエストでデータベース往復を何度も行うので、さらに悪く見える。Web リクエストでレイテンシコストを払うより、アプリサーバーがデータベースへ高速にアクセスできるほうがよいと思う
Fly の対象顧客は大半が静的コンテンツ寄りに見える