構成可能性と操作性の間の隔たり
弊社では、最近の NGINX の買収をきっかけに、配信 (アプリ開発) とデプロイメント (本番環境) の境界に関するブログを数多く投稿してきました。そのうちの 1 つで、本日取り上げる「運用のシンプルさ」という概念について簡単に触れました。
「操作のシンプルさ」というフレーズの背後には、構成可能性と操作性の間に隔たりが存在します。 この二つは互いに全く対照的である。 一方では構成可能性です。 それは、ネットワーク、プラットフォーム、アプリケーション サービスの各層でアプリケーション サービスの特性を操作する機能です。 これにより、Nagle アルゴリズムのオン/オフを切り替えたり、プロトコルのパフォーマンスと効率に影響する設定を微調整したりできるようになります。
一方、操作性です。 それは、アプリケーション サービスを迅速に展開、管理、監視する機能です。 操作性に期待されるのは、アプリケーション サービスに関する知識、そしてそれ以上のものではありません。 オペレーターがプラットフォーム層やネットワーク層の専門家である必要はありません。 これを実現するために、アプリケーション サービス層に存在するノブやボタンが制限される場合があります。 主な目標は、アプリケーション サービスを簡単に展開および運用できるようにすることです。
これらのうちの 1 つは複雑さをもたらします。 一つはそれを減らす。 スタック全体にわたる深く幅広い知識が必要です。 もう一方はそうではありません。 それぞれがアプリケーションの安全な配信において役割を果たします。
職務分担
この区分が重要な理由は、クラウドとコンテナが、アプリケーション サービス インフラストラクチャに対して、よりシンプルなモデルへの移行を迫っているためです。 多数のアプリケーション サービスがコンテナーによって使用されています。 負荷分散、イングレス制御、監視、API ゲートウェイ、API セキュリティは、コンテナ化戦略を成功させるために必要なコンポーネントと見なされています。 本質的に、アーキテクチャの変革とは、アプリケーション サービス自体を分割することです。 データ パスでの展開に適したものもあれば、アプリケーション アーキテクチャの一部としての展開に適したものもあります。
つまり、オンプレミスおよびパブリック クラウドでアプリケーション サービスを利用するのは、運用 (具体的には DevOps) がますます増えているということです。 DevOps の期待には構成可能性よりも操作性が含まれるため、これはアプリケーション サービスに大きな影響を与えます。 DevOps は TCP スタックの調整に特に関心があるわけではなく、高速で頻繁なデプロイメントとアプリケーションの可用性の維持に関心があります。
これは主に、より迅速な提供と展開を要求する価値実現までの時間に重点を置いているためです。 誰もインフラストラクチャをいじっている時間はありません。市場にアプリケーションを投入する必要があるのです。
しかし、それは構成可能性が重要ではないという意味ではありません。 特にセキュリティとパフォーマンスに関してはそうです。 標準化されたネットワークおよびプラットフォーム スタックは、何に対しても最適化されていません。 デスクトップ向けに最適化するのと同時に、モバイル向けに最適化するように調整することはできません。 クラウドでもオンプレミスでも、ネットワーク向けに最適化されていません。
そして、認めたいかどうかに関わらず、パフォーマンスは複合的な尺度です。 ネットワークが遅いと、アプリも遅くなります。 ネットワーク層とプラットフォーム層での最適化の必要性は、可用性だけでなくパフォーマンスも確保するための重要な要素です。 そのため、構成可能性は、それを活用できるユーザーが利用できるようにする必要があります。
二者択一ではない
構成可能性は操作性と同じくらい重要です。 アプリケーション サービスの消費は二者択一ではないため、これは実際には二者択一の選択ではありません。 現在、NetOps と DevOps はどちらもアプリケーション サービスを利用していますが、その違いは、それらのアプリケーション サービスの展開と管理に関する期待にあります。 NetOps には構成可能性が必要です。 DevOps には操作性が求められます。
ビジネスには両方が必要です。アプリが高速で信頼性が高くなければ、市場への配信速度は役に立たないからです。
この隔たりが存在するのは、テクノロジーが、構成可能性が原則であった世界と、操作性が期待される将来の状態との間の移行状態にあるためです。 今日では、オペレーターの運用上の期待に応えるアプリケーション サービスによって、両者の間の溝を埋める方法が必要です。 だからこそ、F5 と NGINX の組み合わせは今とても魅力的なのです。
しかし、私は、構成可能性と操作性を同時に実現できる未来を思い描いています。 だからこそ、F5 と NGINX の組み合わせは将来的に非常に有望なのです。 F5 と NGINX が最新の API 管理をどのように実現するかに特にご興味がある場合は、今後開催されるウェビナーにご登録ください。