.NET アプリケーションをホストする PaaS プロバイダである AppHarbor が アドオン API を発表した。サードパーティのサービスプロバイダを対象とした Self-Service Portal を提供する。開発者は統一されたインターフェースを通じてクラウドサービスを購入し，AppHarbor プラットフォーム上に構築するアプリケーションにその機能を追加統合することができる。開始時点のカタログには Memcacher，MongoHQ，Cloudant，Redis To Go，MailGun などが挙げられている。
InfoQ では AppHarbor の共同創立者である Michael Friis 氏にコンタクトを取り，より詳細な情報を聞くことにした –
InfoQ: サードパーティの開発者が AppHarbor で使用されるアドオンを登録することは可能ですか？ 今回のサービスは，発表されたアプリを当初提供サービスとする，いわゆるマーケットプレースなのでしょうか，あるいは閉鎖的なストア形式ですか？
Michael: 当然，自由参加型のオープンなマーケットとして考えています。開発者に提供する前にアドオンをテストしたいとは思っています (おそらく最初はベータユーザに提供することになるでしょう)が，プラットフォームにアドオンを提供してくれる人たちに，それ以上の制限を課そうとは思っていません。ここで言うオープン性には，プラットフォーム上で複数のプロバイダが，同じ種類のサービスを提供することも含んでいます。例えば２つのアドオンプロバイダが MongoDB のホストを提供している，というようにです。アドオン API の資料は公開されています (アドオンプログラムは Heroku と同じ方法で動作します)。
InfoQ: AppHarbor を使用する開発者が，これらアドオンのテストを (おそらくはサンドボックスを使って) 記述することはできるのでしょうか？
Michael: アプリケーションに追加したアドオンを使うテストを書くことは，技術的には可能です。ただし推奨はしません –– 理由のひとつは，テストがデプロイされたアプリケーションと同じアドオンリソースを使用することになるからです。
一般的には，外部依存部分のモック(mock)を作る方法を推奨します。簡潔さ，実行スピードの向上，さらにユニットテストでのセットアップやティアダウンを複雑にしなくて済むからです。
InfoQ: API のアップグレード時に (既存のデプロイで) テストがパスしなくなった場合には，どのように対処すればよいでしょう？ そのアカウントの持ち主を知る方法はありますか？
Michael: アドオンプロバイダの提供するサービスは，一般的によく理解され，十分に定義されたものです (例えば MongoDB データベースの接続文字列や Memcached バケットのように)。開発者がアドオンを登録するとき，アドオン API を通じて提供されるものは，アドオンリソースへのアクセスに必要なアドレス，あるいは認証の情報といったものになります。アドオンプロバイダの定義に従った適切な API を利用してリソースにアクセスするのは，アプリケーション開発者の責任です。
InfoQ: 私たちはインスタンスが何を意味するのかについて，まだ完全には把握していません – コンピュータパワーなのか，あるいは RAM なのか。これについて説明して頂けますか？
Michael: ひとつのインスタンスがどれ程の量のリソースを消費するかは，まだ正確に決定できていません。計算能力に関しては，EC2 計算ユニットのごく一部という程度になるでしょう –– 現状では 1 ECU (EC2 Computer Unit) より少し小さい程度です。
InfoQ: AppHarbor のデプロイに提供される SLA はありますか？
Michael: プラットフォームユーザが求める SLA については現在，綿密な打合せをしているところです。SLA が .NET を使用する多くの開発者や企業にとって重要であることは十分認識しています。
AppHarbor のプラットフォームは，Git – さらに Mercurial – を利用可能な継続的配信環境へのアクセスを .NET 開発者に提供して，アジャイルチームや新興の企業では標準的な高速ビルド (rapid build)，テスト，デプロイワークフローなどをサポートする。自動ユニットテスト環境も用意されていて，開発者はデプロイあるいはロールバック前にコードをテストすることができる。AppHarbor にホストされているアプリケーションの新バージョンのデプロイは，通常はわずか 15 秒で完了する。