Webサービス開発の潮流の変化

というテーマで書こうとしてみたが、言葉にしてみるとなにかうまくいかなかった。更新予定。

Web 2.0 (?)みたいな時代には明確に「常識」だったことのうち、今は状況が変わっていることっていうのがたくさんあって、人によって過去のある時点のバイアスが強かったり、変化の見え方が違っていたり、歴史的な背景を知っていたり知らなかったりするので、背景が違う人とフラットな議論をするのがけっこう難しい。

1. webサービスオープン文化/フリーミアム大大大正義思想の終わり。品質の高いWebサービスは課金して使うのが当たり前になった。APIを無料全公開する思想が変化した。

2. webサービスの品質や要求される内容の変化、あるいはwebとその他ソフトウェア業界の境界の希薄化。要求される水準が高くなった。設計も昔より複雑になった。

3. 仮想化がただのマシンのラップではなく、上に乗るソフトウェアアーキテクチャや広い意味でのワークフローや設計などを大きく変化させるようになった。

ここから転じて、細かい開発の流儀ややるべきことの変化がいろいろと起きた。

以下私見まとめ。

REST vs RPC

昔)

RPCというのはxmlレガシー遺産の産業廃棄物であって、Web標準/オープンソース文化/西海岸のノリを理解せぬエンプラ界隈のたわごと。真にモダンかつ思想的に正しいのは RESTである。RESTがわからないプロジェクトはレガシーである! REST! REST! Rails! Rails! Web最高〜

今)

Web API はどんどん複雑化。RESTを提供すればはい、ユビキタスコンピューチング!! という時代は来たのか来なかったのかよくわからないうちに過ぎ去っていった。

RESTを全世界公開しているような企業は漏れなくクライアントライブラリ配布を開始。この時点で「HTTPクライアントだけあれば誰でもどこからでも簡単につかえる」のコンセプトが破綻していたが、けっきょくライブラリやスキーマを共有するのであれば、もはやそれってRPC的発想なのであって、ハイレベルなAPI仕様をHTTPの動詞4種類+リソースという貧弱な表現に後退させることはナンセンスである。そのことに早々に気がついた大Tech企業は、内部的なAPI通信についてはRESTを投げ捨てモダンRPCソリューションを発明していく。人間に読み書きできたもんじゃないし貧弱だった swagger.json よりも強力な新世代RPCツールが勃興。オープンにする必要のないAPI通信みたいなものは RESTのスイートスポットではなくなった。あるいはRESTのスイートスポットは縮小した。

IDLなど 人間にとって書きやすく、表現力も json scemaより遥かに高いスキーマ定義ソリューションの誕生

もっとも有名なのは gRPC

Webブラウザを第一級クライアントとして扱いつつツールセットも豊富な GraphQL の普及。

RPC的な文脈でのGraphQLがようやっと言及されるようになってきたようです

プログラミング言語を完全統一した上で型宣言をスキーマとする ソリューションの勃興

デプロイ環境が動的に増減させやすくなった

昔)

デプロイ環境は静的に固定数だけ存在 。人間に依頼して建ててもらう。

「devその2環境の構築おねがいしあす!」「はい。一ヶ月後にお渡ししますね」

今)

コンテナオーケストレーションとか抽象化するのが当たり前になった。IaCも当たり前すぎるほど当たり前になった。デプロイ先の環境のセットはプログラマブルにつくったり消したりできるようになった。

Vercel などモダンなSaaSはブランチやコミットごとに環境つくったり無限個扱える仕組みを提供。

自分が昔いた会社のとあるプロジェクトでは、UIでボタン一発で新しいdev環境を無限に増やすことができ、ボタン一発で消せる。みたいな仕組みがあった。

k8sみたいなやつは、ポータビリティが非常に高い上に、物理的なクラスタ一個の上に名前空間を分けていくつもの環境を同居することができる。

ぽちってやれば勝手に動的に増える

アプリケーションサーバの並行処理パラダイムの変化

昔)

昔はWebサービスっていうのは、技術的にはべつにやってることはみんな一緒。なのでフレームワークの関心事は、いかに決まりきった処理を直感的に書くか、といったところにあった。

というわけでWebサーバを書く用途ではスクリプト言語がとても人気があった。

GIL (GVL) 制約つきスクリプト言語 の プロセスprefork は今では考えられないほど同時接続数がすくなかった。

→ 502 bad gateway という文字と動物のキャラのイラストが載ったページがでまくる時代。むしろそれが出てこそ人気サイトの証。

→ 回線が遅いモバイルとかでアクセスすると 後ろのスクリプト言語のプロセスがその間ブロックされ、全体のスループットが激落ちする=スロークライアント問題。

→ nginx でhttpボディをバッファリングは常識やでっ

WebSocket とか SSE とかそういうの乗せようとするとスループット激落ちくんなので そこだけ別の言語で戦っていくスタイル

今)

C10K問題とか言われてるときに劇的に登場したnode.js、Go はいわずもがな。async/awaitを持つ C# 、Rust とかはもちろん、 旧世代jvm ですらスレッドはブロックされるもののデフォワーカスレッド300本くらいはあったりする。(jvmはkotlin coroutine や virtual threadを搭載しはじめている。)

スロークライアント問題の対策としてのリバプロはべつにいらない

appサーバから静的ファイルとか配信することもほぼない

appサーバを書いてる言語で書かれたリバプロを使うとかもべつにふつうのことやん

むしろ余計に増えがちなhttp終端する経路を減らすことのほうが課題かもしれませんよ

といった状況になった。

Web Socketとかそういうのやる場合も 、I/Oでスレッドをブロックしないランタイムを使っていればべつにぜんぶ同じ言語でよかったりする。

HTTP/1 なリクエスト/リプライだけですべてが完結しない領域が増えた

todo

WebサイトとネイティブアプリのUIが似たようなもんになった

昔)

フルスタックウェッブフレームワークにHTMLレンダリング機能ついてます。jsはついでのアセットです。ネイティブアプリのことは知りません。APIを提供するので勝手になんとかしてくださいますでしょうか。引き続き宜しくお願い致します。

今)

HTMLについでにjsがあるんじゃなくて、むしろjsがHTMLをレンダリングすることで本物のGUIと全く同じパラダイムでプログラミングをするようになった。

jsフレームワークに乗ることでむしろ体感速度も最適化できる可能性がある。

部分的ハイドレーション、アセットの分割など

バックエンドサーバはAPIを提供するだけ。あとはBFFがやったりクライアントサイドでレンダリングしたりする。

あるいは、C# の Blazor など、サーバサイドの言語を wasm にしてブラウザにリアルタイムで投げつけることによってクライアントサイドプログラミングもカバーする。といったやつがある。ここまでやってやっとフルスタックフレームワークなんちゃいますか的な

マルチプラットフォームGUIつくるツールの状況も一変した

webサービスのスケーラビリティのコモディティ化

昔)

webサービスとはスモールスタートするもの。個人がフルスタックフレームワークで3日でつくったものをサービスインすることで一攫千金やで!

ユーザが増えると 動物のキャラと 500 エラー画面がでることは常識なので、出てから考える。サバ落ちしている間の運営のがんばってる感を察してユーザ同士でうなずき合う一体感。これだよこれ。

スケーラビリティの問題は誰も問いたことのない新しい問題だし、負荷がかかったら落ちるのなんて当たり前だよ。

今)

まーふつうにどう考えても自社で実装することが不可能なエレガントかつスケーラビリティが超たかいいろいろな道具をちょっと課金するだけで超簡単に使えてしまう

Webサービスをスケールさせたり可用性を高めるノウハウは昔よりだいぶ共有されてる。

信じられないほど気まずい障害、くそみたいな運用を経なくても最初から割といいかんじに設計しようとおもえばできる。

モニタリングの焦点の変化

昔)

サーバの「CPU使用率」「メモリ使用率」とかのシステムメトリクスをとる = 監視

今)

いちコンテナあたりのCPU使用率とかまーそこまで興味ない。べつにオンプレじゃないし。

それよりもアプリケーションレイヤの中身を丸裸にする いんすとるめんてーしょん 、各種 Telemetryデータの結合、構造化ログの質などが 100倍くらいは大事。

けっこう前から NewRelic APM とか Prometheus とかあったけど、Datadogや後発のプラットフォームが ダッシュボードを統合してその辺の機能を一気通貫で関連づけるようになり、なんかそういうのが当たり前になった。

モニタリングとか監視とかじゃやんくて TelemetryとかObservavlityと言うのがかっこいいらしい。

push型 vs pull型

昔)

無料で無限に使えるオープンなAPI をくっつけるみたいな思想が濃かった時代は、サービスとサービスをつなげる=「リクエスト/リプライ型のHTTP通信」であり、それがかっこいいと考えられていた。オープンなweb api と オープンなweb api を素朴につなげてなんかつくるみたいなことが今よりも試みられていた。そういうテーマの本とかも売られていた。

可用性やメッセージの永続化とかの発想はエンプラや信頼性が要求される領域以外ではべつにやんなくていいくらいに考えられていた。

壊れても気にしない。むしろ障害=ドラマ

今)

GCP の Cloud pub/sub とか Azure の ServiceBus とか、 N:N かつpull型な非同期メッセージングが簡単につかえるようになったし、まーサーバいっぱい分けるならそういうのするのが当たり前な認識にはなった。

AWS はがんばれ

webサービス = 掲示板 時代の終わり

昔)

webサービスっていうのは掲示板のことです。DB負荷はreadが支配的なんですよね。しってた?

今)

webサービスとそれ以外のソフトウェアの境界がなくなるにつれ、様々なワークロードのサービスが増えた。readonly だけスケールさせるが唯一の方法論かというそれがベストではないものも増えた。

ゲームとか

ギョームアプリとか

これによるさまざまな手法の発見、道具の発明、それらのオープンソース化

複数台DBのルーティング

プライマリDB をレプリケーションさせて リードオンリーレプリカをつくり、アプリケーションがどこに接続するかルーティングする、みたいのが昔も今もオードドックスなかんじではあるっぽいが、

アプリケーションからみてひとつの接続が 裏側では複数のノードにルーティングされるみたいなソリューションがでてきていてそっちのがエレガント。将来的にはだいたいそういう方向になるだろう

個人開発者ロックスター vs ワーキンググループ

MS、Google、Meta, AWS, etc などのでっかい組織がつくってる道具を我々もつかう、みたいな領域が多くなった。CNCF とかそういうワーキンググループみたいなやつとかが目立つようになった。

でかい組織がやってることがむしろモダンで出来がよい。ことが多い。 java vs rails みたいな位置づけからすると時代が変わった感がある。

インフラに興味ある人はCNCFを追ってればけっこういろいろ動向がわかっちゃうらしい

ライブラリやツールの開発元と利害関係の結びつきがかなり昔より強くなっている

フロントエンド分離 → CDNエッジ分散サンドボックスコンピューティング → …

todo:

モノレポ vs メニーレポ

昔)

APIのつなぎめというのは全世界に公開するこが大正義であり、 サードパーティにAPIを広くオープンに公開するのがWebであり、自社クライアントアプリはたまたまファーストパーティなだけである。

だからそうつまり、リポジトも分離されているべきべきべきである。

モノレポは Google(?) とかいう海の向こうの企業がやっている悪魔的所業である。くわばらくわばら。

今)

本質的に 自社のサバ/クラ は密結合しており、リリースサイクルも一致させたりする必要があり、それを分けて扱うつらさに反比例する分ける意義のなさ。商売にならないのにAPIをオープンなものとして扱うことに対してのでっかい疑問符。

OSS でもリポジトリは一個でなかにパッケージがぜんぶぶちこんであってリリースサイクルやビルドが一本化されているものが増えた。

プロダクト/サービス開発もモノレポが増えた。ていうかどっちかっていうとモノレポでいいっす。

設計とかアーキテクチャの話とみせかけてポジショントーク

昔)

純粋なハッカー精神、おもしろいから開発してるって人が公開してるものがOSSであり、それがWebの楽しいとこだよねー

ぎーくの間で「流行ってるやつ」=イケてて問答無用で素晴しい。だからSNSでの流行に敏感になろう。

今)

マイクロサービスをさも当たり前のことかのように推しまくってくるのは DDDコンサルか クラウドプラットフォームプロバイダーで、SaaSみたいな業者はまたなんか違う構成を推してくるのはどうしてなんでしょうね。私にはわかりません。