サブドメイン＆サブディレクトリでの運用を考える
前提条件
asp.net core＆Containerでのアプリケーションホストを行うケースである。
cloud runでの利用を考える
お昼のお仕事ではGCPを現在利用しているので、hostする環境はGCP、LBはGLBという構成である。
cloud run＆asp.net coreの組み合わせでサブディレクトリを利用する場合、pathbaseの設定が必要になる。
githubのapiのようにURLとは別にVersion情報はheaderで伝送し、内部で着信先を制御するみたいなことは、自分のチームでは運用が耐えられないので今回は考慮しない。
Applicationの配置を考える
example.com/hoge/*** example.com/cooperation/hoge/***
とした場合に、まず小さい機能を作ろうとした場合でも、2Applicationが必要になる（example.comというクソデカ主語のApplication内にhogeもcooperation/hogeを作るのであれば大丈夫だが……関心事が大きすぎて現実性に欠けるように思う。）
hoge.example.com/*** hoge.example.com/cooperation/***
とした場合、小さく新機能を作りたい場合、まず hoge.example.com への機能追加で完結できるため、初期のカロリー消費が抑えられるように思える。
運用を進めていくうえで、新機能が爆発するのであれば、改めて別Applicationを作成した上でスケールさせるといった戦術が可能になる。
サブドメインを選択するケース
判断ポイントとしては、
小さな機能追加がある程度頻繁に行われる可能性があるドメインの中でもある程度ベクトルが独立した機能が育つ可能性がある
が挙げられるように思える。
アプリケーションの立ち上げのコストはFaaSを使うことで緩和可能だが、GCPの場合でいえばCloudFunctionsのv2でも.NET6までしか利用が出来ないため、面倒なことになりがち。（v1の時代はなんとずっと3.1のままであった。）
ベクトルの独立した機能が業務Domain内に育っていく場合、URLのバリエーションが多岐に渡ることが多いため、FQDNの時点で分離したほうが、後続のURLに混乱が少ないように思う。
一方でWebFrontのApplicationの場合は、大概の場合、SEOのパワーの話が絡んでくるため、productのマネタイズの戦略に左右されるとは思う。
