オープンソースで分断を解消
アプリケーションの配信は変化しています。 流行語を使う危険を冒して言うなら、デジタル的に変革が起こっているのです。 継続的デリバリーは DevOps の標準となり(71% が実装を計画)、アプリケーション キャピタルの時代にビジネスが成功するには、継続的デプロイメントもそれに続く必要があります。 組織の 73% が継続的デプロイメントの実施を計画していますが、約半数の組織はまだ開始していません。 驚くべきことに、42% の企業が、継続的デプロイメント パイプラインのコンポーネントを 1 つも自動化していません。
配信と展開の間には実際に隔たりがあります。 これは、理論的には調査で、実践的にはクラウドとデータセンターの間に存在する溝で確認できます。 これは、継続的なデプロイメントのようなものに遭遇したときに、継続的なデリバリーが停止してしまうという壁として組織内に見られます。
これはテクノロジーの分野でも同様で、アプリケーション配信チェーンが分断されているために、可視性に非常に大きなギャップが生じています。 これは、マルチクラウド環境でアプリケーションのパフォーマンスを監視および測定できないことに表れています。 そして、これは、現在何千もの企業組織によって管理されている複数世代のアプリケーション ポートフォリオ全体にわたって、セキュリティ ポリシーを一貫して展開および適用できないことに表れています。
格差は拡大している
最新のクラウドネイティブ アプリケーションとアーキテクチャの採用により、その格差がますます拡大していることがわかりました。 データセンターに接続されたままのアプリケーションも影響を受けます。 その影響が、新しいアプローチ（継続的なすべて）であるか、最新のクラウドネイティブ環境におけるセキュリティとスケールのニーズに応える新しいアプリケーション サービスであるかにかかわらず、1 つ明らかなことは、マルチクラウドの世界における一貫性と可視性のニーズに対応するには、アプリケーション配信を変更し、DevOps と NetOps の間の溝を埋める必要があるということです。
DevOps の世界はますますオープンソース上に構築されるようになっています。 NGINX CEO の Gus Robertson 氏は最近のブログで、「ソフトウェアが世界を席巻しているのなら、オープンソースはソフトウェアを席巻している」と書いています。 現在、アプリケーション自体は主にサードパーティのコンポーネントから開発されており、その大部分はオープンソースです。 アプリケーション インフラストラクチャは、オープン ソース コンポーネントから構築されることが増えています。 Web サーバーからアプリケーション サーバー、データベースからイングレス制御、メッセージングからコンテナ ランタイムおよびオーケストレーションまで。 IT 運用は、Puppet、Chef、Terraform、Helm、Kubernetes、Ansible などのオープンソース ツールによって推進されています。
これらのツールとテクノロジーが採用されるのは、高速で頻繁な配信と展開、そして摩擦のないビジネス モデルという複数の課題に対応できるためです。 しかし、組織全体がオープンソースベースの運用を標準化する方向に動くと、コラボレーションを促進し、イノベーションを促進するという点でもメリットがもたらされます。
これらはすべて、オープンソース ソリューションの改善に精力的に取り組んでいる熱心な開発者コミュニティがなければ実現できません。
F5 では、このようなコミュニティの価値を高く評価しています。
F5のコミュニティの見方
同様の例として、当社のDevCentral コミュニティは、オープンソース プロジェクトを推進するのと同じ原則の多くに基づいた共同イノベーションに基づいています。 コミュニティ全体でのコード共有と知識移転により、何十万人ものメンバーが革新を起こし、BIG-IP プラットフォームの新しい機能を生み出すことができます。 これらのソリューションには、Puppet、Chef、node.js などのオープンソース プロジェクト用の新しい拡張機能、プラグイン、ライブラリが付属しています。
当社は、自社製品だけでなく、お客様やコミュニティが事業運営に頼っているオープンソース ソフトウェアを強化するために、こうした取り組みに積極的に参加、奨励、サポートしています。
それでも、皆さんの多くが、特に NGINX オープンソース コミュニティでは、F5 をあまりよく知らないことを私たちは知っています。 また、それがあなたにとって疑念を抱かせる理由となることも認識しています。 それは理解できます。 これまで、オープンソースとのやりとりは、主に舞台裏で行われてきました。
とはいえ、当社自身の変革では、アプリケーション配信からアプリケーション サービスへと重点を移す中で、オープン ソースを広範に活用して CI/CD パイプラインと製品を推進しています。 当社はオープンソースと常に交流しており、コアエンジニアはloopback.ioとnats.ioに積極的に貢献しています。 当社のAspen Mesh部門は、定期的に istio.io を消費および貢献しており、 istio-vet 、 istio-client-go 、 tracing-goなど、当社が管理するいくつかの関連オープンソース プロジェクトを生成しています。 私たちは、Ansible 用のオープンソース モジュールのセットを開発および保守しています。
私たちがこれについて大声で宣伝しないのは、マーケティング ポイントを稼ぐために貢献しているわけではないからです。私たちが貢献するのは、それが私たちにとって、私たちの顧客にとって、そしてオープン ソース プロジェクトを管理する各コミュニティにとって正しいことだからなのです。
橋の建設
企業が継続的な IT を実現できない原因となっている溝を埋めるために今すべきことは、アプリケーション配信スタックで最も広く採用されているオープンソース コンポーネントのミッションを拡大し、加速することです。
そこで、ガスとイゴールが伝えたことをもう一度述べたいと思います。 F5 は、NGINX ミッションを拡大し加速するために投資を増やす予定です。
F5 と NGINX を組み合わせることで、エンドツーエンドの一貫したアプリケーション サービス セットを備えた企業が、複数のクラウド プロパティに存在するさまざまなアプリケーション アーキテクチャ全体にわたる高速で頻繁な展開という、IT の最も差し迫ったニーズに対応できるようになります。 これを成功させるには、NGINX がオープンソースのままであり、それを構築したコミュニティによって大部分が推進されるかどうかにかかっていると私たちは考えています。
NGINX はこれまで、オープンソース ソフトウェアとコミュニティの指導において素晴らしい成果を上げてきました。 それは私たちを惹きつけたものの一つです。 NGINX と F5 の両社が、アプリケーションによって推進され形作られる未来を予測すると、NGINX スタックの開発とイノベーションを拡大し加速させる必要性と機会の両方がわかります。
私たちは、これらのコミュニティから学び、アプリケーションとその完璧な配信に対する共通の情熱に基づいた未来に向けて協力していくことを楽しみにしています。