既存のアプリケーションをAzureに移植する際の課題は何ですか？
ここに私がすでに知っているいくつかのポイントがあります。
1）セッションアフィニティがサポートされていない（Azureはステートレス）-Azureの負荷分散がセッションアフィニティをサポートしていないことを認識しています-したがって、既存のWebアプリケーションがセッションアフィニティを持っている場合は変更する必要があります。
2）COMとのインターフェース-現在、現在のアプリケーションがいくつかのレガシーコンポーネントにアクセスする必要がある場合、COMコンポーネントをクラウドにデプロイしてそれらとインターフェースすることはサポートされていないと思います。
3）http以外のプロトコルを使用したクラウドからの他のシステムとのインターフェース
上記の点以外に、あなたが知っている他の重要な制限/考慮事項は何ですか？
また、これらの問題点は最新リリースでどのように対処されていますか？
私たちの最大の課題は、クラウドのステートレスな性質です。私たちは本当に一生懸命努力しましたが、状態の一部がコアに忍び寄り、これが対処されています。
次の課題は、データが一度に数週間オフラインになる可能性があるため、古いデータとキャッシュのサポートです。これは関係なく難しいです。
今日のAzureでの私の最大の問題は、他のOSとの操作性です。ここでは、AzureをEC2 / Rackspaceインスタンスと比較しています（PAASとしてのAzureは、負荷分散、ストレージレプリケーション、地理的デプロイなど、単一の安価なパッケージでそれらよりもはるかに多くの機能を提供します）。
私をBizSparkのスタートアップ企業と見なしても、BizSparkプログラムの3年後に負担しなければならない価格設定ポリシーを受け入れることができないため、データベースをSqlAzure（Sql2005と同等）で実行する傾向はありません。現在、MySqlやその他のデータベースのオプションはありません。これは私にとって中小企業にとってばかげています。EC2を使用すると、MySqlインスタンスを別のLinux VMで実行できます（明らかに同じネットワーク内です。Azureは外部のネットワークに接続する機能を提供しますが、実際にはオプションではありません）
2番目。これも*nixマシンの使用に関連しています。すべてのキャッシュをMemcachedで維持したい。asp.net 4を使用すると、拡張可能な出力キャッシングを通じて、すぐに使用できるmemcachedサポートも提供されます。memcachedに固執する理由は、memcachedが提供するエコシステムです。例：今日、アドオンとして永続キャッシュを使用してmemcachedを取得できます。これにより、memcachedを使用してセッションデータを保存する機会も得られます。さらに、IISログでマップリデュースジョブを実行できます。これは、EC2のclouderaイメージを使用して行われます。Azureでこれらを実行する方法がわかりません。
ご覧のとおり、Amazon / Rackspaceの場合、asp.netWebアプリをWindowsServer 2008の単一インスタンスで実行し、残りを*nixマシンで実行できます。
非階層データ（Webアプリのメニュー項目）をCouchDbで実行することを検討しています。Azureを使用すると、 Azureテーブルを取得できます。しかし、私はそのATMにあまり満足していません。EC2を使用すると、同じMySqlボックスで実行できます（これで私を捕まえないでください:-)）。
これらの問題を忘れる準備ができている場合、Azureは、多くの不平を言う作業が抽象化された環境を提供します。そして、それは素晴らしいことです。スケーリング、負荷分散、非常に安価なストレージ、CDN、ストレージレプリケーション、FabricControllerなどを介したサービスのすぐに使用可能な監視。EC2 / Rackspaceを使用すると、これらのことを行うために$ 150k PAをシェルするシステム管理者を雇う必要があります（AFAIK Amazonはこれらの機能の一部を追加料金で提供します）。
私の比較は、azureインスタンスとAmazon / Rackspaceインスタンス（クラウドではない）の間です。一部の人にとって、これはリンゴとオレンジのように見えるかもしれません。ただし、azureはインスタンスを提供しません。カスタマイズされたサービスを備えたクラウドだけ…</p>
長い展開プロセスに備えてください。現時点（PDC 2009より前）では、展開パッケージのアップロードとホストサービスの起動に30分以上かかることがあります（時刻、パッケージのサイズ、役割の数などによって異なります）。
これの副作用の1つは、web.configファイルで構成を変更すると、アプリパッケージ全体を再パッケージ化して再デプロイする必要があるため、コストがかかることです。構成設定の代わりにAzure構成ファイルを利用します-ホストの一時停止/再起動を必要としないためです。
私の最大の問題は、サインアップしてプロジェクトを作成することでした。そして、それは先月それがどこまで進んだかです。
私が何か非常に悪いことをしている、またはそのサイトはほとんどの場合壊れています。
重要な課題の1つは、学習曲線、経験豊富な開発者の不足、生産性を高めるのにかかる時間です。
これはすべてのテクノロジーで発生しますが、クラウドでは、何かが行われる方法に根本的な変化があります。
アプリケーションにデータベースが必要な場合、Windows Azureにリレーショナルデータベースがあるかどうかはわかりません（現在）
また、仮想マシンを構成する際により多くのオプションを提供できる他のクラウドコンピューティングプロバイダーがあります。たとえば、実際に必要なものと必要なものによって異なります。