Amazon Web Services(AWS)がNode.jsによるSDK/オブジェクトライブラリを提供

Node.jsは今や、アプリケーションを開発するとき誰もが使っている。それはサーバサイドのJavaScriptだ。比較的おぼえやすいので、とても人気がある。今回はAmazon Web Services(AWS)が、Node.jsによるSDKをリリースし一般公開した。

あるブログ記事によると、AWSは12月のプレビューリリース以降、さらに機能を増強した。新しい機能は、バウンドパラメータ、ストリーム、EC2インスタンスのIAM roles、バージョンロッキング、プロキシなどだ。AWSによると、このSDKはAWSのサービス(Amazon S3, Amazon EC2, DynamoDB, Amazon SWF)のJavaScriptオブジェクトを提供して、デベロッパのコーディングを単純化することが目的だ。

Node.jsはその、イベント駆動型のノンブロッキングI/Oにより、アプリケーションのスケーラビリティを支え、しかも、スレッドやタイムアウトのポーリング、イベントループなどをプログラマは扱わずにすむ。だからこそ、大きな人気を獲得した。とくにゲームデベロッパに愛好者が多く、AmazonのCTO Wener Vogelsは、3月にAWSがElastic BeanstalkでNode.jsを提供したときに書いた記事の中で、そのことを説明している。Vogelsによると、Elastic BeanstalkはElastic Load Balancing、Auto Scaling、EC2などのAWSリソースのプロビジョニングとモニタリングと構成を自動化する”。彼によると、デベロッパたちはNode.jsの機能を利用することによって、レイテンシ（ネットワーキング待ち時間）の低い複数の並列的接続を実現している。UberやVoxer、それにDataheroのようなエンタプライズ向けスタートアップはすべて、サーバの実装にNode.jsを使っている。

Node.jsのサポートを提供しているクラウドプロバイダはAWSだけではない。Joyentはこのプラットホームを企業向けサービスの一環として提供している。Windows Azureもビッグなサポーターだ。Rackspaceもサポートしている。3月にMicrosoftは、Windows Azure Service Busを使うオープンソースの寄与貢献物を提供した。それは、Node.jsによるリアルタイムアプリケーションのためのスケールアウトをサポートするライブラリだ。

AWSが今回Node.jsによるSDKを一般公開したことは、デベロッパ界隈における、Node.jsというプラットホームの実力を物語るエピソードの一つだ。つまり、デベロッパを相手にするビジネスでは、もはやNode.jsを無視できない。これで、AWSをベースに開発〜プログラミングをするデベロッパが今後増えることは、ほぼ確実だ。

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

データの高速化について現場最先端の６社が語る

このごろは、何ごとに関してもスピードが重視される。つまり、今でも、ネットワークからデータをかき集めるよりもFedExで送ってもらった方が速いことがある。データを飛行機で運んだ方が速いという、うそみたいな事実が、今でも実際にあるのだ。

数テラバイトのデータを転送するだけなら、丸一日とか一晩かかることはない。でもフィーチャーフィルムの収まった複数のハードディスクを単純に“大陸間移動”することと、正しいデータを取り出し、それを分析し、何かのアプリケーションでプレゼンすることは、状況や抱える問題がまるで違う。スマートフォンの爆発的普及や、言葉の違いなどの障壁、3Dプリンタ、データオブジェクトの限りない多様化と集積、などなど、現代は、データ移動と言っても後者のような複雑な処理ニーズを伴うものが、圧倒的に多くなっている。

このようなデータ移動の複雑性に対応するために多くのアプリケーションは、RAMやフラッシュメモリの有効利用に傾いている。ハードディスクは、もはや古いのだ。ハードディスクの機械的な部品は、現代の企業が分析するデータの量や速度に対応できない。データベースも、完全なメモリ常駐型など、新しいものが登場している。スタートアップだけでなくSAPのような伝統的なIT企業も、それらの開発に取り組んでいる。そしてNoSQLデータベースが、今ではデベロッパたちのコミュニティでは人気者になっている。

しかしアプリケーションのパフォーマンスやデータ分析のスピードを左右する要素は、非常に多面的だ。最近FirstMark Capitalの常勤パートナーになったMatt Turckは、先週ニューヨークの同社のオフィスで行ったインタビューで、物のインターネット(Internet of Things, IoT)がデータ転送の総量を爆発的に増大させる、と言った。彼はそのとき、その兆候としてMQTTの登場を挙げた。この、IoTのための通信プロトコルは、The New York Timesによると、“マシンツーマシン通信のための共通語であるだけでなく、データ交換のためのメッセンジャーでありキャリアだ”。

MQTTの作者は、ワイト島にある16世紀に作られた彼の藁葺き小屋をIoTで自動化しようとしているときに、メッセージングのプロトコルが必要だと気づいた。

物といえば、子どもが床に転がして遊ぶ、あのボールなどを連想するが、しかしTurckによれば、それはボールのような無表情なデータ片ではなく、それ自身の社会的な（かけがえのない、他と同じでない）自己同一性を持ち、いずれは何兆ものほかのオブジェクトと接続することになるデータオブジェクトだ。子どもが壁にぶつけてあそぶSpaldeen〔≒スーパーボール、ビックリボール〕のようなものではなく、それは何かのアバターにもなるデータオブジェクトだ。でも、このボールなどさまざまなオブジェクトから渡されるすべてのデータを、全世界規模で想像すると、それが簡単にゼタバイト級のディメンションになってしまうことが、理解できるだろう*。〔*: したがって通信方式はどうしてもメッセージング（==非同期）方式になる。〕

今では、何ものにも増して重要な話題かつ課題と思われる、IoTなどを契機とするデータ通信量の爆発的増大について、一部のエキスパートたちに話を聞いてみた。しかし彼らの視点は未来よりもむしろ、今まさに起きつつあることに向けられている。

MemSQL

4月の終わりにMemSQLは、同社のリアルタイム分析プラットホームを一般に公開した。このプラットホームは、インメモリデータベースと分散インフラストラクチャを使って大量のデータを分析する。そのデータベースは、スピード重視のアーキテクチャだ。

MemSQLのCEOで協同ファウンダのEric Frenkielは、最近の10年間で大規模なデータ保存技術に重要な改善が見られた、と言う。“企業は圧縮した列保存〔参考〕とHadoopを使って大量のデータを保存し、データの保存と分析を行っていない企業に対して競合上優位に立つようになった”、とFrenkielは言う。“しかしビッグデータは、データ量が十分に多くてしかもアクセス可能でないと無益だ。今企業が苦労しているのは、ビジネスの変化の速度にデータ処理のスピードを合わせること、後者を十分に速くすることだ”。

彼によると、企業がますますデータに依存するようになると、増大する一方のデータに正しいタイミングで対応するために、より高速なデータベースを必要とする。“大量データの保持（リテンション）と保存（ストレージ）という問題が解決されると、次の課題はスピードだ”、とFrenkielは言う。“ハードディスクをフラッシュストレージで置換するとある程度速くなるが、しかし本当に必要なイノベーションはデータを保存し分析するソフトウェアの進化だ”。

MemSQLは、データ分析のためのインテリジェンスとして機能するアグリゲータだ。データ分析は複数のノードにわたってオーケストレーションされ、それらがアグリゲータのコマンドを実行する。各データノード自身は何も知らない（処理インテリジェンスを持たない）、単なる歩兵である点がすばらしいのだ、とFrenkielは言う。

“企業が今インメモリコンピューティングに注目しているのは、それがビッグデータ問題を解決するための新しいアプローチだからだ。インメモリコンピューティングは速度という成分を解決するが、しかし、量という成分を満足させるためにはスケールアウトのためのアーキテクチャが同時に必要だ”。

彼によると、今企業は、既存のソリューションを利用しつつ、データウェアハウスを最新の高速化データベースで拡張して、高速なデータ分析により意思決定の高速化を支えようとしている。“これからは、データ分析が高速で、トレンドや異状を速く見つけられる企業が勝つ”、と彼は言う。“大量のデータを分析しなければならない、という状況は今後も変わらないが、今では速度を重視したアーキテクチャにより、重要な発見や洞察がリアルタイムで得られるようになっている”。

Enigma

Engima は、先週行われたDisrupt NY 2013で優勝した。協同ファウンダのHicham Oudghiriによると、スピードのニーズの背後には必ず、データ量の絶えざる増大というニーズがある。しかし彼によると、EnigmaやPalantirなどが抱えるスケールの問題は、多くのスタートアップが日々直面している問題とまったく異なる。

“ふつうスケールというと、ユーザ数が数千、数万、数百万と増えていくことへの対応だ。だから、問題の形は、どの段階でも同じだ”、とOudghiriは言う。“複数のサーバを並列で動かすとか、予備機を増やすといったワンパターンの対応になる。Webサーバの稼働のラウンドロビン化、CloudFlareのようなCDNの利用、Amazonのようなオートスケール方式でトラフィックのピークに対応する、などなどの方法がある。しかしユーザ数ではなくてデータ集約的なアプリケーションでは、問題がまるで逆になる。スケーラビリティの問題はユーザ数ではなくて、一つのクェリのために何十億もの行を調べるという問題になる。さらにしかも、集めてくるデータの形式や性質や内容がそれぞれバラバラで不統一、という問題に遭遇することも多い”。

彼曰く、これらの問題には、サーバの台数を増やすなどの単純な解はない。ただし、データの保存という点では、冗長性が何よりも重要である。

“唯一の正しいモデル、というものはない。SQLかNoSQLかグラフデータベースか、という選択の問題でもない”、とOudghiriは言う。“それらをすべて使うこと、それぞれに適した役所（やくどころ）を与えることが重要だ。そうやって、各方式の持つ利点を最大限に利用しなければならない。データベースを、一つの理想的なシステムと見なすのではなく、それぞれの声が互いを補い合うことによって生まれる“ハーモニー”だ、と考える。一つの問題を解くときに、頭の中にはつねに、効果的に使い分けられる複数の道具がある、という柔軟性がとても重要だ”。

“第二に、RAMが自分の親友だと考えること、パーシステンシ(persistency,データのオフメモリの持続的存続)はサーバのクラスタで実装することが重要だ（サーバはパーシステンシのための装備であり、実稼働はもっぱらオンメモリで行う）。うちでは、検索のスケール（規模拡大）をRAM内で行っている。今は、メモリがとても安いから、それが十分に可能だ。ただしそうなると、RAMに保存したデータのパーシステンシを確実にメンテできるソフトウェアの構築が、重要な課題になる”。

しかし、中には、RAMのコストを問題視する人びともいる。この点について、彼に聞いてみた。

“部分的にSSDも使っているが、非常に水平的な検索（列よりも行指向）では十分に速くない”、とOudghiriは言う。“しかも、SSDは、こっちが事前に予期できないタイミングでパフォーマンスが急に落ちる。それに比べるとRAMはまったくパーシステントではないけど、むしろノンパーシステントだからこそ頼りになる。リスクと、得られる利点との、トレードオフだね”。

10gen

10genの見方は違う。10genは、NoSQLデータベースMongoDBのスポンサー企業だ。10genの技術部長Jared Rosoffは、スピードには少なくとも二つの側面、アプリケーション開発とアプリケーションのパフォーマンスがある、と言う。

“MongoDBのアプリケーション開発が速いことには、異論がない”、とRosoffは言う。“データモデルに柔軟性があり、ドライバが定型化されていることにより、デベロッパの生産性が高く、機能の改良も速い”。

アプリケーションのパフォーマンスに関しては、MongoDBは余っているメモリのすべてを最近使ったデータのキャッシュに使うので、メモリが十分に大きければインメモリの高パフォーマンスが達成される。

しかしRosoffによると、ワークロードが大きくなるとDRAMはけっこう高いものになる。

“でもビッグデータの仕事を完全にインメモリのデータベースでやろうとすると、十分な量のDRAMを使わざるを得ない。問題は、一台のサーバに載せられるRAMの量に限界があることと、RAMの費用そのものだ。MongoDBは、ディスクやフラッシュストレージを使って、一台のサーバの上で相当大きなデータ集合を処理できる。MongoDBの顧客の多くが、SSDやFlashストレージデバイスを使って、比較的安く、インメモリに近いパフォーマンスを達成している。

また、MongoDBの（NoSQLの）ドキュメント型データモデルではデータのローカリティ…局所性…を維持できるので、複雑なデータモデルと違ってディスクI/Oの回数が少ない。これも、ハイパフォーマンスの重要な鍵だ。

SlashDB

SlashDBは、関係データベースのAPIを作る。ファウンダのVictor Olexの説では、ユーザが求めるスピードはデータベースそのもののスピードに帰結する。

“データアクセスの速度は距離（ネットワークのレイテンシ）だけでなく、ファイルシステムやデータベースからデータを取り出すのに要する時間と、その間のデータ変換の量（フォーマットの変換、エンコード、デコード、圧縮など）にもよる。また、データの取り出しの効率は、データ構造の実装にもよるし、間接参照の少なさも重要だ*。とくに今のデータベース上のエンタプライズデータは（そのデータ構造が）、Webを利用する情報システムにとってボトルネックになっている。関係データベースは宣言型（not手続き型）のクェリができるので便利だが、そのためにインメモリでもディスクからでも、必要なレコードを取り出す計算費用が高くなる。逆にNoSQLのようなドキュメント型のデータベースは、一般的に数値キーでデータを取り出す。データを保存するときに数値を割り当てて、数値とデータを対照するルックアップテーブルを作っておくのだ”。〔*: 直接参照は「n番地にあるデータを読め」、間接参照は「n番地にあるデータに書かれている番地にあるデータを読め」。〕

“さまざまなキャッシング技術がデータアクセスのスピード向上に貢献しているが、そこには精度の低下という費用が発生する（目的データがキャッシュにないこともある）。たとえばWebページでは、キャッシュには古い日付のものしかないことが、よくある。でもそれは、実際にデータベースにアクセスして最新データを取り出す処理費用との、トレードオフという問題だ。我慢できるトレードオフ、と言うべきか。キャッシングとWebアプリケーションのレイヤはスケールアウト(out)して同時に複数のサーバを動かせるから、複数のリクエストを並列に処理できるが、しかしデータベースサーバの方は、一台のサーバの容量やプロセッサを増強するというスケールアップ(up)しかできない。SlashDBは企業のシステムにWeb型のサービスを提供している。つまりURLの中にクェリがあり、結果をHTTPのレスポンスで返す、という形のサービスだ。それは複数のノードでも動かせるし、通常のHTTPプロキシにも対応して、頻用されるリクエストをキャッシュしている”。

“データ集約的な処理は主に、サーバサイドのシステムの領分だった。モバイルデバイスの普及で状況はやや変わってきたが、しかしそれでも、人間の情報処理能力は昔と変わらない。一説ではそれは、毎秒60ビットと言われる。だから、それ以上速いスピードでデータを配布しても意味がない、無駄である、という説もあるのだ。Twitterやメールだけは、別かもしれないがね”。

AlchemyAPI

“AlchemAPIはスピードにこだわっている”、とCEOでファウンダのElliot Turnerは言う。“うちの顧客はみんな、情報の時間価値を知っている。だからデータをできるだけ速く処理することとうちの業績は直接結びついている。しかしデータ処理アプリケーションをもっと速く動かすための簡単な秘訣はない。ボトルネックはいろんなところで発生する。データの保存、取り出し、分析など、いろんな局面で”。

“データの分析の効率化にはさまざまな方法があり、GPUによるハードウェアアクセラレーションや、分散コンピューティング、アルゴリズムのイノベーションなどいろいろだ。AlchemyAPIはこれらすべてを組み合わせて利用するとともに、RAMやSSDを多用することによってデータの保存、取り出し、そして処理を高速化している”。

“RAMは着実に価格が下がりつつあるが（http://www.jcmit.com/mem2013.htm）まだSSDよりも一桁高いし、ハードディスクよりは二桁高い。ペタバイト規模のビッグデータを完全にRAM上で処理するのは、ちょっと費用的に無理かもしれないから、うちも含めてRAMとSSDを併用するハイブリッド方式のところが今は多い。でも、テラバイト規模の小さな展開では、徐々にRAMオンリーに変わりつつある。今後さらにRAMが安くなれば、展開規模も大きくできるだろう”。

Efficient Big Data Analysis (Gluecon 2012) from alchemyapi

まとめ

データ処理の高速化の話は、SSDやRAMや最新のデータベース技術だけで終わるものではない。しかし、一つだけ確かなのは、世界が高度に分散したデータメッシュになり、そしてその負荷が日に日に増大するとともに、新しい高速化の方法が必ず必要になることだ。

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

MicrosoftのWeb開発ツールWebMatrixがバージョン3となりGitHubをサポート

Microsoftが、無料のWeb開発ツールWebMatrixの最新バージョンWebMatrix 3をリリースした。新バージョンではWindows Azureとの統合がより深くなり、そしてGitHubをサポートした。

WebMatrixのユーザはWindows Azureからサインインして最大で10のサイトを無料で作れるようになった。それらのサイトは、ローカルにでも、あるいはWindows Azureからでも管理できる。

WebMatrix 3では、デベロッパが自分のサイトをリモートでエディットできる。すなわち、ヴィジュアルなサイトギャラリーというものが提供され、ユーザは自分のローカルなマシン上に既存のサイトを開けるし、あるいはWindows Azureでホストされているサイトをリモートで編集することもできるのだ。

Windows Azureのブログによると、これまでもっともリクエストの多かった機能が、バージョンコントロールシステムのサポートだ:

TFS(Team Foundation Server)とVisual StudioがGitをサポートしたことの発表に続き、さらにWebMatrix 3がGitとTFSの両方をサポートする。これらによるソースコントロール体験はエクステンションとして提供される。弊社は複数のパートナーとの協働により、CodePlexとGitHubの充実したサポートを提供する。

Windows Azureのブログはさらに、Gitの利用はユーザの緊急リポジトリと構成と既存のツールもカバーする、と述べている。コミット、ブランチ、マルチプルリモート、そしてWebサイトのWindows Azureへのパブリッシュもサポートされる。

WebMatrixは2010年に導入され、ASP.NET、PHP、およびNode.jsによるWebサイト開発をサポートする。Windows Azureとのより深い統合は、Microsoftとしての標準のパターンだ。同社はますます多くのツールをWindows Azureに持ち込もうとしている。たとえば先月Microsoftは、Windows Azure中でActive Directoryを正式にサポートする、と発表した。

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

単一アプリ方式のモバイル開発プラットホームとは？–ユーザはアプリを求めていない,という新世代哲学に立つMowbly

最近ローンチしてDisrupt NY 2013にも出たMowblyは、モバイルの開発プラットホーム環境に、従来とは逆のアプローチをする。

協同ファウンダのVignesh Swaminathanによると、次々といろんなアプリを垂れ流すのではなく、Mowblyはそのモバイル向けPaaSからたった一つのアプリを提供する。Mowblyはサードパーティのアプリもサポートするが、そのサードパーティアプリのAPIを呼び出してデータを処理するだけだ。ユーザ自身は、それらのアプリを使わない/動かさない。ユーザが求めているのは正しく処理されたデータであって、アプリを自分で動かすことではない。それが、Mowblyの異端哲学。

要するにMowblyは“アプリアグリゲータ”であり、データを顧客やその社員やパートナーのためにフィルタしてからアプリを通し、その結果をユーザに提示する。しかもこのサービスはクロスプラットホームであり、アプリを構築〜管理〜展開するためのモバイルサーバと、モバイルのユーザインタフェイスフレームワークから成る。複数のモバイルプラットホームにまたがって利用でき、その際、専門的なモバイル開発の技能は要らない。ユーザである顧客企業のIT部門はデベロッパを雇うことなく、ブラウザ上のツールを使ってアプリを展開する。

一つのユーザ企業が複数のIDを持てるので、たとえば財務の人には企業のリソース計画関連のデータを提供し、パートナー企業には流通経路計画に関する情報のアップデートを提供する、など多面的な活用ができる。MowblyのPaaSが提供するその単一アプリは、オンプレミスのソフトウェアまたはSaaSとして提供される。

Mowblyは新世代のモバイルプラットホームプロバイダの一つで、迅速なアプリ展開のためのバックエンドを提供する。それにより、ネイティブアプリを作るために必要な費用と時間を削減する。またこの単一アプリ方式では、大企業がITポリシーへのコンプライアンスを維持しやすい。

これはまた、モバイルアプリ開発の自動化の始まりでもある。そのトレンドを代表しているのが、Mowblyだ。問題は、プロバイダのコントロールがあまりにも大きすぎるのではないか、ということ。そして、人びとが日常使っているアプリに加えて、アプリが実際には今後どんどん増えていくのではないか、という懸念もある。

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

ファイルやデータを複数のクラウド間で移動するサービスKloudless

今日（米国時間4/29）Disrupt NY 2013でデビューしたKloudlessは、異なるクラウドを結びつけるコネクタサービスで、ユーザはメールを使ってクラウド間のデータ移動ができる。

このサービスを利用するためには、Outlookでは専用のプラグインを、 Gmailなどではブラウザのエクステンションを使う。Kloudless自身にはデータやファイルは保存されない。あくまでもコネクタないしパイプとして機能するだけだ。

Kloudlessはiftttなどのサービスに似ているが、しかしそれほどきびしい自動化はせず、メールからクラウドサービスへのデータフローをユーザがかなりカスタマイズできる。つまり、データ移動に関しユーザに自由、柔軟性を与えることがねらいだ。たとえばSalseforce.comにデータを放り込むときには、その前にそれなりのカスタマイズが必要だろう。CEOのEliot Sunによると、同サービスはたとえば、アクセス分析ツールからのデータをYammerのようなサービスのディスカッションに持ち込むこともできる。

VC企業Draper Fisher JurvetsonのTim DraperとYammerの協同ファウンダDavid Sacksはこのアイデアをとても気に入り、同社にシード資金を提供した。同社のこれまでの資金調達額は90万ドル弱だ。Draperらは、Kloudlessが市場に打ち込まれる楔となり、企業が必要としていた自動化と柔軟性を提供する、と見ている。またこのサービスは、カスタマイズを伴うデータガバナンスを提供する。企業が必要とするコンプライアンスのために何らかの統合化を行う場合でも、そのほかの自動化システムにできない自由性がある。

Kloudlessは、技術的にはクラウドのための“メッセージバス”だ。メッセージバスはシステムに常在するレイヤで、イベント駆動型で動くミドルウェアだ。イベント、たとえば何かのリクエストが発生すると、メッセージバスを起動して正規化されたデータが目的の場所へ、適切なコンテキストで送られる。Tibcoのように、メッセージバス技術で財を成した企業もある。

またMulesoftやSnapLogicはトップダウンのシステムを提供している。しかしKloudlessは、ボトムアップ方式だ。消費者向けアプリケーションのようにダッシュボードを管理職たちやチームリーダー、IT部門などに提供して、データのオーナーシップやワークフローを分かりやすく可視化し、また複数のアプリケーションにまたがるポリシーの設定機能も提供する。

Kloudlessは、料金体系も消費者アプリ的だ。無料版があり、機能のより充実した有料版は月額3ドルからだ。そのネットワーキングの基盤は既存のメールサービス/アプリケーションだから、企業の管理職たちにとって買いやすくて使いやすいサービスだといえる。

Sunは、消費者向けアプリケーションも構想している。最初はクラウド検索を考えたが、あまり売れなかった。しかしKloudlessのようなファイル移動サービスには、需要がありそうだ。今ではベイエリアで行われるイベントや、あるいは大企業のデータ設計担当者たちに売り込みをかけている。

Kloudlessの経営者たちは、CEOも含めて、見た目にはまるで高校の同窓会ふうだが、でもGlideのCEO Eli Rubelが先週、同社についてこう言った: “データは嘘をつかないからね”。

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

今、起こりつつあるAPIエコノミーとか何か？

何という2週間だったろうか。しばらくの間くすぶって何かが起こった。API市場が爆発したのだ。IntelはMasheryを1.8億ドル以上で買収し、CAはLayer 7を買収した。3ScaleはJavelin Venturesから450万ドルの資金を新たに調達した。MulesoftはProgrammable Webを買収した。そしてついにFacebookもこれに加わりParseを買った。

これらの買収や出資は、アプリケーション界に広がるAPIの遍在によって、ある市場が成熟しつつあることを暗示している。それは決して新しい市場ではない。この分野は過去数年間に構築されたAPIをてこにしてきた企業に埋めつくされている。むしろこれは、変曲点というべきだ。主要APIディレクトリーのProgrammable Webによると、現在APIは3万種以上ある。Javelin Venturesのマネージング・ディレクター、Noah Doyleは私のインタビューに答えて、アナリストらはAPI市場が今後5年間で5～10倍に伸びると予測していると語った。

こうしたAPIの規模拡大によって、魅力あるアプリとAPIを作るデベロッパーにとって好循環が生まれる。APIは分散データネットワークの一部となることによってアプリのリーチを広げる。そのAPIを使う人が多くなるほど、アプリ開発者はより多くのデータを生み出す。データの利用範囲が広がればそのサービスはAPIになる可能性が高まる。

Facebookは、新たなデジタル製品を送り出し続けるために新しいデータの流れを必要としている。Parseのような〈サービスとしてのバックエンド〉プロバイダーは、デベロッパーが基本データタイプや位置情報、写真などを保存するインフラストラクチャーにアクセスするSDKとAPIを提供する。どうやってFacebookがこのデータを利用するかは未だに疑問だ。しかしそれでも、ParseはParseプラットフォーム上でAPIを使用するアプリに育まれた活気ある安定データ源としての役目を果たす。今後このデータをどのようにパッケージ化、セグメント化し、その10億ユーザに対して効果的な広告を送り出すかを決めるのはFacebookだ。

APIは接着剤のようなもの

APIはインターネットの接着剤になる、とProgrammable Webのファウンダー、John Musserは言う。Musserは、Doyleと同じくこれを、モバイル端末の需要から生まれ様々な面で新しいクライアント・サーバーの役割を演じる新しい世代のAPIとして期待している。それらのアプリは、クラウドサービスでホスティングされ、モバイル端末に配信されデータを読み書きし、情報を送受し、API経由で互いにつながりあう。

第一世代では、MasheryやApigeeなどの会社がAPI管理分野の先陣を切った。Twitterをはじめとするウェブ企業が第2世代を形成した。第3の波では、IntelやCAといったエンタープライズ企業がこの大きな動きを察知し、ハードウェアとソフトウェアシステムをつなぐべく市場に参入した。

今やAPIの動きはアプリケーションや機械レベルの下方に向かっているとDoyleは言う。それは〈物体のインターネット〉が出現するレベルにまで来ている。あらゆるものがプログラム可能になり、データの送受信、統合、そして動作のトリガーが可能になる。

3Scaleが提供するAPI管理システムでは、デベロッパーがその上にロジックを作ることできるとDoyleは言う。これを使うとデベロッパーは、あれこれ手を加えることなく、APIにそのままデータセットやサービスを追加できる。

APIエコノミー

この動きの高まりは、Apigeeの戦略担当副社長、Sam Ramjiが提唱に一役買った用語、〈APIエコノミー〉を象徴している。Ramjiは、APIとAPIインフラに注目する人々の数はこの一週間で2倍になったかもしれないとメールに書いた。「APIを持っていない会社のCIOやCTOがニュースを読めば、こう自問するはずだ、『わが社もやらねば』と」

Darwin's Finches, 20th Century Business, and APIs from Sam Ramji

そして、彼らにとってAPIを構築するならMashapeやWebshellなどのサービスを使う方が簡単だ。Doyleは、自ら立ち上げたKeyholeが買収された後の3年間をGoogleで過ごした。Googleでは、Google EarthとGoogle Mapsの開発に関わった。

「われわれは地図を軽量なJavaScriptとして公開した」とDoyleは言った。「一種の埋め込みコードのようなものだと考えた。クールですばらしいと思っていたが、あまりの普及の早さにショックを受けた。」

Google Mapsを広く利用されたのは、使いやすかったからだとDoyleは言った。デベロッパーが洗練されたアプリを簡単に作るしくみを組み込んでおくことは、今や最良の慣行だ。

複雑さは避けられない

しかし何もかもが簡単とはいかない。開発が複数のAPIにわたるにつれ複雑さが待ち構えている。MuleSoftはこの穴を、同社のAPIhubで埋めようと考えている。

先週私が書いたように、MuleSoftにとってProgrammable Webとの提携は、同社が〈APIのためのGithub〉と呼ぶAPIhubをProgrammable WebのAPIデータベースと統合し、関連市場でメディアの注目を集めるための好機だ。Programmable Webにとっては、同社のAPIデータベースをMuleSoft APIhubプラットフォームを使ってアプリを開発するコミュニティーへと広げ安定した環境を作り出すことができる。この統合プラットフォームによって、APIの組み込みを容易にしコミュニティーでの協業を促進できると同社は期待している。

アプリケーション・ライフサイクル管理（ALM）のインテグレーター、Tasktop Technologiesは、ソフトウェアのライフサイクル管理プロセスの中で異質なツール群を結び付ける、Software Lifecycle Integration（SLI）というオープンソースの取り組みを開始した。このプロジェクトはオープンソース・プロジェクトのEclipse-Mylynの一部となりM4と呼ばれている。

TasktopのCEO・共同ファウンダー、Mik KerstenはSLIについて、異なるツール間でのリアルタイム同期を可能にする汎用データメッセージバスとして機能し、コードに問題が発生した時にはすぐに対応できる、と評価している。APIエコノミーの発展と共に生まれてくるのが、下支えとなるこうした統合プラットフォームだ。過去2週間にわたる数々の買収と出資は、モバイル機器だけでなくわれわれの生活にある物事ともつながるアプリの開発を真に簡単にするためには、この複雑さを解決する必要があることを示唆している。

[原文へ]

（翻訳：Nob Takahashi）

AWS利用のリソースと費用とセキュリティを分析するCloudCheckrが$2Mを調達

Amazon Web Servicesの複雑さを克服することが、一つのビジネスになりつつある。その新人選手CloudCheckrは、AWSに欠けているリソース分析/費用分析/セキュリティ分析のためのツールを提供し、最近200万ドルの資金を調達するとともに、そのフリーミアムサービスの一般公開にこぎ着けた。200万ドルのシリーズAを仕切ったのはGarrison Capital、そこにGenesee Capitalが参加した。

顧客がAWSを使い始めたとすると、時がたつにつれて、自分が展開したものの全体的な健康診断が、そう簡単にはできないことに気づく。情報は得られるが、それらの構造も相当複雑だ。そこで、CloudCheckrがお助けに参上する。

ユーザが最初にすることは、CloudCheckrからでもアクセスできるように、AWSを構成することだ。

そして次に、報告形式を構成する。必要なモジュール、たとえばリソースの監視、などを指定する。複数のサービスのモニタもできるし、その展開のすべてのリージョンを監視できる。結果はダッシュボードにグラフィカルに表示される。

たとえば「EC2概要報告」は、リソースのサイズ、購入タイプ、リージョン、プラットホーム、AMI、費用などを教える。「詳細報告」は、さらに個々のインスタンスという粒度で、これらの項目プラス、ローンチタイム、利用状態レベル、付随しているEBSのボリューム、IPアドレスなどを教える。

CloudCheckrには費用とベストプラクティスのモジュールもあり、こいつがとりわけ便利なようだ。このモジュールではCloudCheckrが顧客の展開の様態を、AWSで行われているベストプラクティスと対比して評価する。また、例外的事象をチェックして顧客にアラートする。

CloudCheckrは、AWSのモニタリングというこの新しい急速成長市場で、 CloudabilityやNewvemなどと競合する。

Cloudabilityは、社員が利用しているオンラインサービスの状況を一望する。それを見てCFOは、会社のどの部署がどんなサービスのアカウントを持っているか（IaaS, PaaS, SaaSなど）を知ることができる。アカウントは、個々に、あるいは個人レベル〜部署レベルで組み合わせた状態で検分できる。そしてその報告がCFOに、サービスの詳細な費用分析を提供する（サービス別、アカウント別、ユーザ別など）。そして、費用が突出している部分などを教える。

Newvemはとくに、顧客のAWSのインスタンスをモニタする。たとえば昨年同社はAWS用のGoogle Analyticsのようなサービスの提供を開始した。そして顧客のAWSの契約全期間にわたる基準的な最適利用量を見つける。また、それを満たすマシンやインスタンスのタイプを判定する。インスタンスの最適な地理的配分も判定する。以上を要約するとNewvemは、AWSと長期契約を結ぶ前の、さまざまな量的質的判断を助ける。

Get Satisfactionのオペレーション担当VP Jonathan Clayによると、CloudCheckrはAWSの利用状況を総合的に見るためのポータルのようなサービスで、リソースの使われ方やその費用などを報告してくれる。また、インスタンスの混み具合や空き具合を見て、最適容量のリコメンデーションもする。予備インスタンス(reserved instances)の確保量に関するリコメンデーションも提供する。総じて、このサービスを利用すると企業は、費用やリソース利用の無駄をチェックでき、またセキュリティのためのベストプラクティスの遵守状態も知ることができる。

CloudCheckrを利用すると、AWSの内部をリソースと費用とセキュリティの側面から検分する作業が楽にできる。AWSを有効に利用しようと思ったら、それらのチェックが欠かせない。ただしAWSの点検管理サービスはほかにもいろいろあるから、ユーザはそれぞれの得意技を、まず調べるべきだ。

CloudChecklrの料金体系は無料から始まる。プロフェッショナルアカウントは月額会員制だ。そしてエンタプライズアカウントはオーダーメイドである。

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

AWS利用のリソースと費用とセキュリティを分析するCloudCheckrが$2Mを調達

ユーザが最初にすることは、CloudCheckrからでもアクセスできるように、AWSを構成することだ。

たとえば「EC2概要報告」は、リソースのサイズ、購入タイプ、リージョン、プラットホーム、AMI、費用などを教える。「詳細報告」は、さらに個々のインスタンスという粒度で、これらの項目プラス、ローンチタイム、利用状態レベル、付随しているEBSのボリューム、IPアドレスなどを教える。

CloudCheckrは、AWSのモニタリングというこの新しい急速成長市場で、 CloudabilityやNewvemなどと競合する。

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

IBM、フラッシュ技術の研究に10億ドルを投資。ハードディスクの陳腐化を反映

IBMはフラッシュメモリの研究、設計、製造に10億ドルを投資し、同社のサーバー、記憶装置、ミドルウェア等へ統合していく計画だ。同社が巨大データを管理するために必要な要件の変化を反映している。

このニュースの中でIBMは、新しいフラッシュ機器の製品ラインも発表した。このストレージ機器はTexas Memory Systemsから取得したテクノロジーに基づいている。IBMによると、新ハードウェアはハードディスクドライブより20倍高速で、最大24テラバイトのデータを保存できる。

この投資は、モバイルアプリやウェブの普及により画像や動画、無数のテキストメッセージ等が生み出されるようになり、多くの会社が膨大な量のデータを管理するより良い方法を必要としている現状を映しだしている。

長年情報処理を機械式ハードディスクに頼ってきたシステムにとって、これらのデータが主要なボトルネックになっている。ハードディスクシステムは、システムがERPや経営管理ソリューションなど、トランザクションベース・システム向けの垂直型製品であった時代には何の問題もなかった。今日、市場は水平に分散しデータは何万というサーバーに広がっている。

IBMはサーバーおよびミドルウェア市場で長い歴史を持っており、今新たにストレージに焦点を当てた。しかし、これは誰のためなのだろうか？ニュースを見ると、目的は既存顧客のサポートと思われる。これらの顧客は、クレジットカード処理、製造、運用など大規模な企業リソースの計画を必要とするシステムに長期的な投資を行ってきている。

IBMのフラッシュへの投資は、各企業が自社で処理するデータに合わせて戦略を修正している様を示している。Facebookはインターネット規模のアプリケーションを処理するためにフラッシュを使用している。IBMは、大型銀行のデータセンター、工場その他の大規模な事業のソフトウェア運用にフラッシュを利用する方向だ。2つの利用場面は異なるが、データを管理してわれわれの生活や仕事のやり方に組み入れたい、という普遍的なニーズによって結びつけられる。

[原文へ]

（翻訳：Nob Takahashi）

日本のHapyrusがAmazon Redshiftへのデータロードを自動化するサービスFlyDataを立ち上げ

Hapyrusがこのほど立ち上げたFlyDataは、ペタバイトサイズにまでスケールできるデータウェアハウスサービスAmazon Redshiftへの、データのアップロードとマイグレーションを自動化してくれる。

Amazonの主張では、アナリストたちが今日使っているものと同じSQLベースのビジネスインテリジェンスツールを使って各種サイズのデータセットを分析するとき、Redshiftならクェリのパフォーマンスを高速化できる、という。Hapyrusの協同ファウンダKoichi Fujikawaによると、同社のサービスであるビッグデータルータを使用すると、Redshiftをさらに効果的に利用でき、HadoopとHiveを使うよりもお得である。HadoopとHiveの組み合わせは、データの処理分析環境として、これまで多くの人に高く評価されてきた。

FlyDataはバックグラウンドで動き、データをRedshiftに運ぶ。Fujikawaによると、HapyrusはAWS上に仮想プライベートクラウドをセットアップする。顧客は自分の仮想プライベートネットワークをそれに統合してデータを転送する。

Hapyrusは、InformaticaやTalendなどと競合する。現在はAWSとの統合がメインだが、今後はさまざまなソースのデータを統合できるようになる。Fujikawaの説明では、InformaticaやTalendは大企業の、主にオンプレミスのシステム向けに、複雑なデータ統合化ソリューションを提供している。しかし、“弊社は、Redshiftのようなクラウド成分に対するデータ統合化サービスを、企業のサイズを問わず提供する。スタートアップでもよいし、比較的大きな企業でもよい”、と彼は語った。

Fujikawaによると、RedshiftはHadoop+Hiveよりも10倍速くできる。H+Hの顧客たちは、毎日行う日常的なデータ処理をもっと高速に行える代替製品を求めている。H+Hを使っていると、クェリの時間と費用が大きな経営妨害要因として彼らの前に立ちはだかる。

しかし、Redshiftそのものにも複雑性はある。それについてルームレンタルのAirbnbは次のように語る:

まず、Redshiftにロードするデータは、すでにS3やDynamo DBの中にある必要がある。デフォルトのデータロードはシングルスレッドなので、相当長時間かかることもある。データを分割してパラレルでロードすると速いことをわれわれは見つけた。

Airbnbのナード的なブログには、Hadoopにある機能がRedshiftにない、と書かれている。しかしRedshiftはデータアナリストたちに好まれているため、もっぱらそれだけを使っている場合が多い。Airbnbのブログ記事は最後の方で、RedshiftとHadoopは意外と互換性が高いのではないか、とも書いている。

しかしDrawn to Scaleの協同ファウンダBradford Stephensは、“RedshiftはデータウェアハウスだからVerticaやGreenplum、AsterData、Impala、Hadapt、CitusDataなどと比較すべきだ”、と言っている。“Hadoopとは全然違うものだ”、と。

スタートアップたちの売上や利益は大企業に比べると微々たるものだが、しかしときにはHapyrusのような企業が出現して、Amazon Web Servicesの新しい使い方によって、独自の顧客ベースを堅実に築いていく。ビジネスの一件々々の額は小さくても、その技術力はユニークで高い。

Hapyrusは500 Startupsの育成企業で、DeNA（年商40億ドルのインターネット企業）の協同ファウンダShogo Kawadaなど高名な日本のエンジェル投資家たちから、エンジェル資金を獲得している。

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

Heroku、全ユーザーにPostgreSQLのセキュリティーアップデートを強制適用

Herokuのユーザーは、PostgreSQLデータベースシステムの主要セキュリティーホールを修正する重要なアップデートをいち早く利用できる。一般のPostgreSQLユーザーは、木曜日（米国時間4/4）にアップデートが利用可能になる。

Herokuの声明は以下の通り：

Heroku Postgresデータベースに、月曜日（4月1日）から水曜日（4月3日）にかけて小規模だが重要なアップデートを適用する。アップデート中データベースは約60秒間オフラインになり、その後再起動される。本アップデートの性格上、正確な時間を定めることはできない。修正が必要なデータベースに対する個別の通知は送らない。

先週木曜日、PostgreSQLサイトは、4月4日にアップデートを発行し、そこには重大なセキュリティー脆弱性の修正が含まれているという声明を発表した。利用者はできるだけ早くこのアップデートを適用するよう同サイトは強く推奨している。

私はHerokuの広報チームに、なぜ強制アップデートを行うのか、および最初に適用される理由を尋ねたが、まだ回答はない。

Hacker Newsのコメント人たちは、早期アクセスの理由はでPostgreSQLデータベースを利用しているHerokuユーザーの数が膨大だからだろうと言っている。

しかしこの特権は、PostgreSQLのセキュリティー、および誰が早期に利用できるかに関する同社のポリシーに疑問を投げかけるものでもある。

Hacker Newsのあるコメント人がこう言っている。

一方でPostgreSQLは、同じようにセキュリティーを非常に深刻に捉えている数多くの会社を待たせている。これは、PosgreSQLの使用を考えている会社に「セキュリティー修正をすぐに受けられるのか，それともより重要なユーザーが早期に利用している一方で故意に危険に曝されるのか？」を考えなくてはならない状況を作り出している。私にはよい前例だとは思えない。

これはHerokuにとって異例の行動であり、クラウドのセキュリティーが重大問題であることを示す顕著な例だ。Herokuのような会社がこうした強制アップデートを発行することは稀で、その殆どはプラットフォームに対する主要なアップデートだ。しかし今回のようなセキュリティー脆弱性はプラットフォーム全体に影響を与ぼす可能性がある。

[原文へ]

（翻訳：Nob Takahashi）

珍しく初期段階で却下された特許訴訟: 数学的アルゴリズムは特許を取れないと

連邦判事がRackspaceに対する特許侵害訴訟を却下し、数学的アルゴリズムは特許の対象にならない、と裁定した。東部地区(Eastern Disrict)におけるこの裁定は、2012年にUniloc USAが行った告訴に対するもので、その訴えは、Linuxオペレーティングシステムによる浮動小数点数の処理は特許の侵犯であると主張していた。

首席判事Leonard Davisはこの裁定の根拠を、数学的アルゴリズムの特許取得を禁じている合衆国最高裁の判例法としている。Rackspaceによれば、これは、テキサス州の東部地区連邦地裁が、特許を取得できないものへの特許を主張しているとして、裁判の初期段階で告訴を却下した例としては、報告されているかぎりにおいて初めてのものである。

LinuxをRackspaceに供給しているRed Hatは、Rackspaceの弁護費用を負担した。Red Hatは、同社のOpen Source Assurance事業に基づいて、顧客を擁護することをポリシーとしている。

Red Hat法務部の知財担当次長Rob Tillerは、次のように述べている:

“不実施主体(NPE)訴訟は慢性化しており、テクノロジ業界にとって深刻な問題になっている。この種の訴訟は認められてはならない特許に基づいていることが多いが、その弁護費用は通常、数百万ドルにも達する。これらの訴訟は、イノベーションと経済成長と雇用機会の創出を妨げる疫病である。法廷は、初期段階において特許の有効性を判定して、適切な処置をすることにより、この問題に対応できる。今回の事案においては、判事Davisがまさにそれを為し、未来の案件に対する優れた例を設定した。”

特許訴訟は合衆国の古めかしい特許制度につけ込む悪質な行為となっている。今回のような却下はまれであり、特許訴訟において法廷が特許の種類を区別することもまれである。

Unilocにコメントを求めたが、無応答である。

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

エンタープライズ向けアクセラレーターのAlchemist、第2回クラスの 9組が発表

今私はAlchemist Acceleratorグループの第2回クラス9チームによる発表を聞くために、カリフォルニア州サンタクララにあるCitrix本社に来ている。これは選りすぐりのB2Bスタートアップのためのアクセラレーターだ。

Alchemistグループは、ベンチャー支援による新しい取り組みで、シード段階のエンタープライズ・スタートアップの開発支援に集中している。支援者は、Cisco Systems、Draper Fisher Jurvertson、Khosla Ventures、SAP Ventures、およびUS Venture Partner。同グループのルーツはサンフランシスコのハーバードクラブで、アイビー・リーグ等の名門校出身の技術系ファウンダーや学生を対象にしている。

今日発表する9社は以下の通り。

Tylr Mobile：エンタープライズ向けモバイル業務プラットフォームで、メール等の使い慣れたツールを、ビジネスに必要なデータやプロセスと連携させる。
Sourcery：食品ビジネスの発注、調達を簡単にする。旧来のエンタープライズシステムを、ユーザーフレントリーなソフトウェアやクラウド、モバイルベースのアプリで置き換え、食品業界を21世紀に導く。
Eduora：エンドユーザーに焦点を絞った学習管理システム。様々な学習アプリを統一したインターフェースで使える企業内学習向製品を開発。
Zipongo：パーソナライズされた食事メニューを提供し、ヘルシーな食品を買うと特典がある。
Chronon：JVMのあらゆる実行状態をフライトデータレコーダーのように記録する。従来のログファイルは不要。
MightyHive：消費者マーケティングの自動化。エンタープライズ規模でのみ利用できるデータを使ったクロスチャンネル広告の自動化、最適化、および測定を行う。
Purple：モバイル顧客エンゲージメント・プラットフォーム。AppleのPassbookなどのモバイル財布を活用して顧客を引きつける。
Stratio：初のポータブル赤外線センサー。コスト1/0000以下、6桁以上の低消費電力、現テクノロジーの4倍の分解能を持ち、スマートフォンで健康状態のモニタリングを可能にする。
MonkeyBook：Facebookのタイムラインを簡単にeブックにして友達に配れる。ソーシャルデータからクラウドソースで作ったストーリーで人間の記億を置き換える。

イベントの報告は後報の予定。

[原文へ]

（翻訳：Nob Takahashi）

AWSが多売で薄利をまたスケールアップ, DBのストレージとIOPSの上限を3倍に

Amazon Web Services(AWS)は、Relational Database Service(RDS)のデータベースインスタンスに対して配備できるストレージの最大量を、これまでの3倍にする。

AWSのブログには、ストレージのI/OスピードIOPSも3倍にする、と書かれている:

今後作成するDBインスタンス（MySQLまたはOracle）は、ストレージの最大量が3TB（これまでは1TBまで）で、最大30000IOPS（これまでは10000）となる。SQL Serverを使うDBインスタンスは、最大ストレージが1TB 7000IOPSとなる。m2.4xlargeの上のリード/ライト各50%のワークロードに対しては、Oracleで最大25000IOPS、MySQLで12500IOPSとなる。しかしながら30000IOPSの配備では、レイテンシの低下とスループットの向上が可能となる。実際のIOPSは、データベースのワークロード、インスタンスタイプ、使用するデータベースエンジンの違いに応じ、何を配備したかによって異なる。詳細については、Amazon RDS User GuideのFactors That Affect Realized IOPSを見ていただきたい。

AWSのユーザはデータベースの既存のインスタンスに関し、ストレージとIOPSの変更が可能である。それはユーザが、高速で予測可能なパフォーマンスを得られるためだ。

また、ストレージとIOPSのどちらかを単独でスケールすることも可能だ。

RDSは、MySQLやOracle、そしてSQL Serverを使ってデータベースをセットアップ、管理、そしてスケールする際の、“面倒な低レベル作業”をすべて肩代わりする。

上記3つの機能は、今すでに利用できる。IOPSの配備（プロヴィジョニング）が可能なリージョンならどこでもOKだ。

ストレージとIOPSのリミット3倍化は、顧客が保存し処理するデータの質・量に応じた最適インフラを提供していくという、AWSの近年のポリシーの一環だ。この”コスト重視“のコンセプトは、AWSが掲げるアーキテクチャでもある。そのことは、今回の最新アップデートにおいても明らかだ。

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

もはや自前で仮想化は古い?, AWSがEC2の仮想プライベートクラウドをレディメイドで提供

amazon-web-services-copie

Amazon Web Services(AWS)がこれから提供するオプションにより、AWSのユーザなら誰でも、自分の仮想プライベートクラウド(virtual private cloud, VPC)を持てる。VPCは、ユーザが利用するEC2のインスタンスの一つのタイプになる。これまでVPCは、別サービスとして提供されていた。

VPCを使って顧客ができることは、AWSの言葉によると、“論理的に隔離されたEC2のインスタンス群の仮想ネットワークで、それに顧客自身のデータセンターからVPNで接続することも可能”、というものだ。これは、物理的なセンター群を仮想化して自前のエラスティックなインフラを作る、データセンター中心型の方式の再検討を顧客に迫る。自前主義は、ソフトウェアのライセンス、ハードウェアの費用、システムを管理するITスタッフ、といったコストの問題に帰着する。VMwareなどはこういう、‘仮想化はユーザ各社がやれ’という主義を広めてきた。仮想化技術が売りだから、当然だが。

AWSのやり方は、違う。顧客に、AWSの低コストと柔軟性というアドバンテージを与えつつ、今顧客が使っているインフラをそのまま使えるようにするのだ（下図）。

VPC_Diagram

顧客が使うEC2インスタンスは、”EC2-VPC”プラットホームと呼ぶものの中へローンチする。この機能はリージョンごとに展開され、最初はアジア太平洋（シドニー）と南アメリカ（サンパウロ）だ。展開は数週間後に始まる。

その処理は自動化されるので、顧客自身がVPCを前もって作るという作業はない。むしろAWSによれば、顧客はこれまで(EC2-Classic)と同じく、単純にEC2のインスタンスを立ち上げ、Elastic Load BalancersやRDSデータベース、ElastiCacheのクラスターなどを配備（プロビジョン）するだけだ。するとVPCが、特別の課金を伴わずに作られる。

ここから顧客は、一つのインスタンスに複数のIPアドレスを割り当てる、セキュリティグループの帰属関係を平常稼働を妨げずに行う、セキュリティグループに外部フィルタを加えるなど、仮想化特有の機能を利用できるようになる。

AWSによると、VPCでは既存のシェルスクリプトをそのまま使え、CloudFormationのテンプレート、AWSのElastic Beanstalkアプリケーション、Auto Scalingによる構成なども、従来どおりに使える。

VPC機能が使えるのは、AWSの新規顧客と、既存の顧客だがそのリージョンでインスタンスをローンチするのは初めて、という顧客だ。

“エンタプライズ市場は過去12〜18か月で様変わりし、CIOたちはクラウドコンピューティングを受容するようになった”、SXSWのステージでそう語るのは、NEA VenturesのゼネラルパートナーScott Sandellだ。それは何を意味するのか？　彼によると、データセンターに関するこれまでのエンタプライズ技術がすべて陳腐化する、というのだ。AWSの今回の動きも、このような市場のシフトに対応するものであり、それは、インフラに自前で高価な投資をすることに比べて、クラウドを有効利用するサービスのほうが価値が高い、と暗に示唆している。

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

営業（個人/チーム）がセールスコミュニケーションの過程を管理できるFileboard

fboardlogo

今朝（米国時間3/5）は、VMwareがSlideRocketをClearslideに売る、という記事を書いた。Clearslideは、セールス〜営業の人たちが関連資料やプレゼンテーションをアップロードし、エディットし、成績を分析できる、というサービスだ。昨日、Fileboardの協同ファウンダたちに話を聞いたら、同社もClearslideみたいなサービスへ方向転換をする、という。

Fileboardは、企業のCRMシステムの一角に座を占めて、営業に迅速なフィードバックを提供するサービスだ。Clearslideと同じように、さまざまな業種業態の営業マン〜セールスマンが有効に利用できる。それはいわばクラウド上に提供されるコラボレーションのためのプラットホームで、営業が送ったプレゼンテーションに対する顧客のその後の対応や営業アプローチへの反応を随時、追尾記録できる。Clearslideと違うのは、その上でスライドの編集はできないことだ。

しかし協同ファウンダのKhuram Hussainによると、Fileboardは営業のためのプレゼンテーションのプロバイダではなく、営業と顧客とのあいだのコミュニケーションを支えるサービスだ。だから機能的に、スライドの編集などには、こだわらない。むしろファイルを単純にアップロードして、プレゼンテーションを顧客と共有することがねらいだ。

ただし、スライドのアップロードや並べ替えは簡単にできるし、それを顧客の画面上で“上映”することもできる。

fileboarddemo.layout

営業がアップロードしたファイルは、顧客がリンクをクリックしてアクセスできる。下図は、ユーザ（営業マン）がファイルのリンクを作るためのフォームだ。

Fileboardfilelink

また、クリックスルーのアクセス分析ができるから、そのプレゼンが何回見られたか、が分かるし、共有の状況も分かる。

flipboardanalytics

チームの成績も、グラフで分かる:

Fileboardteamperformance

顧客からの、対話やフィードバックによるデータにより、プレゼンテーションが効果を上げた部分や、逆に、だめだった部分を判断できる。管理職は、個々の営業マンの成績とFlipboardから送られたプレゼンの効果を対照できる。

Fileboardは画面の共有をサポートし、BoxやDropboxを統合しているので、プレゼンテーションのアップデートを自動化できる。またCRMシステムに記録を残すことも、自動的に行える。

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

VMwareの経営者たちがAmazonを攻撃, でもその吠え声はうつろに響く

Image1 for post Only The Paranoid Are Scared Of TV Everywhere

VMwareは最近のAmazon Web Servicesのエンタプライズ市場進出に対して、過剰に戦々恐々しているようだ。

CRNの報道によると、VMwareのCEO Pat Gelsingerは、今週行われたあるパートナー企業のイベントで、顧客がワークロードをAmazonに移すたびに、そのパートナーはVMwareを失うだけでなく、自分のビジネスを永遠に失うのだ、と述べた:

Gelsingerはこう言った: “われわれは企業のワークロードを自分の手の中に持っていたい。それらが、あのような安っぽい日用品的なパブリッククラウドに移ってしまえば、われわれは完全に負けだ。われわれは自分たちのフランチャイズをプライベートクラウドからパブリッククラウドへ拡張し、顧客に両方の利点を提供していきたい。わが社にしか提供できない、そのようなユニークなサービスにより、企業のワークロードを今および永遠に、手中にしていたい”。

VMwareの社長でCOOのCarl Eschenbachは、ずばりこう言う:

今日この席にお集まりのみなさまは、企業世界におけるVMwareブランドの高い評価をご存じです。ですから、私たちが一致団結すれば、本を売っている会社を打ち負かせられないことは、ありえないでしょう。

これらの言葉には、破れかぶれのようなトーンがある。これらの言葉は、聴衆に、VMwareのプロダクトへの信頼を植え付けるよりもむしろ、不安をかき立てるだろう。しかもそれは、必要のない言葉であり、それに、あまりにもベタだ。

Gelsingerは、AWSのハードウェアは安物の日用品だ、とけなす。Eschenbachは、Amazonは本を売ってる会社だ、と軽蔑する。どちらも正しくない。

今ではAWSだけでなく、GoogleもRackspaceもFacebookも、日用品的なハードウェアを使っている*。安いし、ソフトウェアを動かしやすいからだ。ソフトウェアを作るのはデベロッパだ。そしてデベロッパが作っているのは、労働者たちが自分のGalaxyスマートフォンやiPadから使うアプリケーションだ。今では、ハードウェアをオープンソース化しようとする動きすらあり、OpenComputeような団体が関心を集めている。だからハードウェアは今後ますます安くなり、そしてイノベーションを加速する。今や、ハードウェアのハッカソンが行われる時代だ。〔*: 日用品的なハードウェア, Sun SPARKのような高価なサーバ専用機でなく、一般市販のx86機のこと。〕

消費者向けアプリケーションには日用品的ハードウェアが最適、という説がこれからは一般化するだろう。アプリケーション/アプリは、職場にも家庭にも、どこにでも転がっている。職場と家庭の境界も、曖昧になる。安いハードウェアが市場を支配するのも、当然だ。

Eschenbachの発言は、良く言っても陰険だ。今のAmazonは、本も売っているデータ企業だ。本のほかに、コンピューティングパワーとストレージとハイパフォーマンスコンピューティングのためのサービスも売っている。Hadoopのジョブやデータウェアハウスの能力も売っている。

私が話をしたVMwareの社員は、パートナーイベントではあのようなレトリックがふつうにある、と言った。でも、VMwareがなぜ、AWSの悪口を言うのか？　最近のVMwareは、おかしくなってしまったのか？

要するに、問題はコストだと思う。VMwareは、ライセンス料が高い。エンドユーザのコストを下げられるための、マルチテナントインフラがない。AWSは薄利多売型だから、たくさん安く売ることによって稼ぐ。

また、エンドユーザ側の選択の幅も問題だ。VMwareには、AWSが提供しているような各種サービスの深さがない。だから、その高料金を正当化できる根拠も実はない。

GelsingerらVMwareの経営陣がAWSをいくらけなしても、彼らの真の脅威は新世代のクラウドインフラストラクチャからやってくる。それは、ときにクラウド、ときにデータセンターでもあるようなインフラだ。OpenStackとCloudstackにはそのエネルギーと、新しいクラウドの活気がある。それが、エンドユーザ企業の新しい仕事のやり方にアピールする。ForresterのアナリストJames Statenが、いみじくも書いている:

平均的な企業のvSphere環境は、その企業のI&OチームがvCloud Directorを採用している場合でも、セルフサービスではない。それは、完全に構成された環境への迅速なアクセスを提供しない。それはChefのスクリプトを扱えないし、費用的にも、Visaカードで5ドルといった大衆的な大量トランザクションには向いていない。VMwareと企業のvSphereアドミニストレータが、新しいエンタプライズソフトウェアをつかまえるためには、彼らは考え方を変えて、ラジカルで企業文化的には困難なシフト、すなわちインフラストラクチャ管理からサービスのデリバリへのシフトを達成する必要がある。クラウドを悪者視するのではなく、クラウドから学ぶのだ。

パブリッククラウドの敵視は、vSphereアドミニストレータの立場を強くするだけであり、最前線のデベロッパにアピールしたいのなら、そのような敵視は間違いだ。vSphereをそのまま（プライベート）クラウドに乗せて、コスト構造に透明性がないまま、ワークロードのデプロイやヘルプデスクからのリクエストへの対応に二日もかかっているようでは、毎日々々、パブリッククラウドに負けることになる。

VMwareは今、ソフトウェア定義データセンターに注力して他社との差別化を図ろうとしている。VMwareの経営陣は、その取り組みをプレゼンすべきであり、AWSとそのエンタプライズ進出に対する不安をさらけ出すのは得策とは言えない。

しかしもっと重要なのは、VMwareが新しいクラウドに合わせる努力だ。空しい閧(とき)の声は、VMwareの深い弱点を表しているだけであり、AWSなどの新勢力は、その弱みに乗じ続けるのだ。

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

ビッグデータ分析の現場実践本がやっと出た–O’ReillyのBad Data Handbook

datacenter

ビッグデータはまだまだ難しくてよく分からない、と一般には受け取られているが、それも当然だ。その複雑さをシンプルに抽象化するやり方の例はいくつかあるが、しかしデータサイエンティストたちの話を聞いても、彼らですら、スプレッドシートに毛の生えた程度のものを見るだけのために、いまだにツールの勉強に苦労している、と言う。

フリーのデータサイエンティストMarck Vaismanが、あるインタビューで言っていたが、多くの人にとってビッグデータが難解なのは、技術の複雑さのせいだけではなく、人間の側の取り組み姿勢にもその原因がある。多くの場合、そのデータの使い方を理解している人は、ほんの少ししかいない。しかも、その人たちの説明能力は高くない。また、データ分析に総合的な視野から取り組んでいる企業はほとんどなく、複数の小さな断片的なプロジェクトがそこらに散乱していて、その方式に標準性がなく、互いに重複していたり、企業や部門にもたらす価値が何もなかったりする。

陥穽（落とし穴）は至るところにあり、重要な基本が忘れられている。Vaismanは最近O’ReilyからThe Bad Data Handbookと題する本を出版し、その中でビッグデータ分析の十戒ならぬ五戒を述べている。

この混乱の中で、ベンダたちは自分のプロダクトやサービスの速さや能力を自慢している。でも企業が本当に必要としているのは、目の前のデータ量と、分析結果がフィードされるアプリケーションの速さをマッチさせられるような、調整能力のある分析アプローチだ。データ分析のベストプラクティスを構築したAccentureの役員たちは、上のビデオと同じくStrataの会場で、短いインタビューに応じてくれた。

データは、戦略的な資産として活かす必要がある。Strataのようなカンファレンスにコンサルタントの姿が多いことは、まだかんじんの顧客企業側が、ビッグデータ分析ベンダたちの語る美辞麗句を、よく理解していないことを、物語っているようだ。

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

Salesforce、4Q売上32%増。年間売上30.5億ドル

Salesforce.comは会計2013年度第4四半期の決算を発表し、売上は前年同期比32%増の8.35億ドル、1株当たり非GAAP利益（EPS）は0.51ドルだった。アナリスト予測は売上が8.25～8.30億ドル、EPSは0.40ドルだった。

2013年度通年では売上30.5億ドル、前年比35%増。

salesforce-q412a

Salesforce.comの発表によると、同社の次年度第1四半期の売上予測は8.81～8.87億ドルで、前年比27～28%。会計2014年度通年の売上予測は38.2～37.7億ドル、25～27%増、非GAAP EPS予測は1.93～1.97ドル。

[原文へ]

（翻訳：Nob Takahashi）

AWS(Amazon Web Services)がメッセージングとノーティフィケーション（通知）APIを値下げ

Amazon Web Servicesがまた値下げをした。今回の値下げ対象は、二つのサービス: Simple Queue Service(SQS)と、Amazon Simple Notification Service(SNS)だ。

SQSは、複数のコンピュータ間を行き来するメッセージを保存するための、スケーラブルなキューを提供する。アプリケーションの各部位が分散しているとき、このようなメッセージングシステムによってお互いが正しく協調〜シンクしながら動くことができる。各部位そのものに、いちいち直接アクセスする必要がない。したがって、SQSを利用するとワークフローの自動化が容易にできる。デベロッパは、Amazon Elastic Compute Cloud(Amazon EC2)とAWSのそのほかのインフラ的Webサービスとの正しい連動を確保できる。

SNSは、クラウドからの通知をセットアップし、操作し、送り出す。この通知処理により、アプリケーションからのメッセージをパブリッシュする、サブスクライバーたちやほかのアプリケーションに配布する、などのことができる。それは、Web上のコンピューティングをより容易にするための便宜の一つだ。

値下げの概要は以下のとおり:

SQS APIは50%値下げ、100万リクエストあたり50セントとなる。
SNS APIは17%値下げ、100万リクエストあたり50セントとなる。
SQSとSNSの無料層が拡大され、各月リクエスト100万までとなる。これまでの10万を一挙に10倍。

値下げの発効は明日（米国時間3/1）から。GovCloud(US)を除くAWSの全リージョンに適用される。

値下げは、このところのAWSの基本戦略の一環だ。この前はS3ストレージが値下げされた。AWSのその戦略は、いわゆる薄利多売だ。サーバ（サービス）のスケールが大きくなれば、提供単価を安くできる。またボリュームディスカウントと提供コンピューティングパワーの拡大により、顧客に最適能力を提供できる。同時にAWS側の余裕も拡大し、ふたたび値下げが可能になる。そんな“善循環”をAmazonはねらっている。

値下げは、競争の激化のたまものでもある。Google Compute Engine(GCE)と、デベロッパたちに好評なWindows Azureも、共に値下げを繰り返している。オープンソースのOpenStackも、今後ますます、そのインフラストラクチャの可利用性を高めるだろう。だから、競争の激化はこれから加速する一方だ。値下げは、サービスの価値を高める重要な要素の一つになる。

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