ニーズに合った最適な PaaS クラウドを選択する

クラウド・プラットフォームを多様な選択肢から選択するための基本的な指針

PaaS (Platform as a Service) は一般に、クラウド・コンピューティングによる 3 つのサービス提供モデルの 1 つであると考えられています。PaaS によって、単純でエラスティック (弾力的) なリソース割り当てや、各種のツールやサービスの提供が容易になるのみならず、クラウド・アプリケーションの開発も容易になります。その一方で PaaS という言葉で一括りにしてしまうと、クラウド・プラットフォームの多様性が隠されてしまいます。この記事では主なクラウド・プラットフォームをいくつか検証し、それぞれのクラウド・プラットフォームを使用するのが適している状況についての指針を示します。

John Rhoton, Cloud Computing Strategist

John Rhoton photoJohn Rhoton は、パブリック・クラウド、プライベート・クラウド、ハイブリッド・クラウド・コンピューティングに焦点を絞り、世界の企業を顧客としたコンサルティングを専門とする技術ストラテジストです。彼はさまざまな業界イベントで、モバイル、ソーシャル・ネットワーキング、仮想化などの新興技術に関する講演を頻繁に行っており、また『Cloud Computing Explained』(2009年)、『Cloud Computing Architected』(2011年) など、6 冊の著作があります。



2012年 11月 01日

PaaS (Platform as a Service) は一般に、IaaS (Infrastructure as a Service) および SaaS (Software as a Service) と共に、クラウド・コンピューティングによる 3 つのサービス提供モデルの 1 つであると考えられています。PaaS によって、単純でエラスティック (弾力的) なリソース割り当てや、コード・ボリュームおよびランタイム・パフォーマンスにおける効率性を実現する上で有用な各種のツールおよびサービスの提供が容易になるのみならず、ホスティング・インフラストラクチャーが提供されるため、クラウド・アプリケーションの開発も容易になります。

その一方で、PaaS という言葉で一括りにしてしまうと、クラウド・プラットフォームの多様性が隠されてしまいます。一見したところでは、Windows Azure と Google App Engine あるいは Force.com との間には共通点がほとんどありません。AWS (Amazon Web Services) は次第に IaaS から PaaS へと移行しましたが、上述の 3 つのクラウド・プラットフォームとはまったく異なる手法が用いられています。また VMware が提供するようなプライベート・プラットフォームは、さらに別のニーズに応えています。この記事では主なクラウド・プラットフォームをいくつか検証し、それぞれのクラウド・プラットフォームを使用するのが適している状況についての指針を示します。

歴史

PaaS は以下の 2 つの状況が重なった結果として生まれました。

  • IaaS はクラウド・コンピューティングに合うように最適化された特質を持っているわけではないこと。
  • Web アプリケーションが進化したこと。

インフラストラクチャー・サービスは、クラウド・ベースの環境にアプリケーションを拡張または移行しようとする顧客にとっては多くのメリットがあります。しかしインフラストラクチャー・サービスは多くの場合、デスクトップ・マシンや従来のクライアント・サーバー環境を対象に設計されたプラットフォーム上で実行されます。現在、インフラストラクチャー・サービスは仮想化されている場合もありますが、まだクラウド用に最適化されるまでには至っていない状況です。

もう 1 つの注目すべき状況は、Web ホスティング・サイトが進化したことです。GeoCities などは 1990年代半ば頃から HTML ホスティング・サービスを提供していました。しかしその後、Web ホスティング・サービスの数は激増し、Microsoft ASP.NET や Java 技術から PHP、Python、Ruby on Rails などのスクリプト言語に至るまで、サーバー・サイドの多様なアクティブ・コンポーネントがサポートされるようになりました。インフラストラクチャー・サービスと比べると、これらのプラットフォームによって各アプリケーションのストレージ要件は緩和され、デプロイメントも単純になります。


検討が必要な事項

クラウド・アプリケーションの開発者や、クラウドのマイグレーション・エキスパート、クラウドを実装する管理者が PaaS クラウドを選択する際に行わなければならない基本的な検討事項にはどのようなものがあるのでしょう。

  • オープンな PaaS クラウドなのか、専用の PaaS クラウドなのか、その混成なのか (さらには、どの程度の混成にするのか): それぞれにおいて、いくつかのコンセプトを検討すれば十分です。
  • ホスティングの構造と制約: 何をサポートし、何をサポートしないのか、など。
  • リソース割り当ての方法: 自動化レベル、手動操作のしやすさ、割り当て解除は割り当てと同程度に容易か、など。
  • データの保管機能と保管方法: 常に自動的に行われるのか、要求しない限り行われないのか、など。
  • サポートされている開発ツールや管理ツール。
  • パフォーマンスと、トランザクションの種類および量との関係。
  • さまざまなクラウド・コンポーネントのセキュリティー: セキュリティーはどのように処理されるのか。

Google App Engine

Google App Engine は最もよく知られたプラットフォーム・サービスの 1 つです。Google App Engine は基本的なランタイム環境を提供する他、何百万人ものユーザーにまでスケーリングすることが可能なアプリケーションを構築する際に伴う、システム管理や開発の難題の多くを解消します。Google App Engine には、クラスターにコードをデプロイする機能の他、監視、フェイルオーバー、自動スケーリング、ロード・バランシングなどの機能も用意されています。

Google App Engine は当初、Python ベースのランタイム環境のみをサポートしていました。その後 JVM (Java Virtual Machine) のサポートが追加されたため、Java で作成されたアプリケーションのみならず、他の JVM 言語 (Groovy、JRuby、Jython、Scala、Clojure など) で作成されたアプリケーションも実行できるようになりました。ソフトウェア開発キットには、開発者のデスクトップ・マシンで Google App Engine をシミュレートできる完全なローカル開発環境が含まれています。

プログラミング言語については多少の制約があります。例えば C モジュールや Pyrex モジュールはサポートされていないため、Python モジュールは Pure Python でなければなりません。同様に、Java アプリケーションは JRE (Java Runtime Environment) Standard Edition のクラスのサブセットしか使用できない場合があり (「参考文献」に挙げた JRE クラスのホワイト・リストを参照)、これらのクラスが新しいスレッドを作成することはできません。

リスト 1 に、Google App Engine で実行する単純な「Hello World」アプリケーションのコードを示します。

リスト 1. Google App Engine で実行する「Hello World」アプリケーションのコード
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
class MainPage(webapp.RequestHandler):
  def get(self):
    self.response.headers['Content-Type'] = 'text/plain'
    self.response.out.write('Hello, World!')
application = webapp.WSGIApplication(
                                     [('/', MainPage)])
def main():
  run_wsgi_app(application)
if __name__ == "__main__":
  main()

当然ですが、実際に必要なコードはアプリケーションによって異なります。リスト 1 の Python の例で示したように、アプリケーションのロジックがほとんどない場合の命令は単純です。SDK に含まれるモジュールをいくつかインポートし、続いてルート URL に対するすべての HTTP GET リクエストを処理する MainPage というリクエスト・ハンドラーを定義する必要があります。このハンドラーのメソッドは self.response オブジェクトを使用して HTTP レスポンスを作成します。run_wsgi_app() 関数は WSGIApplication インスタンスを引数に取り、それを Google App Engine の CGI (Common Gateway Interface) 環境で実行します。それほど要求が複雑ではない場合には、これですべて終わりです。

Google App Engine のデータ・ストアは、オプティミスティック同時実行制御を使用したクエリー、ソート、トランザクションをサポートしています。このデータ・ストアは、強力な一貫性を持った分散型データベースで、下位レベルの BigTable データ・ストレージ・システムをベースに機能を追加する形で構築されています。Google App Engine の問い合わせ言語は GQL と呼ばれ、SELECT 文は SQL (Structured Query Language) に似ていますが、いくつかの重要な制約があります。例えば、GQL では意図的に JOIN 文をサポートしていないため、1 つのテーブルに対するクエリーにしか対応していません。

Google App Engine の環境には多少の制約がありますが、豊富な API (Application Programming Interface) セットも用意されています。上記のデータ・ストア機能の他に、以下のようなライブラリー関数セットがあります。

  • 認証: アプリケーションは Google アカウントを使用してユーザーの認証をすることができます。この場合、アプリケーションは Google アカウントを使ってサインインするようにユーザーに指示し、ユーザーの認証が完了すると、e-メール・アドレスと表示名にアクセスすることができます。OpenID ユーザーも任意の OpenID プロバイダーで ID を作成し、その同じ ID を使用して Google App Engine アプリケーションに対する認証を行うことができます。
  • memcached: memcached サービスは、アプリケーションの複数のインスタンスからアクセスされるインメモリー・キー・バリュー・キャッシュをアプリケーションに提供します。このサービスは永続化機能やトランザクション機能が不要な一時データ (高速にアクセスするためのデータ・ストアのローカル・キャッシュなど) に有効です。
  • スケジュール・タスク: ユーザーは cron サービスにより、毎日、または毎時など、一定間隔で実行されるタスクをスケジューリングすることができます。さらには、アプリケーションによってキューに追加されたタスクをそのアプリケーション自らが実行することもできます。例えば、アプリケーションはリクエストを処理しながらバックグラウンドでタスクを送信することができます。

Windows Azure

Windows Azure は Microsoft の PaaS サービスです。Windows Azure は Google App Engine とコンセプトが似ており、Windows Azure を使用することにより、Microsoft の技術をベースとするアプリケーションを Microsoft のデータ・センターでホストし、実行することができます。Windows Azure のファブリック・コントローラーは、リソース管理、ロード・バランシング、レジリエンシーのための複製、アプリケーションのライフサイクル管理を自動的に実行します。

Windows Azure プラットフォームは分散型サービスとして構築されており、Microsoft データ・センターの特殊なオペレーティング・システム上にホストされています。このプラットフォームには、「Compute (コンピュート)」、「Storage (ストレージ)」、そして (プラットフォームを管理するための)「Fabric (ファブリック)」という 3 つのコンポーネントが実装されています。「Compute (コンピュート)」インスタンスは、典型的な目的に合わせて調整された構成を規定するロール・タイプとして顧客に公開されます。Web ロール・インスタンスは一般に、ユーザーとのやり取りを行い、Web サイトやその他のフロントエンド・コードをホストする場合もあります。それとは対照的に、Worker ロール・インスタンスは Google App Engine の cron ジョブと同様のバックグラウンド・タスクに対応します。

Web ロール・タイプと Worker ロール・タイプは最もよく使用されますが、Windows Azure には特定のニーズのためのテンプレートも用意されています。例えば CGI Web ロールは FastCGI プロトコルをサポートしているため、他のプログラミング言語 (PHP、Ruby、Python、Java など) を使用できるようになります。WCF (Windows Communications Foundation) サービスは WCF サービスのサポートを容易にする Web ロールです。また Windows Azure は現在、Windows Server 2008 R2 VM イメージのアップロードを受け付けるインフラストラクチャー・サービスも (VM ロールの形で) 提供しています。

Windows Azure のストレージが提供するサービスでは、以下の 3 種類のデータをホストすることができます。

  • ブロブ: ブロブは非構造化データのストリーム、つまり明確には規定できないデータのストリームです。こうしたデータは、画像の場合もあれば、ファイル、その他アプリケーションが必要とする任意のデータの場合があります。
  • テーブル: テーブルは構造化データに使用されます。テーブルには通常、一連の同質な行 (「エンティティー」と呼ばれます) が保持され、行は一連の列 (「プロパティー」と呼ばれます) で定義されます。概念としては Windows Azure のストレージ・テーブルとリレーショナル・テーブルは似ていますが、両者には重要な違いがあります。Windows Azure はスキーマを強制せず、問い合わせ言語としての SQL もサポートしていません。
  • キュー: キューはアプリケーションが非同期で通信および調整を行うためのメカニズムです。

Windows Azure の用語で言う「ファブリック」は Windows Azure オペレーティング・システムを実行する一連のマシンのことを指しています。これらのマシンは集合的に管理され、通常は同じ地域に一緒に置かれます。ファブリック・コントローラーは、すべてのユーザー・インスタンス (Web ロールと Worker ロール) をプロビジョニングし、必要なすべてのアップグレードを実行するコード・レイヤーです。ファブリック・コントローラーではアプリケーションの監視も行い、すべてのサービスを健全に維持するために必要に応じてリソースの再プロビジョニングや再割り当てを実行します。


Force.com

Salesforce.com も Force.com という PaaS を提供しています。Force.com は Google のサービスとも Microsoft のサービスとも異なる PaaS です。また Force.com はこの PaaS 技術をベースに、冗長性、セキュリティー、スケーラビリティーなどの通常の機能を備えたホスティング・サービスも提供しています。しかし Force.com はコードの処理よりも、データの処理をはるかに重視しています。

プログラムによる外部からのアクセス

Force.com は、顧客に固有の構成 (フォーム、レポート、ワークフロー、ユーザー特権、カスタマイズ、ビジネス・ロジック) をすべて、プログラムでアクセス可能なメタデータとして公開しています。Web サービス API (SOAP) を利用すると、任意の環境から Force.com アプリケーションのすべてのデータにアクセスすることができます。Force.com プラットフォームには、Microsoft .NET、Java、Facebook、Google、AWS のための開発ツールキットも用意されている他、ERP (SAP R/3 と Oracle Financials) のコネクター、デスクトップ・ソフトウェア (Microsoft Office、IBM Lotus Notes)、ミドルウェア (Tibco、Pervasive、IBM Cast Iron) もパッケージ化されています。Force.com では従来のデータベース・アクセス機能の他に、全文インデックス化機能と非構造化データの検索機能を持つ外部検索エンジンも採用しています。

Apex

Force.com アプリケーションを作成するには、グラフィカル・ユーザー・インターフェースを作成するためのフレームワークである Visualforce と、独自のプログラミング言語である Apex を使用します。Apex は Java のような構文を使用しますが、動作はデータベースのストアード・プロシージャーに非常によく似ています (リスト 2 を参照)。

リスト 2. Apex でアカウントを更新する
// This class updates the Hello field on account records that are
// passed to it.
public class MyHelloWorld {
   public static void addHelloWorld(Account[] accs){
      for (Account a:accs){
        if (a.Hello__c != 'World') {
           a.Hello__c = 'World';
        }
      }
   }
}

Force.com では以下の 3 種類のプログラム・ロジックが区別されます。

  • 宣言型ロジック (監査用ロギング、ワークフロー、承認)
  • 公式ベースのロジック (データ検証、ワークフロー・ルール)
  • 手続き型ロジック (Apex のトリガーやクラス (リスト 3 を参照))
リスト 3. Apex のトリガー
trigger helloWorldAccountTrigger on Account (before insert) {
   Account[] accs = Trigger.new;
   MyHelloWorld.addHelloWorld(accs);
}

Apex は単独のスクリプトとしてオンデマンドで実行することもでき、リスト 3 のようにデータ・イベントに対するトリガーとして実行することもできます。Apex 言語を使用すると、イベント (ボタンのクリック、レコードの更新など) や Visualforce ページにビジネス・ロジックを追加することができます。ワークフロー・ロジックは、タスクのトリガー、電子メッセージの送信、データベースの更新をすることができ、またインターネット上の任意の宛先に SOAP メッセージを送信することで外部アプリケーションとやりとりすることもできます。


Amazon Web Services

インフラストラクチャー・サービスのマーケット・リーダーであり、デファクト・スタンダードとなっているのは Amazon です。典型的なプラットフォーム・サービスと AWS (Amazon Web Services) との主な違いは、Amazon が特定のランタイム環境を確立しない点です。ユーザーは Amazon が作成したマシン・イメージの 1 つを使用することができますが、それらに限定されるわけではなく、ほとんどすべてのプラットフォームを Amazon の環境で実行することができます。

このことからわかるように、Amazon は VM を管理、配布するための手段を提供していますが、アプリケーションを管理するための特定の機能を直接提供しているわけではありません。

図 1 は Amazon EC2 (Amazon Elastic Compute Cluster) のインターフェースの例を示しています。

図 1. Amazon EC2
Amazon EC2 のインターフェースを示す図

AWS のコア・コンポーネントは、Amazon EC2 とその補助的なストレージ・サービスです。Amazon EC2 では、ユーザーは共有の仮想環境でインスタンス化することが可能な VM テンプレートを選択することができます (図 1 を参照)。各 VM は「AMI (Amazon Machine Image)」と呼ばれます。Amazon AMI には永続ストレージがありませんが、インスタンスがアクティブな間、Amazon AMI をログや処理結果、中間データなどを格納するために使用することができます。AMI によってローカルでマウントされるディスクは各インスタンスの間で失われるため、Amazon は 2 つの永続ストレージ機能を提供しています。その 2 つのうち、Amazon S3 (Amazon Simple Storage Service) はキー・バリュー・ストアを実装し、Amazon EBS (Amazon Elastic Block Store) はファイルシステムのベースを提供します。

より構造化されたデータの保存には、一般的なクエリーのための Amazon SimpleDB や、クラウド内でリレーショナル・データベースをセットアップ、操作、スケーリングできる機能を備えた Web サービス、Amazon RDS (Amazon Relational Database Service) を使用することができます。

計算とストレージの他に、Amazon は一連の付加価値サービスとして、コンテンツ・デリバリー、キューイング通知、ロード・バランシング、自動スケーリング、プロビジョニング、監視などのサービスも提供しています。

PaaS をフルサポートするために Amazon が行った最も大きなことは、AWS Elastic Beanstalk をリリースしたことです。AWS Elastic Beanstalk は Java 開発者をターゲットにしたサービスであり、Apache Tomcat ソフトウェア・スタックの上に構築されています。顧客は、AWS Management Console、AWS Toolkit for Eclipse、Web サービス API、またはコマンドライン・ツールを使用して、標準的な任意の Java Web アプリケーションのアーカイブ・ファイルを AWS Elastic Beanstalk にアップロードすることができます。


VMware

プライベート・データ・センターにアプリケーションをホストすると、最大限の制御が可能になると同時に、最大限の柔軟性を得ることができます。必要な任意の Web フレームワークを備えたハードウェアを選択し、そこに Apache または Microsoft IIS (Internet Information Services) をインストールすると、自分の環境で開発したアプリケーションをアップロードできるようになります。プログラミング言語は自由に選択することができ、レガシー・システムやパートナーのシステムへの接続に必要な任意のインターフェースを完全に自由に実装することができます。必要なことは、PHP、Python/Django、Ruby/Rails、または完全な Java ツール・セットをインストールすることのみです。最大の欠点は、クラウド・コンピューティングに関連するメリットが自動的に得られるわけではないことです。クラウド・コンピューティングの多くのメリットを内部で再現することはできますが、そのためには大企業以外には非現実的な相当量の作業と一定レベルの投資が必要です。

プライベート・クラウドを実装することを選択した場合には、パフォーマンス、使用率、自動化におけるメリットを実現する上で、特定のツール、製品、サービスが役に立つ場合があります。VMware の仮想化技術の強力なポートフォリオは、こうした要件に対処する上で役に立ちます。

VMware のクラウド指向アクティビティーの大部分は VMware vCloud イニシアチブの下で実行されています。vCloud は、VMware vSphere、vCloud API、vCloud サービス・プロバイダー・エコシステムなどの一連の実用化技術を表します。VMware の旗艦製品である vSphere プラットフォームは、内部ネットワークと外部ネットワーク両方のソフトウェアとハードウェアを含む、インフラストラクチャーの大規模なプールを管理できる仮想化フレームワークです。vCloud API はクラウド内で仮想リソースを提供し、利用するための RESTful なインターフェースです (REST: REpresentational State Transfer)。この API により、プライベート・クラウド、パブリック・クラウド、ハイブリッド・クラウドの仮想ワークロードをデプロイおよび管理することができます。さらに、仮想アプライアンス (vApp)、仮想ネットワーク、「仮想データ・センター」をアップロード、ダウンロード、インスタンス化、デプロイ、操作することもできます。vCloud API の主要コンポーネントは、主に vApp のプロビジョニングを行うための User API と、主にプラットフォームやテナントの管理を行うための Admin API の 2 つです。

vCloud サービス・プロバイダー・エコシステムは、ビジネスやサービス・プロバイダーのためのクラウド・コンピューティング・サービスの共通セットであり、任意のアプリケーションやオペレーティング・システムをサポートし、アプリケーションの実行場所 (オンプレミスまたはオフプレミス) を選択することができます。このエコシステムは Terremark や Hosting.com などのサービス・プロバイダーによって提供され、仮想アプライアンスとして利用可能な一連のアプリケーションを含んでいます。これらのインフラストラクチャー指向のサービスの他、VMware vFabric は Spring Java 開発フレームワークと一連の統合サービスとを組み合わせ、アプリケーション・サーバー、データ管理、クラウド対応のメッセージング、ロード・バランシング、パフォーマンス管理などの実用的なプライベート・プラットフォーム・サービスを提供します。


IBM SmarterCloud Application Services

パブリック・クラウドのメリットを活用したいものの、オンプレミス・アプリケーションにはセキュリティー、カスタマイズ、そして統合に関するエンタープライズ・クラスの要件がある顧客のために、IBM は IaaS (IBM SmarterCloud Enterprise) と PaaS (IBM SmarterCloud Application Services) を提供しています。IBM SmarterCloud Application Services は IBM SmarterCloud Enterprise に仮想リソースを自動的にデプロイするため、この 2 つは密接に関連しています。これらのサービスを利用することで、アプリケーションの開発から、デプロイメント、そしてデリバリーまでのライフサイクル全体を迅速に行えるようにサポートする、セキュアかつコラボレーティブなクラウド・ベースの環境を実現することができます。図 2 は IBM SmarterCloud Application Services のインターフェースの例を示しています。

図 2. IBM SmarterCloud Application Services
IBM SmarterCloud Application Services を示す図

IBM SmarterCloud Application Workload Services には、IBM Workload Deployer で最初に導入された高度なパターン技術が含まれています。この高度なパターン技術により、専門家の知見を反映したパターンを容易に作成、デプロイ、管理することができます。専門家の知見を反映したパターンは、長年の経験に基づいて、特定のソフトウェア・ソリューションに対するベストプラクティスの実装、構成、管理、監視といった機能を具体的に表現したものであり、IBM や独立系ソフトウェア・ベンダーによってオンライン・カタログの中で提供されています。専門家の知見を反映したパターンは、迅速に価値を提供できるように単純化されていると同時に、一貫性のある予測可能な結果を保証しています。IBM SmarterCloud Application Workload Services に用意された統合ツールを使用することで、専門家の知見を反映したカスタム・パターンを顧客が作成することもでき、それらのパターンを顧客の組織全体で共有することもできます。

この高度なパターン技術は、以下に記載する IBM の新しい PureSystems 製品ファミリーにも含まれています。

  • IBM PureApplication System: トランザクション型の Web アプリケーションやデータベース・アプリケーションとそのワークロードに対応して専用に設計、調整されたプラットフォーム・システムです。
  • IBM PureFlex System: ストレージ、ネットワーク、RAS、インストール、セキュリティーに関係するタスクの管理を支援するパターンが含まれたプラットフォームです。

標準化と移植性

この記事で説明したプラットフォームには、それぞれに魅力もあれば欠点もあります。開発者にとって最大の難題は、これらのプラットフォームが非常に異なるという事実です。ある 1 つのプラットフォームで開発されたアプリケーションは、別のプラットフォームでは簡単には動作しません。

顧客の投資を抑え、ロックインのリスクを減らすために、仕様の統一が強く要求されており、その要求は一層高まっています。また多くの標準化団体が、それぞれの団体の観点からクラウド・コンピューティングに取り組んでいます。最もよく知られたイニシアチブは IaaS に関するものですが、PaaS としての要件を満たす機能も徐々に追加されています。大まかに言えば、これらのイニシアチブは 2 つの異なる手法を採用しています。

  • Eucalyptus と CloudStack は AWS と互換性があり、Amazon とのハイブリッド・クラウドを実現することができます。Amazon を選択すると、インターフェースが十分に理解されているというメリットがあり、また AWS にはリソース需要の一時的な急増を吸収できるだけの巨大なキャパシティーがあります。ただし、Amazon が API を所有し、API の開発が Amazon の意のままであるということは、このプラットフォームは完全にはオープンではないということを示しています。
  • OpenStack は、(IBM を含む) 業界リーダーによる広範なコンソーシアムが共同で出資をしているオープンソース技術プロジェクトの集合で、大規模なクラウドを編成するための運用プラットフォームを提供します。OpenStack はハイパーバイザーに依存せず、また標準的なハードウェア上で VM をプロビジョニングするためのソフトウェアを含んでいます。OpenStack は処理能力のプールを提供する他、分散型オブジェクト・ストアやスケジューラー、ネットワーク・コントローラー、認証マネージャーも提供します。

まとめ

これらの標準イニシアチブが成熟するのに伴い、この記事で説明したようなそれぞれのプラットフォームに独特の性質の多くが明らかにされ、それらに代わる業界標準のプラットフォームの概念が登場するのを期待できるようになります。それまでの間は多種多様なプラットフォームやスタックで凌しのがなければなりません。

それぞれのプラットフォームには長所と短所があるため、顧客はプログラミング言語や開発ツールの観点から、さらには接続性、スケーラビリティー、セキュリティーに関連するインフラストラクチャーの依存関係の観点から、自らの要件を詳細に検討する必要があります。幸いなことに、選択肢が多いことから、自分達に適したものを見つけられる可能性は高くなります。ただし残念なことに、顧客は選択をする必要があり、その選択は必ずしも容易ではありません。

参考文献

学ぶために

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

  • 皆さんに最適な方法で IBM 製品を評価してください。製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

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=Cloud computing
ArticleID=843118
ArticleTitle=ニーズに合った最適な PaaS クラウドを選択する
publish-date=11012012