2017 年のアプリケーション配信の状況: 自動化、API、DevOps
過去 1 年間でデジタル化の動きが加速し、消費者や企業ユーザーにアプリを提供するネットワークとインフラストラクチャの責任者は、DevOps によってもたらされる自動化と、より俊敏で協調的な視点に目を向けるようになりました。 しかし、組織が自動化を採用し、プログラマビリティ（API とテンプレート）の重要性を認識しているにもかかわらず、すべてを統制する単一のスタックに落ち着く準備はまだ整っていません。
アプリ開発者から CEO、セキュリティおよびネットワーク エンジニアまで、IT 部門のあらゆる部門にわたる 2,100 人を超える回答者を対象に実施した 2017 年のアプリケーション配信の現状に関する調査では、DevOps が実稼働環境にさらに移行するにつれて、その推進要因と認識も変化することが明らかになりました。
01 | 自動化の導入
デジタル変革には、企業 API と多数の開発者だけでは不十分です。 ビジネスの成長に合わせて効率的に規模を拡大するために必要な内部の変更にも、同様に（あるいはそれ以上に）重点が置かれています。 より多くの人材をタスクに投入することは、もはやビジネス運営を拡大する現実的な手段ではありません。なぜなら、単に物事を成し遂げるだけでなく、物事を迅速かつ効率的に成し遂げることも重要だからです。
つまり、管理すべきシステム、モノ、アプリ、脅威、ID が増えることになります。 IT 部門では、その需要を満たすために規模を拡大するための同様の取り組みが続いており、自動化とオーケストレーションによる対応がますます進んでいます。
2016 年に実施したアプリケーション配信の現状に関する調査では、回答者のうち 1 つ以上の自動化フレームワークを使用していたのはわずか 21% でした。 1年後、その割合は回答者の52%に跳ね上がり、半数以上が2つ以上のシステムを同時に使用していました。 すべてのシステムで成長が見られ、CIsco、 OpenStack 、VMware ではそれぞれ 19%、14%、22% と最大の増加が見られました。 ネットワークとアプリケーション サービスの自動化が重要であることを証明するかのように、回答者の 35% が Cisco ACI を使用しています。 VMware や OpenStack などの定番製品と比べると比較的新しいことを考えると、わずか 2 年間の追跡で大きな飛躍が見られます。
02 | ハイブリッドスタックルールプロダクション
回答者の 39% はインフラストラクチャとアプリ サービスを自動化するために1 つのシステムのみを使用していますが、大多数 (61%) は 2 つ以上のシステムを使用しています。 組織が大きくなればなるほど (そしておそらく当然のことながら、管理対象のアプリケーションの数が増えるほど)、その数は増えることがわかります。 使用されている自動化システムの平均数は 1.8 ですが、3,000 以上のアプリケーションを管理している場合は、平均 2.43 になることが予想されます。
使用されているクラウド モデルの平均数も 1.8 であることは興味深いことです。 一部の組織では、自動化がクラウド コンピューティングの導入と使用にのみ結びついている可能性が十分にあります。
これは、コンピューティング インフラストラクチャの仮想化に長年 VMware に依存してきた企業にとって非常に理にかなっています。 組織がコンピューティングのプロビジョニングと管理を支える既存の自動化を排除する理由は、事実上 (本当に申し訳ありませんが) ありません。 多くの場合、その答えは、プロビジョニングと管理の自動化をネットワークとアプリケーション サービス インフラストラクチャに拡張する Cisco ACI などの追加システムにあります。
単一の自動化フレームワークに依存している企業のほぼ半数 (47%) が VMware を選択しました。 Cisco は 1 つのフレームワークのみで回答者の 26% を獲得しましたが、OpenStack は 9% を獲得しました。
7% は自動化とオーケストレーションを実現するために Python スクリプトのみに依存しており、ネットワークとアプリ サービス プラットフォーム API を中心に強力で十分にサポートされている顧客向けコミュニティが必要であることを示しています。
03 | スピードよりもスケール
DevOps のメリットとして最もよく挙げられるのはスピードです。 成功を測定するための指標は、展開の頻度と市場投入までの時間を中心に展開されます。 しかし、ネットワークとアプリ サービスのインフラストラクチャに関しては、規模が自動化とオーケストレーションの原動力になります。 回答者のわずか 14% が、自動化フレームワークの使用の原動力として市場投入までの時間を挙げ、導入の理由として規模 (37%) と運用コストの削減 (37%) を挙げました。
OpEx の削減は「予算の現状維持」を意味しているのではないかと疑っています。 Computer Economics の最新調査によると、IT 予算はほとんど変動していないか停滞しているため、予算の最適化は間違いなく大きな懸念事項です。 デバイスとエンジニアの比率がすでに高いことを考えると、スタッフを増やさずに規模を拡大することは困難です。そのため、自動化とオーケストレーションは、運用予算を大幅に増やさずに規模を拡大する 1 つの方法です。
興味深いことに、自動化は多くの場合、展開の速度を向上させる効果があります。 デプロイメント プロセスを調整するための最初のステップとしてバリュー ストリームをマッピングする場合、デプロイメントの遅延の原因となる「待機時間」を見つけるのは簡単です。 これらの待ち時間は、多くの場合、チーム間の引き継ぎや、エンジニアが特定のタスクを実行できるようになるまで待機する「キュー内の時間」です。 自動化により、待ち時間や待ち行列の時間が短縮され、プロセス全体が高速化され、市場投入までの時間が短縮されるという利点があります。
SDN の推進要因を調べてみても、同様の傾向が見られ、62% が運用コストを抑えるために SDN を採用しています。
04 | プログラミングは重要
あらゆるものがソフトウェア定義になるずっと前から、プログラマビリティは、製品を統合して顧客に包括的な機能を提供する手段を提供することで、ベンダー内エコシステムを実現していました。 これらの同じ API は現在、その他の API エコノミーに成長し、顧客に直接提供したり、オープンソース システムとのより広範な統合を促進したりすることで、さまざまな機能と能力を実現しています。
クラウドまたはデータセンターのインフラストラクチャに関連するかどうかにかかわらず、プログラマビリティは、ネットワークとアプリケーション インフラストラクチャを自動化し、プロセスをオーケストレーションし、最終的にスケールを実現する方法です。 プログラミング可能性は、ほとんどの場合 API に関連付けられますが、テンプレートの概念に関連付けられることも増えています。 当社の調査では、どちらも重要性が劇的に上昇しており、明らかに大多数の回答者が、インフラにとって「より重要な」特性として両方を挙げています。
データ パスのプログラマビリティ、つまり、送信中のデータを傍受、検査、変更する機能については、あまり理解されておらず、議論もされていません。 これにより、URL の書き換え、Cookie の保護、HTTP ヘッダーの追加/削除などのアプリケーション層機能と、セキュリティ強化に役立つプロトコルの詳細な検査 (特に新しいエクスプロイトに対する対応) が可能になります。
驚くべきことに、この機能は API やテンプレートよりも「重要」であると考えられています。 回答者の 52% が API を「より重要」と考え、53% がテンプレートを「より重要」と答えていますが、57% がデータ パスのプログラマビリティを「より重要」としています。
特にセキュリティの領域における俊敏性の観点からのデータ パス プログラマビリティのビジネス上の利点は、回答者がそのような機能を採用する十分な動機となります。
プログラマビリティ、自動化、オーケストレーションはなくなることはありません。アプリ開発以外の役割でも、かなりの割合でこれらの概念が取り入れられているのを見ると、心強いです。 彼らは、自動化、オーケストレーション、および関連する概念を、予算や規模などの課題に対応するための戦術的な対応と見なしているかもしれませんが、ビジネスのデジタル変革を内外から実現するために必要な空中援護を提供するために、DevOps というビュッフェを確かに利用しています。
SlideShare でスライド形式のデータを自由に閲覧できます。