AppHarborを使用してみた感想

ASP.NET AppHarbor PaaS

AppHarborとは？
AppHarborとは.NETで開発したアプリケーションで利用するする事が出来るPaaSサービスのこと。
EC2上で動作しており、Herokuをかなり意識している。

AppHarborの特長
アプリケーションを書き換えることなくPaaS上にデプロイすることが可能。
ソースファイルの送信にはGitを使用する。
AppHarbor側でビルド・コンポーネントテストを行ってくれる。（ビルド・コンポーネントテストで失敗した場合はデプロイされない。）
アドオンと呼ばれる外部サービスを利用することが可能。（利用の形態によっては課金される。）（アドオンを開発することも可能）
1インスタンス目は無料(これ重要)
ポータル管理画面でアプリケーションのバージョン管理が行える。（ボタン一つで異なるバージョンをデプロイすることが可能）
インスタンス数を増減させることができる。

開発環境の構築

  • Visual Studio（.NETでの開発で使用）
  • Git（AppHarborにソースファイルを送信するのに使用する）

Windows Azureとの比較
デプロイ

    1. デプロイに必要な時間

Windows Azureに比べ、デプロイにかかる時間が短い。（Azure:約10分に対し、AppHarborは約3分）

    1. デプロイ（送信）する対象

Windows Azureはアプリケーションをパッケージ化したものなのに対し、AppHarborはソースファイルそのものを送信する。


コンポーネントテスト
Windows Azureはローカルでの実行。AppHarborはローカルでの実行とデプロイ前に行われる実行。（いわゆる本番環境でのコンポーネントテスト）

ステージング
Windows Azureではステージング環境が用意されている。AppHarborでは、用意されていない。常にデプロイされてしまう。

アプリケーションのバージョン変更
Windows Azureではステージング環境と本番環境をスイッチすることで変更する。AppHarborでは複数のバージョンの中からデプロイしたいバージョンのものを選択し、デプロイする。

ドキュメント
Windows AzureではMSDNを中心としてドキュメントも充実している。AppHarborは肝心なことが書かれていないという印象がある。無論、日本語でのドキュメントは皆無。

セキュリティ
SQL AzureではIPのアクセス制限をかけることが可能だが、AppHarborのアドオンであるSQL Serverはサーバー名、ユーザー名、パスワード、コネクションストリングのみが発行される。よって、コネクションストリングをのみによるアクセス制限となる不安。
ちなみに、違うアプリケーション（AppHarbor外のアプリケーション）からコネクションストリングを指定して使用することが可能であった。（他のアドオンについては未検証）

使ってみた感想

Good

  • アプリケーションのバージョンをPaaSのサービス側で管理してくれるのは有難い。
  • Windows Azureでは発見できなかったコンポーネントテストの失敗を発見できた。（カルチャーに依存するテストに関しては海外のデータセンターを使用するということで注意が必要。
  • Azureではローカル環境でコンポーネントテストを行うため、失敗しなかった。）
  • デプロイの早さはピカイチ。

Bad

  • 初めて使用したこともあり、Gitに壁を感じた。
  • （調べ足りないのかもしれないが、）欲しい情報が掲載されていない。.NETのバージョンやIISのバージョン、アドオンのバージョンなどなど。
  • デプロイしたアプリケーションがいきなり公開になるのは微妙。
  • SQL Serverのアクセスの問題（上述）により業務アプリケーションをデプロイするには危険。


余裕を見て、AppHarbor実践編を書きたいものです。