クラウドは一夜にして変化する可能性があるため、NetOps は俊敏性が必要です

NetOps は、パブリック クラウドに導入されるアプリケーションの数の増加に対応するために、安定性と速度のバランスを回復するために DevOps の方法論と原則を採用する必要があります。

こちら側（ネットワーク側）には、DevOps を採用するチームは安定性とセキュリティを犠牲にして速度を得ているという考えがあります。

多くの場合、これはまったく真実です。 IoT とモバイル アプリケーションのセキュリティに関するArxan と IBM のこの貴重な情報を覚えていますか? その結果、回答者の大多数が、脆弱なコードを含むアプリケーションがリリースされる主な理由として「リリースを急ぐこと」を挙げていることがわかりました。 スピードはセキュリティや安定性よりも重要です。

安定性の面では、定量化できるデータは少ないものの、逸話的な証拠は山ほどあります。 最も注目すべきは、「クラウド」が一夜にして変化したときのクラウド パートナーの熱狂的な反応です。

誰にも言われません。 誰かが何かが壊れたことに気づくだけです。 調査してみると、必ず基礎となるインフラストラクチャの変更が原因であることが分かります。 この変更はプロバイダー、そしておそらく顧客にとっても間違いなく有益でしたが、その結果、そのインフラストラクチャに依存する多くのソリューションが壊れてしまいました。

パブリッククラウドを制御することはできません。

おそらく、これをルール 0 として「クラウド ルール」を始める必要があるでしょう。なぜなら、これは皆さんの健全な精神と、クラウドの導入に取り組む方法にとって非常に重要だからです。

クラウド インフラストラクチャはあなたのものではありません。 あなたはそれを制御できず、変更することもできませんが、プロバイダーは確かに制御できます（そして実際に変更しています）。 企業のデータセンター インフラストラクチャと同じ考え方でクラウドに取り組むと、悲惨な結果になるでしょう。

あなたにできるのは、それらの変化に反応することだけです。 タイムリーな対応を可能にする DevOps 方法論の 1 つが、コードとしてのインフラストラクチャです。 覚えておいてください、インフラストラクチャ アズ コードとは、インフラストラクチャをデプロイ、プロビジョニング、管理する構成、テンプレート、スクリプトをコードのように扱うことを意味します。

その鍵となるのは、宣言型のデプロイメント モデルの採用です。つまり、可能な場合はテンプレートを使用して、インフラストラクチャがどのように実行されるかではなく、インフラストラクチャに何を実行させたいかを記述します。

宣言型モデルを使用すると、クラウド インフラストラクチャで予期しない (しかし意外ではない) 変更が発生した場合でも、俊敏性 (反応速度) が向上します。 はい、壊れます。 ただし、修正するには中央の（共有）テンプレートで変更に対処するだけでよいため、より迅速に適応できるようになります。

厳密に言えば、コードを変更する必要はなく、既存の構成を一掃して変更する必要もありません (パッチ適用のような、より恐ろしい作業です)。 コードやインストーラー、または PDF 形式の従来の「インストール ガイド」を変更するよりもはるかに速く、テンプレートを変更、テスト、再展開できます。

クラウドは変化していきます。そして、それに対応する必要があります。 制御できない変更に迅速に対応するために、俊敏性を発揮し、その原則に従う必要があります。

パブリック クラウドのインフラストラクチャの宣言型モデルと組み合わせたアジャイル アプローチは、速度を犠牲にすることなくアプリケーションの安定性を回復するための最良の方法です。