GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 David West , 翻訳者 渡辺 裕之 投稿日 2009年2月10日
Sunによる最近の従業員解雇(OpenJDK、JCP、J2SE、そしてデスクトップJavaに従事している人々(リンク)に影響があるということである)及び、Sunが最近クラウド基盤のベンダであるQ-Layerを買収したことで(リンク)、Sunはどのようにして企業戦略の方向性を再定義するのか、そして数多く抱えている技術要素の中でどれに注力していくのかということに関する議論が活発化している。SunはJavaのコミュニティと不可分であるが、Sunの最近の財政面、事業規模の縮小、そして株価の推移に関する問題が心配の種となっている。昨秋、Tim Bray氏が "What Should Sun Do(リンク)(Sunはどうするべきか)?"という記事によってSunの将来の方向性に関する議論の封を切った。他では主にIan Skerrett氏 (リンク)、RedmonkのStephen O'Grady氏(リンク)、BloggingRoller(リンク)を公開しているDave Johnson氏、そしてTerrence Barr氏 (リンク)が議論に加わっていた。
全員がSunには巨大でエキサイティングな技術的資産があることを認めた - それらの現状を考えるとあまりに大き過ぎて、もはやそれらを管理することも開発促進していくことも出来ない状況であるが。さらに、それら技術的資産の中から一部に注力することでSunは利益を得ることが出来るだろうということにも全員が同意した。では、どの部分に注力するべきなのか?
Tim氏はSunに"Sun Web Suiteを構築することに注力してWebアプリケーションをデプロイする基盤の最有力候補となるように"させたいと思っている。この選択によりSunは現在保有しているハードウェア、OS、HotSpot、JVM、そして(例えばGlassFishやMySQLのような)サーバ・サイドの技術を保有し続け、Tim氏がSunでは競争に勝てないと考えている(JavaFXのような)クライアント・サイドの技術やNetBeans、同じようにWebの関係しない技術などは捨てることになる。さらにTim氏はちょうどIBMがEclipseを手放したのと同じようにSunがJCPを手放すことで"Javaの世話役"という役割も終えさせたいと思っている。
Terrence Barr氏はTim氏の忠告の大部分、とりわけクライアント・サイドの技術を放棄することに反対している。Terrence氏はクライアント・サイドの技術はSunを際立たせ、新たな売上を生み出す可能性のあるその他の膨大な技術に人々を向かわせると信じている。
Ian Skerrett氏とStephen O'Grady氏はSunのマーケティングと企業文化を見直すことについて論じている。ビジネスにつながるようないい仕事をすべきであると強調している。改革ではなく、技術と工学的な文化によって会社はよい方向に向かうとしている。10年前にIBMが似たような問題に直面した際に倣って、ビジネスにつながるようないい仕事をする方法を見つけ出すべきである。
Tim氏とStephen O'Grady氏はクラウド・コンピューティングに対するSunの関与の問題を提起している。昨年クラウド・コンピューティング部門を設立したにもかかわらず、この領域では現在Sunの技術的な強みは何もない。まず始めにTim氏はクラウド・コンピューティングに関して不明な点を挙げている。
- AmazonのAWSのように仮想ハードウェアという次元で運用したらいいのか、それともGoogle App engine(やPHPコミュニティに現存するもの)のようにPAAS(サービスとして提供されるプラットフォーム)という次元で運用したらいいのか。
- 利用者はそんなにも多くの(ベンダ)ロック・インを許容するだろうか、それとも一切の壁を取り除くことを要求するのだろうか。
- エンタープライズ・アプリケーションをデプロイしている人達は外部のクラウドにデータを預けることを望んでいるのだろうか。もし望んでいるとするのなら、どのようなプライバシーの保証を望んでいるのだろうか。
- エンタープライズ・アプリケーションをデプロイしている人達は内部にクラウド基盤のようなものを構築したいと思うだろうか。
これらの不明点を挙げながらもTim氏は以下のように結論付けている。
"今現在私たちは以下のことを知っています。クラウド・コンピューティングに関するビジネスの主旨はとても魅力的に思えます。Sunがクラウド・サービスの大規模なサプライヤとして成功するとは思えませんし、そうなる必要もないと思います。ただ、とにかく前進しどうにかしてクラウド基盤を構築・運用して利益を上げられるようにする必要があると確信しています。そうすれば、(クラウドという)エコシステムの形がはっきりした時にその姿を理解し、その中にWeb Suiteを組み込んで販売することが出来るでしょう。"
Stephen O'Grady氏はTim氏の主張に対してSunはこの分野のプレーヤーとなるべきであるという提案をしている。(Google、Amazon、Microsoftといった)透明性、日用品、ハードウェアのオプションに従事している現在のクラウド・ベンダの特性を考えるとSunはこの市場において有力なサプライヤに数えられることすら難しいと考えている。要するにSunがこの分野で活躍するには独自のプラットフォーム上でクラウド・サービスを提供するのが唯一の道だということである。
SunによるQ-LayerとそのソフトウェアNephOSの買収によって同社は一部のクラウド技術を手にしたことになる(そしてこれは仮想ハードウェアという形態で運用したらよいのかというTim氏の疑問への答えも示唆している)が、買収自体はクラウド戦略や方向性のヒントとなるものではない。Sunのクラウド・コンピューティング部門におけるマーケティング分野のVP(副社長)であるCarlos Soto氏は、"Sunは買収をした日にクラウド・コンピューティングに関する発表を行える状況にはなかったが近日中に何かしらの発表を行うだろう"と言及している。
クラウド・コンピューティングの分野を除けば、Sunの研究・開発計画にどのよなものが含まれているのかを探るために同社のこれまでの製品ラインアップにあった技術に言及する人は誰もいなかった。例えば、SunのLively Kernel(リンク)はSunの提供するクライアント・サイド技術を再定義する可能性を秘めているし、今までのところ一切進出できていない市場に浸透するかもしれないのである。
あなたはSunに何を望むだろうか。
原文はこちらです:http://www.infoq.com/news/2009/02/sun-future
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信