ネットワーク自動化ではサイズが重要（ただしそれほど重要ではない）
データはそう言っています。
組織の規模 (およびそれに伴う需要) を考えると、必要とされる多大な労力は正当化できないと主張して、ネットワーク自動化の重要性を軽視するのは簡単です。
結局のところ、組織内に 100 人しかいなければ、それほど多くの需要があるはずがありません。 できますか？
はい。 はい、可能です。
クラウドとそのパートナーである DevOps は多くのことを混乱させましたが、ビジネスを分類するために使用する古い「組織の規模」という区分についてはほとんど議論されていません。 ご存知のとおり、SMBです。 中小企業。 大企業。
従来のターゲット市場は長い間、従業員基盤の規模に基づいていました。 各国には（統治と法的適用のための）法的定義がありますが、それらはソフトウェアベンダーのセグメンテーションの目的にはそれほど関係がありません。ソフトウェアベンダーのセグメンテーションによって、各国があなたの注目と資金を要求するかどうかが決まります。 前提として、人数が増えれば増えるほど、企業全体にサービスを提供するためにより多くの人材が必要になるということです。 テクノロジーが多ければ多いほど、複雑さも増します。 複雑さが増すほど、すべてがより複雑になります。
ソフトウェア ベンダーの世界では、データ センターの規模とプロセスの複雑さが非常に重要です。 どちらも通常は、便宜上、組織の規模（従業員数）に結び付けられます。
しかし、クラウドと DevOps は、仮想化がデータセンター内の「サーバー」の密度に与えた影響と同じ影響を組織の規模に与えています。 仮想爆発を覚えていますか? 私たちは、アプリケーションごとにサーバー モデルから、単一の物理サーバーが 10 台または 20 台の仮想サーバーをホストする、アプリケーションごとに仮想サーバーの世界に移行しました。 アプリケーションが爆発的に増加し、「データ センター」は 100 台のサーバーから 1,000 台以上にまで成長しました。 しかし、データセンターの実際の物理的なサイズは変わりませんでした。 そして多くの場合、オペレーターの数も変わりませんでした。
つまり、あらゆる種類の人員配置レベルを追跡している Computer Economics は、わずか 1 年の間にエンジニアとデバイスの比率が大幅に増加したことを発見しました。 2014 年には、1 人のエンジニアが 36 台のデバイスを担当していました。 1年後ですか? 同じエンジニアが 59 台のデバイスを管理することが期待されていました。
アプリケーション インフラストラクチャの領域でも同様の増加が起こっていました。 これは、部分的には仮想化と、限られた規模での便利な自動化によって可能になりました。
私たちが行ったのは、物理サーバーとその物理オペレーターの両方の効率を向上させることでした。
早送りして今日まで進みます。 クラウドと DevOps、そしてこのグループの最新メンバーである NetOps は、仮想化によってサーバーに対して行ったのと同じことを IT の規模に対して行おうとしています (そしてすでに始めています)。 クラウド（およびコンテナ）と自動化を組み合わせることで、運用効率が大幅に向上します。 つまり、人員数を大幅に変更することなく、現在の 10 倍または 20 倍のアプリケーションと操作をサポートできることになります。
「中小企業」レベルの予算で「大企業」を運営できます*。
従業員数だけを見て、製品やソリューションが適切かどうかを判断するのはほぼ不可能です。 なぜなら、その 30 人規模の組織 (市場および法的な定義のほぼすべてにおいて SMB) は、クラウドまたは自社のデータ センターにアプリケーションのインスタンスを数千個隠している可能性があるからです。
なぜなら、パブリック クラウドや DevOps による自動化によって、運用効率が桁違いに向上するからです。
ネットワーク自動化ではサイズは（ほとんど）重要ではない
そのため、ネットワーク自動化に関しては、組織の規模に応じて、見解、推進要因、導入にほとんど違いがないのは驚くことではありません。 従業員数が 100 人未満の組織の 9% が、生産現場で自動化を完全に活用していることがわかりました。 一方、従業員数が5,000 人を超える組織の 8% も同様の回答をしています。 自動化を使用して大規模な変更を本番環境に導入する場合、従業員数 100 人未満の組織の 23% が常に自動化を使用しています。 従業員数が 5,000 人を超える組織の場合、その数はわずかに 25% に増加しました。 中間の企業では偏差がほとんどなく、21%から23%の範囲でした。
規模に応じて違いが見られるのは、ネットワークと運用の自動化に使用されるツールとテクノロジーです。 おそらく最も印象的だったのは、Python スクリプトの使用に関して小規模組織と大規模組織の間で大きな差があったことです。 大企業（従業員 5,000 人以上）の大半は、おそらく人材の確保と、さまざまな運用プロセスに基づいたカスタマイズされた自動化のニーズの高まりにより、このテクノロジーを採用しているようです。
逆に、非常に小規模な組織（従業員 100 人未満）では、3 分の 1 強（36%）が Python スクリプトを使用しています。 これらの組織では、「なし」を使用している割合も 33% と、非常に大規模な組織 (20%) よりもはるかに高くなっています。
ネットワーク自動化の領域では、この違いは残りました。 Cisco は、非常に大規模な組織の 63% で使用されていますが、非常に小規模な組織では 35% しか使用されていません。 OpenStack は、 VMware と同様に、非常に小規模な企業では 29%、非常に大規模な組織では 36% と、両者の距離を縮めました。 この仮想化大手は、非常に小規模な組織の 63% と非常に大規模な組織の 73% で使用されています。
ネットワーク自動化に「なし」を使用する組織間の差は、自動化ツールセットを使用しない組織間の差よりも驚くほど小さかった。 非常に小規模な組織では、ネットワーク自動化に何も使用していないのはわずか 8% であり、非常に大規模な企業ではわずか 5% です。
これが非常に興味深い理由は、最終的には、自動化には、特注品（カスタム Python スクリプト）やフレームワーク（Chef、Puppet）、あるいはエンジンベース（Ansible、Cisco、OpenStack、VMware）など、何らかのソフトウェアが必要になるからです。 従業員の規模に基づいて組織をセグメント化するというソフトウェアプロバイダーによる従来の慣行は、自動化の導入による運用効率の向上を考えると、あまり意味がありません。
ネットワーク（および IT 全体）における自動化の最大の推進力の 1 つは、運用規模です。 それは従業員の増加ではなく、テクノロジーの増加を意味します。 結局のところ、それが私たちが望んでいることなのです。 私たちは、テクノロジーを活用して人員を増やす必要性を軽減し、日々の業務をより効率的にすることで、ブルックスの法則に抵触しないように努めています。
そうなると、組織の規模に基づいてテクノロジーに対する組織の関連性を表面的に判断するやり方を見直す時期が来ているのかもしれません。 マーク・トウェインが有名な言葉を残している（あるいは言わなかったかもしれないが）。 問題は戦う犬の大きさではなく、犬の闘争心の大きさだ。
自動化によって動くその小さな犬は、見た目以上に闘志に満ちている。