統合は継続的デプロイメントの実現を妨げる障害となる

API は統合ではありません。 これらは統合を実装するための手段です。 また、ITOps で指摘されている課題は、IT の継続性を確保するには不十分です。 

application開発の分野では、統合は常に 4 文字の単語でした。 DLL から共有ライブラリ、ESB からメッセージ キューまで、applicationsを他のアプリやサービスと統合するさまざまな手段を検討してきました。

ネットワーク管理の分野では、特に重要になっています。 統合は、applicationsを配信および保護するネットワーク デバイスとapplicationサービスの複数ベンダーの異機種パイプラインに固有の複雑さを管理する上で重要です。

現在、そのパイプラインはますます自動化されています。 開発者と DevOps は、継続的な開発パイプラインを構築するための統合の課題をうまく克服しました。 彼らは現在、IT 部門が展開パイプラインで同じことを行うことを期待し、いや、要求しています。

ITが対応しています。 「 NetOps Meets DevOps」によると、 「ネットワーク自動化の現状」によると、生産パイプラインのかなりの割合が少なくとも部分的に自動化されています。 

しかし、継続的なデプロイメントの導入には課題が伴います。

通常、調査では、DevOps および DevOps 関連のプラクティスの最大の阻害要因として「文化」が強調されています。 ネットワーク自動化の現状に関する調査では、文化は上位 3 つの項目の 1 つでした。 しかし、それが一番の不満ではありませんでした。 2位も獲得できなかった。 それらのスポットは、スキルギャップと私のお気に入りの4文字の言葉である「統合」に対する不満で占められていました。

実際、これら 2 つの課題は関連しています。 統合を大きなフラストレーションの原因にしている一因は、スキルギャップです。 これは、NetOps が開発者ではない (驚かれるかもしれませんが) ためです。

これが本当の問題です。 DevOps が継続的デリバリーを実現する取り組みで大きな成功を収めている理由の 1 つは、DevOps が主に開発者によって構成されていることです。 コードに生き、コードに呼吸する開発者。 彼らは統合が必要なものの統合に関するノウハウを持っています。 NetOps には必ずしもそのスキルセットは必要ありません。 展開パイプラインは、主にプロトコルを介して統合されるデバイスとシステムで構成されます。 コードベースの統合を必要としないように設計されているため、コードベースの統合を必要としない、明確に定義された RFC ベースのプロトコル。

これは NetOps にとってまったく新しい課題であり、必ずしも対応できる準備ができているわけではなく、スキルも備えていません。

この課題は API では解決できません。 API 対応インフラストラクチャは依然として重要であり、当社の2018 年application配信の現状調査の回答者の 4 分の 3 がそのように認識していますが、API は統合ではありません。 統合は可能になりますが、管理コンソールやコントロールを使用して異なるデバイスやシステムをプラグインおよび接続する実際の作業は、IT 部門の責任のままです。 必ずしもそのために必要なスキルを持っているわけではありません。 これらの課題は、展開パイプラインに対して非常に手動的なアプローチを強制することになるため、日常業務に大きな影響を与えます。 

これは、NetOps の半数以上 (52%) が主に「CLI/スクリプト ベース、デバイスごと」の管理方法を使用していることを説明しています。 DevOps と NetOps が挙げる、複数ベンダーによるオーケストレーションされた運用アプローチの差は顕著でした。 DevOps の 29% がマルチベンダーのオーケストレーション アプローチを使用していますが、NetOps ではわずか 12% が同様のアプローチを使用しています。

この相違は、NetOps の統合に対するより優れたアプローチの必要性と、統合の課題を克服するためにコミュニティと市場が注ぐ同様の熱意を雄弁に物語っています。

自動化とオーケストレーションのこの新しい世界を理解したい場合は、無料のオンラインSuper-NetOps プログラムをご覧ください。 F5 テクノロジーに自動化とオーケストレーションを適用することに重点を置くだけでなく、REST API の操作、Postman などのツールの使用、自動化プレイブックの作成に必要な基礎知識も提供します。