Windows Azure導入までの検討経緯

次に問題になったのが、どのプラットフォームを採用するべきかという点である。当時有力だった、Salesforce、Amazon Web Service(AWS)、Windows Azureについて調べ、そのメリット/デメリットを検討していった。

Salesforce CRMの検討

まず候補に挙がったのが、パブリッククラウドでも比較的導入実績の多かった米Salesforce.comのSalesforce CRM(以下、Salesforce)だ。半年前に別のプロジェクトで導入していたこともあり、導入の手順やコスト感もほぼイメージできていたため、自然に筆頭候補に挙がった。

まず、Salesforceでプロトタイプを作成してみた。主要画面のみではあったが、約1週間でプロトタイプを作成でき、システムのイメージや要件も明確になった。このように実物で検証できる点はSaaSの最大の強みだろう。しかし、今回のケースでは標準機能だけでは業務上重要な処理が実行できないことが判明し、比較的大がかりなカスタマイズが必須となった。

Salesforceをカスタマイズするための独自言語であるAPEXや、社内システムとしては避けて通ることのできない、マスタデータを中心としたオンプレミスとのデータ連携にも障壁があり、このプロジェクトにとってはSalesforceは敷居が高いソリューションとなってしまった。

また、Salesforceの課金方式は基本的にユーザ数に応じた体系であるため、数百人から数千人が利用する可能性があるこのシステムでは相当の利用コストを覚悟しなくてはならない。この面でも有力候補からは外さざるを得ない状況となった。

Amazon Web Serviceの検討

次に検討したのがAWSである。当時は発表されていなかったAWS Elastic BeanstalkどころかRDS(Amazon Relational Database Service)も発表直後であったため、いわゆるIaaSとしてのサービスである「Amazon EC2/S3」を使ったアーキテクチャが検討の対象となった。

AWSは、ハードウェアの導入が不要であることやスケーラビリティの面では魅力的なソリューションであったが、IaaSであるがゆえに一定の基盤構築作業は避けられず(現在はかなり軽減されてはいるが)、アプリケーションの開発に集中するためにはオーバーヘッドが大きいと判断せざるを得なかった。