その問いには、そうすべきだという結論が暗に含まれています。
数十年にわたり、本番環境のパイプラインの大部分を構成するアプリケーションサービスは、共有プラットフォーム上に展開されてきました。負荷分散、アプリケーションパフォーマンスサービス、WAF、フェデレーションIDなどのアプリケーションサービスは、多くの場合、Application Delivery Controller（ADC）という形で、共有インフラストラクチャ上のNetOpsによって提供されています。
しかし、時代の変化や需要の高まりに加え、マイクロサービスのような新たなアプリケーションアーキテクチャの登場により、そのパイプラインは変革を迫られています。こうした変化は、導入スケジュールやInfrastructure as Codeなどの運用手法により適合したモデルへの移行を促すため、NetOpsとDevOpsの双方にメリットをもたらします。
一部のアプリケーションサービスは、依然として共有インフラストラクチャに深く根付いています。DNS、ボリューム型DDoS攻撃への防御、ネットワークファイアウォールなどです。これらは本質的に企業向けのサービスです。つまり、ビジネスを保護、防御、支援するよう設計されています。これらのサービスが停止すれば、企業全体の生産性と収益が失われます。
一方、アプリケーションとの親和性が非常に高いアプリケーションサービスもあります。その構成、API、サービスは、単一のアーキテクチャではなく、単一のアプリケーションをサポートするために個別に設定されることが少なくありません。
これらのサービスに対する責任は、アプリケーション運用（DevOps）へとますますシフトレフトし、アプリケーションを提供する開発者が関与するようになっています。必要なアプリケーションデリバリおよびセキュリティサービスの提供には、共有モデルも引き続き有効であり、実際に機能する場合も多くありますが、いくつかの理由から、その多くにはアプリケーション単位のモデルが適しています。
第1に、アプリケーション単位のモデルなら、デプロイスケジュールの競合をすっきり解消できます。企業では、共有インフラストラクチャがサポートするアプリケーションサービスの構成やデプロイに関して、競合による制約を受けることが少なくありません。インフラストラクチャを共有するということは、リソースも共有するということであり、必然的に構成が衝突する可能性が高まります。この可能性を排除すれば、デプロイの頻度を増やしたり、予定外のデプロイを実施したりする際の障壁を軽減できます。アプリケーションサービスが自分のアプリケーション専用で、独自のリソースを備えた専用プラットフォーム上で稼働していれば、競合はすっきり解消されます。自分のアプリ、自分のリスクです。
第2に、アプリケーション単位のモデルは、Infrastructure as Codeなどの手法を実践する新たな自動化の取り組みを支援します。リソースとプラットフォームを単一のアプリケーション専用にすることで、構成の対象をそのアプリケーションだけに限定できます。イミュータビリティを適用し、エントロピーのリスクを回避できます。実際、私の考えでは（最近もそう主張しました）、アプリケーション単位のアーキテクチャなしにイミュータブルインフラストラクチャを適切に実現することはできません。このアプローチにより、アプリケーションインフラストラクチャの枠を越えて「ネットワーク」にまで及ぶ継続的デプロイパイプラインに組み込めるようになります。この機能を提供するには、構成と継続的な管理の責任をNetOpsからDevOpsへ移す必要があります。責任が増す一方で、DevOpsがアプリケーションサービスの「所有者」となり、自らの条件とスケジュールに従ってアップグレード、パッチ適用、再デプロイを行えるようになるため、より大きな制御権を得られるという利点があります。
最後に、アプリケーション単位のモデルでは、移植性がすぐに向上します。共有プラットフォームに縛られず、ほぼ全面的にデプロイ成果物（構成とテンプレート）を利用することで、本番環境へのデプロイパイプラインの大部分を、クラウド間やオンプレミスからクラウドへ、はるかに少ない手間で移行できるようになります。この柔軟性により、組織は移行に伴うコストに制約されることなく、対象のアプリケーションに最適なクラウドとロケーションを選択できます。
オンプレミスとパブリッククラウドのどちらでも、アプリケーションサービスにアプリケーション単位のアーキテクチャの導入を促進することで、DevOpsは大きなメリットを得られます。NetOpsには、他の運用領域に対してより高度な制御と可視性を提供することが求められています。今こそ、ピザとビールを囲みながら、次世代のアプリケーション中心型アーキテクチャへの移行と、そのサポートについてNetOpsの担当者と話し合う絶好の機会です。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。