これまでの商用システムに対するアプリケーションのデプロイメントでは、1つのインフラに対して、アプリケーションの再配備を行うという手順でした。そのため、アプリケーションのメンテナンスのための停止時間を設けたり、冗長化がされている場合は、ワンセットずつアプリケーションのデプロイメントを実施したりしています。

この場合の問題点は、デプロイメントに失敗した場合のアプリケーションのロールバック（切り戻し）が非常に困難なことです。そのため、リハーサルを実施するなど、万全を期してデプロイメントを実施してきました。しかしながら、どれだけ準備をしても、残念ながら環境差分や変更の蓄積による設計書などに記載されない修正などで商用システムへのリリースは失敗することがよくあります。

前述の一般的なアプリケーションのデプロイメントの問題点を解決するデプロイメントが、書籍『継続的デリバリー^参考1』でも解説されているブルーグリーン・デプロイメントです。

ブルーグリーン・デプロイメントでは商用システムを2組用意して、ブルーとグリーンとを、切り替えることで新しいアプリケーションをデプロイメントしていきます。通常、切り替えは上位のルーターやロードバランサ―、DNSなどで実施するので、デプロイメントに失敗した場合、すぐにロールバックができます。

ただし、商用システムを2組用意するため、コストがかかります。最近ではクラウドコンピューティングをうまく使い、必要なときにだけ、もう1組の商用システムを構築できるため、コストを抑えることができるようになりました。

Immutable Infrastructure（Immutable Serverとも呼ばれます）はインフラ管理の新たな手法です。Immutableとは「不変な」という意味です。Immutable Infrastructureでは、その名の通り、一度作成したサーバー（インフラ）は設定変更などを行わず、不変なものとして扱います。デプロイメントのたびに、新しいインフラを構築し、既存のインフラは不要になった後に廃棄します。そのため、クラウドの利用が前提となります。

これにより従来型のデプロイメントで問題となりやすかった環境差分や変更の蓄積による設計書などに記載されない修正がなくなり、毎回クリーンなインフラを扱うことができるメリットがあります。それにより、デプロイメントが失敗する可能性を下げることができます。

このようなインフラ管理ができるようになってきたのもIaaSを中心としたクラウド技術やInfrastructure as Code^参考2などの技術の成熟に伴い、コンピューターリソースを瞬時に非常に低いコストで扱うことができるようになったためです。

クラウドの登場により、ハードウェアの抽象度が上がり、コンピューターリソースをソフトウェアのように気軽に作成したり、削除したりできるようになりました。それに伴い、アプリケーションインフラの管理手法も新しくなってきています。Immutable Infrastructureはその代表例といえるでしょう。