GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Boris Lublinsky , 翻訳者 能仁 信亮 投稿日 2009年9月7日
Joe McKendrick氏は、"Challenges and Opportunities in SOA and Cloud: Lessons Learned"というセッションの議事録を公開した。このセッションには、Phil Wainewright氏や、David Bressler氏、Ed Horst氏、Joe McKendrick氏が出席した。
セッションは、Phil Wainewright氏が投げかけた質問から始まった。
皆さんはクラウドをどのように定義していおり、SOAとの違いがもしがあるのであれば、主な違いはなんだと考えていますか。
Joe McKendrick氏は次のように語った。
... ここ数年で、これらのコンセプトが一つに集約、あるいは一緒に扱われることが、これほどまでに多くなったことは驚くべきことです。私はSOAとクラウドを個別に話をしましょう。SOAは10年前から存在し、多くの会社が既に取り組んでいます。そして今、この注目はクラウドに移ってきています。これら2つを区別するのに良い方法は、次のようなものだと私は考えます。SOAはアークテクチャです。SOAは下層のアーキテクチャで、開発や、メンテナンス、ガバナンス、提供したサービスのオーケストレーションなどの方法なのです。そしてクラウドは技術です。この技術によってサービスは組織を超えて配備されます。しかし、もはやこれらの2つは切っても切れないところまできていると私は考えます。
Phil Wainewright氏は次のように質問を続けた。
クラウドはある種のWeb指向な方法で実装された単なるSOAだ、というほど話は単純なものなのでしょうか。.. つまり私がこう言ったのは、クラウドはオープン環境で誰が関係しているのかわからないからです。サービスレベルに関して行わなければいけないことはたくさんあるし、契約を結ばなければなりません...そしてセキュリティの要求を定義するといったこと。コントロール下におかれた企業内の環境では気にしなくてもよかったことを行わなければならないのです。企業内の環境はコントロールされ、何が起きているかわかっているので今までは気にしなくてよかったのですが。... SOAとクラウドでは多くの共通点があると考えます。クラウドは、SOAにより可能となった多くのことを行っています。したがってクラウドはSOAの経験から学ぶことができると考えられます。では、SOAが私たちに教えてくれたことはなんでしょうか。クラウドを実装するときに、同じ失敗を繰り返さないための、SOAから得られる教訓とは何なのでしょうか。
この質問に答えるために、Ed Horst氏は3つの主要なSOAの教訓について述べた。
...手頃な規模で、終了時に日常の業務にインパクトがある特定のプロジェクトから始めます... 日常的に使われるものを取り上げるのがいいでしょう。他には ... クラウドでまだ何もしていない段階から、すべてをクラウドで行うといった海を沸騰させるようなアーキテクチャの導入方式は避けるべきでしょう。...しかし最初のプロジェクトが最終的な方向性と無関係に実施することができるといっているわけではありません。その組み合わせなのです。私が見てきた中でもっとも成功した戦略の一つは、全体アーキテクチャや2年後、3年後、4年後、あるいは5年後に達成したい点を伴った広い視野を持ちつつ、ある種の実質的な現実感を持って最初のプロジェクトを行うというものです。そして...早めに、かつ頻繁にシステムを管理し、システムにガバナンスをきかせていくのです。通常、最初の方にやってしまったことを後悔するのではなく、やらなかったことを後悔することの方が多いのです。
Phil Wainewright氏の意見は、Web指向アークテクチャは、SOAとクラウド・コンピューティングを統合することができるというものだ。彼は次のように続けた。
...Web指向アーキテクチャの特徴の一つは、 RESTインターフェースです。RESTインターフェースはSOAPがそうであったような複雑性をもたない単純なインターフェースです。そしてそれはクラウド環境でも必要な特徴であり、通常よりさらにその特徴をもつ傾向があるので、これが共通項なのではないでしょうか。
Ed Horst氏の意見は、RESTもSOAPも相互作用の方式によって適材適所で使えるというものだ。
トランザクションが重要であったり、保護される必要があったり、業務上クリティカルであったりした場合には、SOAPインターフェースが用いられることが多いでしょう。しかし、問合せや更新やビジネス上のインパクトがそれほど大きくない軽い処理には、RESTインターフェースが使われています...RESTがトランザクション処理で利用できないといっているわけではありません。トランザクションであったりセキュリティ要素であったり、整形されたメッセージなどの必要なものを加えるとRESTがSOAPと変わらなくなってしまうのです。
今日、クラウドはITの新しいバズワードであり、SOAは徐々に人気を失っているようだ。少なくともアナリストの中にはそのように考える人がいる。結果として、SOAの欠点や困難さを全てクラウドが解決、改善してくれると広く考えられるようになった。実際にはJoe氏が話したように、SOAは適切なアーキテクチャであり、クラウドは基盤である。皆が知っているように、優れた基盤でも、お粗末なアーキテクチャを救うことはできない。銀の弾丸に頼ることはやめて、適切なサービス・アーキテクチャという基本に集中しよう。
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
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
スレッド表示 返信