Alex Williams | SEO-LPO.net

VMwareのクラウド戦略: Cloud FoundryにもOpenStackにも良い顔を（ただしAWSはノー）

VMwareが今日（米国時間8/26）行われたVMworldカンファレンスで、VMware vSphere 5.5とVMware vCloud Suiteの一般公開を発表した。同社の仮想化技術のこれら新バージョンは、Cloud Foundryを統合している。そしてこのPaaSは今では、VMwareの親会社EMCからのスピンオフPivotalの一部だ。

Cloud FoundryはVMwareを代表する製品だったが、これからはそれは、PivotalがVMwareのために構築するプラットホームとなり、新たなクラウドプロダクトvCloud Hybrid Servicesに統合される。それはPivotal CFと通称され、今年の終頃にVMware vSphereとvCloud Hybrid Servicesの上で可利用となる。vSphereは、クラウドコンピューティングのための仮想化管理ツールの、従来よりも強化された集合だ。vCloud SuiteはvSphereを管理して、企業がエラスティシティ（伸縮自在性）を確保するために行うリソースのプール（保蔵）を助ける。

VMwareのCEO Pat GelsingerはとくにvSphere 5.5の戦略的な重要性を強調し、同社はこれを軸に“ソフトウェア定義デザインセンター(software defined data center)”におけるリーダー的な存在になる、と述べた。vSphere 5は、そのようなアーキテクチャのコンピューティングの側面を表す。その仮想化ストレージは、“仮想SAN(virtual SAN)”と呼ばれるストレージサービスへラップされ、またネットワーキングは今日ローンチしたネットワークハイパーバイザーNSXに体現される。以上の全体として、基本的な概念は、必要に応じ、リソースをプールしクラウドをレバレッジすることだ。

新バージョンのvSphere SuiteとvCloudはVMwareのvCloud Hybrid Servicesに統合される。vCloud Hybrid Servicesは、新たな投資の対象となった新データセンター（カリフォルニア、バージニア、やがてダラス）からサーブされるIaaSだ。マネージドホスティングサービスSavvisも、やはりvCloud Hybrid Servicesからサーブされることになる。

VMwareが今後とくに注力するのは、顧客のデータセンターとVMwareのハイブリッドサービスとの密接な統合だ。そしてすべてが、同社の仮想化技術の上で動く。AWSとの互換性は提供しないので、利用者として、VMwareとAWSの使い分けをするのは難しい。VMwareへの一本化を、ほぼ強制されることになる。単純にVMwareの外向きサービスに接続するだけだから、簡便でもある。ただし、その利用料の“お安さ”ではAWSにかなわないだろう（VMwareはまだ料金体系を発表していないがAWSのような低価格にはならない、とすでに言っている）。

VMwareの、OpenStackへの賭け高は、vSphereがそれを統合することによって一層増した。オープンクラウド運動の旗手Niciraにも手厚く投資をしているので、今後の統合も考えられる。

VMwareの役員の一人が記者会見で、OpenStackを、ホームシアターシステムを買うことと比較した。VMwareをワンパッケージとして買えば、 vSphereとハイブリッド化vCloudがついてくる。しかし顧客は、そうせずにVMwareの技術でOpenStackを使うこともできる。どっちにするか、だ。

すでにOpenStackでクラウドの構築を始めている顧客も少なくない。Cloud Foundryも市場ではわりと広く受け入れられているが、しかしどのソリューションもまだ、コンサルタントが仕事をしやすいプラグアンドプレイタイプではない。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

営業～見込み客発掘をデータ分析で助けるSalesPredictが$1Mのシード資金を調達

企業の営業やマーケティング部門のために予測的分析を行う

SalesPredictが、100万ドルのシード資金を調達した。この投資を等格で仕切ったのはPitango Venture CapitalとAfterDoxとRSL Venture Partnersの三社、これに数名のエンジェル投資家が加わった。

協同ファウンダのYaron Zakai-Orは同社の姿勢を、“うちのやり方は一般的な問題を解決することではなく、営業が抱える一般的でない問題に一般的なアルゴリズムを有効に適用することだ”、と説明する。

そのアルゴリズムは協同ファウンダでCTOのKira Radinskyが開発したSaaSに組み込まれている。彼自身は以前Microsoft Researchにいたが、このSaaSはSalesforceのAppExchangeに緊密に統合化されている。数週間後に同社の顧客は、AppExchangeから同社のSales Predictアプリケーションをダウンロードして、その予測的分析技術を自社の見込み客生成過程に組み入れる。するとそのサービスは多くの見込み客をピックアップして、営業はそれらの優先順を決める。

見込み客発掘のために使われる元データは、Salesforceのデータやソーシャルネットワークのデータ、およびそのほかの情報源（Alexaやdata.comから得られるWebサイトトラフィック情報や、Salesforceのコンタクトデータベースなど）。

SalesPredictはさらに、過去のデータも分析して、有効だった属性と、そうでない属性を分ける〔例: 性別はあまり関係なかった〕。またその分析モデルは固定的でなく、今後の実績によって調整されていく。

今月初めにはInsideViewが1900万ドルを調達して、顧客企業のCRM情報を見込み客発掘源にするためのサービスをより強化した。またLattice EnginesやInferなどは、営業に対して成績予測ツールを提供している。

またSalesforceも、これまでは分析を主にパートナーに任せていたが、Prior Knowledgeを買収して分析サービスに色気を見せはじめた。

営業のための情報提供サービス、いわゆる“セールスインテリジェンス”の分野は、このように、このところ競争が激化してきたが、一方顧客側を見ると、営業活動や見込み客発掘の高度情報化は、まだまだ未採用企業の多い処女地市場だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

FullContactは、名刺をSalesforceに入力する面倒な作業を自動化するサービス

名刺、それは格好の良いものではないが、ビジネスチャンスや売上につながることがある。残念なことに、名刺は忘れられがちだ。名刺データを打ち込む作業があまりに面倒だからだ。

TechStars出身のFullContactは、名刺の連絡先情報をSalesforce.comに登録するサービスだ。顧客は、FullContactリーダーで名刺を読み込めば、Salesforceのグループ、エンタープライズ、およびプロフェッショナル・エディションで利用できる。

名刺リーダーを提供する会社は数多い。例えばLinkedInには、CardMunchがあるが、同サービスでしか使えない。Evernote Hello、NeatMobile、およびShape Business Cardなどのリーダーも要チェックだ。

しかし、Salesforceなどのプラットフォームに連絡先データを自動的に送り込めることこそが、現在のFullContactの優位点だ。まず、リーダーで名刺をスキャンしてデータベースに登録する。次にデータはAmazon Mechanical Turkに送られ、手動でデータ化される。作業が完了したら、連絡先データはSalesforceに送られデータベースに追加される。このプロセスには約15分かかる。

この機能は、FullContactがSalesforce ISVプログラムに加入したことによって生まれた。以前Salesforceユーザーは、同僚と異なるバージョンを動かしていることがあった。この新サービスでは、利用者が使っているバージョンにかかわらず名刺データをアクセスできる。FullContactでは、名刺の約9%が実際にCRMシステムに登録されると推測している。同サービスはiOSで利用可能で、約2ヵ月のうちにAndroidバージョンも提供予定だと同社は言っている。

FullContactは、別のプラットフォームにもこの名刺管理サービスを提供する計画だ。CRMであれ、メールクライアントであれ、個人のスプレッドシートであれ、データが意味を持つところであれば何とでも統合したい、と同社は考えている。

同社が提供するAPIを利用すれば、ソフトウェア・テベロッパーは、自社のサービスやアプリケーション内で、ユーザーに完全かつ最新の連絡先情報を提供できる。デベロッパーは、不完全な古い連絡先データベースを完成させることもできる。名刺情報には、電話番号、メールアドレス、住所、氏名、役職、会社名、ソーシャルプロフィールのURL、写真、誕生日、インスタントメッセージのハンドル等々が含まれる。

FullContactは、ソーシャルデータを収集し、個人やサードパーティー・プラットフォームに統合することに関する深い専門知識を持っている。ひとたびデータをシステムに入れれば、他のツールを使ってどう分析するかは各企業次第だ。データの統合は重要だが、ビジネスのデータ駆動化を進める企業にとって、分析能力がもたらす付加価値は益々重要になっている。

[原文へ]

（翻訳：Nob Takahashi）

モバイル開発プラットホームAppceleratorが高度なAPIアグリゲータSinglyを買収, いよいよ業界の地固め期に

モバイル開発のためのSaaSプラットホームAppcelerator（開発ツールTitaniumなども提供）が、Webとモバイルのアプリケーション開発においてサードパーティサービス（各種API呼び出し）を管理するプラットホームSinglyを買収した。買収の金額条件などは公表されていない。Singlyは、同社のAppFabricサービスとDataFabricサービスをAppcelerator PlatformおよびTitaniumに統合する作業をただちに開始する。

Singlyは3年前に創業され、昨年12月に公開ベータに入った。本誌のSarah Perezは当時、Singlyは（アプリが呼び出す）サードパーティのサービスでユーザを認証したり、いろんなソーシャルネットワークやそのほかのサービスからデータ（フレンドリスト、写真、プロファイルなど）を取り込んだりするコードを、簡単にはやく書けるようにする、と紹介していた。アプリケーションの中で、ユーザが複数の異なるソーシャルネットワークで共有することも、可能にする。こういう、複数サービス横断型の総合API管理デベロッパサービスのことを、同社は“app fabric（アプリケーションの織物）”と呼んでいた。Singlyはほかにも、データのシンク、ストレージ、データの重複排除、データのクェリとフィルタリング、などの便宜をデベロッパに提供する。

SinglyのファウンダJason Cavnarは、それまでソーシャルリーダー(reader)のNsyghtにいた。Jeremie Millerは、インスタントメッセージングのオープンソースプロトコルJabber/XMPPの発明者として有名だ。そしてもう一人のファウンダが、Simon Murtha-Smithだ。

APIアナリストのKin Laneにメールでインタビューしたら、こう言った: “いろんな有力APIを利用したアプリケーションを書くとき、それらのAPIのユーザ認証とか統合といった面倒な部分を、全部Singlyが面倒見てくれる。面倒なだけでなく、各APIごとにユニークなoAuthとAPIエンドポイントをバランス良くナビゲートするのが難しい。今度の買収でSinglyのファンが増えるだけでなく、開発プラットホームとしてのAppceleratorの魅力も高まる。APIアグリゲータはほかにも数社あるが、この方面で（Singlyのファウンダ）Jeremie Millerの専門知識・技能にかなう者はいない”。

Singlyがデベロッパたちの注目を浴びているのも、その血筋の良さと、技術に対する深い理解、そしてオープンソースやコミュニティに対する情熱のためだ。その姿勢は、合衆国の主要都市を巡回して行われるAPIs&IPAsツアーにも表れている。同社のブログによると、そのイベントはミートアップでもカンファレンスでもハッカソンでもなく、とにかく、楽しい時間を過ごすことだ、という。同社は各都市の地元のテク企業とパートナーし、地元スタートアップになじみのバーを選び、テクコミュニティを惹きつけるためにイベントを宣伝する。まさに、デベロッパマーケティングの王道だ。

この二社の合体は、API管理という業界分野における一つの節目だ。これまでの数か月で、IntelがMasheryを買収、CAがLayer 7を買収、そして著名なAPIデータベースProgrammable WebをMulesoftが買収するなど、業界の再編成が激しく進んでいた。Appcelerator + Singlyは、その総仕上げだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

OpenStackインフラサービスとしてアジアで伸びるMorphlabsが新たに$10Mを調達

OpenStackの管理コンソールを提供し、Flashを使った視覚化により、クラウドインフラのハードウェアとソフトウェアのスピードとパフォーマンスを最適化するMorphlabsが、このほど1000万ドルの資金を調達した。このラウンドを仕切ったのはTallwood ManagementとEntropy Research Labで、既存の投資家G2iGも参加した。Morphlabsの資金総額は2250万ドルになった。

サービスの部門で成長しているMorphlabsは、とくにアジアで伸びていて、ソフトウェアのターンキーソリューションを主にハードウェアのベンダに提供している。たとえば、DellのハードウェアはMorphlabsで最適化されている。Media Templeは、このDell-Morphlabsの統合を利用して小企業の顧客にクラウドサービスを提供している。

OpenStackがクラウド構築プラットホームと呼ばれるのには理由がある。企業はそれを使って独自のインフラストラクチャを構築し、そのエラスティックなインフラはほかのOpenStackシステムと連携できる。つまりそれは、大量のサーバの上にソフトウェアをインストールする、という単純な話ではない。それは総合的なシステムであり、その各部がデータセンターのさまざまな層に接続して、あらゆるものを一つの仮想化環境にプールする。いったん動き出したそのシステムは、同じくOpenStackを使っているほかのインフラストラクチャに接続できる。

今週の初めにVMwareのCEO Pat Gelsingerが、OpenStackはエンタプライズ方面では伸びない、と言った。私はその理由について考察してみたが、結局彼が言いたいのは、OpenStackはサービスプロバイダにとってのよりベターな選択である、ということなのだ。

たしかにそれは本当だが、今では複数のクラウドシステムの連携～連邦化が、とりわけフィリピンやインドネシア、シンガポールなどのアジア各国で台頭している。とくにそれらの地域の通信企業のクラウド採用形態は、OpenStackは公共サービスの分野と大企業の企業環境を支配するのだろうな、と思わせる初期的な兆候を示している。そして連邦化によって、彼らの拡張のためのスペースに制約がなくなる。そういう分散化によって、SaaSツールの利用から先進的なデータ分析に至るまでの、さまざまな利益がもたらされる。分散インフラストラクチャが良質であればあるほど、より多くのサービスや企業が成長し、雇用を増やしていける。

Morphlabsが競合する戦場は、今とても混み合っている。たとえばNebulaは、やはり同じような統合化方式により、カスタムメイドのOpenStackボックスを開発している。またHPやIBMは、そのインフラの何でも屋的な特性を生かそうとしている。

しかしそれでも、Morphlabsが見つけた環太平洋地域というクラウド処女地は、これからさまざまな企業や消費者市場がクラウドインフラストラクチャを積極的に導入していく地域なのだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

GitHubにトレンドページが登場: プロジェクト別, 言語別, デベロッパ別など

GitHubが、同サービス上で今何がトレンドかを知るための方法をローンチした。ユーザは期間別、プロジェクト別、デベロッパ別、プログラミング言語別などでトレンドを知ることができる。

そのGitHub Trending Pageと呼ばれるサブサービスは、日別、週別、および月別のトレンドデータを1日に8回計算する。ユーザは、自分が見たい期間を指定できる。

プログラミング言語はランク付けされ、デフォルトではすべての言語のトレンドアイテムが表示される。ユーザは、自分自身のリポジトリに基づいてトレンド言語を見られる。リポジトリがまだないユーザは、GitHub全体の上位言語を見る。

言語は、つねにリポジトリベースで計算される。GitHubのブログは、こう説明している: “リポジトリ(repositories)タブではユーザが選んだ言語フィルタによる主要言語のリポジトリが見られる。デベロッパタブでは、選んだ言語における上位トレンドのリポジトリを持つデベロッパを見られる”。

リポジトリのトレンド情報は、リポジトリの説明や言語、上位5名の寄与貢献者、そしてFacebookのLikeなどに相当する星印ボタンがある。デベロッパのトレンド情報では、そのデベロッパが抱えるすべてのリポジトリと、そろぞれの所属組織や団体も表示される。

GitHubがトレンドを求めるとき利用するデータは、星印の数、フォーク数、コミット数、フォロー数、ページビューなどだ。またそれらの各項目は、新しいものほど点が高くなる。トレンドページには、上位25のリポジトリとデベロッパが表示される。それより多いと結果がより希薄になり、またデータ分析の負荷が大きすぎる、と彼らは言っている。つまり、25がちょうどよいところである、と。

GitHubは、デベロッパのためのデータ駆動型のソーシャルネットワークだ。トレンドページによって、これまで検索を何回も繰り返さないと分からなかったデータが、一目で分かるようになった。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

CRMのコンタクト情報を商談成立確率の高い充実した見込み客リストへ育てるInsideView, $19Mを調達

客先のCRMにいろんな情報をプラスして営業やマーケティングのツールに仕立てるInsideViewが、Split Rock Partnersが仕切るラウンドにより1900万ドルを調達した。既存の投資家Emergence Capital、Foundation Capital、Rembrandt Venture Partnersらもこの投資に参加した。これでInsideViewの総資金は4640万ドルになった。

同社はおよそ3万のソースからデータを集める。Twitter、Facebook、Reuters（ロイター通信）、SEC（証券取引委員会）の提出書類、などなど。そしてそれらのデータを同社のAPIに通し、企業のマーケティングや営業環境にフィードする。

たとえば、企業はInsideView for Marketingを利用して接触先の肩書きなどのデータを見つけ、その見込み客のプロフィールを充実させる。データはその企業のCRMシステム内で提示され、そのシステムを支えるデータベースに入る。InsideViewの営業ツールが加える情報により営業は、見込み客についてより多くのことを知る（服のサイズとか…）。

このサービスはさまざまなCRMプラットホームのデータモデルに対応している…Microsoft Dynamics、Salesforce.com、Sugar CRM、などなどのメジャーなCRMプロバイダだ。データを各プラットホームに統合するとき同社は自然言語処理(NLP)を使用してデータを整理し、Hadoopのようなオープンソース製品や関係データベースや特製のNLPライブラリに収める。

InsideViewはいわばコンタクト情報システムの現代版で、当時はなかったAPIの力、NLPを利用する多様なシステムへのデータ供給能力などをフルに活用する。同社の競合他社であるHarte-Hanksは、やはりマーケティングや営業を助けるデータの供給によって一財産を築いた。

また、新たな競合相手としては、ビッグデータ分析のビジネス利用を進めている連中がいる。それら各社の差別化要因はさまざまだが、とくに重視されるのはスピードだ。ルートセールスの人たちが正しい情報に基づいた見込み客リストを持てば、営業の効率は一挙にアップする。すなわち、商談をまとめるスピードがアップする。ドアを開けた途端に商談が成立するなら、それが最高だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

CRMのコンタクト情報を商談成立確率の高い充実した見込み客リストへ育てるInsideView, $19Mを調達

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

ProfitBricksが料金を下げてAWSは高すぎると主張

クラウドプロバイダのProfitBricksがCPUコアとRAMの料金を50%値下げして、うちのサービスはAmazon Web Services(AWS)に比べて大幅に安い、と主張している。

彼らはいろんな要素を取り上げてAWSと比較しているので、私の頭の中も散漫になってくる。たとえばAWSの一時的ストレージの要件とか、AWSの料金プランの体系など。AWSはインスタンスのサイズに柔軟性がない、とも言っている。まだまだある。

ProfitBricksには好感を持っているが、それはAWSより安いからでも、AWSが高すぎるからでもない。同社の良いところは、そのプラットホームの力と、市場への接近の仕方だ。数か月前に同社を取り上げた記事でこんなことを書いた:

ProfitBricksは1950万ドルを調達し、総資金量は3830万ドルになった。ファウンダのAchim WeissとAndreas Gaugerが作った1&1 Internetは、世界最大のWebホスティングプロバイダの一つで、70000台のサーバが1000万の顧客にサービスを提供している。同社は資金量だけでなく、顧客のスケールアップ/スケールアウトニーズへの対応力でも優れている。スケールアップではAWSと似た環境で新しいアプリケーションを展開でき、一つのスタックが最大で62コアまで大きくなれる。

ProfitBricksは、計算とストレージにのみ課金する。しかも従量制なので、AWSより安いと彼らは言いたいのだ。InfiniBandネットワーキングのピュアプレイを志向しているので、同社のサービスはとても高速だ。

しかしAWSの価値は、まさにProfitBricksがバカにするそこんところにある。AWSには幅広い料金体系があり、顧客のニーズにきめ細かく応じられるサービス群を擁している。

結局のところProfitBricksもAWSの料金体系の真似をして、そのうえで、高速で柔軟性に富むサービスを売り物にしたいのだ。それはそれで良い。しかし、そこにはおそらく、AWSの顧客がAWSを捨ててまでProfitBricksになびくほどの、要素はない。AWSを使うのは、料金が理由ではなくて、AWSのすべてがその理由だ。トータルコスト、コミュニティ、そして多様なサービスと機能。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

AWSがアプリのリクエストがロードバランサを通っても元のクライアント情報が失われないサービスを開始

Amazon Web Services(AWS)に、ユーザにアプリケーションのトラフィック（ビジター数）が分かるためのサービスが加わった。ただしアプリケーションがAWSのElastic Load Balancer(ELB)を通っていて、IPアドレスが分かる場合のみだが。

それはAWSに、いわゆる”Proxy Protocol Version 1“のサポートが加わったということだ。このプロトコルを使うと、ELBのようなプロキシのトランシット間にもTCP上で接続情報が失われずに得られる。

ELBはリクエストをAWSのクラスタ群に分散するが、そのとき通常、クライアントの接続情報、IPアドレスやポート番号などは失われる。つまりロードバランサーは一種のプロキシとして働き、アプリケーションに対して、自分があたかもクライアントのように振る舞う。だから本来のクライアントのIPアドレスはサーバに届かない。しかしこのProxy Protocolを使うと、そのIPアドレスを知ることができる。そしてデベロッパはそれを利用して通常のアクセス分析ができるし、また、IPアドレスをホワイトリスとブラックリストに仕分けることもできる。

Proxy Protocolのアドバンテージは、TCP上のどんなプロトコル層でも使えることだ。つまりそれは、その接続が担っている高レベルのプロトコルにはいっさい関知しない。だからHTTP以外のトラフィックをサーブするときでも、使える。またHTTPSのリクエストを送るときも、ロードバランサーの上でSSL接続を断たずにすむ。

この新しいサービスの詳細はAWSのブログ記事にある。

このニュースは、AWSが絶えざる機能拡大マシンであることを、改めて認識させる。AWSほどの頻度で機能が増えていくクラウドサービスは、ほかにない。Windows AzureやGoogleも善戦しているが、もっと機能拡張のペースを上げて独自のニッチを作り上げないと、成功しないだろう。Azureならエンタプライズへの特化。Googleは独自のコンピューティングサービスと分析能力が差別化要因だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

OpenStackをAPIレベルでAWS互換にせよ, という切実なる公開書簡

CloudscalingのCTO Randy Biasが今日（米国時間7/24）、OpenStackに宛てた公開書簡を書いた。その中で彼は、オープンなクラウドを目指す各種の取り組みは、Amazon Web Services(AWS)のデファクトスタンダード性を素直に認めて、それと互換性のあるAPIを整備しなければ勝利できない、と述べている。

彼は、AWSは事実上のリーダーだ、と主張する。だから正しい対応は: OpenStackは独自のAPIを作って自己を差別化する努力をやめて、AWSがパブリッククラウドにおける勝者であるという現実を受け入れることだ。そうすればOpenStackは、AWS的なパブリッククラウドと現代的なデータセンターが交わる“ハイブリッドな”クラウドの分野で勝てる。OpenStackが伸びる場所は、そこだ。その顧客は、それなりの伸縮自在性を持つクラウドオペレーティングシステムを必要とするが、何万何十万もの一般ユーザにサービスを提供する必要はない企業ユーザだ。

とりわけBiasは、OpenStackを使う場合の、スタンダードとなるAPIを作ることを、Rackspaceに呼びかけている。彼は、OpenStackがこれまでRackspaceのオープンクラウド寄りのAPIを作ってきた経緯を、詳しく述べている。Biasによれば、RackspacはOpenStackのAPIを自分のために作ってきた*。同社はOpenStackを利用して、自己のサービスを差別化しようとしてきた。〔*: RackspaceはOpenStackの最有力の創設メンバーの一人。〕

たしかに、それは事実だ。明らかにRackspaceは、OpenStackという公共的な性格の団体を作るという機に乗じて、自分自身をより大きくしようとした。当時の同社は、クラウドの今後の方向性について模索し迷っていた。同社は、ホスティング企業からソフトウェアデベロッパへという、重要な曲がり角にさしかかっていた。そのことを、Rackspace自身も理解していたのか？　理解していたと思う。同社はOpenSackのリーダー役を買って出ることによって、それをコントロールしようとし、自社のクラウドとそのAPIをOpenStackの“ネイティブの”APIと呼ばせようとした。

しかしRackspaceには、世界初の大規模で本格的なオープンクラウド運動の口火を切った、という功績がある。今ではそこに、250社あまりが参加し、何千ものデベロッパが120万行を超えるコードを書いている。IBMもRed HatもHPも、みなOpenStackに加わった。そしてBiasはCloudscalingの新しい市場を開拓でき、そこに対し、クラウドインフラを構築するためのシステムサービスを提供していった。

しかし、ここにきてBiasがAWSを持ち上げるのには、理由がある。それは、彼自身の利害だ。彼の会社はAWSとGoogle Compute Engineを重視している。だからAWSとOpenStackが重なるようなAPIがあれば、彼の若い会社の大きな助けになる。こういった問題に関しては、クラウドコメンテーターのBen Kepesが良い記事を書いているので、一読をおすすめしたい。

それは、奇妙な状況でもある。OpenStackに参加している企業は、強きも弱きも、大きな市場圧力にさらされている。そしてそのプレッシャーを増幅しているのがAWSと、その疑問の余地なきイノベーションだ。OpenStackの創設から今日までの3年間で、AWSはクラウド宇宙を支配してしまった。

しかし、HP、IBM、Red Hat、AT&Tなどなど多くの企業は、AWSをそう簡単にパブリッククラウドのデファクトスタンダードとして受け入れるわけにはいかない、それぞれの事情を抱えている。彼らは、AWSに勝たせたくない。彼らから見ると、Amazonの、自分がコントロールを握ろうとするときのやり方は、あまりにも苛烈で非情だ。そのAPIはクローズドだし、いつでも勝手に変えることができる。独自の理由で、一部のサービスを一方的に切り詰めることすらありえる。

だから、Rackspaceがこれまで我が道を行くでやってきたように、誰もがそうしてきたのだ。

Biasは、OpenStackの将来性に疑問を投げかけている。最終的にそれは、誰の役に立つものになるのか、と。この、AWSのAPIとの互換性、という問題について、RedMonkのアナリストDonnie Berkholzに話を聞いてみた。彼は、結局それは将来性の問題だ、と言った。APIのプロバイダには、それを将来にわたってメンテする義務がある。そのAPIは、今後もずっと動くもの、使えるものでなければならない。その点に関しては、Amazonには疑念の余地がない。しかしOpenStackは、大きなクェスチョンマークだ。OpenStackには今すでに変種が相当多くて、統合を難しくしている。たとえば、Dreamhostはストレージに（分散並列ストレージ）Cephを使い、RackspaceはSwiftを使っている。Dellは、自社製を使っている。

OpenStackは、こういった複雑性を解消すべきである。しかし参加企業が多くてそれぞれが独自の利害を抱えているから、その課題は、言うは易く行うは難しの典型となる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

企業がNoSQLデータベースを導入するためのプラットホームDataStaxが$45Mを調達, 狙いはApache Cassandraの育成

ハイパフォーマンスでスケーラブルなNoSQLデータベースのプラットホームを提供しているDataStax が、Scale Venture Partnersが率いるシリーズDのラウンドにより4500万ドルを調達した。Draper Fisher JurvetsonとNext World Capitalのほか、以前からの投資家たちもこのラウンドに参加した。

DataStaxはこの資金を、同社のデータベースディストリビューション（配布系）の基盤でもあるオープンソースのNoSQLデータベース実装Apache Cassandraの、さらなるグローバルな構築と、それへの投資に充てていく。今回の投資は同社のIPOを示唆するものでもあるが、CEOのBilly Bosworthによれば、どうなるかは市場の方向性次第だ、という。“IPOは弊社の既定路線だが、それは外部要因に依存するところも大きい。しかし内部的には、すでにその準備を開始している”。

今回の資金調達を機にDataStaxは、同社のデータベースソフトウェアのエンタプライズ向けとコミュニティエディションをバージョン3.1へアップデートし、データロード能力の強化と検索の高速化、およびユーザザビリティの改善を約束する。

2010年に創業されたDataStaxは、今ではApache Cassandraの主席コミッターで、その製品はパフォーマンスの高さとスケーラビリティで定評がある。しかしCassandraは比較的新しいため、それを独力で使えるところは少ない。しかし需要は増えているので、DataStaxはCassandraに大きな投資をしてコミュニティをより大きくし、プラットホームの用途も拡大したいと考えている。今回の投資ラウンドでもDataStaxはCassandraへの投資を続けて、ミートアップの開催数を増やすなどの取り組みを行う。とくに重視するのが、今後の拡張先と考えているアジアとラテンアメリカだ。

この投資のタイミングは、多くの企業が、関係データベースから今のデベロッパたちに人気のあるデータ集約的なNoSQL環境への移行を始めている時期と合致する。NoSQLデータベースは、関係データベースが一台の専用サーバの上で動いたのに対し、コンピューティングの多くがマルチテナントのクラウド上で行われる新しい時代に向いている。その市場はオープン性が高くて、IBMも、もっとも人気の高いNoSQLデータベース技術と思われる10GenのMongoDBへと標準化している。〔関連記事。〕

一方、データベース市場の新しいアイデンティティの模索は続いている。NoSQLはスタートアップたちの寵児だが、まだ多くの企業は長年使い慣れた関係データベース上のトランザクションシステムを簡単には捨てきれない。でも、そういう従来的な企業も近頃はデータの生成量が多くなっているため、今後はDataStaxのお客さんが増える一方だ。またこの市場変動は、ハイブリッド型のデータベースにも機会を与えつつある。たとえばNoSQLのプロバイダであるFoundationDBは先週、NewSQL系のAkibanを買収して、NoSQLのスケーラブルなパフォーマンスに関係データベースのトランザクション指向の強みを妻合（めあ）わせようとしている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

消費者向けサービスでセキュリティの弱いGoogle Driveに企業利用のための鎧を着せるEgnyte

会社でGoogle Driveを使っている人は多いと思うが、実はGoogle Driveは、同社の‘エンタプライズ’サービスの一環でありながら出自が消費者サービスなのでファイルレベルのセキュリティが完全でない。しかしそこが、独自のファイルサーバ技術を持つEgnyteの出番となる。このたびEgnyteとGoogleが提携して、企業が全社的に利用できアクセスできるプラットホームを提供することになった。

EgnyteのファイルハブがGoogleのドキュメントをクラウドやオンプレミスで読み、それらをフォルダのレベルで保安を図る。たとえば企業は[財務]という名前のフォルダを作り、そのセキュリティを確保できる。パーミッションはサブフォルダのレベルで与えられるから、自分の所属部署の会計情報しか見られない、という状態を作れる。ドキュメントのシンクはEgnyteのファイルハブ全体に対して行われる。ビジネスパートナーにアクセスさせるべきドキュメントはPDFで提供し、PDFレベルのセキュリティ設定を行う。またEgnyteは完全なオーディットトレイルを残すので、個々のファイルのアクセス履歴がすべて分かる。

というわけでEgnyteという層をかぶったGoogle Driveは、企業が安心して使えるファイルシステムになる。ただし、ネットワークに接続されたGoogle Driveのファイルにオフラインでアクセスしようとすると、限界を露呈する…オフラインアクセスにはChromeのプラグインを必要とするので、どのブラウザからでも、とはいかなくなる。今ほかのブラウザへも対応努力中だが、それが実現するまでは利用が制限される。

Egnyteのサービスには、最初から企業向けに作られたプロダクトの強みを見る思いがする。一人のユーザではなく、社内の全員あるいは複数の部署が利用することを、最初から前提として、作られているからだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Puppet LabsがCloudsmithを買収してGitHubからAWSへの開発の流れを高効率化

企業ITのアドミンタスク(アプリケーションの構成、展開等）を自動化するサービスとして定評のあるPuppet Labsが、自動化インフラ構築ツールのプロバイダ Cloudsmithを買収する。たしかにインフラストラクチャの自動化は、今日のクラウドの時代において必須だが、今回の買収の金額条件等は非公開だ。

Puppet LabsのファウンダでCEOのLuke Kaniesがメールで教えてくれたところによると、Cloudsmithは、Eclipseとその関連ツールのエコシステム、およびオープンソース全般に関して、詳しい粒ぞろいのエキスパートを抱えている。また、PuppetとCloudsmithとのこれまでの協働歴も長い。Kaniesによれば、CloudsmithのIDE GepettoをPuppetのインフラストラクチャにくっつけてGitHubからPuppetのモジュールを取り出せるようにし、さらにアプリケーションのAmazon EC2へのインストール・構成・展開を自動化したい。

‘プログラマブルなインフラストラクチャ’の価値が認められつつある今日では、クラウド環境にテストツールを統合することがますます重要になっている。その必要性には、いくつかの理由がある。企業が作るアプリケーションは昔に比べると相当増えているので、アプリケーションをテストし展開する方法にも迅速と簡便が求められる。その課題に対し、古典的なIT部隊はほとんどお手上げであり、低コストなソリューションを提供できない。それに代わって今トレンドになりつつあるのが、インフラストラクチャの自動化によるアプリケーションおよび増大する一方のデータの管理だ。

しかしインフラストラクチャの高度化に伴ってSaltStackのような新しいタイプのサービスが注目され始めている。SaltStackはいわば各種のサービスをモジュール的に扱って、それらの組み合わせにより顧客企業の課題、すなわちインフラストラクチャ環境の管理とモニタリングに応えようとする。したがってそれは、Puppetなどに代わるものだ、とも言われる。

Real-time Cloud Management with SaltStack from SaltStack

[SaltStackによるリアルタイムクラウド管理]

しかし、企業がデータを正しく扱い、データに正しく対応できるIT体質を身につけていくためには（“データ駆動型企業”になるためには）、コラボレーションが重要な鍵となる。効果的なコラボレーション体制がないなら、どんなデータも無意味だ。そして、コラボレーションが活発になればなるほどアプリケーションのサイクルは速くなり、そして良くなっていく。

そこで、買収案件を見ると企業の方向性が分かることが多い。PuppetによるCloudsmithの買収は、システムアドミニストレータのワークフローにより深く具体的に介入していきたい、そしてまた同時に、現代的で協働的なやり方でアプリケーションを開発したいというデベロッパのニーズをも満たしていきたい、という同社の意思の表れだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

オープンシステムの旗手Googleがクラウドサービスのロックインは当面必要と言い訳

Googleの技術者の一人が、Google+の彼のページで、ロックインのまったくないクラウドプラットホームはありえない、と結論していた。たしかにそれはそうだけど、でもそんなことをわざわざ言うのには理由がある。クラウドのユーザたちのあいだで議論になっているこのロックインというホットな話題に関しては、Googleも他社もあまり変わらない、とGoogleは言いたいのだ。

Googleのエンジニアリング部長Peter Magnussonが書いたその記事は、その真のねらいを汲んで読む必要がある。MagnussonはGoogle App Engine(GAE)のロックインの問題を主に述べているのだが、彼はそれと同時に、同社の管理サービスやIaaSを、AWSなどと比較しているのだ。そして彼曰く、Googleも、何らかの制約なくしてサービスを提供することはできない、と。彼らがこれから提供しようとしているのは、AppScaleなどが提供しているサービスに代わるものだ、という。

どうやらMagnussonがこんなことを言うのも、Google App Engineのユーザの中には、それにいくつかの制約が伴っていることを、嫌っている者がいるかららしい。ランタイム環境が独特だし、システムコールができない、ファイルシステムへのライト(write)ができない、オペレーティングシステムを選べない…。

Magnussonは、GoogleがGAEというサービスを提供するためにはロックインが避けられない、と言う:

ある程度のロックインなしに革新的なプラットホームを作ることは不可能だ。たとえばDatastoreは、そこらにあるそのほかのNoSQLやNearSQLサービスやスタックと似ていない。レプリケーションが複数のデータセンターで同期する、カーソルがある、ディスティンクトクェリ、プロジェクションクェリ、ジグザグマージJOIN、トランザクションタスク、自動シャーディング/ロードバランシング、マネージドセカンダリインデクス、マルチロウ/マルチマシントランザクションなどなど、いずれも独特だ。これらの機能を犠牲にして何らかの最小公分母で妥協することはできない。ベースとなっているソフトウェアの機能を十分に生かせる機能を、なるべく多く提供したいのだ。

GAEは、そのほかのPaaSプロバイダ、たとえばCloudbees、Heroku、6月にCenturyLinkが買収したAppFogなどと横並びで比較される。しかしGoogleは、手作業的な操作やインフラの管理など、そのほかのサービスが特長としている側面をあえて抽象化している。そこで、Googleのアプリケーションサービスには、ユーザが直接できないことがいくつかある。それらの部分は、ユーザのファイアウォールに代わってGoogleが担当し、DoS攻撃やウィルスなどを防いでいるからだ。

Magnussonの主張ではそのために、モバイルアプリやWebアプリケーションの多くが、立ち上がりが速くて、スケールするのも速い。スケールや、アプリケーションを別のデータセンターに移動させることなどは、すべてGoogleが面倒を見る。

しかし実際の問題は、ユーザをプロプライエタリなプラットホームに閉じ込めてしまうクローズドで独特なAPIだ。Twitterの上でぼくの質問に答えてくれた人たちの多くが、何らかのロックインは避けられないという点では同意している。

@alexwilliams

— Pete Johnson (@nerdguru) July 10, 2013

[訳]: ロックインのレベルはプラットホーム自身よりも顧客のユースケースに依存する面が大きい。データの重力の影響はそれほどでもないし、ツールがマイグレーションを十分に助けてくれる。

AWSはロックインのあるサービスとして挙げられている:

@alexwilliams

— Jack Clark (@mappingbabel) July 9, 2013

[訳]: AWSが独自のエコシステムを築こうとするやり方も、事実上のロックインだ。

ThinkJarのファウンダで主席アナリストのEsteban Kolskyによると、ロックインの最小化はオープンスタンダードで可能だが、現状のマーケットに関してそれを言うのはまだ早すぎる:

共通の規格を使えば理論的にはロックインは起きないが、まだそういうものを採用している企業が少ない。

自分が提供するプラットホームにある程度のロックインを設けることは、ベンダの利益に貢献する。今のライセンス方式では、ロックインによる“縛り”がないとユーザが流動的になりすぎて、売上の予測ができない。売上が今のクラウドが約束しているように（すでに小さなベンダが実行しているように）単純明快な従量制なら、ユーザは必然的に複数のベンダからつまみ食いする使い方になるので、ロックインは存在できなくなる…ただしそれも、現状ではあくまでも理論だ。しかしAmazonとRackspaceを比較しても分かるように、ロックインが今でも相当厳しいのは、プラットホーム(PaaS)よりもインフラストラクチャ(IaaS)の方だ。

また、ロックインにはユーザの利益もある。とくに企業のIT部門は身軽な移行ができないし、それを迫られてもいない。

だからこの問題は、エンタプライズソフトウェアの問題は何でもそうだけど、ユーザやベンダの目先の利便性をとるか、それとも経営トップや市場など最終受益者の利益を優先するか、という問題に帰結する。

ロックインという問題は、クラウドサービスのプロバイダにつねにつきまとう。OpenStackも、今後のプラットホームの多様化（Red Hat、IBM、Cloudscaling、HP、Rackspaceなどなど）とともに、結果的にロックインを余儀なくされる。

Magnussonも、スタンダードの重要性は認めつつ、まだそれを言うのは時期尚早だ、と述べている。たしかに、そんな見方もありえるだろう。

しかし、多くのベンダが今の市場で学びつつあるのは、あるクラウドから別のクラウドへデータやアプリケーションを移動させるサービスの重要性だ。そして複数のクラウドベンダが、顧客の要求の高度化により、互いの相互運用性を優先的に重視せざるをえなくなれば、彼ら全体が一つのエコシステムとして成長し、繁栄していくことになるだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

ボットネット対策のSeculertが$10Mを調達–Hadoopでログを分析

マルウェアに対する先進的なセキュリティを提供するSeculertが、シリーズBで1000万ドルを調達した。幹事会社Sequoia Capitalに加え、既存の投資家Norwest Venture Partners(NVP)もこのラウンドに参加した。同社の最初の資金はYL Venturesからのシード資金だったが、今では総資金が1540万ドルに達する。

Seculertは、elastic data net（伸縮性のあるデータネットワーク）というものを作り上げ、それが、以前は検出できなかったようなマルウェア攻撃を発見する。そのサービスはボットネットのトラフィックを監視し、その中に顧客のIPアドレスを探す。顧客のIPアドレスがあったら、その顧客が攻撃されていることになる。ボットネットのトラフィック中に見つけた攻撃関連のデータはSeculertのクラウドに送られ、顧客はWeb上のダッシュボードからそのデータにアクセスできる。またそのAPIにより、メールで通知をもらうこともできる。

クラウドにはこのように、複数のアプリケーション間の境界を融解する効果がある。あるサービスがほかのサービスを消費し、それによって集積されたデータをまた別のサービスに送り込んだりする。Seculertもこのやり方で、顧客が独自に使っている別のマルウェアウェア撃退ツールからのデータを、顧客にアップロードさせ、Seculert自身がそれを利用できるようにしている。

たとえば顧客がBlue CoatやSquidなど別のツールのログファイルをSeculertのクラウドにアップロードすると、SeculertはそのログをHadoopの分析機能で分析し、それらのツールが看過した攻撃を見つける。

Seculertは、企業のITに対するセキュリティサービスの、新しいタイプの代表格だ。Seculertは、いろんなソースからのデータ中にある関連性を探し、進行中の攻撃を見つける。ほかにZettasetなども、Hadoopベースでデータ管理とセキュリティサービスを提供している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

デベロッパがクラウドを生かす; その逆ではない–Oracle/Salesforce批判

今週（米国時間6/23-29）はOracle/Salesforceの連携を契機にクラウドの話題が盛り上がったが、でもそれは、クラウドの実態から見ると、かなりずれた話ばかりだった。クラウドを支えているのはデベロッパであり、その逆ではない。

大物たちが手を組むのも、今やそうせざるを得ないからだ。それは既存の顧客にサービスを提供していくための、守りの姿勢だ。それは、老いたる王たちが新しいソフトウェアのライセンスで稼ぎを増やす、という前向きの話ではない。合従連衡してクラウドからレガシー技術を提供していくのは、まあそんなクラウドの使い方もあるね、という程度の話にすぎない。

彼ら独特のクラウドの定義によると、大きなITを抱える大企業が旧タイプのデータベースの新しいバージョンを手に入れて、10年も15年も前にインストールしたソフトを動かす、という筋書きになる。デスクトップやクライアント/サーバの時代に作られたオペレーティングシステム*を、クラウドサービスとして新たに鋳込むことはたしかにできる。古手のSaaS企業（ここではSalesforce）がオンプレミスの旧敵（ここではOracle）と組んで、過去14年間順調に動いていたものが次の二世代およびそれ以降もそのまま良好に使える、と嬉々として語るのもよい。何かをしなければならない会社は、牛がいればカウベルをつけたくなるものだ、それにはきりがない。〔*: operating system, ここではコンピュータのOSではなく、ITオペレーション(DevOpsのOps側に相当）のベースとなるシステム。具体的にはRDBMSを軸とする業務系システムのインフラ。〕

しかし、このような、レガシーデータベースによるオペレーティングシステム（業務系）とCRMが手を組む動きは、イノベーションではない。それは単にステータスクォーを保全し、彼らがこれまで数十億ドルを稼いできた源泉であるパンとバター（ご飯と味噌汁）的な定番的事業を提供するにすぎない。真のイノベーションは、新しいジャンルのデータベースにあり、デベロッパフレームワークに、ソーシャルなコーディングサービスに、データ分析によりコンテキスト対応力を持ったAPIに、などなどにある。クラウドに価値がない、と言っているのではない。価値なら、たくさんある。クラウドは、その価値ゆえに買われる。計算処理とストレージの費用低減、という価値だ。Joyentの料金は、今や月でも年でもない、秒単位だ。

しかしそのインフラストラクチャの底の方を見ると、そこにすらデベロッパの仕事のきざしがある。たとえば、ソフトウェア定義データセンターの話題が盛り上がっている。それは、金属製のスイッチではなくソフトウェアがデータセンターを構成し、そのAPIがすべての要素を結びつける、というコンセプトだ。APIが、ネットワークと、データストアと、ありとあらゆる形のクライアントやデータベースや等々を結びつける。今や、ネットワークの働きでアプリケーションが構成され機能する。昔とは逆だ。

そうやって巨大なマシンもパイプも抽象化され、その変化をデベロッパが引っ張る。あの小さなスマートフォンが、今やサーバだ。JoyentのProject Mantaが示しているように、大きなストレージとネットワークマシンがオペレーティングシステム*の一部になりつつある。計算処理とストレージが一体となり、インメモリデータベースが分析を瞬時に行う。〔*: operating system, 前記訳注参照。〕

Just.meのファウンダKeith Teare（本誌TechCrunchのファウンダの一人）が、今週のGillmor Gangで、クラウドは定数だが、やることは毎回同じとはかぎらない、と言っている。たしかに、最近のクラウドの使い方は変わりつつある。クラウドの消費のされ方が、変わってきた。クラウドを使うアプリケーション、デバイス、クラウドにプッシュされ〜〜からプルされるデータが。クラウドはデータのインテグレータ（メッセージバス）でありデータストアだが、今ではブラウザだけから消費されるものではなくなっている。

Andreessen HorowitzのパートナーPeter Levineが先週のインタビューで、15〜20年前にはMicrosoftとWinAPIがすべてだった、あらゆるプログラムやAPI呼び出しがWindows詣でをした、と言った。しかし今では、APIはおびただしく多様化している。今は、何をするにもそのためのAPIがある、と期待する。そしてそのことが、開発を加速する。

今年は、デベロッパの年だ。GitHubの会員が一日に約1万ずつ増えている。Levineの説では、クラウドという雲を高みに押し上げたのは、この、噴火して盛り上がるようなデベロッパたちの軍勢だ。クラウドのプロバイダたちは、その価値を提供してデベロッパの関心に沿い、するとデベロッパはますます多くのアプリケーションを作る。アプリケーションが増えれば、ますます多くのクラウドサービスが必要になる。スマートフォンのメーカーやキャリアも、充実したデベロッパコミュニティを育てることに関心がある。デベロッパの作品が増えれば、彼らのデバイスや時間の売上も増えるからだ。Levineは、上流がデベロッパ、下流がアプリケーション等のユーザ/ユーザ企業だ、と言う。

だから、今度また、レガシーのプレイヤーたちが嬉々としてクラウドはすばらしいと宣（のたま）う記事を見たら、よく考えてみよう。レガシーのクラウド化もそれなりにすごいことではあるけど、でもそこに、新しいクールなものを作るデベロッパがいなければ、無意味だ。ポケットにあるスーパーコンピュータが、われわれを世界につなぐのは、デベロッパが作りだすイノベーションがあるからだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

AzureのもとでOffice 365がプログラマブルなサービスになることにより, アプリケーションのラピッドデリバリを実現

Microsoftは、Office 365とWindows Azureを使ってビジネスアプリケーションを構築する、という方法を今後提供していく。それは、同社のクラウド環境を有効利用してラピッドビルド(rapid build, 高速構築)を提供するサービスの一環だ。

MicrosoftのCEO Steve Ballmerは、Buildカンファレンスの初日の水曜日（米国時間6/26）に、ラピッドデリバリがMicrosoftの主要テーマの一つである、と述べた。そして木曜日にMicrosoftは、Windows Azureを利用してOffice 365をプログラマブルなサービスに変え、アプリケーションの統合とWebサイトの管理を迅速に行うやり方をデモした。その取り組みは、GoogleがGoogle Appsとサードパーティのサービスを統合するやり方を思い起こさせる。

そのデモではたとえば、PC MagazineのMichael Millerの指摘によると、Visual Studioで作ったアプリケーションが“Office 365のドキュメントやそのほかの情報を利用する”…つまりアプリケーションがOffice 365の機能を借用する、というやり方を見せた。Azureでアプリケーションを作るんだけど、そのアプリケーションの主機能はOffice 365からそっくり借りるので、ビルドもデリバリも速い、というわけだ。

木曜日のキーノートとデモは、エンタプライズを強調したクラウドが主役だった。サーバとツール事業部の社長Satya Nadellaがキーノートを担当し、そのあと、Visual Studioの新機能や、オートスケール、オンプレミスのソフトウェアをSaaS環境と統合するBizTalkサービスの使い方、などのデモが行われた。データサービスもちらりと見せたが、しかしそれはGoogleやAWSが提供している強力なサービスに比べるとまだ弱い、と見えた。

しかしMicrosoftの方向性は正しい。Office 365をWindows Azureに、いわば前者を後者の機能コンポーネントとして押し込むのだが、そのことによってカンファレンスに来た者には、Microsoftの将来にとってのAzureインフラストラクチャの重要性が、いやが上にも伝わってくる。またそれは同社のマーケティングのテーマとしては、AzureはWebサイトやWebアプリケーションをクラウドとエンタプライズ環境にまたがって開発するためのプラットホームとして使えますよ、という訴求になる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

データサイエンティストのいない企業でもHadoopを有効利用できるビッグデータ分析サービスDatameer

最近は、データサイエンティストでないふつうの人にデータ（とくにビッグデータ）分析を提供するプラットホームが増えているが、Datameeerもその一つだ。コンピュータといえば仕事でスプレッドシートを使うぐらい、という圧倒的多数のコンピュータユーザが、こうやって徐々に本格的なデータ分析に接近しつつある。

Datameer 3.0には、“Smart Analytics”（スマートアナリティクス）と呼ばれる機能があり、それによって、データサイエンティストたちがつねに自分でゼロから計算するようなワークを、あらかじめ組み込んでいる。そろそろ、こういう抽象化〜ラッパー化があってもよい頃合いだ。Hadoopの普及率は今ではとても高いから、今度はそうやってそのアクセス性が向上すべきだ。

そのための重要な課題が、雑多なデータの統合化だ。すべてのデータを集めて、それらを分析可能に整理すること。また物理面では、サーバクラスタのセットアップ、という課題もある。さらに、技術者でない者にも理解できるユーザインタフェイスも必要だ。そしてもちろん、分析結果がユーザの仕事に活をいれる、有益なものでなければならない。

Datameer 3.0のSmart Analyticsは、以下の4つの方法でデータ分析を単純化する:

レコードをクラスタ化してデータ集合中に有意なグループが見られるようにする。データは、位置データ、写真、顧客のオペレーティングシステムなどさまざまだ。このクラスタ化により、ユーザはたとえば顧客リスト中の顧客データを有意義に分類できる。
デシジョンツリーが目的とする結果を表示し、その中の多様な要因を分析して、デシジョン（意思決定）に導く過程を一望する。
カラムディペンデンシー(column dependencies, カラム間依存関係)により異なるカラム間の関係を表示し、データ間の、それまで自明的ではなかった結びつきを明らかにする。たとえば、位置と疾病タイプの関係や、職階とクレジットスコアの関係が分かったりするだろう。
ユーザの履歴データに基づいて、次はどんなものに関心を持つかを予測し、個人化されたリコメンデーションを生成するような、リコメンデーションエンジンを提供する。この機能により企業ユーザはユーザに対し、より関係性のあるより有意義なリコメンデーションができるようになる。社内にデータサイエンティストがいなくても。

CEOのStefan Groschupfが今日（米国時間6/24）のブログ記事で、市場の現状について述べている。Hadoopはそのほかの技術と同様に進化してきているので、今や何かをスクラッチで（==ゼロから）作る必要はない。Hadoopベースのサービスの中には、カスタム化ができず、長期的なメンテナンスが困難なものもある。しかし今では、Hadoopを企業がより現実的に活用できるためのサービスもあるのだ、と。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

煩瑣な処理のクラウド化自動化, それによるITの軽量化, そこに次世代スタートアップの商機が–GigaOm Structureカンファレンスより

GigaOm主催のStructureカンファレンスで、午前中（米国時間6/20）6社が3名のVC審査員の前でプレゼンをした。その3名は、Sequoia CapitalのパートナーLuis Robles、Lightspeed Venture PartnersのパートナーBipul Sinha、そしてHummer Winblad Venture PartnersのマネージングディレクターAnn Winbladだ。

優勝したのは、新しいDevOps*プラットホームを提供するSaltStack、そして会場の人気投票ではFactor.ioが入賞した。〔*: DevOps参考記事。〕

以下に、今日のステージに立った各社を簡単に紹介しよう:

28msec: 企業の全データソースをインターネット上で統合化する。データの…必要部分の…取り出し、プリプロセス、JSONオブジェクトへの変換、MongoDBへのクェリ、などをサポートする。昔の、バッチ処理による古いタイプのデータ取り出し法に替わる新しい方法だ、という。

AppScale: 事故復旧企業が提供する、クラウド上のアプリケーションとデータのためのフェイルオーバー。その最初の商用製品はGoogle App Engine用のバックアップ。

Factor.io: アプリケーションのクラウドへの展開過程を単純化し、デベロッパが収益生成部分に注力できるようにする。

MetricaDB: SQLによるデータ統合化サービスで、クラウド内のコンソールの役をする。サービスを分析し、結果をデータベースのような表形式にする。たとえばこの方式で、OptimizelyとStripeを統合化できる。

SaltStack: 優勝作品のDevOps。クロスクラウドで、どんなクラウドでも使える。

Synapsify: テキスト分析技術により、Webサイトの全体的な価値を評価し、調整もする。競合コンテンツに対してクォリティを定量化する。

これら新進スタートアップのプレゼンにほぼ共通しているのは、重い処理や複雑な処理をクラウド化により自動化するサービスだ。今はどの企業も、アプリケーションの展開や分析はより簡単にしたい、と願っている。またインフラの管理も、少人数でやれるようにしたい、と考えている。そういう願望に対応していくのが、これからのスタートアップたちだ。

大量のデータが至るところにある。しかし、それらをなんとか管理可能にしたい/管理下に置きたいというニーズが、スタートアップたちの取り組む課題になっている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）