今日のつぶやき
[Twitter]今日のつぶやき ff.im/ck55L #
結構いい感じのところまで来てる。今度試してみよ。『Windows Azure Tools for Eclipse』 ff.im/clvVQ #
AppEngineとAzureをマッシュアップしたアーキテクチャが面白そう。social系、mobileの受け口など、スケールさせたい所はAppEngine、企業システムとのつなぎはAzureとか。 #
もちろん、AppEngine単体、Azure単体でもシステム構築はできると思うけど、性能特性やスケーラビリティ特性、コスト特性などの要因でマッシュアップした方がよい場合も多々あるはず。 #
開発要員のスキル・セットも重要な要因になる。JavaエンジニアがAppEngineとAzureのサービスを同じ技術(Eclipse+Java)で開発できると、開発部隊運用の選択肢が広がる。 #
開発要員のスキル・セットも重要な要因になる。JavaエンジニアがAppEngineとAzureのサービスを同じ技術(Eclipse+Java)で開発できると、開発部隊運用の選択肢が広がる。 ff.im/clAdT #
AppEngineではServletの上でRESTサービスを構築する。生ServletとRESTの間はやや距離があるので作り込みが必要。JAX-RSがAppEngineの上で動けばこの問題は解決される。 #
AzureではWorkerRole上でAppFabric(.NET, WCF) Service Busを使って、.NETサービスをRESTサービスとして公開する、というのが一つの形かなと考えている。 #
Web UIはAppEngine、AzureのいずれもAjax RIAからWeb MVCまで色々な選択肢があるので、好きな技術を選ぶ。 #
Web UIは好きな技術ドリブン。
サービスはRESTとしてAppEngine、Azureのどちらでも同じように構築できる。プラットフォームの性能特性、スケール特性、コスト特性、運用性、SLAなどが重要な選択要因。 #
サービスを束ねてアプリケーションとして構築する機構は、もう少し考えてみたいところ。Service BusになるのかApache Camel的なIntegration Frameworkになるのか。
Security, Transactionも重要な要因。 #
Java系(Eclipse)、.NET系(VS)、LAMP系(LL)、レガシー系(COBOL、昔のVB)、デザイナー系(Flush)のエンジニアが、それぞれ、どのプラットフォームに落ち着くのか、というのもクラウド時代の方向を決めるポイント。 @myen #
データはRDBMSとNoSQLが共存時代が当面続く。ドメイン・モデルを用途に応じてRDBMSとNoSQLに落とし分けて、アプリケーションでマッシュアップするアーキテクチャになる。モデリング技術はこの問題を扱わなければならない。 #
NoSQLはスケーラビリティ前提なので、関数型など大規模演算の方式との親和性がデータ設計に効いてきそう。 #
BASEによるトランザクションでは、トランザクションを集中管理できないので、各エンティティが自らの責任でトランザクション断片を管理する方式になるかもしれない。エンティティが自立的に状態機械として振舞うというモデルを、ドメイン・モデルでも扱う必要がある。 #
そんなん言うても、困るやんか。
エラいことがおきましたな。
エエこっちゃ。
賢いなー、Google日本語入力
Tabで選べるのがまた良い。 #
うわ、こういうのも出てるのか。『AppFabric for Java Developers』 ff.im/cme0o #
AppFabricのService BusとAccess ControlにJavaでアクセスできるのはかなり大きい。AppEngine上で動作するサービスがAzureのサービスと簡単に連携できるようになるはず。 #
Javaで開発したサービスを、直接AzureのWorkerRole上で動作させるのも簡単にできるようになるし、EC2上のWindows Serverで動作させることもできる。性能特性やコスト特性でプラットフォームを選択できるのは大きなメリット。 #
Automatically shipped by LoudTwitter