傍観者から CTO へ: Cloud Foundry Foundation での 5 年間

[51CTO.com クイック翻訳] 最近、Cloud Foundry プロジェクトがわずか 5 年でどれだけ変化したかについて考えていました。

この反省の結果として、オープンソース エコシステムとエンタープライズ コンピューティング市場は 2015 年以降劇的に変化しました。その結果、Cloud Foundry とその広範なエコシステムの共進化により、互いに異なる方向に進むようになりました。

同時に、この 5 年間は私のキャリアの中で最も速い 5 年間であると同時に、最も長い 5 年間でもありました。

[[314820]]

Cloud Foundry の元々のアイデアは、2009 年に VMware 内で生まれました。プロジェクトは 2011 年 4 月まで正式に発表されませんでした。このプロジェクトがまさに市場のニーズに応えたものであったことを私ははっきりと覚えています。発表されたプラットフォームは、アプリケーションの開発と展開を簡素化することに重点を置いています。その後数年間、私はこの製品が成熟していく様子（そして何度か所有者が変わる様子）を見守ってきました。 2014 年に、プラットフォームに統合された最初のサービス プロキシを作成し、コミュニティに少し近づきました。

2015 年に、現在オープンソースとなっている Cloud Foundry プロジェクトを中心に、若いオープンソース コミュニティが誕生しました。 Cloud Foundry Foundation は 2015 年 1 月下旬に設立されました。この時点で、私の役割はコミュニティの傍観者からサービス プロバイダーに変わりました。

基盤となるアーキテクチャの変更

このプラットフォームは、内部アーキテクチャとプラットフォームを使用する開発者に公開されている機能の両方において、2015 年以降大きく変化しました。

Cloud Foundry Foundation が最初に設立されたとき、コミュニティは、元の Ruby ベースのコード ベース (DEA アーキテクチャと呼ばれる) から新しい Go ベースのアーキテクチャ (Diego と呼ばれる) へと、プラットフォームの基盤となるアーキテクチャに大幅な変更を加えていました。これは、実現するのが難しい大規模なアーキテクチャの変更の 1 つです。課題は、新しいアーキテクチャそのものではなく、移行、つまり、既存のアーキテクチャにおける新しい機能に対する競合する要求と、不確実性の少ない新しいアーキテクチャに対する要望です。私はこれまでのキャリアでこうした移行を数多く経験してきましたが、Cloud Foundry コミュニティで最も感銘を受けたのは、この変化にどう対処したかということです。

確かに、オープン コラボレーションは面倒な場合がありますが、その結果、下流のディストリビューションとエンド ユーザーのエコシステムに移行を行うための十分な時間を与える、計画的な移行が実現します。 DEA アーキテクチャから Diego (およびそのすべてのサブシステム) への正式な移行は、Diego がバージョン 1.0 に達した 2016 年 11 月に開始されました。このメジャー リリースは、コミュニティに対して 2 つのことを実証しました。DEA と機能が同等であることと、一部のダウンストリーム ディストリビューションが求めていた 250,000 コンテナー規模の目標に到達したことです。

ウォーデンとガーデン

Diego 自体の進化と並行して、ノードレベルのコンテナ管理を担当する Cloud Foundry コンポーネントも大幅に変更されました。 DEA アーキテクチャでは、アーキテクチャのこの部分は Warden と呼ばれるコンポーネントです。 Warden は Docker より少なくとも 2 年前に利用可能でしたが、エンド ユーザーに公開されたテクノロジではありませんでした。 Diego は Warden の補完的な書き直しと並行して作成されました。その作品は「庭」と呼ばれています。

Garden の設計は、ユーザーが新しい OS レベルのコンテナー機能をサポートするためにコードの最も低レベルの詳細を簡単に変更する必要があることを予測しているため、思慮深いものとなっています。 Cloud Foundry コミュニティは、2015 年の早い時期に、Linux ベースのホストと Microsoft Windows ベースのホストの両方をサポートする Garden の実装を構築していました。基盤となるオペレーティング システム レベルのコンテナー テクノロジを変更できるため、Cloud Foundry プラットフォームでは、Docker が Open Container Initiative (OCI) に寄贈した runC ライブラリを採用することも可能になりました。実際、Cloud Foundry プロジェクトは、runC を採用し、エコシステム全体の実稼働グレードのクラスターで大規模に実行した 2 番目のプロジェクト (Docker 自体に次ぐ) でした。

ディエゴはなぜ重要なのでしょうか?

ディエゴの登場により新たな可能性が開かれました。 Diego の開発が順調に進むと、コンテナ間ネットワークとボリューム サービスが最初に追加された 2 つの機能でした。これら 2 つの機能は、内部の最適化 (南北トラフィックの削減など) と見なすことができますが、開発者エクスペリエンスの向上としてより重要です。 C2C ネットワーク機能を使用すると、より複雑なアプリケーション間ロジックを実装できます。この時点で、Cloud Foundry はより広範なオープンソース ネットワーキングの世界も受け入れ始めました。ボリューム サービスにより、プラットフォーム上でホストできるアプリケーションの種類の範囲が拡大し、オペレーターはアプリケーション開発者にネットワーク アドレス指定可能なストレージ デバイスのファイル システム マウントを提供できるようになります。

コンテナネットワーク

ネットワークの世界に戻ると、コンテナ間のネットワークは機能し、開発者にとって貴重な機能を多数追加します。これは、Cloud Foundry コミュニティにとって、サービス メッシュ分野で標準とプロジェクトの開発を開始する転換点でもあります。この作業は、コンテナベースのプラットフォームが基盤となるネットワーク層と対話しやすくして構成を簡素化する仕様であるコンテナ ネットワーク インターフェイス (CNI) の採用から始まりました。次のフェーズは、2017 年の Envoy プロキシの採用でした。最近では、Cloud Foundry ネットワーク スタック全体で、クラスターの受信/送信とコンテナ間のネットワーク機能をサポートするために、Istio + Envoy がデフォルトのコンポーネントとして採用されています。

Kubernetes + クラウドファウンドリ

最近、Cloud Foundry コミュニティは、Kubernetes という別のオープンソース プロジェクトを採用しました。これは、Pivo​​tal、Google、VMware が共同で開発したプロジェクトである Kubo の寄贈から始まりました。 Kubo はすぐに Cloud Foundry Container Runtime となり、Elastic Runtime (従来の Cloud Foundry PaaS としてよく知られています) は Application Runtime に名前が変更されました。これにより、私たちのコミュニティは、基盤となるコンテナ オーケストレーション レイヤーとして Kubernetes を採用するための次のステップを踏むために必要な自信を得ることができます。

Eirini プロジェクトは、Cloud Foundry クラスターがアーキテクチャ内で Kubernetes を使用できるようにし、最終的には Diego コードベースを置き換えることを目的としています。

過去 5 年間で、コミュニティは非常に多くの追加の変更と拡張機能を作成し、それらすべてを追跡することは困難です。いくつかのプロジェクトは、インストールされているほとんどの Cloud Foundry システムの主要コンポーネントへと進化しました。その他のプロジェクトは、その使命を終えた後、現在は財団の屋根裏に追いやられています。

変わらないものは何でしょうか?

過去 5 年間で変わっていない 2 つの点に注目する価値があります。それは、世界クラスのエンタープライズ開発エクスペリエンスを提供するというコミュニティの取り組みと、プラットフォームの継続的な進化に対するコミュニティの取り組みです。これら 2 つの本来の意図はどちらも「テクノロジー」ではなく、コミュニティの核となる精神です。私たちは、Cloud Foundry を使用する何万もの組織と、このプラットフォームにソフトウェアを展開する何十万もの開発者を引き付けるために懸命に取り組んできました。私たちは、エンタープライズ開発者により良いサービスを提供する方法を常に学び、このエクスペリエンスを継続的に反復して充実させています。また、幅広いオープンソース コミュニティからの最良のテクノロジーを取り入れながら、アーキテクチャの改善も継続しています。もちろん、私たちはこれらの変更を慎重かつ誠実に行います。私たちは頻繁なリリースで徐々に新しい機能を導入することで、この進化を可能にしています。

多くのことが変わりましたが、変わっていないのは、Cloud Foundry コミュニティがエコシステムを成長させ続けるという取り組みです。

原題: 傍観者から CTO へ: Cloud Foundry Foundation での 5 年間の旅、著者: Chip Childers

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。