Agile Cat — in the cloud

API により拡大する、サービスの可能性 と 新たなリスクとは?

Posted in .Selected, API, Social, Strategy by Agile Cat on November 22, 2013

What APIs Are And Why They’re Important

Brian Proffitt – September 19, 2013

_ Read Write (2)

APIs make the modern Web what it is today. Here’s a simple guide to what they are, how they work and why we care.

API により、いまふうの Web がもたらされている。 以下に、それが、何ものであり、どのように動作し、また、取り扱われるべきかを示していく。


It’s getting harder to turn around in tech without bumping into some reference to APIs, or application programming interfaces. Here at ReadWrite, for instance, we’ve recently discussed Google’s flip-flops on the open Calendar API and why Pinterest hasn’t made its APIs public yet. I’ve even put forth the notion of getting my own API.

最近のトレンドだが、いくつかの API 参照に突き当たることなく、テクノロジーを上手い方向へ転換させることが難しくなってきている。 何の話かと言えば、そう、Application Programming Interfaces のことである。実際のところ、最近の ReasWrite では、Google がオープンな Calendar API に大転換した理由と、Pinterest  が未だに API を公開しない理由が、ちょっとした議論を呼んでいる。 そして、私も、自身の API を取得するという概念を打ち出している。

If you work with APIs, you already know why they’re important. But the rest of you may well be wondering: What are APIs, and why do we care so much about them?

あなたの仕事で、API が用いられているなら、その重要性について、すでに認識しているだろう。しかし、あなたの心の中には、その意味と、それに強くこだわる理由について、若干の疑念が残されているだろう。

This is your story.


APIs: Windows To The Code

In the simplest terms, APIs are sets of requirements that govern how one application can talk to another. APIs aren’t at all new; whenever you use a desktop or laptop, APIs are what make it possible to move information between programs—for instance, by cutting and pasting a snippet of a LibreOffice document into an Excel spreadsheet. System-level APIs makes it possible for applications like LibreOffice to run on top of an OS like Windows in the first place.

簡単に言えば、API とは、なんらかのアプリケーションが、他と会話するための方法を管理する、要件のセットのことである。だからと言って、API は まったく新しいもというわけではない。あなたが、デスクトップやラップトップを使用するとき、API が機能することで、プログラム間で情報を移動できるのだ。具体的に言うと、LibreOffice でドキュメントの一部をカットし、Excel のスプレッドシートにペーストすることなどが、それにあたる。また、System レベルの API は、Windows のような OS の上で、LibreOffice などのアプリケーションを走るようにしてくれる。 そもそも、それが、API の始まりである。

On the Web, APIs make it possible for big services like Google Maps or Facebook to let other apps "piggyback" on their offerings. Think about the way Yelp, for instance, displays nearby restaurants on a Google Map in its app, or the way some video games now let players chat, post high scores and invite friends to play via Facebook, right there in the middle of a game.

その一方で、Web における API は、Google Maps や Facebook といった大掛かりなサービスと、自社製アプリの組み合わせを実現してくれる。例として、Yelp の方式について考えてみる。まず、そのアプリ内に取り込んだ Google Maps で、近くにあるレストランを表示できる。また、ビデオゲームで遊んでいる最中のプレイヤーたちに、Facebook を介して、チャットを提供し、ハイスコアのポストや、ゲームへの招待などにも対応していく。

APIs do all this by "exposing" some of a program’s internal functions to the outside world in a limited fashion. That makes it possible for applications to share data and take actions on one another’s behalf without requiring developers to share all of their software’s code. Code-sharing on that scale wouldn’t just ruffle the feathers of programmers who’d rather keep it secret; it would also be grossly inefficient.

API は、プログラム内の機能の一部を、限られた方式で外の世界へエクスポーズすることで、そのすべてを実現していく。 それにより、2つのアプリケーション間でデータが共有され、双方のアクションが互いに代行されるようになるが、そのソフトウェアにおける全コードの共有が、開発者に求められることはない。そのスケールにおけるコードの共有は、それを秘密にしておきたいプログラマーの、心の中を波立たせるものにはならないだろう。 つまり、心配するほどの、秘密の開示には至らないのだ。

That’s true even for open-source programs. Who has the time to comb through all the code for somebody else’s application—which, trust me, can be awfully messy—just to use one function? (It’s also possible to run into tricky licensing issues if you’re not careful.)

それは、オープンソース・プログラムとして考えても、とても意味のあることだ。たった 1つの機能を使用するために、他人のアプリケーションにおける、すべてのコードの枝葉までしらべるなんていう(私を信じてくれるなら、その行為が、ひどく厄介なことも信じて欲しい)、暇人がいると思うだろうか? (そこまで考慮できないなら、トリッキーなライセンスを発行することも可能である)

APIs simplify all that by limiting outside program access to a specific set of features—often enough, requests for data of one sort or another. Feel free to think of them as doors, windows or levers if you like. Whatever the metaphor, APIs clearly define exactly how a program will interact with the rest of the software world—saving time, resources and potentially nasty legal entanglements along the way.

API により簡素化されるのは、特定の機能のセットに対して、制約された外部プログラムからのアクセスで実現される、すべての事柄である。 つまり、大半のケースでは、何らかのデータに対するリクエストで、事足りてしまう。 それが気に入るなら、ドアとでも、窓とでも、レバーとでも、自由に捉えることができる。どのようなメタファーを用いるにしても、ソフトウェアの世界で手の届かなかった領域を、API が正確かつ明確に定義すると言える。そして、これから先も、時間とリソースを節約し、厄介な法的問題を回避していくだろう。

How APIs Work

These days, APIs are especially important because they dictate how developers can create new apps that tap into big Web services—social networks like Facebook or Pinterest, for instance, or utilities like Google Maps or Dropbox. The developer of a game app, for instance, can use the Dropbox API to let users store their saved games in the Dropbox cloud instead of working out some other cloud-storage option from scratch.

このところ、とりわけ API が重要になってきているのは、大規模な Web サービスを活用する、新しいアプリケーションを開発する手法を、API 自身が決定するようになっているからである。実際のところ、Facebook や Pinterest のようなネットワークを、そして、Google Maps や Dropbox のようなユーティリティを、活用するケースなどが挙げられる。また、ゲーム・アプリの開発者も、同じような判断を下している。 たとえば、ユーザーがゲームの結果を保存するクラウド·ストレージであるが、それをスクラッチで開発するのではなく、Dropbox API を用いて、Dropbox クラウドに保存させるようにしている。

In one sense, then, APIs are great time savers. They also offer user convenience in many cases; Facebook users undoubtedly appreciate the ability to sign into many apps and Web sites using their Facebook ID—a feature that relies upon Facebook APIs to work.

ある意味において、API により、素晴らしいかたちで時間が節約される。そして、API は多くの場合において、ユーザーに利便性を提供する。 たとえば、Facebook ユーザーであれば間違いなく、数多くのアプリや Web サイトに、Facebook ID を用いてサインインできることを高く評価しているはずだ。 もちろん、これも、Facebook-ID に依存するものである。

Viewed more broadly, though, APIs make possible a sprawling array of Web-service "mashups," in which developers use mix and match APIs from the likes of Google or Facebook or Twitter to create entirely new apps and services. In many ways, the widespread availability of APIs for major services is what’s made the modern Web experience possible.

しかし、もう少し俯瞰してみると、不規則に広がった Web サービスの群れが、API により Mashup されている状況が理解できるだろう。開発者たちは、完全に新しいアプリケーションやサービスを作成するために、Google や Facebook やTwitter といった同類から得られる、異なるものを組み合わせるために API を使用しているのである。多くの点において、主要なサービスにおける API の、広範囲におよぶ可用性こそが、現代的な Web エクスペリエンスを実現しているのだ。

When you search for nearby restaurants in the Yelp app for Android, for instance, it will plot their locations on Google Maps instead of creating its own maps. Via the Google Maps API, the Yelp app passes the information it wants plotted—restaurant addresses, say, along with the Yelp star rating and more—to an internal Google Maps function that then returns a Map object with restaurant pins in it at the proper locations. Which Yelp can then display inside its app. (On iOS, Yelp taps Apple’s Maps API for the same purpose.)

さらに言えば、Android 用の Yelp のアプリで近くのレストランを検索するとき、そこでは独自マップが作成されることもなく、探している場所が Google Maps に表示されると気づくだろう。つまり、Google Maps の背後に置かれた機能が、そのレストランの場所をつなぎ合わせ、Map オブジェクト上に正確にピン止めしているのだ。そして、Yelp は、自身のアプリの中に、その Map オブジェクトを表示する ( iOS 用の Yelp は、同じ目的のために、Apple の Maps API を叩いている)。

We see APIs like this all the time. Elsewhere on this page you should see the icons to share this article on Facebook, Google+, Twitter, LinkedIn or Reddit. These are just links that call on the APIs associated with each of those services to allow users to Tweet or post about an article without leaving the site itself. APIs also allow our comment system, run by a service called Disqus, to accept user comments and then display them right here on ReadWrite without our intervention.

このように、いつも私たちは、API を参照している。たとえば、この記事を共有するための、Facebook や、Google+、Twitter、LinkedIn、Reddit などのアイコンを、ページのどこかで確認できるはずだ。つまり、このサイトから離れることなく、この記事に関するツイートやポストを実現するために、リンクから API を経由して、それらのサービスを呼び出しているのだ。さらに、API から Disqus というサービスを呼び出すことで、私たちのコメント・システムが動き出す。それは、ユーザーのコメントを受け付けた後に、私たちの仲介を必要とすること無く、あなたのコメントを ReadWrite のページに表示する。

When APIs Go Bad

Of course, just because an API is available now, that doesn’t mean it always will be. Twitter, for instance, notoriously limited third-party applications’ use of its APIs just over a year ago—a move that had the practical effect of killing off alternative Twitter clients and driving users to Twitter’s own site and apps, where Twitter can "monetize" them by displaying ads … er, promoted tweets. Twitter insisted the move was necessary to deliver a "unified" Twitter experience.

もちろん、いまでは API が利用できるようなったという理由だけでは、これからも常に存在し続けると捉えることができない。たとえば、Twitter を例にすると、サードパーティ・アプリからの API 使用に制限をかけるという、ひどいことを 1年ほど前に行っなっている。そして、他の Twitter クライアントを殺し、Twitter 自身のサイトとアプリに、ユーザーを誘導するという、具体的な効果をもたらすことになった。それらの場所は、広告やプロモーションのつぶやきにより、Twitter がマネタイズを図るためのものであったのだ。しかし、Twitter の主張はというと、統一された Twitter エクスペリエンスを提供するために、必要な措置であったとなる。

Other examples abound. Companies can shut down services and APIs that your applications depend on—or they can go out of business entirely, as Memolane and Everyblock did last February. And let’s not get started on all of the services that Google regularly shuts down when it doesn’t see any profit in them—like Google Health or more recently, Google Reader. These kinds of service shutdowns can leave you in a lurch if your application depends on those APIs to function.

他にも、たくさんの例がある。 あなたのアプリが依存している サービス や API が、それらを提供している企業により、シャットダウンされてしまうという事態も起こり得るのだ。 昨年 2月の、Memolane Everyblock のケースが、それに当てはまるだろう。また、Google も、たとえば HealthReader のような、利益をもたらさないものを、定期的に廃止していくので、すべてのサービスを使い始めるべきだとも言えない。この種のサービス停止が生じると、それらの API と機能に依存しているアプリが、置き去りにされてしまう。

There’s still more than a hint of the Wild West in today’s API landscape. But none of these complications seem likely to dampen developer enthusiasm for APIs, nor that of users for the incredible variety of apps and services they make possible.

今日の API を取り巻く風景の中には、フロンティアのためのヒント以上のものが潜んでいる。しかし、これらの、合併症とも言える出来事が、API へ向けた開発者の熱意に水を差すとも思えず、また、それが可能にする、素晴らしいアプリやサービスが、消えていくこともないだろう。

See also: The New API Gold Rush


TAG indexAgile_Cat の日常において、どにように API が機能しているのかというと、まず、WordPress とソーシャル・メディアの連携が挙げられます。 このコンテントも、ポストされた瞬間に、2つのサービスを連携する API が動き出し、Twitter 側に新規のポストを示すリンク情報が流れていきます。 また、最近のお気に入りである、Business Insider や Mashable などの Android アプリからは、2タップするだけで、Evernote に Web クリップを取り込むことが可能です。 まぁ、一言でいって、毎日が API 漬けなのですが、それは、みなさんも一緒のはずです。依存するだけではなく、代替の手段を常に考えておくことも、API の時代には必要なのかもしれませんね。image



Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ
BaaS で自由になる? それとも便利になる? そして DoCoMo の i-Concier は?
Bloomberg 金融アップストアがオープン : Apple みたいに 30% をイタダキ!
Facebook が Open Graph API を遮断 : 外れてしまった Yandex の狙い
NY の地下鉄では、スマホ・チケットの試みが始まるらしい

Facebook が Open Graph API を遮断 : 外れてしまった Yandex の狙い

Posted in .Selected, API, Facebook, Open Graph, Social, Yandex by Agile Cat on March 27, 2013

Wonder No More. Yandex Pulls Social Discovery App After Facebook Closes Door On Graph API Use + Says It’s A Competing Search Engine
Ingrid Lunden – January 30th, 2013


Some closure on the story of how Yandex — the Russian search giant — built a social discovery app that relied on Facebook interconnection to gather data, and then found Facebook blocking its service within hours of launching.

ロシアのサーチ・ジャイアントである Yandex だが、これまでに開発してきた、ソーシャル・ディスカバリー・アプリの廃止に追い込まれている。それは、Facebook が集めるデータとの接続に依存するものだが、ローンチから数時後に、そのサービスを Facebook がブロックしていることが判明した。

Today Yandex said that after discussions with the social network, Facebook has finally, terminally said that the app violates its Platform Policies, specifically on the point of Wonder being a competing search engine. Facebook will not reinstate the ability to use Facebook’s Graph API, so as a result, Yandex is planning to pulll the app from the app store and put it on hold for now.

今日(1/30)のことだが、Yandex は、このソーシャル・ネットワークと議論した後に、Wonder が Platform Policies に違反し、さらには、競合するサーチ・エンジンになっているという、Facebook の発言を引用している。Facebook は、その Graph API を、Yandex に対してブロックし続けるだろう。 それを踏まえて、このアプリをアップ・ストアから引き下げ、保留にすることを、Yandex は計画している。

The full statement from Yandex:

以下は、Yandex からのフル・ステートメントである:

“We discussed the issue with Facebook and it was confirmed that Facebook views the application Wonder as something that violates the Facebook Platform Policies (section I.12) and that the access to Facebook’s Graph API will not be restored.

“According to Section I.12, no data obtained from Facebook can be used in any search engine or directory without the company’s written permission. The reason behind Facebook’s decision to revoke our access to their data appears to be that they do consider Wonder to be a search engine, while our understanding of what it is differs from this view.

“Wonder’s functioning, in its current state, as well as the quality of user experience it provides, largely depends on the access to Facebook’s Graph API. Since this access was revoked, we decided to put our application on hold for the time being. We will be considering partnership opportunities with other social networks and services to offer our users a richer internet experience via Wonder.”

この問題について、私たちは Facebook と議論した。そして Facebook が、この Wonder アプリに対して、Platform Policies(Section I.12)だと見なし、また、Graph API へのアクセスが復活しないことが確認された。

Section I.12 によると、Facebook から得られる、あらゆるデータは、同社による書面での許可を受けることなく、いかなるサーチ・エンジンおよびディレクトリで、利用することができないとされている。彼らのデータに対するアクセスが取り消された背景には、Facebook が Wonder を サーチ・エンジンであると認識しているのに対して、私たちは異なるものだと認識しているという、考え方の相違があると思われる。

現時点における Wonder の機能は、提供されるユーザー・エクスペリエンスの質的な向上であるが、それと並行して、Facebook の Graph API アクセスに大きく依存している。 そのアクセスが無効とされたことで、このアプリについては、保留にすると決定した。 したがって、私たちは、他のソーシャル・ネットワークおよびサービスとパートナーシップを構築し、Wonder を介したリッチなインターネット・エクスペリエンスを提供していくことになるだろう。

The emergence of Wonder, and a week before the blockage of Voxer, has kicked off a new level of scrutiny about how Facebook allows other apps to appropriate its data: in effect, the company has said that it is not sharing with apps that don’t share back, or that replicate core functionality without permission.

Wonder の出現と、その1週間前に起こった Voxer の出来事は、他のアプリケーションが Facebook のデータを利用する適切な方式という、新しいレベルにおける調査の始まりでもあった。 そして、その結果において同社は、共有した結果を戻さないアプリや、コアとなる機能を許可なく複製するアプリとは、共有していかないと発言している

The Wonder app, which was nearly a year in the making, was put together by Yandex Labs, which is based in Palo Alto, CA. I actually met the three leads on the project, Maxim Grinev, Maria Grineva and Sergey Fayfer, for the first time in person yesterday, as I’m in town for the week.

約 1年をかけて開発されてきた、この Wonder アプリは、Palo Alto, CA をベースとする、Yandex Labs によりまとめ上げられた。 昨日(1/29)のことだが、その街を訪れた私は、このプロジェクトの 3人のリーダーである、Maxim Grinev および、Maria Grineva、Sergey Fayfer と会ってきた。

They told me about how the idea germinated from their own move to the Bay Area a year ago, when they were trying to figure out what to do and where to go when they arrived, because, in their collective mind, there wasn’t a good enough social app out there to provide that kind of recommended viewpoint.

彼らは、何処へ行って何をすれば良いのかを 1年前に理解し、Bay Area に引っ越してきたことで、このアイデアが生じたと、話してくれた。なぜなら、この種のリコメンデーションの視点を、充分なかたちで提供するソーシャル・アプリは存在しないという認識が、彼らの中で共有されていたからである。

The app then went on to be built using a number of different features — including Nuance-powered voice recognition, API feeds from various other social networks like Foursquare, and new algorithms for how to digest and cancel out repetitive news in favor of more up to date information — but without the core dataset provided via Facebook’s Graph API, the carpet was effectively pulled from under Wonder.

そして、このアプリは、数多くの機能を用いることで構築されていった。そこに含まれるものとしては、Nuance がパワーを提供する音声認識や、Foursquare などのソーシャル・ネットワークフィードされる多様な API、そして、人々が好む最新情報を抜き出し、また、重複を排除していくための、新しいアルゴリズムなどが挙げられる。しかし、Facebook の Graph API たら提供される、コアとなるデータセットに依存することなく、そのカーペットを効果的に、 Wonder の足元まで持ってくることは不可能だ。

Considering that Facebook flat-out thinks of Wonder as a search engine, and one that competes against Facebook itself, makes one speculate about what else Facebook has planned for its own, new Graph Search feature in the future.

Facebook が率直に、Wonder をサーチ・エンジンとみなし、また、自身と競合するものと認識したことで、現時点で計画されている範囲を超えて、これからも新しい Graph Search 機能が登場してくると、推測することが可能になる。

And if there are more apps — or would-be apps in development — that might find themselves blocked in future, will we see companies begin to look for alternative solutions? Is there room for another social data aggregator like Facebook in the market?

そして、もし、それら以外のアプリが、また、これから開発されるアプリが、将来においてブロックされると認識されるなら、それらの企業は代替えのソリューションを探し始めるのだろうか? そして、このマーケットには、Facebook のような、別のソーシャル・データ・アグリゲータのための空間が存在するのだろうか?

Equally, it’s worth wondering whether we will see some of the smart technology that went into Wonder appearing elsewhere — something Yandex had already said it would consider even when it first launched its Wonder “experiment.” It was potentially a route for Yandex to build its profile and dataset for U.S. consumers, and English-language users, so it’s clear that these markets remain in the company’s sights.

それと同様に、Wonder が示したような領域へ、新たに飛び込んでいくスマートなテクノロジ-について、考える価値も生じていくる。 それは、Yandex が Wonder に「実験」を開始した当初から、すでに考えていたであろう、何かである。また、それは、アメリカのユーザーと、英語圏のユーザーのための、プロファイルとデータセットを構築するという、Yandex のための潜在的なルートでもあった。 したがって、このマーケットが、同社の視界の中に留まり続けることは明確である。


Company: Yandex
Launch Date: September 23, 1997

Yandex is an internet technologies company that operates in Russia, CIS and Turkey. It is the largest Russian and fifth-largest world internet search engine. Yandex is an acronym for the phrase Yet Another Indexer. As of December 2011, Yandex had 60.9% of the Russian search market (source: Yandex’s mission is to give the answer to the user anytime and anywhere. Company provides its services for desktop and mobile users and develops embedded solutions as well. The company specializes on highly-targeted sophisticated…

Yandex は、Russia/CIS/Turkey で運用される、インターネット・テクノロジー企業である。 それは、Russia で最大であり、世界でも 5番目に大きな、インターネット・サーチ・エンジンである。 Yandex は、Yet Another Indexer から頭文字を抜き出した名称である。 2011年12月の時点おいて、Yandex は Russia のサーチ・マーケットの 60.9% を有している(情報源:。 Yandex のミッションは、Anytime and Anywhere で、ユーザーに答えを提供することである。 同社は、デスクトップとモバイルのユーザーに対して、また、エンベッド・ソリューションにおいて、そのサービスを提供している。 そして、きわめて洗練された、高度な目標に対して、特化されている・・・


TAG index先日に、『 Yandex の Wonder は、ロシアからアメリカへ向けた観測気球なのか? 』というタイトルの抄訳をポストしましたが、この Yandex の狙いは外されてしまったようですね。Facebook に蓄積した情報であれば、(その持ち主が同意するなら)何でも引き出せる Open Graph は、これからの IT を構成する、きわめて重要なテクノロジーになるはずです。 しかし、この Wonder のケースのように、外部からの API を介した検索は NG というのが、Facebook の基本スタンスのようです。この話は、あくまでも Facebook と Yandex の取り決めという、限定された範囲にフォーカスするものですが、プライバシーと利便性とリテラシーについて、より本質的なところで、議論していく必要があるのだろうと思います。Open Graph からは、目が離せませんね。Image(221)



Facebook の Open Graph : すでに 4000 億回 の インタラクションを達成
Facebook の Graph Search について、簡単だが説明したい : GigaOM
Google の Knowledge Graph は、スタートレックを目指す!
Yandex が Bing を追い越した : 検索マーケットの4番手に踊り出る
Yandex と CERN がコラボ! 機械学習と物理学は 共鳴するのか?

BaaS で自由になる? それとも便利になる? そして DoCoMo の i-Concier は?

Posted in .Selected, API, BaaS by Agile Cat on December 11, 2012

Mobile Backend-as-a-Service (MBaaS): Give me Liberty or give me… Convenience?

Guest Author, November 29th, 2012

_ ProgrammableWeb

This guest post comes from Miko Matsumura, Senior Vice President of Platform Marketing and Developer Relations for Kii Corporation. Miko main role at Kii is evangelizing the Kii Cloud Mobile Backend-as-a-Service (MBaaS).

What’s good about MBaaS?

imageMBaaS provides mobile developers with LIBERTY and CONVENIENCE. LIBERTY in the sense of self-determination, control and an independent destiny–they can communicate with, manage, understand and serve their users without being beholden to external influences. An app developer who doesn’t control their users has no independent future. CONVENIENCE is a simple matter of reducing time-to-market, risk and cost of development.

LIBERTY は、自身による判断と制御、そして独立した運命の意味を持つ。つまり、外部からの影響を受けることなく、ユーザーに対するコミュニケーションとサービスを実現し、その関係を理解し、管理していく。自身のユーザーをコントロールしないアプリ・デベロッパは、独立した未来を持ち得ない。 CONVENIENCE は、ビジネスを立ち上げる時間と、開発におけるリスクとコストを低減するという、シンプルな論点である。

MBaaS is only one of several options for cloud backend:

MBaaS は、クラウド・バックエンドにおける、いくつかの選択肢の 1つに過ぎない:


Why not just roll-your-own backend?

Now I’m sure the web-programming gurus here at ProgrammableWeb are all wondering why its not more convenient for mobile developers to write their own backends?

そして、ProgrammableWeb 上において、Web プログラミング接着剤だと確信できるものが、自身のバックエンドを書こうとするモバイル・デベロッパーにとって、さらに便利なものになるなら、それがなんで悪いのか?

Reasons vary, but in our experience, these factors are pretty common among mobile app developers, particularly independent app store developers who are often just one person (and in some cases someone who has a full time job doing something else).


  • Pace: especially when competing in major app stores, the pace of mobile app development demands at least bi-weekly updates, patches and bug fixes. There’s no time to architect scalable back-end services.
  • Learning Curve: some mobile developers can double as server programmers, some can’t–but more importantly, the pace is fast enough on the client that they can’t afford to context switch.
  • Stack Risk: stacks can be confusing? MongoDB? Couch? Cassandra? MySQL? Postgres? Ruby? Python? PHP? Node? For some this is simple, but not for all. The consequences of picking the wrong combinations can be severe.
  • ペース:特に、メジャーなアップ・ストア内で競争するとき。 モバイル・アップの開発ペースは、少なくとも隔週のアップデート/パッチ/バグ・フィックスを要求する。 そして、スケーラブルなバックエンド・サービスを、デザインする時間がない。
  • 学習曲線:サーバー・プログラマーを兼任できる、モバイル・デベロッパーもいいれば、それが難しいこともある。しかし、それよりも重要なことは、容易なコンテキ・ストスイッチが不能なクライアント上で、十分に速い学習のペースが得られるところにある。
  • スタックは、混乱するだろうか? MongoDB? Couch? Cassandra? MySQL? Postgres? Ruby? Python? PHP? Node?  いくつかはシンプルであるが、すべてではない。 不適切なコンビネーションの選択は、厳しい結果を生じるだろう。

Turns out it’s a full time job to keep users happy and release new versions of apps in the ragingly competitive app stores.


So MBaaS fills in the sweet spot in this chart by giving mobile app developers liberty over their own users, their own data and other such benefits, but with relative convenience–not requiring them to invest large amounts of time and effort in building and scaling back-end services.

したがって、MBaaS は、モバイル・アプリ・デベロッパーに自由を与え、彼らのユーザー/データ/メリットなどをカバーする点において、上記のチャートで及第点を得ている。しかし、相対的な利便性については、バックエンド・サービスの構築とスケーリングにおいて、彼らに大量の時間と労力を投じるようには要求しない。

Liberty is more important than convenience

To paraphrase Ben Franklin, those who would give up liberty for the sake of a little convenience deserve neither liberty nor convenience.

Ben Franklin の言葉を、ちょっとした便利さのために自由を諦める人々は、自由も便利さも手にすることができない、と言い換えられるだろう。

This is the biggest mistake of mobile developers when selecting a mobile backend strategy. Now another way of looking at it is that many developers marry their MBaaS for “love” (features) rather than “money” (business reasons). Many developers are in such a hurry to ship the next feature or version of their product that they just fall in love with whichever tool comes in handy. Or even more commonly they fall in love with the tools that are the most elegantly designed or have the coolest feature set. One issue can be that once you select, it can be hard to switch.

それが、モバイル・バックエンド戦略を選択するときに、モバイル・デベロッパーが犯しやすい最大の誤りである。 そして、数多くのデベロッパーが、 “money” (business reasons) よりも  “love” (features) のために、MBaaS に依存し続けるという、別の道筋が見えてくる。 数多くのデベロッパーが、そのプロダクトに新機能や次期バージョンを矢継ぎ早に送り込もうとするのは、どんどんと便利になってくるツールとの、恋に堕ちるからである。 それよりも一般的なケースは、最もエレガントにデザインされ、クールな機能のセットを取り込んだ、ツール自体に惚れ込んでしまうことだ。 一度、決めてしまったことが、その後の変更を、とても難しくすることもあり得るのだ。

A longer term and more business-oriented view of this decision may save a lot of trouble down the road. When selecting an MBaaS partner (and there are many) it’s probably worthwhile to consider whether the provider is going to be in business a year from now or even 6 months from now. Startups get acquired (or worse, acqui-hired) or even run out of business. Be sure to understand whether your supplier has sufficient history of operation and a stable financial base.

そのための判断において、よりビジネス的で長期的な視野を持てば、これからの道筋に潜んでいる、数多くのトラブルを回避できるだろう。 MBaaS パートナー(数多く存在する)を選ぶときに、対象となるプロバイダーが 1年後に、あるいは 6カ月後に、ビジネスを展開しているのかどうかを考えることに、おそらく価値が生じる。 スタートアップには、買収される可能性がある(最悪は人材だけを買われてしまうケース)。 さらには、ビジネスから脱落することもある。 あなたにとってのサプライヤが、充分な実績を持ち、財政的にも安定していることを、確認すべきである。

Backend case study: NTT DoCoMo i-Concier

To understand what it takes to provide reliable service, we can take a look at the Kii Cloud MBaaS currently deployed by the largest carrier in Japan to millions of paying subscribers of the i-Concier™ mobile sync service. Historically, this kind of reliability, elasticity and scalability was only available to the largest carriers in the world, however, Kii has opened this service up to the developers of the world.

信頼性の高いサービスを提供する際に、必要となるものを理解するために、Kii Cloud MBaaS に注目してみる。それは、Japan で最大のキャリアにより、i-Concier モバイル同期サービスの何百万という有償サブスクライバーに対して、現時点で提供されているものである。  歴史的にみて、この種の安定性/柔軟性/スケーラビリティは、世界での最大級のキャリアだけが提供できるものであったが、このサービスは Kii により、世界のデベロッパーへ向けて開放されているのだ。


Isn’t MBaaS part of the weird closed mobile bubble-world?

One of the greatest things about the Programmable Web is the glorious freedom of connecting services from anywhere to anything–and the ethos is supported by web standards like REST. It’s all so open and free (as in free beer).

Programmable Web において最も素晴らしいことは、あらゆる場所から、あらゆる事象にいたるまで、サービスの接続に対して輝かしい自由度を提供する点にある。 そして、この理念は、REST などの Web スタンダードによりサポートされる。 さらに言えば、その、すべてが、オープンでフリーなのだ(無料のビールのようなもの)。

This makes mobile development paradigms like HTML5 seem most attractive as these solutions are not fenced behind app stores and paywalls. I think theres plenty of room for this and environments like Node.js provide common language across client and server. Commenting on this is outside the scope of this post, but the short perspective on this is that there should be room for everyone in mobile.

それにより、HTML5 のように、最も魅力的だと思われる、モバイル開発のパラダイムがもたらされる。そして、それらのソリューションは、アップ・ストアや課金のカベに囲まれるものではない。 そこには、たくさんの考え方があると思う。そして、Node.js のような環境が、クライアントとサーバーにまたがる、共通の言語を提供している。 それについて意見を述べることは、このポストのスコープ外のことであるが、モバイルにおいては、それぞれの人々のための考え方があるというのが、私の簡潔な展望となる。

For those who do choose native mobile client programming, they do have to put up with ugly app store approval processes, app store “taxes” and a much more “closed” mindset around their technology stacks. But in exchange for being part of this world, developers gain access to monetization and professionalization and can build sustainable businesses with exponential growth properties. There’s room for everyone.

ネイティブのモバイル・クライアント・プログラミングを選ぶ人々は、面倒なアップ・ストアの承認プロセスと「税」に耐え、自身のテクノロジー・スタックに「閉じ込められた」固定観念を引きずらざるを得ない。しかし、この世界の一部になるこという交換条件により、デベロッパーたちはマネタイズとパーソナライズに取り組み、自身の特質を活用した、持続可能なビジネスを構築できる。 そこには、みんなのための方式がある。


imageこのところ、すっかりと BaaS にハマっている Agile_Cat ですが、例の Kinvey Subway Map に入っていないため、この Kii を見逃していました。 そして、先日、このところご無沙汰だった ProgrammableWeb に行ってみたところ、このような重要な記事を見つけたというわけです。最近の Agile_Cat の悩みは、この新たに作った BaaS カテゴリに、これまでの API カテゴリを統合すべきなのかというものです。 う~ん、どうしたものでしょうかね?  



AWS イベントでの Parse が スゴそう – BaaS の勢いが加速する?
Ray Ozzie の Talko も、$4M の資金で BaaS に参戦!
Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ
Bloomberg 金融アップストアがオープン : Apple みたいに 30% をイタダキ!
モバイル BaaS って何だ? Appcelerator による Cocoafish 買収から探ってみよう

Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ

Posted in .Selected, API, BaaS, Facebook, Open Graph, Social by Agile Cat on November 16, 2012

Kinvey Service Fixes Crack In Facebook’s Open Graph Back-End

Dan Rowinski – November 12th, 2012


Facebook’s Native Mobile Problem With Open Graph

In 2010, Facebook attempted to redefine the meaning of "verbs" in the Web Era. The company’s Open Graph turned users actions (such “Jon ran” or “Susie listened”) into status updates, tied to Web apps. The Open Graph opened up a new world of data to Facebook and its developer community. But there was a hitch and, like many of Facebook’s recent issues, the source was mobile. In the Mobile Era, Facebook’s Web-centric approach has caused it many problems, from monetization to user experience in its mobile app on iOS and Android.

Facebook は 2010年に、Web Era における「Verb」の意味を再定義しようと試みた。同社の Open Graph は、ユーザー・アクションを、Web アプリケーションに結びつけられたステータス・アップデートに置き換えた( たとえば、“Jon ran”、“Susie listened” など)。 この Open Graph は、Facebook とベロッパー・コミュニティへに対して、新しいデータの世界へのドアを開けた。 しかし、Facebook における最近の問題のように、モバイルからのソースを、接続する必要があった。 そして Mobile Era になり、この Facebook の Web セントリックなアプローチは、iOS や Android といったモバイル・アプリにおける、マネタイズからユーザー・エクスペリエンスにいたるまで、数多くの問題をもたらしてきた。

Image(66)クリックで拡大 ⇒

On the other hand, Facebook’s biggest strength is its ability to make connections between its users’ friends, what they “like” and what they do. The more threads that Facebook can tie to a user, the better able it is to sell advertising to them. That makes Open Graph the biggest single innovation Facebook has introduced in the last few years.

その一方で、Facebook の最大の強みは、Like などのアクションに関して、ユーザーのフレンドたちの間で、コネクションを作る能力にある。 そして、Facebook がユーザーたちを結びつけるスレッドには、広告を販売していく能力まであるのだ。それこそが、この数年において、Facebook が Open Graph に導入してきた、最も大きなシングル・イノベーションなのである。

Integrating Open Graph has been a problem since the it was announced in 2010 and expanded in late 2011 to include the new Timeline profile. Apps with Web-based back ends, such as Spotify, have been easily able to use Open Graph but the option for most native developers was beyond their means. But developers with “native” mobile apps had to go through extraordinary lengths to tie the Open Graph to their applications and only a handful of well-funded startups (such as Instagram or RunKeeper) with big development teams have been able to pull it off. The problem was that the backend systems for native mobile apps are difficult to optimize to Open Graph.

2010年の発表から、Timeline プロファイルを取り込んだ 2011年後半の拡張に至るまで、Open Graph の統合は問題をかけ続けてきた。Spotify のような、 Web ベース・バックエンドを持つアプリケーションは、Open Graph を容易に使うことができたが、大半のネイティブ・デベロッパーのための選択肢は、彼らの手段を超えたところにあった。 しかし、Native のモバイル・アプリを取り扱うデベロッパーは、自身のアプリと Open Graph を結び付けるために、並外れた長さのパスを通り抜けなければならなかった。そして、大規模な開発チームと資金力を持つ、ほんのひと握りのスタートアップ(Instagram や RunKeeper などの)だけが、それをやり遂げることができた。つまり、ネイティブ・モバイル・アプリのためのバックエンド・システムを、Open Graph に最適化することが難しいという、問題が存在していた。

Kinvey’s Middle Point

A startup in Boston is aiming to fix that. Kinvey, a “Backend-as-a-Service” provider for mobile application development, has created a simple way for native developers to connect their apps to Open Graph and allow users to use easily use more "verbs" on their timelines from their smartphones and tablets.

ある Boston のスタートアップが、その問題を FIX しようとしている。 モバイル・アプリ開発のための Backend-as-a-Service であるKinvey は、ネイティブ・デベロッパーのアプリと Open Graph を接続するための、容易な方法を作り上げている。そして、ユーザーたちは、スマートフォンとタブレットから、自身の Timeline 上で、さらに多様な Verb を利用できる。

Image(182)クリックで拡大 ⇒

Open Graph functions by pulling in data from Web endpoints by connecting the action (verbs like "run," "cook," "listen" etc.) with metadata from the Web app. So, if I am baking cookies, I can hit the “I baked cookies” button on some webpage and Facebook will crawl for the metadata associated with that action and post it to Timeline. This works only because the webpage has metadata, stored on the Web, that Facebook can crawl. Mobile apps do not often have this type of metadata available to be searched, nor any backend system or URL that Facebook can crawl.

Open Graph の機能は、Web アプリからのメタデータと、アクション( run、cook、listen など)を結び付けることで、Web エンド・ポイントからデータを引き出す。したがって、私がクッキーを焼いているなら、いくつかの Web ページ上で、「私はクッキーを焼いた」ボタンをクリックできる。そして Facebook は、そのアクションと結び付けられるメタデータを探し出し、Timeline にポストしてくれる。 この機能は、Web ページがメタデータを持ち、それが Web ページにストアされ、さらに Facebook がクロールできるときにのみ、上手く処理される。 しかし、大半のモバイル・アプリは、この種のサーチに対応するメタデータを持っていない。 さらに言えば、Facebook がクロールできる、バックエンド・システムも URL も同様である。

Kinvey has a simple solution. It takes the metadata (known as the “object”) from a mobile app and hosts it on its own servers. It then takes that data and creates its own Web endpoints for Facebook to crawl. It is a clever bit of integration. Kinvey is not changing the basic nature of Open Graph nor doing anything extraordinarily technical, rather it is creating a new middle point between a developers’ apps and the Open Graph – with an interface that lets them push or retrieve data. Kinvey sets up the entire system on its own and handles the data flow for the developers.

Kinvey には、シンプルなソリューションがある。 それは、モバイル・アプリからメタデータ( ojeect のこの)を受け取り、自身のサーバー上にホストする。 続いて、そのデータを取得し、Facebook からクロールできる、自身の Web エンドポイントを生成する。 それは、インテくグレーションのための、利口なやり方である。 Kinvey は、Open Graph の基本的な特性を変えることもなく、また、テクノロジーに走りすぎることもない。どちらかと言えば、データを Push/Get するためのインタフェースを用いて、デベロッパーのアプリと Open Graph の間に、ミドル・ポイントを作るだけである。Kinvey は、自身の環境にシステム全体を設定し、デベロッパーのためにデータ・フローを処理する。

Good For Everyone?

The benefit for mobile developers is clear: they can extend native apps actions to Facebook’s entire population and make them accessible on Timeline without creating an entirely new structure.

モバイル・デベロッパーにとって、明らかなメリットが生じる。 つまり、ネイティブ・アプリのアクションを、Facebook の全ユーザーへ向けて拡張できる。そして、まったく新しい構造を作ることなく、Timeline へのアクセスを実現していく。

Facebook benefits because it does not have to completely reconfigure Open Graph to serve the large native mobile developer environment. Plus, it gets previously unavailable data from smartphone and tablet users. This could significantly help Facebook spread through the app ecosytem just as it has already done with Web pages.

Facebook にも、メリットが生じる。なぜなら、巨大なネイティブ・モバイル・デベロッパー環境をサポートするために、Open Graph を再定義する必要がなくなるからだ。 さらに、以前には対応できなかった、スマートフォンとタブレットのユーザから、データを受けとることが可能になる。 それにより、すでに Web ページで完了しているように、Facebook の大規模な拡散を、アプリ・エコシステムを介して促進できる。

Users get the benefits of Open Graph on the Web extended to mobile applications.

そして、ユーザーは、Web 上での Open Graph のメリットを、モバイル・アプリにも拡張できる。


Image(219)BaaS にも、いろいろなタイプがあるはずなので、一概には言えませんが、このように、エンド・ポイント間のミドル・ポイントとして機能するというのは、とても分かりやすい話ですね。Image(220) なんというか、Agile_Cat にとっては、OpenGraph も BaaS も、茫洋として、掴みどころがなかったのですが、この記事は、双方に対する理解を、一度に進めてくれる、とても素晴らしい内容だと思います。 嬉しいです! Image(221)



Facebook – Open Graph Beta の概説
Facebook が Open Graph アクションをアップデート
モバイル BaaS って何だ? Appcelerator による Cocoafish 買収から探ってみよう
Yahoo の Mojito は、Mobile デバイスに対応する OSS Dev プラットフォームなのだ
AppMobi の狙いは、Mobile + OSS + HTML5 の惑星大直列なのだ!

Bloomberg 金融アップストアがオープン : Apple みたいに 30% をイタダキ!

Posted in .Selected, API, BaaS, Mobile, Post-PC by Agile Cat on November 14, 2012

Bloomberg launches financial app store, offers Angry Bonds

Jeff John Roberts – Nov 13, 2012


Financial giant Bloomberg has opened an app store in which it will take 30 percent of revenue. The move is significant because it is the first time the tightly-controlled company is opening up its rich pools of data to outside developers.

金融大手 Bloomberg がアップストアをオープンし、そこから 30% の収入を得ていくという。 このトレンドが重要なのは、タイトに制御された企業が外部のデベロッパーに対して、リッチなデータ・プールを開放するという点で、初めての試みだからである。

It’s not exactly Angry Birds or Call of Duty but, well, this is Wall Street. Financial giant Bloomberg this morning launched an app store with offerings like Trade Navigator, Market Grader and, yes, Angry Bonds.

これは Angry Birds や Call of Duty ではないが、まあ、Wall Street である。今朝のことだが、 金融大手 Bloomberg がアップストアをローンチした。 そして、Trade Navigator や Market Grader、そして、なんと Angry Bonds などを販売していくという。

Alas, Angry Bonds is not about disgruntled 007 agents. Instead, it is one of more than 45 apps in the Bloomberg App Portal that perform tasks like risk analysis and client management. The company didn’t disclose specific prices for the apps, which are free to preview, but it’s a safe bet they cost more than 99 cents. The Financial Times reports that Bloomberg will, like Apple, take a 30 percent cut.

なんというか、Angry Bonds は、しかめっ面の 007 のエージェントに文句を言うものではない。 それに代えて、この Bloomberg App Portal にストアされた 45本以上のアプリには、リスク分析とクライアント管理といった、仕事をこなすものが含まれる。 同社は無料でプレビューできるアプリ群について、それぞれの価格を明らかにしていないが、99セント以上の費用が発生すると思ったほうがよいだろう。 Financial Times のレポートによると、Bloomberg は Apple のように、30% を取り分にするようだ。

The launch is significant because Bloomberg has now opened up its vast pool of financial data to outside developers who can then craft new products to help traders and analysts. Until now, the company founded by New York City mayor Mike Bloomberg has closely guarded its proprietary system, which costs around $20,000 a year for a license.

今回のローンチが重要なのは、Bloomberg の巨大な金融データ・プールを、外部のデベロッパーにオープンされたからである。そして、デベロッパーたちは、トレーダとアナリストを支援するために、新しいプロダクトを仕上げていくだろう。 New York City 市長でもある Mike Bloomberg により設立された同社は、そのプロプライエタリ・システムをしっかりとガードし、これまでは、年間で約 $20,000 のライセンス費用を請求してきた。

The app store comes at a time that Bloomberg is adopting its famous financial terminal for the mobile environment through tools like Bloomberg Anywhere and selling a new edition of its core product, Bloomberg Next. The company and its main competitor Thomson Reuters were hard hit by the economic meltdown in 2009 that decimated many of their financial clients.

このアップストアは、モバイル環境における同社の金融ターミナルが、Bloomberg Anywhere などのツールを介して適用される、タイミングに合わせて登場する。そして、Bloomberg Next などのコア・プロダクトの、新しいバージョンが販売されていく。 同社および、その最大の競合相手である Thomson Reuters は、2009年の 経済崩壊により大きな打撃を被り、数多くの金融クライアントを失っている。

Here are some more screenshots of the apps (don’t have too much fun…)


↓ クリックで拡大 ↓


imageこの Bloomberg のアップストアは面白そうですね。 いま訳している、Kinvey の興味深い記事では、『 何らかの方法で、それらのアプリケーションは、いかなるソースからであっても、データを取り込まなければならない。そこに含まれるものには、もちろん、サードパーティーからのデータソースがある。そして、さらに、企業の IT 部門が、膨大なコストと時間を費やして、維持・保持してきた密結合データベース・システムでさえある 』というふうに、BaaS について説明されています。文中にもあるように、ココが、重要なポイントなのだと思います。 image



iOS/Android デバイスでカード決済 : Bank of America
NY の地下鉄では、スマホ・チケットの試みが始まるらしい
Apigee は、テレコムのための SDN を考える
単純/安価/高速 : .NET から Node + Heroku に乗り換えた Playtomic


iOS/Android デバイスでカード決済 : Bank of America

Posted in .Selected, API, BaaS, Mobile by Agile Cat on November 14, 2012

Bank of America releases a mobile payment service to compete with Square

November 13, 2012 –
Tom Cheredar

_ VB Business

The latest company to plunge into the world of mobile payment services is Bank of America, which announced it new Mobile Pay on Demand dongle today.

モバイル・ペイメント・サービスの世界に、新規参入者として飛び込んできたのは Bank of America であり、今日のアナウンスメントで、Mobile Pay on Demandドングルを披露した。

The new dongle allows people to process credit and debit card payments from an iPhone, iPad, or Android device. Money from each transaction goes into a Bank of America account, and there’s a 2.7 percent fee for each swiped transaction (3.5 percent for non-swiped/keyed in transactions).

この新しいドングルにより、iPhone/iPad/Android といったデバイス上で、クレジットとデビットカードによる支払いが処理させる。 それぞれのトランザクションからの送金は、Bank of America のアカウントに集められるが、カードを利用した場合の、トランザクションごとの手数料は 2.7% となる(キーインの場合は 3.5%)。

The dongle/service is targeted at small business owners who are likely to find it attractive due to its convenience and the fact that it charges a lower transaction fee than most credit card services. And that fee is also slightly lower than Square’s, which is 2.75 percent.

このドングル/サービスは、簡単な手続きに利便性を見出し、また、大半のカード・サービスより少ない手数料を望む、中小企業のオーナーをターゲットにしている。 そして、その手数料は、Square の 2.75% よりも、少しだけ低く抑えられている。

Bank of America’s Mobile Pay service is hardly the only mobile transaction service available these days. In addition to industry leader Square, Bank of America Mobile Pay will face competition from Intuit, PayPal Here, LevelUp, and a new service from Groupon.

Bank of America の Mobile Pay サービスは、現時点で利用できる唯一のモバイル・トランザクション・サービスというわけではない。 業界のリーダーである Square のほかに、IntuitPayPal HereLevelUpGroupon(参入予定)などのコンペティタと、Bank of America Mobile Pay は戦っていくことになる。


image今朝は、どのメディアを見ても、Sinofsky の話題であふれていて、あまり爽やかな目覚めではありませんでしたが、Mobile BaaS の到来を実感させる面白いトピックが 2つほど見つかり、なかなかゴキゲンな Agile_Cat です Smile  Bank of America のような金融機関が、簡単にモバイル・ペイメントに参入できるのも、Mobile BaaS のエコシステムがあってこそと思うのです。 このあと、Bloomberg の金融 App Store の話題も、続けてポストしていきます。image



モバイル BaaS って何だ? Appcelerator による Cocoafish 買収から探ってみよう
NASDAQ の FinQloud は、AWS ベースの金融サービス・プラットフォームだ
Amazon AWS 上の Data as a Service を、粛々と進めてきた NASDAQ の戦略
NYSE と EMC と VMware が、ウォール・ストリートに浮かべるクラウドとは?
Amazon AWS が Equinix に、ハイブリッド用のダイレクト接続を提供
アメリカの キャリア・エクスチェンジについて DCN が概説する

単純/安価/高速 : .NET から Node + Heroku に乗り換えた Playtomic

Posted in .Selected, API, Research by Agile Cat on October 24, 2012

Simpler, Cheaper, Faster: Playtomic’s Move from .NET to Node and Heroku

Monday, October 15, 2012 at 9:15AM

_ highscalability

This is a guest post by Ben Lowry, CEO of Playtomic. Playtomic is a game analytics service implemented in about 8000 mobile, web and downloadable games played by approximately 20 million people daily. Here’s a good summary quote by Ben Lowry on Hacker News:

Playtomic が提供する分析サービスは、2000万の人々が毎日のようにプレーする、モバイル/Web/ダウンロードを前提とした、約 8000 種類のゲームにインストールされたものである。以下は、Ben Lowry が Hacker News で発言した、きわめて明快な概要である:

Just over 20,000,000 people hit my API yesterday 700,749,252 times, playing the ~8,000 games my analytics platform is integrated in for a bit under 600 years in total play time. That’s just yesterday. There are lots of different bottlenecks waiting for people operating at scale. Heroku and NodeJS, for my use case, eventually alleviated a whole bunch of them very cheaply.

20,000,000人以上の人々が、昨日は 700,749,252回も、私の API にアクセスした。その解析プラットフォーム上の、8000弱のゲームをプレーすることは、600年分の時間を費やすに等しくなる。 ただし、それは、昨日の利用だけに過ぎない。 大規模スケールに取り組む人々にとって、それぞれのボトルネックが、たくさんの位置に存在している。 私のユース・ケースにおいては、最終的に Heroku と NodeJS が、きわめて低コストで、その多くを緩和している。

Playtomic began with an almost exclusively Microsoft.NET and Windows architecture which held up for 3 years before being replaced with a complete rewrite using NodeJS.  During its lifetime the entire platform grew from shared space on a single server to a full dedicated, then spread to second dedicated, then the API server was offloaded to a VPS provider and 4 – 6 fairly large VPSs.   Eventually the API server settled on 8 dedicated servers at Hivelocity, each a quad core with hyperthreading + 8gb of ram + dual 500gb disks running 3 or 4 instances of the API stack.

NodeJS を用いて完全に書き換えられる以前の Playtomic は、Microsoft の .NET と Windows のアーキテクチャを、ほとんど排他的な形式で、3年も採用してきた。この  プラットフォーム全体は、専用のシングル・サーバー上の共有スペースから、専用の分散サーバーへと成長してきた。 そして、さらに、API サーバーは、4~6 社の大手 VPS 上へと、均等にオフロードされた。 最終的に、この API サーバーは、Hivelocity が提供する 8台の専用サーバー上に落ち着いたが。 しかし、その API スタックでは、Quad-Core のハイパー・スレッディング + 8GB の RAM + 二重化された 500 GB により、3 ~ 4 個のインスタンスを走らせるという状況であった。

These servers routinely serviced 30,000 to 60,000 concurrent game players and received up to 1500 requests per second, with load balancing done via DNS round robin.

これらのサーバーは、DNS ラウンド・ロビンを介したロードバランシングを用いて、30,000 ~ 60,000人のゲームプレイヤーに対して、コンカレントなサービスをルーチンとして提供し、また、1秒あたり 1500 のリクエストを受けている。

In July the entire fleet of servers was replaced with a NodeJS rewrite hosted at Heroku for a significant saving.

そして、この 7月には、全体的なサーバーの構成を、Heroku 上にホストされる NodeJS で、書き換え、また、リプレイスすることになった。 そして、大幅なコストの削減が実現されたのだ。

Scaling Playtomic with NodeJS

There were two parts to the migration:

Dedicated to PaaS:  Advantages include price, convenience, leveraging their load balancing and reducing overall complexity.  Disadvantages include no New Relic for NodeJS, very inelegant crashes, and a generally immature platform.

Dedicated to PaaS: アドバンテージとしては、価格/利便性/ロードバランシングの活用/全体的な複雑さの低減などが挙げられる。  ディス・アドバンテージとしては、NodeJS 用の New Relic の不在/とてもエレガントとは言えないクラッシュ/全般的に見て未熟なプラットフォームなどが挙げられる。

.NET to NodeJS: Switching architecture from ASP.NET / C# with local MongoDB instances and a service preprocessing event data locally and sending it to centralized server to be completed; to NodeJS on Heroku + Redis and preprocessing on SoftLayer (see Catalyst program).

.NET to NodeJS: ASP.NET / C# からローカルな MongoDB インスタンスへの、アーキテクチャの置き換え。 そして、ローカルでのイベント・データの処理と、処理を完了されるための、センタライズされたサーバーへの送信。具体的には、NodeJS on Heroku + Redis と、SoftLayer 上でのプリ・プロセシング( Catalyst プログラムを参照)。

< 続きは原文で ど~ぞ >


image.NET と NodeJS の比較ということですが、この Playtomic のアプリケーション・モデルとビジネス・モデルにおいては、NodeJS の方が適しているという事なのでしょうね。 そして、このようなアプリケーション・モデルが、ものすごい勢いで増えてきているのだと思います。さまざまなサービスが、API という形式で提供され、さらに、それらを分析するためのプラットフォームが加わっていくわけです。こういう記事を読むと、理想的なコンピューティングが具体化しているのだと感じられますね。 image



NY の地下鉄では、スマホ・チケットの試みが始まるらしい
Apigee は、テレコムのための SDN を考える
分散オブジェクト・ストアの Basho が CloudStack に参加
次世代ビジネスとして、Data as a Platform に注目する _1

%d bloggers like this: