FewbytesのCTOで，テルアビブDevOps Daysの主催者のひとりでもあるAvishai Ish-Shalom氏は，一貫性を欠いた構成定義とアップデートによって今日のシステム管理が被っている困難を指摘した上で，その問題を解決する手段として，５つの設計原則を提案している。
問題となるのは，複数のフォーマットを用いることで必要となる過大なスキルセット，検証とフィードバックの欠如，特に自動生成の困難な特殊なフォーマットなどだ。Ish-Shalom氏は，昨今の構成管理(CM)ツールが普及し，システムの自動化や標準化が損なわれたことによって，これらの問題が顕在化した，と指摘する。
問題の一例としてIsh-Shalom氏は，Linuxで一般的なconf.dパターンを挙げている。この方法では，構成管理ツールによって，マシンに一定の構成が自動的に適用される一方で，手作業によるファイルの追加(あるいは単に順序の変更のみ)で最終的な構成を変更することも可能だ。CMツールには，このような逸脱を検出するために必要な粒度やコンテキストが欠如している。
加えてIsh-Shalom氏は，ファイルの削除を行った場合でも，システム構成が実際に更新される保証のない点を指摘する。システム構成の適用方法の非統一性(リロードと再起動のように)のため，些細な構成変更でさえ，自動的に矛盾なく適用することの保証が困難になっているのだ。たとえ不変(Immutable)インフラストラクチャであっても，あらゆるケースのソリューションとは成り得ない，とIsh-Shalom氏はInfoQに語っている。
不変インフラと使い捨て(Disposable)インスタンスを使った構成にも大きな問題があります。ある面ではかえって深刻です。構成は，アプリケーションにおける"状態"のようなものです。コードと同じようにVCS内で変更を管理して，ビルド時に統合し，CDパイプラインでテストして，不変インフラにデプロイ可能な場合もあるでしょう(そうならば素晴らしいですし，可能であればぜひそうすべきです)。ですが，ほとんどの場合はそうは行きません。データベースのロケーションのような環境構成を考えてみてください。これは運用環境のみに存在する動的な値で，障害の発生によって変更される可能性があります。あるいは，機能フラグのようなものを考えてください。特定の機能を有効にした別のデプロイセットを不要にするために，フラグをいつでもオンあるいはオフすることが可能なものです。そして最後に，不変インフラと使い捨てのコンポーネントの方向に進んでいる組織もありますが，大部分は相変わらず従来のインフラを使用しています - しかも事実として，今この時点でも，不変インフラよりも従来のインフラの構築を続けている企業の方が多いのです。
氏の提案する５つの設計原則の基本には，中心となる２つのアイデアがある。RESTベースの構成APIの作成と，必要とするシステムの更新タイプによる構成ファイルの分離だ。
APIは，標準的なGETとPOSTメソッドを通じて，システム構成の読み書きをサポートする必要がある。これにより，GETによる現行のシステム構成とCMツール内にある定義のクロスチェック，POSTによる新しい構成の適用が可能になる。これら２つの原則が，システム構成の更新に関する全責任をCMツールに与えるという第３の原則をサポートすることで，conf.dパターンを回避できるのだ。
システムの更新タイプによる構成ファイルの分離(第４の原則)を併用することで，CMツールは，例えば，同じ更新タイプの必要な複数の構成(ファイル)を統合して，POSTを通じてその変更を構成APIに適用した後，READを使って適用が成功したことと，その後の変更が行われていないことをチェックできる。
最後に，CMツールによる自動生成を可能にするため，理想的な構成フォーマットを標準化して，シリアライズ可能(JSONやYAMLのように)することが必要だ。それが不可能ならば，コンフィギュレーションをひとつのプラグインとして取り扱い，その変数を抽出して外部構成とする方法が次善の策になる。
このような構成APIが潜在的な脆弱性になる恐れはないのだろうか，InfoQはIsh-Shalom氏に質問した。
構成APIも，他のコントロールAPIと違いはありません。暗号化して(SSLクライアント証明書のような)高レベルの認証を求めたり，信頼できるネットワークだけを対象に別ポートで公開したり，あるいはもっと単純に，他のAPIで使っているのと同じ認証方法を使用することも可能です。パブリッククラウドサービス(PAASとSAAS)がよい例です。どちらもAPIを通じて日常的に構成設定をしていますが，ごく自然で快適ですし，最初からセキュリティも組み込まれています。
Ish-Shalom氏はリュブリャナで開催される次のDevOps Daysで，DevOpsにおける“work”について講演する予定だ。