Spring Framework は、当時主流だった EJB があまりにも複雑だったため、「もっとシンプルに Java でアプリケーションを作れるようにしよう」という思想から生まれたアプリケーションフレームワークです。その後、Spring Framework をさらに便利に、そして設定なしで使えるようにするためのレイヤーとして Spring Boot が登場しました。
私も最初は誤解していましたが、Spring Boot は Spring Framework の後継ではありません。Spring Framework の上に乗り、その機能を簡単に使えるようにするための仕組みです。
主要な比較改善ポイント
CoCとは「Convention over Configuration」の略で、日本語だと「設定より規約」です。考え方はシンプルで、「普通はこうするよね」という決まりごとに従えば、設定を書かなくていいという思想らしいです。
今もSpringを選ぶ意味はあるか
新規開発で「Spring Framework 単体（＝Boot なし）」を選ぶ意味は、基本的にはほとんどありません。理由は、Spring Boot が Spring Framework の上に構築されていて、Spring の機能をそのまま使いつつ、設定や起動まわりを大幅に簡略化してくれるからです。
ただし現場では以下のような理由でSpring Boot化ができないところもあります。
- 超レガシーな既存プロジェクトでSpringのみを使っているなら、あえてSpring Bootに移行するコストがかかる
- 非常に特殊なサーバー環境（古いJava EEコンテナへのデプロイが必須など）で組み込みサーバーが邪魔になる場合（Javaのバージョン的に対応できない）
実務の新規開発では、Spring Bootを選ばない理由はほぼないというのが現在のコンセンサスだとおもいます。
「組み込みサーバー型 vs 共有サーバー型」アーキテクチャ対比
「1つのサーバーに複数アプリを同居させる」という昔からの運用スタイルに対し、最近（とはいっても随分久しいと思う）のコンテナ時代ではTomcatも含めて１アプリとなります。こうする事でOSからみると１アプリ1プロセスとなり、メモリやCPUの割り当てが柔軟になります。それに対し、複数のアプリが1プロセスで動作する従来の方法では、アプリAがメモリを食いつぶして他のアプリに影響を与えたり、致命的なエラーを出した場合アプリが全滅というような危険もありました。
