ビルドシステムを限定した事でメモリ効率が良い
VPSはLinux→VM→ユーザ空間でサービスを提供しているけど、ユーザ空間内でゲストOSを読み込むのでマシン効率は良くない。 ただNetlifyのようにLinux→ビルドシステム→ユーザ空間で提供するとメモリ効率が非常に良い。 これNetlifyがなぜ無料枠がこれだけ大きいかにも関わってくる話だと思ってる。ビジネスユーザだけで賄えている
Netlifyは1ユーザならAWS Lambdaを使い過ぎない限りは無料で使える。 チーム開発の課金だけでお金は賄えると言っている。 FirebaseもGoogle App Engineと比較すると無料枠が大きくなっている。 海外は最近このような個人優遇の傾向が徐々に強まってきている。動的サービスの無料提供のハードルが下がった
ビルドシステムを起点にしてユーザ空間を分割させるのは頭の良い割り切りで、有名なビルドシステムに対応すればほぼすべての静的サービスのニーズに対応できている。 しかしそこで終わらせなかったのがNetlifyの凄いところだと思う。 AWS Lambdaを登録なしに使えるようにしてハードルを下げたのは実に上手いやり方だった。 これによってログインが不要な動的サービスの大半はNetlify「だけ」で提供できるようになったのは大きい。 無料で提供するためには、このような割り切りを見極められないといけないのだろう。使ってみて感じた展望も書いてみる。
VPSである必要性が小さくなりそう
個人ならVPSからFirebase/Netlifyに移動する人が増えそうと思った。 単純なリクエストを処理するだけならこれらで十分と思う。 逆にVPSでなければならないケースは、サーバで何らかの処理をして返却する時に、(1) メモリをたくさん利用して処理するケース、(2) サーバサイドで何らかの処理をして必ず100ms以内に応答を返したいなどの高速ニーズ、(3) 認証くらいじゃないかな。 そんなには多くなさそう。 これはDeep Learning以外ならサーバの負荷をクライアントに移譲すれば割と解決できる事が多いからだ。 これからのVPSはただ提供するだけでは駄目で、Firebase/Netlifyに価格面で何らかの対抗ができないといけない。JavaScript/Node.jsはさらに流行りそう
またNetlifyは様々なビルドツールに対応してはいるけど、Node.jsが機能的に突出しているので、なんやかんやとNode.jsへの移民が増えそうな気がする。 他にもNetlifyのAWS Lambdaのサポートが今のところNode.js/Goだけ、FirebaseのサポートはNode.jsだけな事もあって、ベンチマークが良ければ色々な言語覚えるの面倒だから、今後はサーバからクライアントまでJavaScriptで良いやともなるかも知れない。 仮にそうなれば割と多くの言語がWeb開発から脱落しそうでもある。 言語の棲み分けは考えておかないといけない。サーバ処理のレスポンスがどこまで早くなるかが鍵
バックエンドはNetlifyにぶん投げして、WebフレームワークもNetlify Functionsで妥協して、JavaScriptで完結した世界はどうなるか。 まずスケーリングとか、障害監視とか、Linuxカーネルの設定とか、HTTPサーバの設定とか、Webフレームワークの選定とか、バッチの設定とか、セキュリティの設定とか、そういった煩雑な仕組みをまったく意識する必要がなくなる。平和だ。肝心の速度はどうかというと、簡易的な静的ページのTTFBを測定してみるとNetlifyは80msだった。 Vultrなら20msくらいなので、平凡よりちょっと早い感じである。 ではNetlify Functionsはどうかというと、Node.js実装でほぼ何もせず返答を返すようなモデルで1.3sくらいかなあ。 ゴリゴリ使わなければ無料で返答が帰ってくるだけで画期的と思うけど、まあ遅いですね。 Firebaseは確認してないけど、キャッシュに載っていなければそこまで早くはないんじゃないかなあ。 ここが改善されるとVPSの領域はガンガン小さくなる。 プログラムの起動時間の高速化技術などがもっと進化するかも知れない。
0 件のコメント:
コメントを投稿