NetOpsにはアジリティが必要 - クラウドは一夜にして変わり得るから

NetOps（ネットワーク担当者）がパブリッククラウド内で増え続けるアプリケーションをサポートするには、DevOpsの手法と原則を取り入れることによって安定性とスピードの間のバランスを取り戻す必要があります。

ネットワーク担当者の中には、DevOpsの手法を取り入れることはスピードのため安定性とセキュリティを犠牲にすることだという考えが存在します。

多くの場合、これは真実です。Arxan社とIBM社が行った、IoTとモバイルアプリケーションのセキュリティに関する調査があります。この調査では、脆弱性を持つコードが含まれるアプリケーションがリリースされる原因は「リリースを急ぐこと」であると回答者の過半数が答えています。スピードはセキュリティを、また安定性も犠牲にしてしまいます。

安定性に関しては定量化できるデータはそれほどないものの、事例に基づく証拠が多数存在します。最も注目すべきなのは、「クラウド」が一夜にして変わった場合のクラウドパートナーによる大騒ぎです。

そのような変更が行われるとは誰も聞いていませんでした。しかし誰かが何かが壊れていることに気づきました。調査から判明した原因は、必ずといっていいほど、基盤となるインフラストラクチャに変更が加えられていることです。プロバイダにとって有益であり、顧客にとっても有益かもしれない変更が、そのインフラストラクチャに依存する数々のソリューションを破壊することがあります。

パブリッククラウドはコントロールできない。

「クラウドのルール」を決めるとすれば、ルールその1にさらに先立ち、ルールそのゼロとしてこれを定めなければなりません。これはあなたが健全に、そしてクラウド導入をどのように進めるかにおいて決定的に重要な項目だからです。

クラウドインフラストラクチャはあなたの持ち物ではありません。あなたはクラウドインフラストラクチャをコントロールせず、変更も加えられませんが、プロバイダにはそれが可能です（そしてそれらを実際に行います）。企業データセンターのインフラストラクチャと同じように考えてクラウドを導入すれば、あなたは惨めな思いをすることになります。

あなたにできることは、この変化に対応することだけです。またタイミングを逃すことなく対応するには、DevOpsが使う「インフラストラクチャ・アズ・コード」の手法が役に立つ可能性があります。この「インフラストラクチャ・アズ・コード」とは一種の比喩で、インフラストラクチャを展開、調達、および管理する、コンフィグレーション、テンプレート、およびスクリプトをあたかもコードのように扱うことを意味します。

これには宣言型モデルによる展開を導入することが鍵となります。つまり、インフラストラクチャがどのように動作すべきかではなく、インフラストラクチャに何を行って欲しいと思うかを記述する際、可能なかぎりテンプレートを使用することを意味します。

宣言型モデルを使用することにより、予想しなかった（ただし驚きはしなかった）変化がクラウドインフラストラクチャに生じた場合のアジリティ（対応速度）が改善します。ソリューションが動作しなくなるのは回避できません。しかし共有されているテンプレートを修正するだけですむため、変化への対応をより迅速に行うことができます。

コード自体を修正する必要はなく、またあちこちを点検して既存のコンフィグレーションを変更する（あるいはさらに恐ろしい方法としてパッチを当てる）必要もありません。テンプレートの修正、テスト、および展開し直しは、コードやインストーラーや、あるいはPDF書類になっている「インストール手順書」を修正するよりもはるかに迅速に行えます。

クラウドにはいずれ変更が加えられ、あなたはそれに対応せざるを得ません。自分ではコントロールできない変化に迅速に対応するため、あなたは素早く行動し、またその原則に従わなければなりません。

パブリッククラウドのインフラストラクチャにおいて、スピードを犠牲にすることなくアプリケーションの安定性を回復するには、アジャイルなアプローチと宣言型モデルの組み合わせが最善の手段です。