63

だから私はCloud Foundryについて読んでいますが、それが何であるかについてはまだ混乱しています. とにかく、CF 上の PaaS に関する私の見解は次のとおりです。うまくいけば、私が間違っているかどうかを教えてくれ、もう少し詳しく説明してくれることを願っています。

Microsoft Azure や Google AppEngine などの従来の PaaS サービスは、Web アプリを開発、テスト、ホスト、および管理するための完全なプラットフォームを提供します。ただし、API を使用する必要があり、提供するサービスとサポートする言語/フレームワークに制限されます。

Cloud Foundry は、アプリが多くのパブリック クラウドのサービスを使用できるようにする、ある種の「仲介者」のようです。それはどのようにこれを達成しますか?LibCloud や JCloud のような単一の API を使用していますか? たとえば、あるプロバイダーの 1 つのサービスと、別のプロバイダーの別のサービスを使用できますか? また、Cloud Foundry 自体は何らかのサービスを提供していますか? それとも、あるプラットフォームから別のプラットフォームに簡単に移行し、単一のアプリでさまざまなプロバイダーのさまざまなサービスの組み合わせを使用できるようにする仲介者にすぎませんか?

4

4 に答える 4

86

私は Cloud Foundry の開発者です。確かに、Cloud Foundry は少しあいまいです (しゃれは意図されていません)。うまくいけば、私は物事を少し明確にするのに役立ちます.

Cloud Foundry はサービスとしてのプラットフォームですが、その下にサービスとしてのインフラストラクチャが必要です。Cloud Foundry は、 BOSHツールを介してインフラストラクチャとしてvSpherevCloudOpenStack、およびAmazon AWSをサポートします。ほとんどの Web アプリケーション開発者はそのことを気にしませんが、大規模な IT インフラストラクチャについて心配しなければならない人々にとって、これは非常に素晴らしいことです。

あなたが AcmeCorp の IT を担当しているとします。50,000 人の従業員がいて、全員が内部 Web サービス Fizzbuzz を使用して仕事を支援しています。すべての従業員をサポートするには、強力なプロセッサと大量のメモリを備えた複数のマシンで実行される Fizzbuzz アプリケーションの数十のインスタンスが必要であり、使用する Foo、Bar、および Baz アプリケーションによって生成された情報を格納するための大量のディスク領域が必要です。内部的にも。自分のブレード サーバーで管理したい範囲をはるかに超えてしまったので、データセンターをリースすることにしました。

残念ながら、AcmeCorp はひどく機能不全です。財務部門は、使用するデータセンターについて大きな発言権を持っており、数年ごとに 1 つのデータセンターから別のデータセンターに切り替える必要があります。数年ごとに、エンジニアが vSphere、vCloud、OpenStack などの切り替えによって明らかになった Fizzbuzz のバグを修正しようとしている間、数週間のダウンタイムがあります。

エンジニアが、基盤となるインフラストラクチャに対して直接ではなく、Cloud Foundry に対して Fizzbuzz、Foo、Bar、および Baz を作成していれば、ダウンタイムは最小限に抑えられていたでしょう。ホスティングのレイヤーは Cloud Foundry によって抽象化されているため、特定のデータセンターに閉じ込められることについてそれほど心配する必要はありません。Cloud Foundry は、PostgreSQL、MySQL、Mongo、Redis、RabbitMQ などの特定のサービス セットもサポートしています。Foo、Bar、および Baz が Cloud Foundry によって提供されるこれらのサービスを使用すると、インフラストラクチャ間で移行するときに心配することが 1 つ少なくなります。

後で、Fizzbuzz をサービスとして他の大企業に販売することで、大金を稼ぐことができることに気付きます。エンジニアは Cloud Foundry で実行するように Fizzbuzz を再設計したため、Cloud Foundry を AWS に必要なだけデプロイできます。お客様は 6 か月間試用し、サービスを更新しないことにしましたか? 問題ありません。データセンターのリースについて心配する必要はありません。これらの EC2 インスタンスをすべて終了して、次に進みます。サービスとしての Fizzbuzz のインスタンスごとに 1 つの Cloud Foundry を簡単にデプロイして、顧客のデータを互いに完全に分離することができます。

さらに嬉しいことに、Cloud Foundry はオープン ソースです。ニーズに合わないことがわかった場合は、サポートに電子メールを送信して、Cloud Foundry のエンジニアが夢の機能を実装するのを待つ必要はありません。ソースも入手できるので、作成することができます。必要な変更。また、Apache 2.0 ライセンスの下で利用できるため、必須ではありませんが、プル リクエストは喜んで受け入れられます。

これで、Cloud Foundry が解決する問題の種類を理解できることを願っています。詳細については、コメントでお気軽にお問い合わせください。また、今後の質問に役立つ場合は、 Cloud Foundry メーリング リストをチェックしてください。

于 2013-05-03T04:51:50.643 に答える
4

確かに、CF は IaaS (サーバー、ストレージ、ネットワーク) とアプリケーションの間の抽象化レイヤーであり、パブリック クラウドとプライベート クラウド間でアプリを移動するための移植性を提供しますが、それだけではありません。

1. 水平スケーラビリティの高いコンテナベースのプラットフォーム

アプリはコンテナーで実行され、アプリをホスト (VM) に割り当てるよりも優れたリソース管理が可能になります。Warden/Garden は CF ネイティブのコンテナー テクノロジですが、最近のバージョンでは Docker もサポートされています。

2. アプリケーションに複数の HA レイヤーを提供する自己修復プラットフォーム

正常性管理システムは、障害が発生したアプリ インスタンス、コンテナー ホスト、プラットフォーム プロセス、および VM を停止することなく復活させます。アベイラビリティ ゾーンのサポートにより、インフラストラクチャ レイヤーで HA が提供されます。ローリング アップデートとカナリア デプロイにより、デプロイやプラットフォームのアップグレード中でもダウンタイムをゼロにできます。

3. 独自の多言語アプリケーション ランタイム

heroku の「buildpack」コンストラクトを使用すると、アプリの言語が自動検出され、適切なランタイム スタックがバニラ OS イメージの上に構築されるため、開発者はコードの記述に集中できます。

4. 開発者によるステートフル データ サービスのオンデマンド プロビジョニング

開発者は、MySQL、RabbitMQ、Redis などのクラスターのスライスを自己プロビジョニングして、uri/資格情報をアプリの環境に自動的に挿入できます。

于 2016-01-19T01:29:31.930 に答える