IT リーダーは DevOps に取り組み、受け入れる必要があります

IT 実務家は実践的なタイプの人が多いです。 文化的な変革としての DevOps は、アプリを本番環境にデプロイし、その可用性、セキュリティ、パフォーマンスを維持する役割を担う人々にとって、十分に具体的ではないことがよくあります。 しかし、現実には、文化的な変化、つまりグループ内およびグループ間のサイロの破壊は必ず起こる必要があり、しかもそれは遅かれ早かれ起こる必要があります。 

これは、新たなトレンドやアーキテクチャがネットワークに与える影響に関して特に当てはまります。

ネットワークに重点を置くリーダーや実務者の多くは、変化するアプリ アーキテクチャの状況にそれほど注意を払っていません。 たとえば、API とマイクロサービスへの移行は、私たちのインフラストラクチャにも API があるという事実を除けば、ネットワーク業界で実際に議論されることはほとんどありません。その理由は、SDN (または SDDC) です。

しかし、これらの変更と、それがネットワークと、要求の厳しい消費者や同僚へのapplicationsの配信にどのような影響を与えるか（影響を与えるかどうかではなく、実際に影響を与えるか）を認識する必要があります。 完全にapplicationアーキテクチャの決定のように見えるものでも、ネットワーク アーキテクチャだけでなく、ネットワークのパフォーマンスと要件にも大きな影響を与える可能性があります。 たとえば、マルチテナント マイクロサービスとシングルテナント マイクロサービスのどちらを選択するかという決定は、セキュリティから基本的なルーティングやスイッチングに至るまで、ネットワーク サービスに大きな影響を与えます。 マイクロサービスと組み合わせて HTTP/2 または HTTP/1 を使用する際のアーキテクチャ上の決定を認識しないと、ネットワークに重大な問題が発生し、パフォーマンスが低下する可能性があります。

開発者は、自分のドメインの内外におけるアーキテクチャの影響について、ますます認識を深めています。 サービス遅延 (2 つのサービスがネットワーク経由で通信するのにかかる時間) は、高度に分散されたapplicationアーキテクチャではよく理解されている問題です。 開発者が気づいていないのは、ネットワーク（およびそのサービス スタック）が、このような環境のパフォーマンス（および回復力）への悪影響を軽減するのにどのように役立つかということです。 

それはネットワーク担当者が知っていることです。

問題は、110 億のマイクロサービスが本番環境に導入されるまでネットワーク担当者が関与しないことです。 彼らは相談を受けておらず、関与している時点で提案を行うことは、サービスまたはapplicationの大幅なやり直しを意味する可能性があります。 アプリ内部ではなくネットワークにスケーラビリティを組み込む単純な変更でさえ、悪夢になります。 しかし、サービスがネットワークのスケーラビリティを考慮して設計されていれば、これはスムーズに動作するはずです。

しかし、そうではありませんでした。10 人中 9 人の幹部が、アプリをより早くリリースしなければならないというプレッシャーを感じているのでしょうか? これほど多くの相互接続され、関連し、依存するサービスを提供するためにネットワークに必要な変更を加えるには時間がかかるため、彼らはさらにプレッシャーを感じています。

IT には、インフラストラクチャ、ネットワーク、ストレージ、セキュリティの 4 つのオペレーションがあります。 そして、4 つのサイロ (中世の比喩で言えばタワー) すべてが、開発サイクルの早い段階でコラボレーションとコミュニケーションを促進する橋を互いに構築する必要があります。 アーキテクチャの選択に関するコラボレーションは、展開時ではなく設計時に行う必要があります。 そして、新しいテクノロジーやアーキテクチャがいつ検討されるかを知るために、各組織を把握しているリーダーがコラボレーションを開始する必要があるかもしれません。

DevOps は単なる自動化ではありません。自動化は目標を達成するためのツールとテクニックです。 自動化は、アプリの展開と配信に必要なサービスの展開を担当する人々の負担を軽減し、4 つの運用ドメインすべてにわたって専門家の負担を軽減する上で重要な役割を果たします。 組織間でのコラボレーション（共有）をさらに推進し、成長するアプリ経済の中心となるapplicationsの規模、パフォーマンス、セキュリティを向上させることができます。

ビジネスの成功と成長は、現場だけでなくリーダーシップの場でも IT 部門全体のコラボレーションにかかっています。