CraftConf 2015でMitchell Hashimoto氏は，現状のプロビジョニングおよびコンフィギュレーションツールについて，'現在のデータセンタ' を管理するには適していないものだと評した。現在のデータセンタはアジャイルかつエラスティックだ。そして計算リソースやDNS，CDNなど，アプリケーションのデプロイに必要な‘サービス’は，さまざまなベンダの提供する異種プラットフォームに渡って拡がる可能性がある。このような課題を抱えた環境でオートメーションを提供する方法として氏は，HashicorpのTerraformとConsulという２つのツールを紹介した。
Hashicorpの創業者であり，VagrantとPackerのプロジェクトリーダでもあるHashimoto氏の講演は，データセンタ技術の歴史を概説するところから始まった。企業の観点から見たデータセンタの利用は，単一の物理的サーバから発展して，複数のベアメタルサーバへと移り，最終的に複数の仮想化インスタンスへと到達している。この進化の最新トレンドがコンテナ化の動きだ。このような進化に伴ってプロビジョニングやデプロイメント，メンテナンスといった作業は複雑さを増し，自動化のニーズが差し迫った課題となった。初期の要件に対応するために現れたのが，CFEngineやChef，Puppet，Ansibleといったツーリングだ。
パブリックおよびプライベートクラウド技術の普及によって，私たちは今，新たな課題を抱えながら'現代的データセンタ'を運用し続けている，とHashimoto氏は説明した。かつてはコアインフラストラクチャのスタックに統合されていたDNSやCDN，あるいはデータベースといった技術が，現在ではサーバベースの製品に移行しつつある。また企業側でも，複数の異なるベンダを使ってインフラストラクチャプラットフォームを開発することが多くなった。これら２つの変化により，従来のプロビジョニングには，新たに複雑な層が追加されている。この要求に現在のツーリングは応えられていない，というのがHashimoto氏の主張だ。
セットアップしたいアプリケーションのひとつひとつに，ChefやPuppetのオートメーションを用意することも可能でしょう。ですがもし，必要なサービスすべてのセットアップを自動化する方法がなかったとすれば，どのような事になるのでしょうか？つまり，アプリケーションが動かないのです ...
データセンタで行われるアクティビティの中心は，サーバやデータストア，ロードバランサといったリソースの取得(acquisition)，提供(provision)，更新(update)，廃棄(destruction)などの作業で構成されることが多い。かつてこれらのプロセスは遅く，その結果もどちらかといえば静的だったが，現在では，これらのアクティビティは速くなり，アウトプットもエラスティックでスケーラブルなものになっている。この実例は，コンピューティングリソースのプロビジョニングに見ることができる。従来のデータセンタならばサーバを購入して物理的なラックに収め，プロビジョンした後に，固定的なユニットとしてデプロイされていた。しかし現代的なデータセンタでは，コンピューティングインスタンスはAPIコールを通じて獲得され，起動時に構成が指定される。インスタンスをその場で水平スケーリングしたり，あるいは水平スケーリングのためにインスタンスを追加したりするのも簡単だ。
現在のデータセンタ内で提供されるスピードや柔軟性を，人間が活用することは不可能である，とHashimoto氏は論じる - 自動化は必須なのだ。現代的なデータセンタを自動化するための要件として，氏は次のようなものを挙げた。
- ゼロの状態から，１つのコマンドでデプロイが可能
- 分散システムによる耐障害性
- 自動スケーリングと自動ヒーリング
- 体系化された知識によるチームワーク向上
Hashimoto氏は，複数のデータセンタや異なるベンダにわたるインフラストラクチャを効率的に構築，組み合わせ，ローンチするという要件に対応可能なツールとして，HashicorpのTerraformを紹介した。例えば，Amazon Web Service(AWS)のEC2コンピューティングインスタンスとDigitalOceanのDropletコンピューティングインスタンスをローンチし，Dyn DNSサービスを通じてそれらへのアクセスを設定するという作業が，Terraformでは可能だ。さらにTerraformは，ヒューマンフレンドリなテキスト形式で，インフラストラクチャの宣言的定義を行うことができる。特定の低レベルな設定操作を行うTerraformモジュールを生成することも可能だ。
Terraformは，‘terraform apply’というコマンドひとつで起動する。‘terraform plan’コマンドで，applyが行うアクティビティをプレビューすることも可能だ。planコマンドを実行すると，現在のインフラストラクチャの状態から要求された宣言的定義に向けて実行される変更の内容が，順序付きリストとして出力される。変更がその場で実行可能なものか，破壊的な性質のものか(サーバの再起動のように)についても，その中で示されている。あるオペレーションの実行が特定の状況，例えばメンテナンスウィンドウの表示中に適切であるかを決定する上で，この情報が役に立つ。
planコマンドの出力をファイルに保存して，後日，インフラストラクチャの変更を決定論的に実行することも可能だ。インフラストラクチャの変更をプレビューできることはTerraformの最も重要な機能のひとつだ，とHashimoto氏は述べている。インフラストラクチャコードの変更と，その結果としてのプロビジョニング計画の組み合わせは，現在の開発ワークフローの中でもプルリクエストの生成や差分の見直し，変更の受け入れなどに使用することができる。
Terraform以前の運用チームには，実運用システムのスタック管理に関して，信じられない程の責任が負わされていたはずだ，とHashimoto氏は言う。現行の複数のクラウドプラットフォームを深く理解した上で，インフラストラクチャ状態を判断し，状態遷移の結果を計算しなければならなかったのだ。かつて多くの開発者がアセンブリ言語から第３世代プログラム言語に移行したように，運用担当者やDevOps技術者の中には，'スタックを上方向に移動'して，Terraformのようなツールを活用して目標を達成したいと望んでいるかも知れない，とHashimoto氏は言う。
コアオペレータとアプリケーションオペレータの違いはここにある，と私は思っています。どのような企業にも，高可用性のデータベースクラスタを構築する方法を理解しているオペレータと，理解してはいないが，高可用性のデータベースクラスタを望んでいるオペレータがいるのです。彼らを教育して理解させることもできますし，[Terraformのように]抽象化した上で提供することも可能です。
プレゼンテーションの第2部では，HashicorpのConsulツールが紹介された。サービスディスカバリと構成，オーケストレーションといった機能を，データセンタ全体にわたって，可用性の高い方法で提供するツールである。企業のインフラストラクチャ内の，‘サービスXはどこにあるのか’，‘サービスYの状態はどうなのか’，‘現在実行中なのは何か’，‘サービズZの構成はどうなっているのか’，あるいは，‘私のプラットフォームでオペレーションAを実行しているのは，他に誰がいるのか’といった疑問にConsulを使って答えることができる，とHashimoto氏は述べている。
ConsulはDNSあるいはHTTP APIを通じて，データセンタを越えた内外のサービスの検出が可能なサービスディスカバリ機能を提供する。シェルスクリプトとして実装されたヘルスチェック機能には，独自のサービス検証プロトコルを実装することができる。さらには高可用性のキーバリュー型のデータストアも提供され，一貫性を備えた情報を公開する能力を備えている。これを利用すれば，構成管理ツールを実行する必要なく，構成パラメータの'チューニング'を行うことが可能だ。チューニング可能な例としては，サービスのロケーション指定やシステムが保守モードであることの提示，サービスのQoSパラメータ設定などがある。
Cosulの他の機能としてHashimoto氏は，オーケストレーションに関する機能の提供に加えて，UDPを通じてデータセンタ全体に非同期ブロードキャストを行う‘event’，TCPを使って特定のマシンで同期的な処理を実行する‘exec’，およびeventとexecの長期的なポーリング処理の実装である‘watch’に言及した。
Mitchell Hashimoto氏のCraftConfでの講演 ‘Automating the Modern Datacenter, Development to Production’ に関するビデオ録画など，より詳細な資料については，カンファレンスのWebサイトで入手可能だ。Terraform v0.5はTerraform.io Webサイトで，Consul v5.0はConsul.io Webサイトで，それぞれダウンロードすることができる。