わかりやすくするために、データストレージシステムの例を示します。 そのため、すべてはファイルから始まりました。 最初は、すべてのデータを保存し、プログラムから直接アクセスするファイルのみを使用しました。 遅かれ早かれ誰もがそれに飽きて、 DBMSに切り替えました。 ルーチン作業の量が減少し、 SQLクエリを介してデータベースサーバーにアクセスしました。
しかし、しばらくするとそれも不快になりました。 ソースコードに大きな変更を加えることなく、あるDBMSから別のDBMSに切り替えることができるようにしたかったのです。
各データベースにアクセスするための低レベルAPIが必要に応じて接続されたドライバーに分散される抽象化DALを開発しました。 また、ユーザー自身が、リクエストを受信して結果を返す高レベルのオブジェクトとのみ通信しました。 しかし、しばらくすると、このスキームは必要な柔軟性を提供しなくなりました。
PS私はこの機会に、テクノロジー、心理学、哲学、および個人的な経験に特化した個人的で完全に非営利のブログを調べます: http : //v673.com 。
データベースと通信する必要がなくなったORMの作成を開始しました。特定のオブジェクトのプロパティとパラメーターを変更するだけで、データベースへの保存はすでに抽象化によって処理されています。
クラウドコンピューティングが登場しました。 サーバーのメンテナンスの放棄、パフォーマンスの監視、スタッフによる安定性、バックアップを可能にする優れた利点により、企業はすべての心配事を外部委託し、データベースとファイルをクラウドに移動することで、コストを最小限に抑えることができました。
問題がありました。特定のクラウドシステムにアマゾンEC2かRHEV-Mにしっかりと接続しないようにし、必要に応じてクラウドプロバイダーを簡単に変更できますか? 私の物語から判断すると、この抽象化を作成するシステムの外観を簡単に予測できます。 そして彼女が登場しました!
会いましょう! 悪名高いRed Hatの新しいDeltaCloudプロジェクト。 2009年のRed Hat Summitカンファレンスで発表されました。
Deltacloud REST APIを使用すると、システムを開発する際に、必要な柔軟性、決定を比較的独立した状態に保つ機能、必要に応じてクラウドプロバイダーを簡単に変更する機能を設定できます。 また、 Deltacloud Proxyを使用すると、開発者は独自のユーザーインターフェイスを作成し、アカウントのステータス、ユーザーの承認、リソースの割り当てを監視できます。
現在、2つのプロバイダーがサポートされています。
- Amazon EC2
- Red Hat Enterprise Virtualization Manager(RHEV-M)
開発者は、サポートされるプロバイダーのリストの増加(具体的には、VMWare ESXおよびRackSpaceのサポートの出現を約束する)を約束するとともに、REST APIとの直接の対話を回避する既製のライブラリーの追加を約束します。 そのため、たとえば、 Rubyのライブラリはすでに用意されています。
上位レベルでは、 Deltacloud Portalが提供するWebベースのインターフェースを使用すると、 インスタンスを表示および管理し、ストレージ間でデータを簡単に移動でき、便利な監視を実行できます。
ところで、プロジェクトは完全に無料でオープンソースです( LGPL 、 GPL )。 開発者によると、 Deltacloudのタスクは、ネイティブAPIの変更とクラウドプロバイダーによるサービスの表示条件からプロジェクトを保護することです。 Red Hatのエンジニアがこのシステムについて語るDeltacloudの公式Webサイトでもビデオを見ることができます。
美しいソリューションと美しいアプローチ。 市場で需要がありそうなプロジェクト。 開発者に製品の幸運、忍耐力、継続的な改善を願うことは残っています。
PSフレンズ、誰かがこの分野に興味を持っているなら、 ツイッターや別の方法で私に連絡してください。チャットするのは面白いでしょう。 クラウドの問題で明らかにされていない領域に興味がある場合は、たとえば、それらを調べて、これに関する記事を書いてうれしいです。