GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Boris Lublinsky , 翻訳者 和智 右桂 投稿日 2009年6月1日
6ヶ月ほど前、Anne Thomas Manes氏は最初のSOAの死滅に関する記事を書き、InfoQでの熱い議論と多くのブログやTwitterでのつぶやきが引き起こされたのだが、その彼女がSOAに関する見解をさらに強くした。
Anne氏の記事はSOAに関する自身の立場を説明する所から始まっている。
用語としての「SOA」はその輝きを失いましたが、実践としての「SOA」はあらゆる組織が前に進む上で本質的なものです。多くの組織がSOAに対して多額の投資を行いましたが、そこから得られた利益はほとんどありませんでした。さらに組織によっては赤字になっているところもあります。厳しい経済状況にあっては、ビジネスを行う人々が、沈みゆく船に見えるものにより多くのお金を注ぎ込みたいと興味を持つことはまずないでしょう。今年、SOAの第一歩を踏み出すための予算を確保しようと思うのならば「SOA」という単語の使用を避け、その代わりに「サービス」を構築することで、ビジネスに計測可能な価値を提供するよう努力することに焦点を当てるべきでしょう。
Anne氏はSOAがまだ死滅していることを証明する上で、最近のGartnerの調査に言及している。調査によると利用者の40%が、SOAに対する投資から利益を得るのにどれほど時間がかかるのか分かっていない。また、まだSOAに着手していない企業の50%はその理由として、SOAのビジネス的な価値を明確に示すことができなかったことを挙げている。価値を計測する手段が無ければ、SOAへの第一歩は失敗する運命にあるのだ。それに加えて、SOAはアナリストやソフトウェアベンダによってあまりにも誇張されすぎてしまっているため、以下の事態が起きる。
(前略)多くの企業はSOAにアプローチする時に過剰な期待を抱き、なんらかの利益を得るためには必要になる努力、リソース、時間についてほとんど気にかけないのです。
SOAの死滅を示すさらなる兆候は、Anne氏によれば、SOA(SOA基盤)に対する企業の支出に基づいている。
- Gartnerはちょうど最近、アプリケーション統合およびミドルウェア (AIM: Application Integration and Middleware)市場に関する年間アセスメントを公開しましたが、そこでは2008年における1けた台の成長が示されています。Application Development Trends誌のレポート「ミドルウェア市場は2009年に失速する」についてのレビューによると、Gartnerは今年のAIM市場について0.8%の後退を見込んでいます。
- (前略)Report Buyerによる市場研究によれば、IBMがSOA基盤市場の70%を保有していますので、IBMの売り上げはSOA基盤市場に関する極めて優れた指標になるでしょう。そして、IMPACTにおけるJames Governor氏のつぶやきによれば「GMのRobert LeBlanc氏が言うには、ソフトウェアの売り上げを見ると、現在顧客はSOAを以前よりも細かく購入していることが分かる」とのことでした。(なお、私は「SOAの購入」を「SOA基盤ソフトウェアの購入」と解釈しています。ご存知の通り、SOAを購入することはできませんから。)
Anne氏によるこの記事は、最初の記事と同じように少なからぬ反応を引き起こしている。例えば、Pierre Fricke氏は記事に対するコメントとして次のように書いている。
思うに、不景気の最初の波がビジネスの支出に与えているごく普通の衝撃が「SOAは死滅した」と表現されているのでしょう。(中略)現金が枯渇し、資金の流れが劇的に遅くなれば、支出は頭打ちになります。(中略)SOAは重要な取り組みであり、この最初の波によって影響を与えられるだろうと考えられます。各企業は一段落したところで自分たちのほこりを払い、ビジネスを遂行し、かつて無いほどの競争力を身につける必要があると気づいています。(中略)フィナンシャルサービス産業がSOAとBPM/BRMSプロジェクトに目を向けて準備を始めているのは興味深いことです。(中略)きちんと正当化されていない、あるいは考え尽くされていないような、予算のないSOAプロジェクトを見て、組織がSOAを実現しようとしていない、もしくはSOAは死滅したと混同しているのだと思います。
Steve Jones氏はAnne氏への返信として記事を一本書いている。Steve氏は「SOAはテクノロジーではなく、実践である」と説明する。
Steve氏の見解では、現在SOAが失敗している原因は、アナリストとベンダが人々を最初にテクノロジーの方向へ導いてしまった(そして今でもそれは続いてる)からだという。
ベンダが「私たちは今でも製品を変え続けている」と主張する一方で、かつてはそれらの製品を買うように勧めていたアナリストたちが、実はまだ価値が分かっていないと不平を漏らしているというのはまさに茶番です。(中略)SOAは失敗していません。失敗したのは次世代の「ブタの口紅」、つまり「ウチのテクノロジーを買えば問題は起きませんよ」「大規模なプロジェクトを実行しなさい、そうすれば全て解決しますよ」といったスタイルのITであり、それは常に失敗するものなのです。
Steve氏が死滅したと考えているのはSOAではない。
(前略)ゾンビ・チャイルド、つまりベンダ駆動の戦略はIT部門に本来の利益をもたらすことができませんでした。同じことがクラウドに関しても起こりつつあります。ゾンビに取り付かれた組織、つまりベンダ・マーケティングは他のアプローチを腐敗させようとします。SaaSの場合には、大部分がビジネス駆動なものでした。そうやって、以前に失敗したものと同じ技術を再び売ろうとしているのです。
SOAは現在、そしてこれまでも常に、アーキテクチャに関するものだ。融資を得るための方法でなければ、アナリストが誇張するものでもなく、また特定のミドルウェアプラットフォームでもない。ここ10年でIT産業はこのアーキテクチャのスタイルを理解し、改良することに関してめざましい進歩を遂げた。だから、Anne氏は本当に死滅したのは何かを結論づけなければならない。アナリストの誇張だろうか?しかし、アーキテクチャの発展はどんなものであれ、しばしばそのように起こっていた。執行役による盲目的な資金調達だろうか?エンタープライズ・アーキテクトが今は、何を得ることができて、それはなぜなのかについて説明しなければならず、以前のように白紙小切手をもらうことができなくなったという事実は良いことだと考えねばなるまい。ソフトウェアベンダの利益が削減されたことだろうか?現在オープンソースで提供されているものと、企業からのより高度な要求によって、ソフトウェアベンダは一層革新的な製品を作り出さなければならない。
確かに、SOAソフトウェアに対する支出は減速している。しかし、同じことは他のどんなソフトウェア製品にも、他の産業にも言える。Pierre Fricke氏の言葉を借りよう。「家を買いたいですか?車は?稀少な芸術作品は?石油のリースはいかがでしょう?2006年から07年の時の価格で。」
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
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
スレッド表示 返信