SaaSのモジュラー性の無さ
ハードウェアもソフトウェアも複雑だけど部品として流通可能
「電源モジュール」みたいなものは部品として流通する
多くのライブラリ・OS・コンパイラ
SaaSと呼ばれている物は、非常にしょうもないコードでも人間込みのサービスになることが多い
自動車みたいに複雑でミッションクリティカルなら、人間による「メンテナンス」セットになるのは理解できる
ほとんどのSaaSは複雑でもミッションクリティカルでもない
人間込みのサービスはエンジニアリング的には非常によろしくない
代替・コピー不可能
伝染性
人間が混ざった部品と接するシステムには人間が含まれる必要がある
仕様変更が全て人間経由だから
SaaSという形態を持続させる要素について考える
意味があるもの
人間をwrapしている
人間とのインターフェース・社会とのインターフェース自体が本質価値であるケース
これらは人間が必ず必要
少なくともHLAIがいい感じになるまでは
人間そのものと人間にまつわるロジックをAPIでwrapしている
組織とコードが密結合だが、それは外部にとって意味が無い
e.g. どうやって不正決済をオペレーションチームが処理しているか
外部からはbool is_fraudだけ分かればよい
決済サービス
UGCサービス
Mechanical Turk
特殊ハードウェアをwrapしている
殆どの場所に存在しないハードウェアを使うためのインターフェース
それとセットになる特殊コードもセットで隠蔽している
従量課金のハードウェアというのも実は特殊
ChatGPT
量子計算機のインターフェース
複数ユーザーのデータを集積することが価値を生み出す
データを集積することでMLができる
ログを集積することで、体験を改善できる
このへんまでくると、開発コストとユーザー数の規模の経済という側面
もはやソフトウェアとあんまり関係なく、通常のビジネスがノウハウを蓄積するのと同じ
単純な囲い込み
AGPLはこれを妨げようとするライセンス
データを保持したままmigrationするプログラムを書いてくれるサービス
しかし多くのソフトウェアはすでに従量課金のハードウェア (クラウド)の上に構築されているはず
そのとき、上記メリットを全く活用していない物は大量にある
e.g. algolia, bigquery, imgix, ...
こういうのは「別のDCにある物理的メリット」がゼロ
bqはもしかすると特殊なネットワークハードウェアを必要とするかもしれないが…
それと同じソフトウェアがローカルのクラウドに展開できる方が遥かに都合がよい
すごくニッチならプロプライエタリになるのは通常
だが、誰もが必要とするものは通常OSSになるはずなのに、そうならない
なぜかインターネット経由のSaaSになってしまう
インターネットは遅いし高いし何の保証もない
全部のSaaSが同じデータセンターにあることが保証されてない
k8sの上にモジュラーに構築することを考える / 物理的構造
そもそもOSSとしてパッケージ化可能なのか?
どういうものだろう?
実際の負荷がかからないと設計できない問題
そもそもAPIがおかしい (不完全)問題
いわゆるオペレーション的な部分がAPIになってなくて、所詮、設定ファイル
生命的システムが設計できてない
とりあえず作って都度対応みたいなモデルを脱せてない
制御できない生命的システムにインターフェースするために別の生命 (人間の組織)をあてている
リソース抽象化の不完全性
リソースの種類が少なければ少ないほど自由にプログラムを書ける
古代、ソフトウェアは無限のリソースを使えるつもりで書けた
富豪的プログラミング
つまり0種類のリソースしか気にしなくていいということ
single-machineで動作する多くのプログラム
特に何も気にせずに掛ける
気にする順序: 応答時間 >> ディスク・メモリ
応答時間はまぁまぁ気になる
容量が律速で、工夫しないと書けない!というものはめったにない
時間もまてば動くので必須ではない
GUIはほどほどに時間を気にしないといけない
ゲームは時間を気にしないといけない
これがCUIの強さでもあり、今のOSが提供している価値でもある
メタ視点では、二つのリソースだけを考えてプログラミングすればよかった
(CPU=時間)効率性
扱える複雑性
リソース種類が多いと、複雑性を下げるための抽象化ではなく、制約をかいくぐるパズルみたいになってくる
パレート最適解を見つける問題
現状のソフトウェアのコードはこの探索に極めて不向き
解空間の特定の一点しか記述できないから
実際には解集合を記述し、それを最適に向かって動かすようなことが本質的
今のプログラミング言語でもこういう記述方法はできるだろう
文化的発明はいくつか必要かもしれないが
が、リソース種類が多いと組み合わせ爆発する
テスト不可能になる
なので、「実際に動かしてみないと分からない」現象が発生する
そうしないと、一生実行されないコードパスをちゃんと維持し続ける必要が出てくるから
特性が似ているコンポーネントごとにサービスとして分離し、あとはSREががんばるというモデル
組織による技術的問題の解決
リソースは何種類あるのだろう?
もしかするとAIが複雑性を吸収してくれるかもしれない
時間
計算
ネットワーク
lambda soup
--
(完成した)ソフトウェアでは無く、「一緒に作っていきましょう」という合意を薄くして売っている
体験が変化しているとき、いつか・誰かがデータの移行をする必要がある
それを分散する?
--
生命的システムを構築する能力が人類には欠けている
一方で、生命も伝染性である
資本主義というエコシステムの個体である法人-SaaSで収まってることは準安定なのかもしれない
生命的システムが一旦あふれると、機械的システムは生き残れない
なぜなら生命のほうが強いから (勝手に生存する可能性が高いから)
--> 「ソフトウェア工学」は生命を相手にするウェットな感じになる
一方で、世の中がコンピュータウイルスまみれになってないのは不思議
たぶん、「自由な計算機」が存在しないから
誰かが所有している
所有者の責任がある
所有者は維持コストを払っている
都市に大型動物がいないのと同じ
無視できるほど小さい動物は存在している
謎のファイルとかはそう
一方で、生命もスケールを変えてみると機械的に扱える
醸造プラントは化学プラントのように扱える
生命がどれだけがんばろうと、物理法則の限界を超えることはできない
突然質量が増えたり減ったりしない