Framework Defined Infrastructure

#architecture #infrastructure #framework #platform

フレームワークのコードが必要とするインフラをフレームワーク自身が定義・最適化するアーキテクチャの考え方。アプリケーションコードを書くだけで、最適なインフラ構成が自動的に決まる。

概念

従来の開発では「アプリケーション」と「インフラ」は分離されており、開発者がインフラを別途設定する必要があった。FDIでは：

従来:
  アプリコード → 開発者がインフラを設計 → デプロイ

FDI:
  アプリコード → フレームワークがインフラを決定 → デプロイ

Next.jsにおける例

Vercelの組み合わせがFDIの代表例：

getStaticPropsを使ったページ → 自動的にCDNキャッシュ
getServerSidePropsを使ったページ → サーバーレス関数としてデプロイ
ISRのrevalidate設定 → Vercelのキャッシュ無効化インフラが稼働
Edge Middleware → Vercelのエッジネットワークで実行

開発者はフレームワークのAPIを使うだけで、最適なインフラ構成を意識せずに利用できる。

メリット

インフラ設計の認知負荷が大幅に削減される
フレームワークがパフォーマンス最適化を責任を持って行う
Zero Configurationと組み合わさり、デプロイが非常に簡単になる

デメリット・課題

ベンダーロックイン

フレームワークのデプロイプラットフォームへの依存が生じる。

「Incremental Static Regenerationは極端な例だ。Vercelのプラットフォームが永続化、キャッシュ無効化、再生成トリガーを独自のメカニズムで処理する。同じアプリケーションをNetlify、Cloudflare Pages、AWSにデプロイすると、この機能は完全に失われる」

ポータビリティの喪失

フレームワーク固有のインフラ機能を多用すると、他のプラットフォームへの移行が困難になる。

Infrastructure as Codeとの関係

IaCは「インフラをコードで管理する」のに対し、FDIは「アプリコードがインフラを定義する」という点で逆の発想とも言える：

IaC: インフラエンジニアがインフラを記述 → アプリが乗る
FDI: 開発者がアプリを記述 → フレームワークがインフラを決定

両者は排他的ではなく、組み合わせて使うことも多い。

概念