クラウド・コンピューティングという迷宮をナビゲートする

アプリケーションに最適なクラウド・コンピューティングのプラットフォームを知識に基づいて決定するために

幸運にも、皆さんがクラウド・コンピューティングに関する基本を理解しているとしたら、そのスキルには需要があります。しかし実際にアプリケーションを構築するとなったら、どのプラットフォームを使用しますか?Google と Amazon はどちらも有名なので、どちらがよく使われているかを基準に選ぶことはできません。さらに、あなたが Microsoft 派だったとしたらどうでしょう。その場合には、どんな選択肢があるのでしょうか。この記事で、クラウドを賢くナビゲートして特定のアプリケーション要件に最適なプラットフォームを選ぶ方法を学んでください。

Brett D. McLaughlin, Sr., Author and Editor, O'Reilly Media, Inc.

Photo of Brett McLaughlinBrett McLaughlin は、受賞歴のあるノンフィクションのベストセラー作家です。コンピューター・プログラミング、ホーム・シアター、そして分析と設計に関する彼の著書は、100,000 部以上売れています。これまで 10 年近く、技術関連の著作、編集、制作活動を続けてきました。ワード・プロセッサーの前で過ごす時間と同じく彼にとって快適なのは、ギターの演奏、そして 2 人の息子を家のなかで追いかけ回したり、妻と一緒にテレビのコメディー番組を見て過ごしたりする時間です。最新の著書『Head First オブジェクト指向分析設計』は、2007年に Jolt Technical Book 賞を受賞しました。彼の著名な『Java and XML』は今でも、Java 言語での XML テクノロジーの使用方法に関するもっとも信頼のおける著作物の 1 つとして数えられています。



2009年 3月 31日

まるで迷路のなかのネズミのような・・・

最近では誰もが「クラウド」について話題にしています。試しに、技術カンファレンスの会場を歩き回ってみるか、プログラミングで収入を得ている誰かと一緒に時間を過ごしてみてください。たちまち「クラウド・コンピューティング」、「Google App Engine」、「Amazon がホストするアプリケーション」といった言葉の洪水を浴びることになるでしょう。

仮定として、あなたはクラウド・コンピューティングが何であるかをわかっているとします (この記事の「参考文献」セクションに、クラウド・コンピューティングの理解に役立つ優れた記事を多数紹介しています)。もし、クラウド・コンピューティングが結局はプログラミング言語であったとしたら、基本的な理解は実際のコーディングにつながっていくことになります。例えば、いったん Java™ オブジェクトの基本を理解してしまえば、そのほかに知っておく必要があることの大半は深く掘り下げて学ぶことができます。

しかしクラウド・コンピューティングは言語ではありません。実際には、クラウド・コンピューティングはパラダイムです。クラウド・コンピューティングとは、インターネット上のリモート・サーバーで実行およびホストされるサービスのすべてであるということを理解したとしても、コードの作成に取り掛かるには、その前に決定しなければならない数々の事項が残っています。何よりもまず、クラウド・コンピューティングのニーズに合ったプラットフォームを選択しなければなりません。

選択肢には Amazon および Google のオファリングもあれば、Microsoft® のオファリング、さらには AppNexus や GoGrid などの単発のオファリングもあります。しかもすべてが同等というわけではないため、単にリンゴとリンゴを比べるというわけにはいかないということです。実際、さまざまな機能セットによって分類しようとすることは、非常に大きな、そして非常に入り組んだ迷宮をナビゲートするようなものです。しかし細心の注意を払ってナビゲートすれば、特定のアプリケーションのニーズに基づいてプラットフォームを決定することも不可能な話ではありません。


主役となる顔触れは?

各種のフレームワークを調べる前に、何はともあれ、実際の選択肢について基本を理解しておく必要があります。このセクションの説明は意図的に簡潔にしているので、以下のいずれの選択肢にしても、「参考文献」を利用して情報を補足してください。

Amazon EC2

Amazon EC2 は Amazon Elastic Compute Cloud の略です。「エラスティック・コンピュート・クラウド」という呼び名はそれほど直観的ではありませんが、Amazon のオファリングは極めて実用性に優れています。実質上、Web サービスである EC2 では、クラウドのなかにある多数のリソース (つまり、Amazon がホストするリソース) を要求して使用することができます。リソースには、サーバーからプログラミング環境に至るまで、あらゆるものが揃っています。

Amazon のオファリングは、さまざまな構成を採ることができるその柔軟性を大々的な売りにしており、必要なサービスだけを要求したり、必要に応じてサービスを構成したり、静的 IP を設定したりすることが可能で、独自のセキュリティー設定とネットワーク構成を明示的に行うこともできます。言い換えると、使用する側が大幅な制御権を握るということです。そんな Amazon ならではの評判に加え、料金は使用した分だけ支払う従量課金制モデルであることから、EC2 はクラウド・コンピューティングというパズルのなかで、人気の高い重要な位置を占めています。

Google App Engine

Google の App Engine は技術的に言えば Amazon EC2 の競合となりますが、このオファリングは EC2 とは大きく異なります。Amazon が柔軟性と制御を提供する一方 (これについては、後ほど詳しく説明します)、Google が提供するのは使いやすさ、そして大幅な自動構成です。App Engine では、コードを自分で作成してアプリケーションをアップロードすれば、その後の処理のほとんどを Google が引き受けてくれます。

知名度が非常に高く、膨大なキャッシュを持っているという点では、Google は Amazon と変わりありません。Amazon と異なるのは、Google では使い始めは無料だという点です。トラフィックが増え、大量のコンピューティング・リソースを使用するようになってきた時点で初めて料金が発生します。さらに、Google は Python を中心としたアーキテクチャーとエンジンで構成されていることも、Amazon とは異なります。Google App Engine を使用するということは、Python を使用するということです。この制約は、単なる制約として見なされることも、あるいは作業を単純にするための便利な制約として見なされることもあります。

Windows Azure

クラウド・コンピューティングに対する Microsoft のアプローチは完全に異なります。PC と Mac とではまったく別物であるのと同じように、Microsoft は他とは異なり、極めてリッチで専門的なハイエンドのコンピューティング環境を提供することに重点を置いています。つまり、Amazon EC2 と Google は未だに vi で Python のコーディングをしているユーザーや、ネットワーク・プロトコルを扱うのに慣れているユーザーを対象としているのに対し、Microsoft の Azure 製品が対象としているのはまさに Microsoft 開発者そのものです。Visual Studio やビジュアル・ツール、そしてビジュアル環境 (これらに共通しているものにお気づきでしょうか?) によって、Azure は日常的に C# と SQL Server を使用している人々にとって取り組みやすく、快適なサービスとなっています。

Amazon EC2 が Google App Engine とは異なるように、Windows Azure はこのどちらとも異なります。なかでも特に顕著で、極めて単純な違いは、Azure が Windows® であるところにあります。Azure のベースは Windows であり、対象とするのは Window ユーザーであり、使用するのは C# と SQL Server、そして .NET と Visual Studio です。SharePoint と多少の CRM を加えれば、Azure とはどのようなものかを理解できたも同然です。この後すぐわかるように、Azure を使用するかどうかは、機能の問題ではなく、どのプラットフォームを使い慣れているかの問題となります。

ほかにも選択肢はあります

EC2、App Engine、Azure は、クラウド・コンピューティングの世界で群を抜いた「三大」サービスです。ただし念のために言っておきますが、選択肢はこの 3 つだけではありません。他にも GoGrid や AppNexus など、多数の選択肢があります。しかし、これらの他のツールについては知らなくても、それほど心配する必要はありません。Google、Amazon、そして Microsoft のオファリングが用意されている今、クラウド・コンピューティングの世界に足を踏み入れようとしている「一般的な」開発者であれば、これらのオファリングのいずれかに取り組むことになるからです。この三大オファリング以外の存在を認識しているほどの開発者であれば、この記事を読む必要はないでしょう。

その他の選択肢について言えることは、これらの選択肢が Google、Amazon、Microsoft のオファリングとは異なるように、それぞれが互いに異なるということです。このため、この記事の残りの部分で強調するように、どのプラットフォームを選択するかは、そのプラットフォームが提供する機能で決まるというよりはむしろ、皆さんのアプリケーションの要件によって決まるのです。

この記事の残りでは、その大半で皆さんに自分のスキル、好み、そしてアプリケーションの要求に関する根本的な質問を沢山投げかけ、それぞれの質問で、特定のクラウド・コンピューティング・プラットフォームのソリューションを薦められることになります。その狙いは、具体的なアプリケーションの機能と皆さんのスキル・セットに基づいて、最適なプラットフォームを選択できるようにすることにあります。


データベース (そしてスキーマ) にこだわっていますか?

アプリケーションの中心となるのは究極的にはデータです。アプリケーションではデータを表示し、データに対して検索を行い、データを整理し、そしてほとんどすべてのアプリケーションが最終的にはデータを保存します。既に選択したデータベースがある場合、そのデータベースが、どのクラウド・コンピューティング・プラットフォームを選択するかに大きな影響を与えます。

一から始めるのであれば、選択を制限するものは何もありません

アプリケーションを今まさに構築中で、既存のデータがないとしたら、決定権はあなたにあります。この場合、データの保存方法を自由に決定できるだけでなく、既存のデータをインポートする作業にかかりきりになることもありません。つまり、何の問題もないのですが、既存のデータが大量にあるとしたら、事態は一変します。

あなたは経験を積んだデータベース・プログラマーですか?

特定のデータベースを使い慣れている場合、あるいは使わざるを得ないとしたら、それがクラウド・コンピューティング・プラットフォームでの問題になる可能性があります。具体的に言うと、例えば Google の App Engine では Google のデータベースを使用しなければなりません。Google のデータベースが良くないとか、データを壊してしまうとか、SQL を使うことができないといったことは決してありませんが、独自のデータベース・サーバーをきめ細かく制御する習慣がついていたり、MySQL または PostgreSQL のお気に入りのバージョンに特有の SQL の動作に慣れていたりするとしたら、Google はイライラの種になるかもしれません。

IBM と Amazon Web サービス (AWS)

IBM と AWS はチームを組み、仮想コンピューティング環境で IBM ソフトウェアを利用できるサービスを提供しています。このサービスでは、Amazon EC2 で得られるエクスペリエンスを利用することで、ユーザー自身のシステムにインストールしなくてもソフトウェアを評価したり使用したりすることができます。また、ほとんど瞬時に容量を調整することができ、企業対応のアプリケーションを信頼性の高いハイパフォーマンス環境で構築できる上、料金は使用した時間と容量に対してしか発生しません。IBM が EC2 で提供しているミドルウェアは以下のとおりです。

  • DB2 Express-C 9.5
  • Informix Dynamic Server Developer Edition 11.5
  • WebSphere® Portal Server と Lotus® Web Content Management Standard Edition
  • WebSphere sMash

これらは製品レベルのコードであり、すべての機能とオプションが使用可能です。これらの製品の詳細について、またこれらの製品の Amazon Machine Images のダウンロードに関しては、developerWorks の Amazon EC2 クラウド・コンピューティングのページを参照してください。

クラウド・コンピューティングに関する他のリソースについては、developerWorks の Cloud Computing スペースを参照してください。

こうした場合に生彩を放つのは Amazon EC2 です。基本的に Amazon EC2 は、どこかしらの場所で稼動しているサーバーを提供するだけのサービスで、root 権限でアクセスしているような感覚で使え、必要なものを何でもインストールすることができます。さらに便利なことに、Amazon ではデータを保管できるサービスとして Amazon S3 (Simple Storage Service) を提供しており、このサービスにはデータに関してこれ以上ないほどの機能が用意されています。その一方、コマンドラインからでもアクセスできるため、必要なことは何なりと実行することができます。つまり、データベース・プログラミングをするとなれば、すでに使い慣れている環境を極めて忠実に模倣できるということです。例えば、コマンドラインで SQL コマンドをテストし、端末のような応答を取得して、環境を取り仕切ることができます。このこと自体は、単にデータを保管して扱いたいというだけであれば、たいしたことではありませんが、長い時間をかけてデータベースとその内部の実際の動作を学んだデータ・マニアにとっては大きな魅力です。

インポートするデータが大量にありますか?

Google は使いやすさに重点を置いているため、コマンドラインを使えば簡単にできることが App Engine ではできずに、実に苛立たしい思いをすることがあります。Google のデータベースへのデータのインポートは不確かで、簡単には修正できないエラーの原因となりがちです。それとは逆に、ここでもまた大きな存在となるのが、Amazon EC2 のコマンドライン・アクセスです。このコマンドライン・アクセスではバッチ・インポートを行ってから、その過程を追ってエラーを解決できるだけでなく、そうすることが大いに推奨されています。

図 1 に、このセクションでの基本的な決定木の要点を示します。

図 1. 現行のデータベースにどれだけ強いこだわりがありますか?
現行のデータベースにどれだけ強いこだわりがありますか?

あなたは Python 派ですか?それとも他の言語をお好みですか?

Python についての問題もまた、クラウド・コンピューティング・プラットフォームの決定を左右する質問です。かいつまんで言うと、Google で使用できるのは Python だけです。Google ではすべてが Python を中心に作成されています。一方、Amazon はそうではありません。Amazon では Python (または他の多数の言語) を使用できるものの、Python は Google App Engine でこそ、その威力を発揮します。ですから簡単な Python ソリューションを探しているとしたら、Google App Engine が第一候補です。

ただし、以下の場合にはそうとも限りません。

UNIX を得意としている場合

何度か言ったことですが、ここでもやはり当てはまることは、さまざまなものを制御し、コマンドラインを使用した上で、コンパイルを別とした Python のすべてのツールを手に入れてプログラムを実行したいのなら、Amazon EC2 が王者だということです。Amazon では何の障害もなくコマンドラインから Python コードを実行することができます。そしてこれは、Amazon EC2 の長所でもあり、弱点でもあります。ファイルにテキストを組み込んで Python に渡し、システム・エラーをコマンドラインでデバッグすることを厭わないのであれば、Amazon がお気に入りとなり、お節介が過ぎる Google には苛立ちを覚えることでしょう。

Python で C を使用している場合

Python で C 言語を使用していない場合、あるいはこれを費用が高くつく贅沢だと考えているのなら、次のセクションにスキップしてもらって構いません。しかし、Python に C コードを組み込んで使うことがよくあるとしたら、Google ではこれらの拡張機能をサポートしないことを肝に銘じてください。また、Google ではほとんど Python の標準ライブラリーしか使用できません。Google のデータ・ストア用、フェッチ用、そしてメール・サービス用の API はありますが、手に入れられるのはそれくらいのものです (注目すべき例外としては、Django があります)。ここでも同じく、肝心なのは制御です。あなたは鍛え上げられた Python のベテランですか?そうだとしたら、Amazon が適しています。Web サービスにのめり込んでいて Python の操作にも慣れているけれども、この言語で夢を見ないというのであれば、Google が最適です。

このセクションで説明した内容を図解すると、図 2 のようになります。

図 2. Python を使用しますか?どれだけの「おまけ」をお望みですか?
Python を使用しますか?どれだけの「おまけ」をお望みですか?

Microsoft 派なら、Azure を選択してください

単純な質問をさせてください。あなたが出発点としてあるいは最終的に、第一に優先するプラットフォームは Microsoft ですか?そうだとしたら、Azure が最適な選択肢となるはずです。それでは、Microsoft を出発点として、あるいは最終的に使用するとは実際に何を意味するのかを説明します。

出発点として Microsoft を使用しますか?

あなたは筋金入りの Microsoft 開発者ですか?具体的に質問すると、プログラミング作業の 3分の2 以上を Visual Studio で行っていて、Visual Basic、Visual C#、または Silverlight などに関連した技術を扱っていますか?そうだとしたら、ほぼ確実に Windows Azure を選ぶ気になるでしょう。開発フレームワーク全体の情報が Microsoft によって提供されるため、Azure は快適に感じられるはずです。さらに重要な点として、Amazon/Google を操作するとなると、Microsoft 以外の数々の言語や手法を学んだり、最初から理解しなおしたりする必要がでてきます。

最終的に Microsoft を使用しますか?

この質問はほぼ間違いなく重複するものですが、主に VB/C# などの領域で作業する開発者たちは大抵、自分たちのユーザー・ベースとして Microsoft プラットフォームをターゲットとしています。既存の Microsoft ユーザーに狙いを定め、プラットフォーム間の互換性についてはそれほど心配していないのであれば、Windows Azure を利用し続けることはまったく問題ありません。Azure には Microsoft プラットフォームとの重宝な接続機能が多数あるので、Azure がホストするクラウド・アプリケーションは極めてシームレスに既存のMicrosoft アプリケーションを統合することができます。平均的な Microsoft ユーザーにとって、使い慣れた Word や Internet Explorer などのデスクトップ・ベースのアプリケーションのルック・アンド・フィールドを持ち、場合によってはこれらのアプリケーションを操作することもできるクラウド・ベースのアプリケーションには絶大な価値があります。

Azure に誤った制約を設けていませんか?

皆さんが Azure を誤って解釈する前に (または、私が事実を誤って伝えたと責める前に) 言っておきますが、出発点として Microsoft を使用するとしても最終的に Microsoft を使用するとしても、Azure が Windows プラットフォームだけに制限されることは決してありません。Azure ベースのアプリケーションには、どのプラットフォームからでもアクセスすることができます。また、C# 以外の言語を使用して開発することも可能で、例えば Python と Perl を使うこともできます。このクラウドの良いところとしては、もちろん言語とサーバー技術がクラウドのなかにあるということがあります。つまり、どの言語やサーバー技術が使用されているかが、ほとんどのユーザーにわかるようになっています。

そうは言っても、Mac OS X システムをターゲットとする Python 開発者が敢えて Windows Azure を使用するというのは、どう考えても間抜けな話です。現実的には、またプログラミングの観点からも、賢い選択とは言えません。もし Azure の高度な機能を、例えばまだ知られていない新しい技術と比べたとしたら、Azure の純然たるプロ指向が原因で、Microsoft を中心としたクラウド・ベースの世界のなかで Microsoft 以外の技術を使用する方向に気持ちが傾くかもしれません。しかし、それは間違っています。Azure を比較する対象は、同じように完成度の高い (もちろん、今でも完成度を高めている) Google や Amazon のオファリングでなければなりません。これらのオファリングとの比較が、多くの点で同等に強力なプラットフォームを使用する際に役に立つことはほぼ確実です。その上、これらのオファリングが持つ性質から、さまざまなプラットフォームと Microsoft 以外の技術を利用できるようにもなります。図 3 に、この説明の要点をもう少しわかりやすい形で表します。

図 3. PC 派なら、Azure を気に入るはずです
PC 派なら、Azure を気に入るはずです

それでも Azure は使いたくないという場合

逆のことも同じく真実で、Microsoft プラットフォームをターゲットとする Microsoft 開発者が Azure を使用しなればならないというわけではありません。Amazon EC2 の柔軟性と機能、あるいは Google App Engine のこの上なく「クール」な決定要因を選ぶこともできます。前にも述べたように、Amazon と Google は両方とも、実に見事な機能を提供しています。そうは言っても、Amazon や Google を選ぶ理由は果たしてあるのでしょうか。新しい技術を学ぼうと決心したのでない限り (もちろん、新しい技術を覚えるのは面白いことで、大抵は無駄になりません)、一貫して Microsoft 製品で作成したソリューションを、充実した Microsoft クラウドがあるのにも関わらず Microsoft 以外のクラウドに放り込む正当な理由は、そう簡単には見つからないでしょう。アプリケーションを改良するか、別のアプリケーションを作成すれば楽にこなせた作業に、無駄な苦労をつぎ込むことにしかなりません。


いくつのリソースが必要ですか?どれだけのキャッシュがありますか?

初めて登場した当初、Google App Engine は以下の 2 つの点で Amazon EC2 とは大きく異なっていました。

  1. Google App Engine はプラットフォームとして無料で使用できましたが、Amazon EC2 はそうではありませんでした。
  2. Google App Engine にはリソース割り当て量に制限がありましたが、Amazon EC2 には (少なくとも、実質的には) ありませんでした。

しかし Google では今年 2月、使い始めは無料という制度をそのまま維持しながらも、無料のリソース割り当て量を超える分を有料で使用できるようにしました。これは Google にとってユーザーを大きく惹きつけるサービスの拡大であり、実際、リソースに制限のあるサービスからリソースで関心を引くサービスへと移行しています。

リソースで関心を引くとは一体何のことでしょうか?

コストがかかるのは、Amazon と Google のどちらか?

Google App Engine と Amazon EC2 を対等に比較してコストを分析するのは容易なことではありません。まず、Google は一定の割り当て量までは無料で使えます。その線を超えると、アプリケーションが使用した上り帯域幅と下り帯域幅、CPU 時間、データ保管量、E メール送受信数に応じた料金が発生します。Amazon でも同様のリソース、そして IP の再割り当てに対して料金が発生しますが、Amazon の場合は最初から有料です。

計算機を取り出すまでもなく、料金は Amazon と Google のどちらを選ぶかを決める要因にはなりません。Google の無料の最低割り当て量に固執するのでない限り、標準的なアプリケーションを使用していれば、どちらのプラットフォームでも同じくらいの料金になるはずです。

「リソースで関心を引く」という言葉を使っているのは、Google のようなモデル、つまりある時点まで無料で、その後に料金が発生するというモデルには、他のほとんどすべてのモデルに勝る大きな利点があることを示唆するためです。Google App Engine は、使い始めは無料です。これは、App Engine を試すのも、アプリケーションを実行するのも、さらにはアプリケーションを公然とデプロイするにも、すべて一銭もかからないことを意味します。これが、「最初は無料」の方式の大きな利点です。

このモデルが面白くなってくるところは、使っているうちに帯域幅を正確に判断できるようになり、正確な帯域幅がわかった時点で、アプリケーションを無料の割り当て量以上に拡張できるという点です。Amazon EC2 でも必要に応じてリソースを増強することができるので、いったん有料のモデルを使うようになれば、Amazon と Google のオファリングに大きな料金の差は出てきません。

使用した分だけ支払うとしたら、Google の魅力はどこにあるのでしょうか?

Google の「最初は無料」という方式には、Amazon に勝る 1 つの素晴らしい利点があります。それは、料金が発生する以前に、何らかの調整やリソースの再調整が可能であることです。本格的なプログラマーの常識として、アプリケーションの最初のバージョンには通常、以下の 2 つの問題が付き物です。

  1. 機能面でのバグ。機能が正常に働いていない、あるいは正常に働いているけれども修正が必要というバグ。
  2. リソースに関するバグ。接続が閉じているか、プーリングが使用されていないか、あるいは他の何かがアプリケーションの動作を遅くしているため、修正が必要というバグ。

Google 方式の利点は、文字どおり失敗の代価を払う前に、この類のリソース関連のバグを追跡できることです。

ここでの結論は、Google のほうが多少有利なものの、決定的な要素は何もないということです。

Windows Azure での課金はどのように行われるのでしょうか?

App Engine と EC2 と同じく、Azure でも使用した量に応じて料金が発生します。Azure サービスの使用量が増えれば増えるほど、料金は上がっていくという仕組みです。また、App Engine と EC2 とのもう 1 つの類似点として、Azure の料金も計算時間 (CPU 使用量)、帯域幅 (上り、下り)、そしてストレージ・ベースであることが挙げられます。さらに、Azure の料金はトランザクションにも基づきます (GET や PUT の操作数など)。

もちろん、この料金は (2009年3月初めの時点では) まだ公開されていないため、今は誰もが実際の料金がどのようになるかを見守っているところです。正直なところ、Azure の料金は Google App Engine や Amazon EC2 よりも多少高くなると予想されますが、それでも価格帯は変わらないと思います。料金の点でも、Google または Amazon の場合と同様に、Windows Azure を選択する決定的要因にはならないでしょう。


まとめ: 単純にすること、ただしほどほどに単純化すること

どのプラットフォームを使えばよいかは、ひとことで簡単に言うことができ、「Python がお気に入りの初心者は Google を、熟練の開発者は Amazon EC2 を、そして Microsoft 派の人は Azure を使用するとよい」いうことです。このように単純に割り切った言葉の中には、多くの真実が込められています。決定をする上での情報が結局はこれだけだったことに、読者の皆さんはがっかりしていることでしょう。Amazon は絶大な能力を提供しますが、ソリューションを素早く立ち上げるとしたら Google には敵いません。Google では極めて短時間で、しかも失敗する可能性もほとんどなくソリューションを軌道に乗せることができます。

Amazon では、開発者が自分の作業内容を把握しておく必要があります。例えば、何冊か本を調べたり、皮肉にも Google を使って多くの調査を行ったりしなければならないかもしれません (この場合の Google は、App Engine ではなく検索エンジンです)。しかしこうした作業が開発者の能力を高め、実質的に限りないリソースを有効に利用できるようになります。

端的に言うと、Azure は Windows プラットフォームとしては最適です。多少の難点はありますが、Microsoft プログラマーにとっては直観的に理解することができます。また、アプリケーション・ユーザーにとってのプラットフォームという点から見ても、ユーザーが快適に感じられるはずです。

結局のところ何をすべきかと言えば、優れたプログラマーの常に従うことです。使用できるあらゆるツールについて学び、適材適所でツールを使い分ければ、どんなときでも自力で問題を解決することができます。まずはGoogle App Engine から始めて、使い慣れてきたら同じアプリケーションを今度は Amazon EC2 にデプロイしてください。Visual Studio を調べて C# で何が実行可能なのかがわかった上で、アプリケーションを Azure にデプロイしてください。この 3 つすべての主要なプラットフォームでの経験が、特定のニーズを持つ特定のアプリケーションに直面したときに役に立ってくるはずです。

参考文献

学ぶために

製品や技術を入手するために

  • Google App Engine ホーム・ページで App Engine キーにサインアップしてください。SDK をダウンロードして、早速 App Engine を使い始めることができます。
  • Amazon Web サービスの Web サイトで、 Amazon Elastic Compute Cloud (Amazon EC2) にサインアップしてください。
  • Windows Azure は Microsoft フレーバーのクラウド・コンピューティングです。Microsoft に、包括的で管理しやすい優れた資料が用意されています。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development
ArticleID=385350
ArticleTitle=クラウド・コンピューティングという迷宮をナビゲートする
publish-date=03312009