NetOps に最小限の実行可能な展開はありますか?
ネットワーク自動化は本当にすべてかゼロか？
ネットワーク自動化 (生産パイプラインの DevOps の実践) は、すでにかなりの割合の組織で使用されています。 完全に取り組んでいる企業はごくわずかですが、大多数 (当社の最新のapplication配信状況によると 77%) は自動化を試験的に導入しているか、本番環境で部分的に使用しています。
DevOps と密接に結びついており、NetOps と結び付けられることが多い概念の 1 つに、最小限の実行可能な製品 (MVP) という概念があります。
これはアジャイル手法の一部であり、開発サイクルを高速化し、ソリューションをより早く市場に投入する方法として使用されます。 それは「ネットワーク」に絶対に必要なものです。 以前のブログで言及した Appian の調査を覚えているかもしれません。その調査では、回答者の 72% が、ビジネスのニーズに合わせて IT を拡張できるかどうか自信がないと回答しました。
痛い。 IT 分野では自動化がかなり広範に使用されているにもかかわらず、開発者やビジネス関係者は、IT 部門が自動化を遂行できる能力にまだ自信がありません。
したがって、DevOps のツール、テクノロジー、方法論を採用して（よりスマートにスケーリングすることで）スピードアップすることは、それほどおかしなことではありません。 しかし、MVP をネットワークに適用する方法を理解する前に、MVP とは何かを理解する必要があります。 DevOps、Agile、MVP に馴染みのない方のために、Agile Alliance によるわかりやすい定義を以下に示します。
最小限の実行可能な製品 (MVP) は、新製品開発における学習の影響を強調する Lean Startup の概念です。 Eric Ries 氏は、MVP を、チームが最小限の労力で顧客に関する検証済みの学習を最大限に収集できる新製品のバージョンと定義しました。 この検証された学習は、顧客が実際に製品を購入するかどうかという形で得られます。
MVP の考え方の背後にある重要な前提は、顧客に提供できる実際の製品 (ランディング ページのみの場合もあれば、自動化されているように見えても裏では完全に手動で行われているサービス) を作成し、その製品やサービスに対する顧客の実際の行動を観察することです。 人々に何をするかを尋ねるよりも、製品に関して人々が実際に何をするかを見るほうがはるかに信頼できます。
チームは、実験戦略の中核として MVP を効果的に使用します。 彼らは、顧客にはニーズがあり、チームが取り組んでいる製品はそのニーズを満たすという仮説を立てます。 次に、チームはそれらの顧客に何かを提供し、顧客が実際にその製品を使用してそれらのニーズを満たすかどうかを確認します。 この実験から得られた情報に基づいて、チームは製品の作業を継続、変更、またはキャンセルします。
この論文では、DevOps (および関連するテクノロジと方法論) に関連する多くの概念が、NetOps イニシアチブに適用された場合に必ずしもうまく変換されるとは限らないことに注意しています。 実験は、ネットワークの変更について議論するときに、IT のエンジニア、アーキテクト、または幹部が使用する用語ではありません。
爆発半径がわかるでしょう。 大きくて威厳があります。 ほとんどの組織は、正当な理由により、運用リスクに対する許容度が高くありません。 停止は実際に金銭的な損失を招き、場合によっては雇用にも影響を及ぼします。 ネットワークは実際には実験に適した場所ではありません。
しかし、これは NetOps に最小限の実行可能な展開 (MVD) が存在しないことを意味するものではありません。
NetOps の MVD の定義
現在、運用パイプラインは、スイッチ、ルーター、DNS、マルチクラウド ルーティング (GSLB) などの共有リソースと、ロード バランサー、WAF、applicationアクセス制御などのアプリごとのapplicationサービスの両方で構成されています。
興味深いことに、共有リソースに関連する変化率を見ると、それらはかなりわずかであることがわかります。 つまり、変化率が低いのです。 それは良いことです。なぜなら、彼らは混乱に対しても許容度が低いからです。 アプリごとのリソースに目を向けると、変更率が高くなり、中断に対する許容度も高くなります。
結局のところ、これはアプリごとのアーキテクチャの利点の 1 つであり、何か問題が発生した場合に他のアプリが中断しないようにデータ パスを分離します。
私たちの調査によると、そのデータ パスには、組織がapplicationsの配信とセキュリティ保護に使用している平均16種類のapplicationサービスが存在します。 ネットワーク ファイアウォールや DNS など、その一部は共有リソースです。 他のものはそうではありません、あるいは少なくともそうである必要はありません。 これらは現在、共有プラットフォーム上に展開されているかもしれませんが、正当な理由があれば、独自のデータ パスに設計することもできます。
もちろん、私があなたに与えるのはそれです。
その理由は、そもそもアプリに密接に結合されているapplicationサービスに対してアプリごとのアーキテクチャを採用すれば、applicationの MVD を効果的に開発できるからです。
MVP の定義からわかるように、「製品」(この場合はアプリの展開) は完全に自動化する必要はありません。 最もリスクが高く、許容度の低いリソースは引き続き手動で構成 (および検証) する必要があるという前提で運用すると、依然として優位に立つことができます。 ファイアウォールや DNS などのコア サービスの変更率は非常に低いため、手動の方法が展開のタイムラインに大きな影響を与えることはないと想定できます。 アプリごとのapplicationサービスの大部分を自動化すると、オペレーターやエンジニアが必要に応じて手動で変更を加えるための時間が確保されるため、このことはさらに当てはまります。
コア (共有) サービスとアプリごとのapplicationサービスの比率が約 1 対 3* であると仮定すると、平均的な組織には手動で管理する共有リソースが少なくとも 4 つあり、自動化するアプリごとのリソースが 12 個あることになります。
applicationサービスの広範なリスト (現在、30 の異なるサービスを追跡しています) を見ると、アプリケーションを配信または保護するために必要なもの (DDoS、WAF、スケールのための負荷分散、アプリケーション アクセス) もあれば、拡張機能とも言えるものもあります。 それは、パフォーマンスを向上させるアクセラレーション オプションや生産性を高めるシングル サインオン (SSO) などのapplicationサービスです。
したがって、MVD の実装を検討する場合は、アジャイル アプローチを採用し、初日の配信とセキュリティに重要なapplicationサービスに重点を置く可能性があります。 これは、機能強化を無視するという意味ではなく、まずは重要な機能強化に重点を置き、それらを自動化していくという意味です。 生産性やパフォーマンスを向上させるサービスは手動で管理することもできますが、MVD の場合は利益に影響を与えるサービスに焦点を絞りたいと考えています。
アジャイルネットワークへの MVD アプローチ
MVD を定義して提供するという意図を持って自動化に取り組むということは、より迅速に行動し (よりアジャイルに)、堅牢で持続可能な製品 (導入の自動化) が得られるまで、各スプリント (四半期ではなく週単位で測定) で自動化を繰り返し改善および拡張する機会が得られることを意味します。
自動化に MVD ベースの戦略を採用するには、アーキテクチャだけでなく、applicationsに重点を置いたアプローチと姿勢への取り組みも必要です。 この種のアプローチでは、運用の観点とビジネスの観点からapplicationとそのニーズを理解する必要があるためです。 あるアプリの MVD は、別のアプリの MVD と一致しない場合があります。 これが、固定された手動ネットワークからアジャイル (自動化) パイプラインに移行するときに、アプリごとのアーキテクチャが非常に重要なコンポーネントとなる理由の 1 つです。
つまり、NetOps には最小限の実行可能な展開があるということになります。 つまり、ネットワーク自動化にアジャイル アプローチを採用できるということです。アジャイル ネットワーク イニシアチブの一環としてアプリごとのアーキテクチャに移行すれば、ネットワーク自動化ははるかに高速 (かつ安全) になります。
ネットワーク関連のほぼすべてを自動化します。
*これはリスト、私の経験、そして私の（強い）意見に基づいた完全なSWAGです。 走行距離や定義は異なる場合があります。