Vagrantを開発したMitchell Hashimoto氏が先月のVelocity Conf Londonで，“FutureOps” に対する自身のビジョンをテーマに，不変(Immutable)インフラストラクチャとビルトイン障害回復(Built-in Failure Recovery)の話題を交えながら講演を行った。
氏が披露したビジョンには，(コンフィギュレーション管理ツールによる)環境の再現性，(事前に構築された静的イメージを使用した)極限的な高速展開，(分散型オーケストレーションツールによる)サービスオーケストレーションなどの話題が包含されている。このシナリオでは，新しいサーバの追加と障害の発生したサーバの置き換えとの間で，動作上の違いは何もない。
氏のビジョンが基本とするのは，スタートアップ時に行われたマシン設定を一切変更しないという，不変インフラストラクチャの発想だ。起動以降の環境変更はすべて，古くなった不変マシンに代えて新たなマシンを配置することで対応することになる(複雑なデータベースサーバの更新や，CSS修正のような些細なアプリ修正は別として)。今日のシステムの無数とも言える外部依存の存在を理由に，このアイデアを夢物語だとする意見も一部にはある。
このような問題に氏が注目するようになったのは，PuppetやChefといった最近の構成管理ツールによる部分が大きい。これらのツールでは，対象とするサーバが同じでも，パッケージやネットワーク可用性，あるいは (ChefのクックブックやPuppetのマニフェストといった) 環境定義の変更に対する依存性のために，同一の結果を保証することが難しい。予測可能性の鍵は，ソースコードからコンパイルされたソフトウェアバイナリと同じように，あらかじめビルドとテストを済ませたマシンイメージ(バイナリ)を使用することにある，と氏は言う。
氏によると，マシンイメージの利用はこれまで，そのメンテナンスの難しさから，あまりよい評価を得られていなかった。しかし現在の構成管理ツールを使えば，継続的インテグレーション方式でイメージを更新していく上で困難な部分は何もない。Packerのような新しいツールでは，単一のテンプレートと環境定義のセットから複数のハイパーバイザ(VirtualBoxやVMWareなど)に対応するイメージを構築することによって，作業はさらに簡素化されている。
しかしながら，サービスの検索やオーケストレーションタスク(ロードバランスの設定のような)に関しては，イメージの展開後に(配信プロセスそのものとは別に)必要な作業がまだ残っている。この分野のために氏が開発したもうひとつのツールがSerfだ。 氏によれば，Serfは疎結合されたエージェントとゴシップ方式(Gossip-based)のメンバーシップ(新しいエージェントはシステムに参加するために，既存の１ノードにコンタクトしなければならない)によって，障害検出と回復をサポートするように設計されている。同様にエージェントが，障害が発生したノードを検出して，そのニュースを他のノードへ “ゴシップ” する場合もある。それによってノード交換の必要が判断されるのだ。
この方式の大きなメリットとして氏が挙げるのは，オーケストレーションの早さ，マシンイメージ生成時における構成管理プロセスの単純さ(Serfエージェントサービスだけを設定すれば，Serfがマシン起動時に自動的に立ち上がる)などの点だ。
氏はQ&Aの間，Docker(アプリケーションコンテナ)やPacker(共通インフラストラクチャ)とSerf(サービスオーケストレーション)を同居させた場合でも問題がないことにも言及した。