プラットフォーム・ランタイム・フレームワークの選択
発端
グレゴール・ホープ氏の投稿した記事を読んでたらいろいろ思うところがあった。
- Don't get locked up into avoiding lock-in
- ロックインを避けることに縛られないで！
- 自分用に日本語化したやつ。FAQとか読んでも特に禁止されているわけじゃなかったから公開した
プラットフォーム・ランタイム・フレームワークの選択
基本的には、これらを判断できる情報が集まってればよさそう。
なんか投資信託みたいだな･･････
それなりの期間継続して利用する前提のシステムなら、業務あるいは事業の予算計画や売上計画があるはず。
プラットフォーム・ランタイム・フレームワークという技術要素の選択は、それらの計画に正負両方の影響を与える可能性がある、というのを意識する（させる）必要がありますねと。
具体例を踏まえたよもやま
- 対象：社内業務システム（Webシステム）のリプレース
- 利用期間：今の業務が無くなるまで（つまり未定）
- 開発期間：4ヶ月くらい（できるだけ早くして欲しい）
- 環境：AWS（社内標準だから）
- ランタイム：Java11（社内標準だから）
- フレームワーク：指定なし
- 運用：自社のメンバーでやっていくつもり
ノーコードじゃないんかい、とかいろいろ思うところはあるけど、 できるだけ早く とか Java11 に引っ張られて Wagby や Spring Boot を選んでしまいそう。
たぶん、その考えは落とし穴です。辛い話がいろいろ思いついてしまう。
Spring Boot は依存ライブラリ管理とコンポーネント構成を半自動化するフレームワークで、イニシャルコストはすごく下げられる。 しかし、EOLが15ヶ月なので、比較的短期に deprecated になってしまう。
依存ライブラリのセキュリティフィックスを単独で取り入れようとしても、旧バージョンの Spring Boot が対応していないバージョンなら、依存ライブラリ定義とコンポーネント構成を自前でやらないといけない。 そのためには、MavenやGradleに加えて Spring Frameworkの高度な知識が必要になってしまう。
Spring Boot を最新版にすればいいかというと、それもまた悩ましい判断になる。 全ての機能が正しく動作する保証はないから。
それをランニングコストと呼ぶのか、リスクヘッジのコストと呼ぶのかわかりませんが、安く付くはずが無い。
さらに、Java11 が保守されるのは一般的に 2024 年までとされているので、たとえ今の業務が続いているとしても、その次の LTS へ乗り換えないといけない。 もちろんフレームワークも Spring Framework 6.x へ切り替えないといけないわけで。
