Agile Cat — in the cloud

Serverless Architecture の調査: 利便性においてクラウドがオープンソースを上回る?

Posted in API, On Monday, PaaS by agilecat.cloud on July 18, 2016
Serverless Architecture: The Cloud is Killing Open Source
Dick Weisinger – July 13th, 2016
http://formtek.com/blog/serverless-architecture-the-cloud-is-killing-open-source/
_ formtek
Serverless architecture. It’s the promise of products like Amazon AWS Lambda.  The idea is that it’s not that there it doesn’t require servers and hardware, it’s a higher abstraction that thinks about computing resources as services rather than hardware, virtual machines or containers.
 
サーバレス・アーキテクチャとは、Amazon AWS Lambda などのプロダクトが約束するものだ。ただし、この発想は、サーバーとハードウェアが不要になると、言っているわけではない。コンピューティング・リソースを、ハードウェア/仮想マシン/コンテナというより、サービスとして捉えることで、抽象レベルを引き上げるものとなる。
 
Seurat_10Amazon AWS explains it as follows:  “Serverless architectures allow you to build and run applications and services without having to manage infrastructure. There’s a lot of undifferentiated heavy lifting to be building and running applications, such as installing software, managing servers, coordinating patch schedules, and scaling to meet demand.  Your application still runs on servers, but all the server management is done for you… Serverless architectures can make it easier to build, manage, and scale applications in the cloud by eliminating much of the heavy lifting involved with server management.”
 
Amazon AWS は、「サーバレス・アーキテクチャでは、インフラ管理を必要とすることなく、アプリケーションやサービスの構築/実行が可能になる。アプリケーションの構築と実行においては、区分されていないハードワークが沢山ある。ざっと見渡すだけでも、ソフトウェアのインストール/サーバーの管理、パッチ・スケジュールの調整/需要に応じたスケーリングなどが、すぐに浮かび上がってくる。あなたのアプリケーションは、いまもサーバー上で走っているだろうが、そのために、すべてのサーバー管理が必要とされている。サーバレス・アーキテクチャは、サーバー管理に関するヘビーなものを大胆に排除することで、クラウド・アプリケーションの構築/管理/スケーリングが容易になる」と説明している
 
Matt Assay, open source evangelist, recently wrote: “Open source is dead. The cloud has killed it. Maybe “dead” is too strong… all signs point to the convenience of cloud supplanting the convenience of open source in the hearts of developers. Why? Because cloud is just that much more convenient, and new services like Amazon Web Services’ Lambda take that convenience to extreme—and welcome—levels.
 
オープンソース・エバンジェリストである Matt Assay は、「オープン・ソースは死ぬ。クラウドが、それを殺す。おそらく、それは大量死というレベルのものだ。すべての兆候が示すのは、開発者が抱くオープンソースの利便性に、クラウドの利便性が取って代わるという展開である。なぜだろう?その理由は、クラウドの方が、かなり便利であるからだ。そして、Amazon Web Services の Lambda のような、新しいサービスは極端に便利なものであり、また、歓迎されるレベルに達していると思われる」と、つい先日に述べている
 
ーーーーー
On Monday原文では、Kill という表現が用いられていますが、ちょっと穏やかなものに変えてしまいました。たしかに、サーバレスの時代になると、かなり抽象度が上がることになり、開発者に求められるものも変わってくるのでしょう。そして、クラウドへの移行というフェーズが終了し、クラウド・ネイティブの時代が始まると、サーバレスという考え方が広まっていくのでしょう。先日にポストした、「AWS と Azure のシェアが 3年後には逆転する? Morgan Stanley の調査結果を1枚のチャートで!」という抄訳で、No Public IaaS が激減していくという、Morgan Stanley の調査結果を紹介しましたが、なんらかの関連性があるのかもしれません。このサーバレスのトレンドには、これから注目していきたいと思います。_AC Stamp
ーーーーー
<関連>
サービス・プロバイダーが暗号化に走る:政府が要求する情報開示に対抗するためなのか?
Automation の調査: インターネット・トラフィックの 50% を Bot が占めている!
nternet Speed の調査: ワイヤレスやメタルを使って1G 接続を安価に達成!
Machine Learning の調査: Google のニューラル・ネットワークが、機械学習を身近にする
AI の調査: すべてのメジャー・クラウドが、人工知能をプッシュする時代になってきた!
 

Comments Off on Serverless Architecture の調査: 利便性においてクラウドがオープンソースを上回る?

AWS IoT プラットフォームを、開発者の目線でレビューしてみた!

Posted in .Selected, Amazon, API, IoT, Strategy by agilecat.cloud on January 12, 2016
AWS Announces IoT Platform With Deep AWS Integration
Romin Irani, Contributing Writer – Oct. 15 2015
http://www.programmableweb.com/news/aws-announces-iot-platform-deep-aws-integration/2015/10/15
 
_ ProgrammableWeb
 
At the most recent re:Invent conference, Amazon Web Services (AWS) announced its entry in the Internet of Things (IoT) space. The AWS IoT platform as expected brings not just the scale expected of AWS, but introduces deep integration with services in the AWS ecosystem along with Device SDKs, and Starter Device Kits that are ready to kick-start your IoT development.
 
先日の re:Invent 2015 Conference において、Amazon Web Services(AWS)は、Internet of Things (IoT) スペースへの参入について発表した。この AWS の IoT プラットフォームは、AWS に期待されるスケールをもたらすだけではなく、これまでの AWS エコシステムのサービスと、Device SDKs および Starter Device Kits を緊密に統合するものだと紹介されていた。それにより、誰もが IoT の開発をキック・スタートできるようになる。
 
re_invent_2015At its heart, AWS IoT is a Managed IoT platform that provides a Message Broker which can handle messages published by your devices, as well as a Rules Engines that can transform and invoke actions both into other AWS Services and back to your devices.
 
AWS IoT の中核となるのは、Message Broker を提供する Managed IoT  プラットフォームであり、利用されているデバイスからのメッセージを処理することになる。 それに加えて、Rules Engines も提供され、各種の AWS サービスとデバイスの間で用いられるアクションを呼び出し、状況に応じて適合させていく。
 
これが、AWS IoT の概念図であり、緑の部分が IoT Platform となる。
 
A high level diagram of AWS IoT is shown below, with the IoT Platform shown in green.
 
AWS IoT PlatformClick to Large >>>
 
“Things” are devices that you need to control. They publish messages to the broker via the MQTT protocol (note that HTTP is also supported). The Message Broker can then deliver the message to subscribers, IoT Applications, or other Things. Security and Identity is a first-class citizen in this platform and needs to be taken care from the ground up. The Rules Engine is pretty interesting and it can not just transform the data but route the message back to not just subscribers/applications but also invoke the rest of the services available in the AWS Ecosystem like DynamoDB, Lambda functions and more.
 
“Things”  とは、ここでコントロールすべきデバイスのことである。それらが発行するメッセージは、MQTT プロトコル(HTTP もサポートされていることに注意)を介して Message Broker へと至る。続いて、この Message Broker は、受信したメッセージを、他の Subscriber/IoT Application/Things へと配信する。セキュリティと ID は、このプラットフォームで最も大切なオブジェクトであり、また、徹底的に精査される必要がる。Rules Engine は、とても興味深いものであり、データだけでなく、その転送ルートも変換する。 それによりメッセージは、Subscriber/Application 以外にも転送されることになる。それだけではなく、AWS Ecosystem における DynamoDB/Lambda といった、その他のサービスも呼び出せる。
 
The Thing Shadow is a very interesting concept and is key to disconnected Things. Given the conditions that Things would operate it, it is very likely that due to bad connectivity, they are not always in a connected state. This means that when a message is likely to be pushed to the Thing, it is not available. In comes the concept of Thing Shadow to address it.
 
Thing Shadow は、きわめて興味深いコンセプトであり、また、ディスコネクトされた Things にとって重要なものとなる。Things を運用する条件を考えると、コネクションが不良なケースと、たまにコネクトされるケースは、きわめて似ている。つまり、Things へ向けてメッセージがプッシュされたときに、相手が接続されていないこともある。Thing Shadow の in-comes のコンセプトが、そのような状況に対応する。
 
A Thing Shadow is a copy of your Thing state in the Cloud and contains the last known state and a desired state. When a Thing is connected again, the state is synced with the Thing Shadow. Applications too can control the state of a Thing by simply using the REST API to control the Thing Shadow state. Check out How It Works section for more details on the core building blocks of the AWS IoT Platform.
 
具体的に言うと、対象となる Thngs のコピーを、クラウド内に保持しているのが Thing Shadow であり、最終のステートと、望ましいステートを、その内部に確保している。そして、Things が再びコネクトされると、その時のステートが Thing Shadow と同期される。この、Thing Shadow のステートを、REST API を用いてシンプルにコントロールすることで、アプリケーションによる Things のステート管理が、きわめて容易になる。より詳細な情報に関しては、AWS IoT Platform コア・ビルディング・ブロックの、How It Works をチェックしてほしい。
 
Amazon has made sure that developers can interact with the IoT Platform via its standard SDK but it also has a Device SDK that you makes it easy for developers to connect to the IoT Gateway. The Device SDK is available for C, JavaScript and Arduino. Check out the Device SDK page, from where you can even download the same.
 
Amazon が検証してきたことは、開発者たちが標準の SDK を介して、この IoT Platform をインタラクトできることである。また、Device SDK を用いて、IoT Gateway へのコネクションを、容易に開発できることも、そこに含まれる。この、Device SDK は、C/JavaScript/Arduino に対応している。先ほどと同様に、コア・ビルディング・ブロックの、Device SDK ページをチェックしてほしい。
 
The maker community is well versed with using Kits that have helped them write IoT applications and it would be interesting to them that AWS has partnered with various Device Manufacturers to help jump start the applications. These starter kits contain all you need to get connected to the AWS IoT Gateway. The Starter kits are from various vendors including Intel Edison, Beaglebone and more.
 
一般的に、メーカー・コミュニティは、そのキットの使い方に精通しているため、IoT アプリケーションの記述を支援してくれるだろう。AWS と各種デバイス・メーカーが提携し、AWS アプリケーションのジャンプ・スタートを支援していくことに、それらのコミュニティは興味を示すだろう。それらのスタート・キットは、AWS IoT Gateway をコネクトするための、あらゆる情報を提供してくれる。Intel Edison や Beaglebone などを含む、各種のベンダーから、この Starter Kits は提供される。
 
For AWS developers, the IoT platform is an excellent gateway to help build their Internet of Things applications. If you are invested in the AWS Ecosystem, you are probably using multiple services and this close integration is a big win for developers.
 
AWS デベロッパーにとって、この IoT Platform は、IoT アプリケーションを開発するための、素晴らしいエントランスになるだろう。あなたが、AWS エコシステムにコミットしているなら、おそらく、数多くの既存サービスを利用できるだろう。 そして、この緊密なインテグレーションが、デベロッパーを勝利へと導く。
 
ーーーーー
IoTこの記事は、re:Invent 2015 の直後にポストされていたものであり、ちょっと間が空いてしまいましたが、ようやく対訳をポストできました。その後の AWS IoT ですが、昨年末に一般公開され、また、AWS Japan からも日本語ドキュメントが提供されています。訳していて、ナルホドなぁと思ったのは、Thing Shadow のところであり、ひとつの気づきを与えてもらった気分です。 昨日の後書きでも参照した、Gartner の Top 10 Strategic Technology Trends for 2016 には、 Internet of Things Platforms という項目があり、「 IoT プラットフォー ムとは、アーキテクチャとテクノロジーの観点から IoT を実現していくという、IT の 舞台裏となる作業を構成するものとなる」と解説されていました。そして、いくつかの標準化が必要になるだろうが、暫くはベンダー間の競合が続くため、2018年までは難しいとも、述べられていました。今年は、この AWS IoT に限らず、いろいろな動きが見られるのでしょうね。 とても楽しみです! _AC Stamp
ーーーーー
<関連>
IoT の調査: この時代に生まれたなら、マック・バーガーの累計表示も頓挫しなかったはずだ!
IoT の調査: これからの5年間で7兆ドルの市場に成長するが、セキュリティが難題となる
IoT Security の調査: 黎明期の IoT デバイスは、セキュリティを考慮しないものが大半を占める
今年の IoT:APAC の市場規模は $24.2 B にいたるだろう
2015 IoT: これからの世界をリードし、人々に幸せをもたらすものに
 

Comments Off on AWS IoT プラットフォームを、開発者の目線でレビューしてみた!

API の調査: このソフトウェア資産の運用術が、ハイテク・ビジネスの命運を分ける!

Posted in API, On Monday, Salesforce by agilecat.cloud on June 22, 2015
APIs: Virtual Assets that are the Key to Driving a High Tech Business
Dick Weisinger – June 15th, 2015
http://formtek.com/blog/apis-virtual-assets-that-are-the-key-to-driving-a-high-tech-business/
 
_ formtek
Companies like Uber, Airbnb, Facebook, Alibaba, and Paypal are examples of businesses that have high valuations but which don’t have any physical assets.  One thing these businesses do have though is software and these businesses are experts in using Application Program Interfaces (APIs) to expose their data and software algorithms to increase their business’ value.
 
Uber/Airbnb/Facebook/Alibaba/Paypal といった企業は、大きな価値を有してはいるが、なんらかの物理的な資産を、自身では所有しない企業の代表格である。それらの企業に共通するのはソフトウェアの存在であり、また、Application Program Interfaces (APIs) 使いとしての有能さである。つまり、自身のデータやソフトウェア・アルゴリズムをエクスポーズすることで、そのビジネスの価値を高めているわけだ。
 
Programmableweb.com estimates that there are over 12,000 different APIs.  Harvard Business Review estimates that Salesforce.com generates half of its revenues from APIs.  Expedia generated 90 percent, and eBay 60 percent.
 
Programmableweb.com は、現時点で 12,000種類以上の API が存在すると推定しているHarvard Business Review は、Salesforce.com における収益の半分が、API から生み出されていると推定している。 その値は、Expedia の場合で 90% となり、eBay は 60% となる。
 
Brian Lillie, CIO of global data center provider Equinix, said that  “CIOs should care a lot about APIs, because they are a way to unlock data and make it available to enterprise applications, customers and partners.  APIs can liberate your data…  Writing reports on these old systems takes a lot of work and a lot of people.  But if you put a handful of APIs in front of that old system of record, you can expose the trapped data to developers who can easily extract it.  APIs eliminate the need to write custom reports in archaic languages, like COBOL.  It’s a powerful way to give self-service to your organization.”
 
グローバルなデータセンター・プロバイダーとして有名な、Equinix の CIO である Brian Lillie は、「CIO たちは、API について、たくさんのことを考えなければならない。つまり、データにかけられたロックを解除し、エンタープライズにおけるアプリケーション/カスタマー/パートナーたちが利用できるようにする必要があるからだ。API により、あなたのデータは解放される。一般的に言って、古いシステムを呼び出すコードを書こうとしても、多くの作業と多くの人々が必要になる。しかし、いまも稼働している古いシステムのフロントに、一握りの API を配置するだけで、一連のデータをエクスポーズすることが可能になり、それを取得した開発者たちは、必要なデータを容易に抽出できるようになる。そして、API を利用することで、たとえば COBOL のような古風な言語の場合のような、カスタムなコードを記述する必要もなくなる。つまり、それぞれの組織におけるセルフ・サービスという、パワフルな方式を API は提供してくれるのだ」と述べている
 
Lillie said that “with the Internet of Things (IoT), we are going to see a tremendous number of devices and consumer products producing and communicating a huge amount of data…  Over time, every one of these devices will have the ability to communicate via an API in an integrated, consolidated and standardized way When APIs meet the Internet of Things, the result is going to be game-changing for most companies.”
 
そして Lillie は、「 私たちは Internet of Things (IoT) に出会ったことで、膨大な数のデバイスやコンシューマ製品が、膨大な量のデータを生み出し、また、送受信していく様を、目の当たりにしようとしている。時間が経つにつれて、それらのデバイスのすべてが、統合化/簡素化/標準化された方式の中で、API を介して通信する能力を持つことになる。結論として、API と IoT が出会うとき、大半の企業に対してゲーム・チェンジを迫る変化が生じるだろう」と発言している。
 
ーーーーー
On MondayAPI がもたらす収益としての、Salesforce と Expedia と eBay での推測値が示されていますが、いまの時代のビジネス・モデルを明らかにする、とても明確な切り口ですね。 そして、この Agile_Cat でも、ずいぶんとお世話になった Programmableweb ですが、そういえば、このところ、見ていなかったなぁ・・・ と反省しているところです。 なんらかのソフトウェア資産を API というかたちで、エクスポーズすることは究極のオープンソースだと、どこかで読んだ記憶があるのですが、まさに、そのとおりだと思います。 そして、API を活用する企業が、大きな収益を上げることも、理にかなっていると思えるのです。 API と IoT が出会うときを想像すると、ワクワクしてきますね! _AC Stamp
ーーーーー
<関連>
HTTP/2 の調査: Web の速度を 10倍〜40倍にアップし、将来の暗号化を視野にいれる!
Container の調査: CoreOS と Google のタッグと、新興の OSv が、Docker に対抗する!
Cloud の調査:コンテナの潜在能力を解放し、無駄なリソース消費を排除すべきだ
Browser の調査: IE を Spartan でリプレイスする、Microsoft の狙いは 何処にあるのか?
Security の調査: ハッカーが物理的に侵入すると、大半の企業は数時間で丸裸にされる?

Comments Off on API の調査: このソフトウェア資産の運用術が、ハイテク・ビジネスの命運を分ける!

Facebook の Graph API がアップデートされ、AD API も強化されたようだ!

Posted in Advertising, API, Facebook, Open Graph by Agile Cat on November 18, 2014

Facebook Releases Updated Graph API
http://wp.me/pwo1E-825
David Cohen – October 30, 2014
http://allfacebook.com/graph-api-2-2_b135773

_ All Facebook

Facebook announced the release of version 2.2 of its Graph API and updated software-development kits for iOS and Android to support the updated application-programming interface, also revealing that its ads API now supports versioning.

Facebook が、Graph APIVer 2.2 のリリースについて発表した。そして、最新の API をサポートするために、iOSAndroidi の SDK をアップデートし、さらには、バージョニングをサポートすることになる、Ads API についても明らかにした。

Software engineer Mahesh Sharma wrote in a post on the Facebook developer blog that applications created starting Thursday may only call version 2.2 of the Graph API or greater, adding that version 2.1 will be depreciated Oct. 30, 2016.

ソフトウェア・エンジニアである Mahesh Sharma は、この木曜日(10/30)以降に作成されるアプリのみが、Graph API の Ver 2.2 を利用できるようになり、また、2016年10月30日には、これまでの Ver 2.1 は価値を失うと、Facebook Developer Blog で述べている

Facebook had announced at its F8 global developer conference in San Francisco April 30 that version 1.0 will be depreciated April 30, 2015.

なお、今年の 4月30日に San Francisco で開催された、F8 Global Developer Conference で Facebook は、 2015年4月30日に Ver 1.0 が終了することも発表している。

Sharma offered some highlights of new features of version 2.2, saying that the full list of additions, changes and depreciations can be found in the change logs for the Graph API and the iOS and Android SDKs, as well as the upgrade guide:

Sharma は、Ver 2.2 の新機能から、いくつかのハイライトを提供している。具体的には、Graph API および iOSAndroid SDK のために、追加/変更/廃棄のフル・リストが、更新ログ内で参照できるようになり、また、Upgrade Guide も提供されると言及している:

  • アプリ群からプログラムを介して、ページ・ポスト上のコメントを表示/非表示に設定できる。
  • ユーザー・オブジェクト上に新たに提供される token_for_business フィールドにより、1つの企業が所有するマルチ・アプリ間をまたいで利用するユーザーを、容易に特定できるようになる。
  • そのために特化された subscribed apps edge を経由して、ページ・サブスクリプションをリアル・タイムで更新するための、新たな管理手法を提供する。
  • ページ・ノードおよび settings edge を介した API により、より詳細なページ属性の編集が実現される。

Sharma wrote on the addition of support for versioning to the ads API:

Sharma は、Ads API のバージョニング・サポートについて、以下の項目を追記している:

We recently announced new access levels for the ads API. In addition, from v2.2 onward, the ads API now supports versioning.

先日、私たちは、Ads API に関する、新しいアクセス・レベルについて発表した。 また、V2.2 以降より、Ads API はバージョニングをサポートするようになる。

For developers using the ads API, versioning means increased control over how you opt into new ads API features. Rather than changing a migration setting in your app dashboard, you can now control the behavior by specifying the version number in your client codebase.

Ads API を使用するデベロッパーがバージョニング機能を利用すると、新しい Ads API 機能にオプトインする際の、コントロールの幅が広がるようになる。それぞれのアプリのダッシュボードで、マイグレーション設定を変更するのではなく、クライアント・コード・ベースのバージョン番号を指定することで、その動きをコントロールできるようになる。

Our advertising products continue to evolve at a fast pace. To ensure that developers take advantage of this progress, the ads API will follow a 90-day breaking-change policy. To make this behavior clear, ads API methods will be removed from a version 90 days after the next version is released.

私たちのアド・プロダクトは、きわめて速いペースで進化し続けている。そのアドバンテージを、デベロッパーに対して保証するために、Ads API は 90日間のブレーキング・チェンジ・ポリシーに従う。具体的に言うと、Ads API における各メソッドは、次のバージョンがリリースされた90日後に削除されることになる。

As v2.2 is the first release for the ads API, ads API methods will be removed from v1.0, v2.0 and v2.1 in 90 days’ time. Developers using the Ads API should update their apps to call v2.2 before Jan. 28, 2015. After that date, all calls to ads API methods that do not specify v2.2 (including calls that do not specify any version) will result in an error.

v2.2 の Ads API が最初にリリースされた時から、90日が経過した時点で、古い広告 API メソッド群は、V1.0/V2.0/V2.1 から削除されることになる。Ads API を使用しているデベロッパーは、2015年1月28日以前に、自身のアプリから V2.2 を呼び出すよう、変更する必要がある。その日以降、V2.2 で指定されていない、すべての Ads API メソッド群への呼び出しは(バージョンを指定しない呼び出しも同様)、エラーを返すことになる。

For full details on the changes to the Ads API in v2.2, see the ads API blog and the dedicated ads API change log and upgrade guide.

Ads API V2.2 での変更に関する詳細は、ads API blog で参照できる。 また、専用の ads API change log および upgrade guide も参照して欲しい。

Finally, Sharma reminded developers of policy changes tied to the release of version 2.1 of the Graph API, which take effect at the end of their 90-day depreciation period, Nov. 5:

最後に、Sharma はでデベロッパーに対して、Graph API Ver 2.1 のリリースに関連する、ポリシーの変更について再確認している。それは、Facebook が規定した 90日後となる、11月5日に廃棄されることになる:

The recommendation bar plugin is deprecated and will stop appearing on your pages after Nov. 5. Please remove the <fb:recommendations-bar/> XFBML tag from your pages at the earliest opportunity.

Recommendation Bar プラグインが廃止されるため、11月5日以降は、ページ上での表示が行われなくなる。できるだけ早い時期に、ページの <fb:recommendations-bar/> XFBML タグを削除して欲しい。

You must not incentivize people to use social plugins or to like a page. This includes offering rewards, or gating apps or app content based on whether or not a person has liked a page. From Nov. 5, the liked field within the page property of the signed_request object will return true for all apps created before Aug. 7, 2014, when those apps are rendered inside a page tab.

ソーシャル・プラグインおよびページへの LIKE を用いて、人々にインセンティブを提供してはならない。つまり、人々がページに LIKE を付けていてもいなくても、賞金/アプリ/コンテンツなどを含む、一切の利益供与は禁止される。 11月5日以降、signed_request オブジェクトのページ・プロパティ内の LIKE フィールドは、2014年8月7日以前に作成されたアプリに関して、それらがページ・タブの内側にレンダリングされるときに、True を返すようになる。

The insights edge will be removed from the application object in v1.0 and v2.0. You should update your apps to call /v2.1/{app_id}/app_insights or /v2.2/{app_id}/app_insights to take advantage of the new app insights API.

V1.0/V2.0 の Application オブジェクトから、insights edge は削除されることになる。 新しい App Insight API のアドバンテージを得るためには、以下を呼び出すよう、あなたのアプリをアップデートする必要がある。

/v2.1/{app_id}/app_insights or /v2.2/{app_id}/app_insights

Developers: What are your initial thoughts?

デベロッパーたちへ:あなたの第一印象は どうだろう?

Related Stories

ーーーーー

今年の 2月に、「Facebook が Open Graph の デベロッパー・コレクションを停止した:とても残念!」という抄訳をポストしましたが、Graph API 自体は残っていたのでしょうね。 いずれにしろ、Facebook が Graph という考え方を捨てることはないはずであり、デベロッパーに開放する API を、新たに整理し直しているように思えます。 いずれにしろ Graph API は面白そうですし、Facebook のアーキテクチャとストラテジーを理解する重要な切り口になるはずなので、とてもワクワクしています。 そして、Open Graph というカテゴリを、残しておいて良かったと思っています🙂

ーーーーー

<関連>

Facebook の News Feed は、どう 変わったのか? なぜ 変わったのか?
Facebook が提供する、Open Graph のベスト・プラクティスとは?
Facebook の超高速ストレージ : TAO の詳細を説明しよう
Facebook が発表した TAO : これで MySQL と Memcached を接続する
Facebook は Open Graph へと ユーザーを誘う

Comments Off on Facebook の Graph API がアップデートされ、AD API も強化されたようだ!

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

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

What APIs Are And Why They’re Important
http://wp.me/pwo1E-6VI

Brian Proffitt – September 19, 2013
http://readwrite.com/2013/09/19/api-defined

_ 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 の地下鉄では、スマホ・チケットの試みが始まるらしい

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

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 
http://wp.me/pwo1E-5QI
Ingrid Lunden – January 30th, 2013
http://techcrunch.com/2013/01/30/wonder-no-more-yandex-says-facebook-has-given-a-final-no-on-graph-api-usage-will-pull-its-social-app/

image

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 のための潜在的なルートでもあった。 したがって、このマーケットが、同社の視界の中に留まり続けることは明確である。

ーーーーー

Image(1)Crunchbase
Company: Yandex
Website: yandex.ru
Launch Date: September 23, 1997
IPO: NASDAQ:YNDX

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: LiveInternet.ru). 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% を有している(情報源: LiveInternet.ru)。 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 がコラボ! 機械学習と物理学は 共鳴するのか?

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

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?
http://wp.me/pwo1E-5li

Guest Author, November 29th, 2012
http://blog.programmableweb.com/2012/11/29/mobile-backend-as-a-service-mbaas-give-me-liberty-or-give-me-convenience/

_ 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つに過ぎない:

___space

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).

さまざまな理由があるが、私たちのエクスペリエンスにおいて、以下の要因は、モバイル・アプリ・デベロッパーに共通するものである。そして、大半のケースにおいて、1人で作業を行う、独立したアップ・ストア・デベロッパーにおいて顕著なものとなる(そして、何らかのテーマに、フル・タイムで取り組むデベロッパーにも共通する)。

  • 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 により、世界のデベロッパーへ向けて開放されているのだ。

___space

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 買収から探ってみよう

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

%d bloggers like this: