Agile Cat — in the cloud

Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC by Agile Cat on December 11, 2014

Facebook Mobile Drops Pull For Push-based Snapshot + Delta Model
http://wp.me/pwo1E-85F
Monday, October 20, 2014
http://highscalability.com/blog/2014/10/20/facebook-mobile-drops-pull-for-push-based-snapshot-delta-mod.html

We’ve learned mobile is different. In If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong we learned programming for a mobile platform is its own specialty. In How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks we learned bandwidth on mobile networks is a precious resource.

私たちは、モバイルが別の世界のものであることを学んできた。If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong では、モバイル・プラットフォームのためのプログラミングが、独特のものであることを知った。そして、How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks では、モバイル・ネットワークの帯域幅が、きわめて貴重なリソースであることを学習した。

Given all that, how do you design a protocol to sync state (think messages, comments, etc.) between mobile nodes and the global state holding servers located in a datacenter?

それら、すべてのことを考慮して、ステート(メッセージやコメントなど)をシンクさせるためのプロトコルを、どのようにデザインすべきなのだろうか? ここでは、複数のモバイル・ノードと、データセンターのサーバーに置かれたグローバル・ステートの、同期について考えていく。

Facebook recently wrote about their new solution to this problem in Building Mobile-First Infrastructure for Messenger. They were able to reduce bandwidth usage by 40% and reduced by 20% the terror of hitting send on a phone.

最近のことだが、Facebook の Building Mobile-First Infrastructure for Messenger というポストにおいて、この問題に関する彼らの新しいソリューションが紹介されている。それによると、帯域幅の使用率が 40% まで、そして、スマホでの送受信を阻害する要因が 20% まで、削減できたという。

That’s a big win…that came from a protocol change.

それは、素晴らしい成功体験であり、また、プロトコルの変更にもたらされたものである。

<関連> Facebook が語るモバイル・チューニングの極意

Facebook Messanger went from a traditional notification triggered full state pull:

The original protocol for getting data down to Messenger apps was pull-based. When receiving a message, the app first received a lightweight push notification indicating new data was available. This triggered the app to send the server a complicated HTTPS query and receive a very large JSON response with the updated conversation view.

Messenger がデータをダウンロードする際の、オリジナルのプロトコルは Pull ベースのものであった。 このアプリはメッセージを受信するとき、新しいデータがあることを示す、ライトウェイトなプッシュ通知を最初に受信する。それは、アプリに対するトリガーであり、その結果として、サーバーへ向けて複雑な HTTPS クエリーを送信し、また、アップデートされた会話を取り込んだ、きわめて大規模な JSON レスポンスを受信することになる。

To a more sophisticated push-based snapshot + delta model:

Instead of this model, we decided to move to a push-based snapshot + delta model. In this model, the client retrieves an initial snapshot of their messages (typically the only HTTPS pull ever made) and then subscribes to delta updates, which are immediately pushed to the app through MQTT (a low-power, low-bandwidth protocol) as messages are received. When the client is pushed an update, it simply applies them to its local copy of the snapshot. As a result, without ever making an HTTPS request, the app can quickly display an up-to-date view.

私たちは、前述のモデルに代えて、Push ベースの SnapShot + Delta モデルに移行することを決めた。 この新しいモデルでは、クライアントは自身のメッセージに関する、イニシャルの SnapShot を取得する(一般的には、これまでの HTTPS Pull のみとなる)。 続いて、Delta アップデートが読み込まれるが、それはメッセージを受信した直後に、MQTT(リソースと帯域において負荷の少ないプロトコル)を介してアプリに Push されるものである。また、クライアントからアップデートが Push されるときには、ローカルに保持される SnapShot に、その内容がコピーされる。その結果として、これまでのような HTTPS リクエストを必要とすることなく、アプリはアップデートされたビューを表示できるようになる。

We further optimized this flow by moving away from JSON encoding for the messages and delta updates. JSON is great if you need a flexible, human-readable format for transferring data without a lot of developer overhead. However, JSON is not very efficient on the wire. Compression helps some, but it doesn’t entirely compensate for the inherent inefficiencies of JSON’s wire format. We evaluated several possibilities for replacing JSON and ultimately decided to use Thrift. Switching to Thrift from JSON allowed us to reduce our payload size on the wire by roughly 50%.

さらに、私たちは、メッセージと Delta アップデートから、JSON エンコーディングを切り離すことで、このフローを最適化した。もし、開発者のオーバーヘッドを最低限に抑えたかたちで、ヒューマン・リーダブルで柔軟なデータ転送を実現するなら、JSON は素晴らしいソリューションとなる。しかし、JSON における送受信の形式は、きわめて効率が悪い。 圧縮により、いくつかの問題は解決するが、JSON の固有の非効率性を、完全に補完することは不可能だ。私たちは、JSON を置き換えるための、いくつかの可能性について評価し、最終的には Thrift を使用することにした。JSON から Thrift へ移行することで、転送における実質的なサイズを、およそ 50% に低減できた。

On the server side Facebook also innovated:

Iris is a totally ordered queue of messaging updates (new messages, state change for messages read, etc.) with separate pointers into the queue indicating the last update sent to your Messenger app and the traditional storage tier. When successfully sending a message to disk or to your phone, the corresponding pointer is advanced. When your phone is offline, or there is a disk outage, the pointer stays in place while new messages can still be enqueued and other pointers advanced. As a result, long disk write latencies don’t hinder Messenger’s real-time communication, and we can keep Messenger and the traditional storage tier in sync at independent rates. Effectively, this queue allows a tiered storage model based on recency.

Iris は、メッセージングのアップデート(新しいメッセージやメッセージ・リードによるステートの変化など)で用いる順列キューのことであり、Massenger アプリに送信された最新のアップデートと、伝統的なストレージ階層において、別々のポインタを持つことが可能になっている。ディスクおよびスマホへのメッセージ送信が成功すると、それに対応するポインタが前進する。もし、スマホがオフラインであったり、ディスクに障害が発生した場合には、対象となるポインタを所定の位置に留めながら、新しいメッセージをキューに保持し、他のポインタを前進させることができる。その結果として、ディスクへの書き込みなどの、大きなレイテンシが発生しても、Messenger のリアルタイム通信を妨げることはない。 そして、Messenger のレベルと伝統的なストレージ階層を、それぞれの頻度で同期させることも可能だ。このキューの効率性により、新しい階層型ストレージ·モデルが実現する。

Delta based syncing strategies are very common in Network Management systems where devices keep a north bound management system in sync by sending deltas. The problem with a delta based approach is it’s easy for clients to get out of sync. What if changes happen at a rate faster than than deltas can be moved through the system? Or queues get full? Or the network drops updates? The client will get out of sync and it won’t even know it. Sequence numbers can be used to trigger a full sync pull if there’s an out of sync situation.

Delta ベースの同期ストラテジーは、ネットワーク・マネージメント・システムにおいて、きわめて一般的なものである。 そこでは、デバイスが Delta を送信することで、上位階層のマネージメント・システムとの同期を維持する。 Delta ベースのアプローチにおける問題点は、その同期のメカニズムから、クライアントが容易に逸脱してしまうことである。 何らかの変更が Delta よりも速く、対象となるシステムを介して移動することが、実際に起こり得るだろうか? また、キューが溢れると、どうなるだろうか? さらに言えば、ネットワーク上でアップデートが失われたら、何が起こるだろうか? いずれにせよ、クライアントは同期から逸脱し、起こっていることを知ることもできない。そのような場合には、シーケンス・ナンバーを用いる。 それにより、完全な同期を引き起こし、同期から逸脱している状況を解消できる。

It’s also good to see Facebook got rid of JSON. The amount of energy and bandwidth wasted on moving and parsing fat JSON packets is almost criminal.

Facebook が JSON から離れることは、別の観点でも歓迎すべきことだ。このような巨大なシステムが、重たい JSON パケットを解析して転送するために、膨大なエネルギーと帯域幅を消費することは、きわめて罪作りなことでもあるのだ。

ーーーーー

先日にポストした「Facebook が語るモバイル・チューニングの極意」に続いて、今回も Todd Hoff さんの記事を紹介することができました。途上国におけるモバイル通信の状況を前提とした、ストレスを最小限に抑えた環境を提供したいという、Facebook の一貫したストラテジーが見えてきますね。 ただ、これは、途上国だけの問題ではなく、たとえば日本においても、モバイル・トラフィックの大幅な削減という、大きなメリットをもたらすはずです。 そして、私たちが使用している大半のサービスは、① モバイル・デバイス、② モバイル・インターネット環境、③ バックエンド・テクノロジー、④ データセンター・インフラのバランスの上に成り立っているわけですが、とりわけ途上国においては、① と ② のケアが不可欠なのでしょう。

ーーーーー

<関連>

iOS から Android へ : Facebook は優先順位を切り替えるのか?
Facebook が キャリアの協会に参加 : 狙いは Internet.org だ!
Mark Zuckerberg と Internet.org : コネクティビティが社会経済をバランスさせる
Facebook とモバイルの巨人たちが、Internet.org を立ち上げた!
Facebook に続け : 10億に挑む Android と iOS

Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC, Strategy by Agile Cat on December 2, 2014

How Facebook Makes Mobile Work at Scale for All Phones, on All Screens, on All Networks
http://wp.me/pwo1E-84k
September 22, 2014 – ImageTodd Hoff
http://highscalability.com/blog/2014/9/22/how-facebook-makes-mobile-work-at-scale-for-all-phones-on-al.html

When you find your mobile application that ran fine in the US is slow in other countries, how do you fix it? That’s a problem Facebook talks about in a couple of enlightening videos from the @scale conference. Since mobile is eating the world, this is the sort of thing you need to consider with your own apps.

アメリカ国内では快適に走るモバイル・アプリが、その他の国では遅くなると分かったとき、どのように修正すればよいのだろう?それは、@scale conference における何本かのビデオで、Facebook が指摘している問題である。そして、この世界をモバイルが呑み込んで以来、あらゆるアプリにおいて考察すべき、ある種の問題でもある。

<関連> Facebook アプリ:Push + Delta + Thrift でモバイル帯域を 40% も削減!

In the US we may complain about our mobile networks, but that’s more #firstworldproblems talk than reality. Mobile networks in other countries can be much slower and cost a lot more. This is the conclusion from Chris Marra, Project Manager at Facebook, in a really interesting talk titled Developing Android Apps for Emerging Market.

アメリカにおいても、私たちはモバイル・ネットワークに文句を言うだろうが、Twitter の #firstworldproblems で語られていることが真実だ。その他の国々におけるモバイル・ネットワークは、はるかに遅いものであり、また、より多くの費用がかかる。以下に示すのは、Developing Android Apps for Emerging Market という興味深いタイトルの講演の中で、Facebook の Project Manager である Chris Marra が結論づけたものである。

Facebook found in the US there’s 70.6% 3G penetration with 280ms average latency. In India there’s 6.9% 3G penetration with 500ms latency. In Brazil there’s 38.6% 3G penetration with more than 850ms average latency.

Facebook が調べた結果によると、アメリカにおける 3G の浸透率は 70.6% であり、レイテンシは 280ms である。それがインドとなると、3G の普及率は 6.9% であり、レイテンシ は 500ms になる。そしてブラジルの場合は、38.6% と 850ms だ。

Chris also talked about Facebook’s comprehensive research on who uses Facebook and what kind of phones they use. In summary they found not everyone is on a fast phone, not everyone has a large screen, and not everyone is on a fast network.

さらに Chris は、Facebook のユーザーである人々および、そこで用いられるスマホに関して、同社が実施している包括的な調査についても話してくれた。要約すると、誰もが高性能のスマホを使い、大きなスクリーンを持ち、高速のネットワークを使用できると思ったら、それは大きな間違いということだ。

It turns out the typical phone used by Facebook users is from circa 2011, dual core, with less than 1GB of RAM. By designing for a high end phone Facebook found all their low end users, which is the typical user, had poor user experiences.

その結果として、Facebook ユーザーが使用する典型的なスマホは、2011年頃のモデルから始まり、Dual-Core の CPIU を搭載し、RAM は 1GB 以下ということが分かってきた。 ハイエンド・スマホに合わせてデザインしてきた Facebook は、ローエンドのデバイスを持つユーザーが大半であり、そのすべてがプアなユーザー・エクスペリエンスを持つことを理解した。

For the slow phone problem Facebook created a separate application that used lighter weight animations and other strategies to work on lower end phones. For the small screen problem Facebook designers made sure applications were functional at different screen sizes.

Facebook は性能の低いスマホのために、軽いアニメーションなどの戦略を適用するために、使別のアプリを作成した。また、同社のデザイナーたちは、小さなスクリーンという問題に対処するために、異なる画面サイズであっても、機能的にアプリが振る舞えるようにしていった。

Facebook has moved to a product organization. A single vertical group is responsible for producing a particular product rather than having, for example, an Android team try to create all Android products. There’s also a horizontally focussed Android team trying to figure out best practices for Android, delving deep into the details of what makes a platform tick.

つまり、Facebook 自身が、プロダクトを構築するための組織に転身しているのだ。例を挙げるなら、すべての Android プロダクツを、そのためのチームが開発するのではなく、特定のプロダクトを構築するために、垂直方向へと問題を掘り下げていくグループに責任が振り分けられている。ただし、プラットフォームに適合するものを詳細まで踏み込み、Android のためにベスト・プラクティスを把握していく、水平方向に焦点を当てた Androidチームも存在する。

Each team is responsible for the end-to-end performance and reliability for their product. There are also core teams looking at and analyzing general performance problems and helping where needed to improve performance.

そして、個々のチームが自身のプロダクトに関して、その性能と信頼性を隅から隅まで担当することになる。さらに、コアとなるチームが、全体的なパフォーマンスの問題を分析し、それを向上させるために必要な支援を行う。

Both core teams and product teams are needed. The core team is really good at instrumentation and identifying problems and working with product teams to fix them. For mobile it’s important that each team owns their full product end-to-end. Owning core engagement metrics, core reliability, and core performance metrics including daily usage, cold start times, and reliability, while also knowing how to fix problems.

コアとプロダクトの、双方のチームが必要とされている。コア・チームは、適切に測定を行い、問題を特定し、それらを修正するために、プロダクト・チームと協調していく。モバイル開発において重要な事は、それぞれのチームが自身のプロダクトについて、隅から隅まで責任を負うことである。また、コアとしての共有メトリクス/信頼性/性能の指標を確立し、そこにアプリを立ち上げたときや、連続して使用したときの、信頼性を加える一方で、問題の解決方式を認識していく。

To solve the slow network problem there’s a whole other talk. This time the talk is given by Andrew Rogers, Engineering Manager at Facebook, and it’s titled Tuning Facebook for Constrained Networks. Andrew talks about three methods to help deal with network problems: Image Download Sizes, Network Quality Detection, Prefetching Content.

低速のネットワークに関連する問題を解決するという、包括的なテーマがある。今回は、Facebook の Engineering Manager である Andrew Rogers の、Tuning Facebook for Constrained Networks というタイトルが付けられたトークを紹介したい。Andrew の話は、ネットワークに関連する問題を解決する、Image Download Sizes/Network Quality Detection/Prefetching Content という、3つの方法論に集約される。

Overall, please note the immense effort that is required to operate at Facebook scale. Not only do you have different phones like Android and iOS, you have different segments within each type of phone you must code and design for. This is crazy hard to do.

総論として、Facebook のスケールで運用するには、膨大な労力が要求される点に注意してくほしい。そこには、Android と iOS といったモバイルの種別だけではなく、それぞれのデバイスごとのセグメントがあり、それに対してコーディングしていく必要があるのだ。それを実践していくことは、まさしくクレイジーである。

Reducing Image Sizes -  WebP saved over 30% JPEG, 80% over PNG

  • Image data dominates the number bytes that are downloaded from Facebook applications. Accounts for 85% of total data download in Facebook for Android and 65% in Messenger.
  • イメージ・データは、Facebook アプリにダウンロードされる、バイトの大半を占める。 Android 用の Facebook においては、全ダウンロード・データの 85% を占め、Messenger では 65% を占めている。
  • Reducing image sizes would reduce the amount of data downloaded and result in quicker downloads, especially on high latency networks (which we learned were typical).
  • イメージ・サイズを削減すれば、ダウンロードされるデータの量が低減され、より迅速なダウンロードが達成されるだろう。それは、高レイテンシのネットワークにおいて、特に有効な手段となる(そこから、私たちは学んだ)。
  • Request an appropriate image size for the viewport
  • 表示環境にあわせた、適切なサイズのイメージを要求する。
  • Resize on the server. Don’t send a large image to the client and then have the client scale the image down to a smaller size. This wastes a lot of bandwidth and takes a lot of time.
  • サーバー上で、イメージのサイズを変更する。クライアントへ向けて大きなイメージを送信し、クライアント側でイメージを小さくするという手法を取ってはならない。 そのような方式だと、大量の帯域幅を無駄にし、長時間を要することになる。
  • Send a thumbnail (for profile pictures) and a small preview image (this is seen in the newsfeed), and then a full image (seen in photo stories) when a user asks to zoom in it. A low-res phone may never need a full image. Most of the time a thumbnail and a small preview is all you need.
  • サムネイル(画像のサムネイル)と、小さなプレビュー・イメージ(例 NewsFeed)を送信し、ユーザーが拡大を要求したときに、フル・イメージを送信する(例 Photo Story)。低解像度のスマホの場合は、フル・イメージが不要かもしれない。また、大半のケースにおいて、サムネイルとプレビューで、すべての要求に応えられる。
  • Significant savings. Scaling a 960 pixel image that is 79KB is size to 240 pixels wide yields a 86% size reduction, to 480 pixels is a 58% size reduction, to 720 pixels is at 23% size reduction.
  • データ転送量を、大幅に削減できる。たとえば、960 pixel スケールのイメージは 79KB であるが、240 pixel なら 86%、480 pixel なら 58%、720 pixel なら 23% の削減が達成される。
  • With screen sizes becoming larger scaling images isn’t as effective as it used to be. Still worth doing, but the payoff isn’t as much.
  • スクリーン・サイズより大きなイメージを、効果的に利用できるケースはほとんど無い。何らかの価値があるかもしれないが、その代償は大きい。
  • Change the image format
  • イメージ・フォーマットの刷新
  • 90% of images sent to Facebook and Messenger for Android use the WebP format.
  • Android 用の Facebook および Messenger では、90% のイメージで WebP フォーマットが用いられている。
  • WebP format released by Google in 2010.
  • WebP フォーマットとは、Google が 2010年にリリースしたものである。
  • WebP saves 7% download size over JPEG for equivalent quality.
  • WebP は、同品質の JPEG に対して、7% のサイズ圧縮を実現にする。
  • WebP saved over 30% download size over JPEG by tuning quality and compression parameters with no noticeable quality differences. A big savings.
  • WebP は、画質チューニングと圧縮パラメータにより、JPEG に対して 30% のデータ削減を可能にするが、視覚的な劣化は生じない。 それにより、ダウンロード・サイズを大幅に削減できる。
  • WebP also supports transparency and animation, which is useful for their Stickers product.
  • さらに WebP は、透過性とアニメーションをサポートするため、Sticker などのプロダクトに適している。
  • WebP saves 80% over PNG.
  • WebP は PNG の 80% に、データ量を低減する。
  • For older versions of Android the images are transported using WebP but transcoded on the client to JPEG for rendering on the device.
  • Android の古いバージョン用のイメージは、WebP を使って転送されるが、レンダリングのためにクライアント上で JPEG に変換される。

Network Quality Detection – Adjust Behavior to Network Quality

  • On the same network technology 2G, 3G, LTE, WiFi, connections speeds in the US were 2-3x faster than in India and Brazil.
  • 2G, 3G, LTE, WiFi といった、それぞれのネットワーク・テクノロジーにおいて、India や Brazil に対して U.S. は、2倍〜3倍の接続速度を有する。
  • LTE is often faster than WiFi, so you can’t just base the connection speed on technology.
  • 大半のケースにおいて、LTE は WiFi より高速であるため、テクノロジーの接続速度を論拠にはできない。
  • Built into the client the ability to:
  • Measure throughput on all large network transfers
  • 以下の機能を、クライアント内に作り込む:
  • 大規模ネットワークを通過する際のスループットを測定する。
  • Facebook servers provide a Round Trip Time (RTT) estimate in the HTTP header in every response
  • Facebook のサーバーは、すべてのレスポンスにおける HTTP ヘッダー内で、Round Trip Time (RTT) 推定値を提供している。
  • The client maintains a moving average of throughput and RTT times to determine network quality.
  • そのため、クライアントは、ネットワーク品質を判断するために、変動するスループットと RTT 時間の、平均値を保持できる。
  • Connections are bucketized into the following groups: Poor is < 150kbps. Moderate is 150-600kbps. Good is 600-2000kbps. Excellent is > 2000kbps.
  • 接続スピードは、以下のグループに分類される:Poor 150kbps 以下:Moderate 150〜600kbps:Good 600〜2000kbps:Excellent 2000kbps 以上。
  • Feature developers can adjust their behavior depending on the connection quality.
  • それらの接続品質に応じて、それぞれの機能の振る舞いを適正化していく。
  • Some possible responses based on quality:
  • その通信品質に基づき、いくつかの対策がある:
  • Increase/decrease compression.
  • Issue more/fewer parallel network requests. Don’t saturate the network.
  • 圧縮比の増減。
  • 並列ネットワーク・リクエストの増減。それにより、ネットワークをサチらせない。
  • Disable/enable auto-play video. Don’t cause more traffic on slow networks.
  • ビデオ自動再生の ON/OFF。 低速ネットワークでは、大量のトラフィックを要求しないようにする。
  • Pre-fetch more content.
  • より多くのコンテントを、プリ・フェッチする。
  • A tool developed at Facebook called Air Traffic Control supports the simulation of different traffic profiles. Each profile can be configured: bandwidth, packet loss, packet loss-correlation, delay, delay correlation, delay jitter. Extremely helpful in finding unexpected behaviour on slow networks.
  • Facebook では、内製のツールである Air Traffic Control により、各種のトラフィック・プロファイルのシミュレーションを行なっている。それそれのプロファイルは、帯域幅/パケット損失/パケット損失相関/遅延/遅延相関/遅延ジッタなどで構成されている。低速のネットワーク上で、予期できない動作などを見つけるのに、きわめて便利である。
  • There are buckets for videos, but not sure what they are.
  • ビデオ・トラフィックに関しては、その内容が不明である。

Prefetching Content

  • Issuing network requests for content ahead of when the content is actually needed on the device.
  • 実際にデバイスでコンテントが必要になる前に、ネットワーク・リクエストを発行する。
  • Prefetching is especially important on networks with high latency. Waiting to issue a download request for an image the user will be looking at a blank screen.
  • プリ・フェッチングは、とりわけ高レイテンシのネットワークで重要となる。イメージをダウンロードするリクエスト発行を待っているのでは、ユーザーにブランクの画面を見せることになる。
  • Issue network requests for feeds early in the app startup process so the data will be present when the feed is displayed to the user.  The download can occur in parallel with other initialization tasks.
  • アプリ起動プロセスで、フィードの先頭へのネットワーク・リクエストが発行されていれば、ユーザーに対して表示するときに、すでにフィードの準備が整うことになる。このダウンロードは、他のイニシャル・タスクと並行して、引き起こすことが可能である。
  • Keep a priority queue of network requests. Don’t block foreground network requests on background network requests or the user won’t see the data they are currently interested in.
  • ネットワーク・リクエストの、プライオリティ・キューを維持する。バックグラウンドのネットワーク・リクエストにより、フォアグラウンドのネットワーク・リクエストをブロックしてはならない。また、ユーザーが興味を持っているデータを、見せないような状況も避けるべきだ。
  • Monitor for overfetching and excess consumption of device resources. Over fetching could fill up the disk or waste a lot of money on the user’s data plan.
  • 過剰なフェッチングとデバイス·リソース消費をモニタリングする。フェッチングが行き過ぎると、全体的なディスク容量が不足し、また、データ・プランによっては、ユーザーのコストを増大させる。

Miscellaneous

  • Client uploading to servers. The idea is to send fewer bytes over the wire from the client to the server, which means resizing images on the client side before they are sent to the server. If an upload fails retry quickly. It’s usually just a problem in the pipe.
  • クライアントからサーバーへのアップロードに関しても、サーバーに送信する前にクライアント側でイメージをリサイズし、データ転送量を低減すべきである。アップロードに失敗した場合は、速やかに再試実行する。 一般的に、この問題はパイプ内のもとと認識すべきだ。
  • There are 20 different APKs (Android application package) for the Facebook app, cut by API level, screen size, and processor architecture.
  • Facebook アプリ用として、20種類の APK(Android Application Package)が存在する。 具体的に言うと、API レベルや、スクリーン・サイズ、プロセッサ・アーキテクチャなどにより分類されている。

Related Articles

Update: Instagram Improved Their App’s Performance. Here’s How.

ーーーーー

この長い記事を訳しながら、似ているなぁと思い始めてきたのが、Google の Street View 撮影部隊の話です。 どちらも、データセンターに積み上げたコンピューティング・パワーや、優秀な頭脳から生み出されるアルゴリズムでは解決の出来ない、労力と根気の世界の話です。 とは言え、このような労働集約型の作業に、膨大なリソースを投じるには、その正当性を裏付けるだけのストラテジーが必要です。 言い換えれば、途上国のマーケットに賭ける、Facebook の強い思いが生み出した唯一無二の方法論が、そこにあるはずなのです。 そして、そのノウハウを、こうして開示してくれる Facebook と、分かり易く整理してくれた Todd Hoff さんに感謝です。すばらしい!

ーーーーー

<関連>

FB+WhatsApp+Instagram のユーザー数は、世界の 1/3 に相当する 22億人だ!
Facebook の Graph API がアップデートされ、AD API も強化されたようだ!
Instagram が史上最大のマイグレ:200億枚のイメージを AWS から FB へ!
Facebook が買収し続けている特許の内容が、とても興味深い
Youtube と Facebook がモバイル・トラフィックの 1/3 を占有している

Mobile App の調査:厄介なエンタープライズを素通りして、コンシューマ市場へと流れるデベロッパーたち

Posted in DevOps, Mobile, On Monday, Post-PC by Agile Cat on December 1, 2014

Enterprise Mobile App Development: Complexity and a Skills Gap are Roadblocking App Development
http://wp.me/pwo1E-844
By Dick Weisinger – Nov 28, 2014
http://formtek.com/blog/enterprise-mobile-app-development-complexity-and-a-skills-gap-are-roadblocking-app-development/

The mobile enterprise business application market is expected to reach $61 billion by 2018, says Strategy Analytics.  In 2013, 900,000 mobile app developers were targeting the enterprise app market, and a survey by  VisionMobile found that only 15 percent of app developers are targeting the enterprise.

Strategy Analytics の予測によると、モバイル・エンタープライズにおけるビジネス・アプリケーションの市場は、2018年までに $61 billion に達するようだ。また、2013年には 90万のモバイル・アプリ開発者が、エンタープライズ・アプリ市場をターゲットにしていたが、VisionMobile の調査によると、アプリ開発者のうちエンタープライズをターゲットにしているのは、全体の僅か 15% に過ぎないことが分かった。

While enterprises are spending increasing amounts of money in developing mobile apps, independent mobile app developers have been shunning those projects, preferring to work instead on consumer apps where they can typically make more money.  Consumers are much more inclined to download apps and to pay for ones they view as useful, although that’s becoming increasingly difficult as Gartner predicts that nearly 95 percent of consumer apps in 2018 will be free to download.

エンタープライズはモバイル・アプリ開発における予算を増額しているのだが、独立系のモバイル・アプリのデベロッパーたちは、それらのプロジェクトを避けて、もっと稼げるコンシューマ・アプリを好んで開発しているのだ。 その一方で、コンシューマ・ユーザーは、まずはアプリをダウンロードし、自身にとって有用と思えるものには、対価を支払うという方向へ傾き始めている。しかし、Gartner が指摘するように、2018年におけるコンシューマ・アプリの 95% 前後は、無料ダウンロードになると予測されるため、その門は次第に狭くなっていく。

Enterprise mobile apps have become a pain point for many businesses.  Paulo Rosado, CEO of OutSystems, said that ”it’s clear that organizations are struggling to deal with a deluge of mobile app requests, with multiple platforms to support, hundreds of change requests and complex back-end integrations.  To make matters worse, as demand for mobile app developers grows, companies will continue to have a challenge hiring developers. Not only will they be increasingly hard to find, they will also be increasingly expensive.”

エンタープライズにおけるモバイル・アプリは、多くの企業にとって、痛みを伴うものになっている。 OutSystems の CEO である Paulo Rosado は、「 明らかなことは、それらの組織が、モバイル・アプリの要求という大洪水に対処するために、とても苦慮していることだ。つまり、マルチ・プラットフォームのサポートや、膨大な変更の要求、そして複雑なバックエンドの統合などが山積みとなっている。最悪のシナリオは、モバイル・アプリ開発者への需要が高まるにつれて、それらの企業が、デベロッパーを雇用しようと動き始めてしまうことだ。そうなると、デベロッパーを探し難くするだけではなく、コストの高騰を引き起こすだろう」と述べている

A survey on mobile app development by OutSystems found that:

OutSystems による、モバイル・アプリ開発者の調査からは、以下のような論点が読み取れる:

  • The average length of time to develop a mobile app is between three and twelve months
  • 63 percent of enterprises have 11 to 25 percent of their mobile app developer positions unfilled
  • モバイル・アプリ開発における平均的な期間は、2ヶ月〜3ヶ月である
  • エンタープライズの 63% が、モバイル・アプリ・デベロッパーの確保において、11%〜25% の不足を訴えている

ーーーーー

11/27 の Statista に、PC Outlooks Remains Grim Despite Tablet Slowdown という記事とチャートが紹介されていました。緩やかに低下していく Laptop/Desktop に対するニーズを、Tablet が補ってきますが、スマホのような爆発力があるかというと、そこまで盛り上がるマーケットではないようです。 そうなると、エンタープライズ・アプリのプラットフォームも、必然的にスマホへと集約されていくのでしょうが、まずは、小さなスクリーンに合わせたアプリの構造、多様化するスクリーン・サイズへの対応(特に Android)、そして、モバイル帯域の有効利用といった、問題を解決しなければなりません。ちょうど、いま、How Facebook Makes Mobile Work at Scale for All Phones, on All Screens, on All Networks と、Facebook Mobile Drops Pull For Push-based Snapshot + Delta Model という記事を訳しているのですが、同じような問題にエンタープライズも取り組まざるを得ないのでしょう。 来年が、Mobile BaaS の年になり、この辺りを吸収し始めてくれると良いですね。

ーーーーー

<関連>

Container の調査:Flocker を Docker 上に積み上げることで、アプリとデータの移動を容易に
CoreOS の調査:足し算から引き算へと、Linux ディストリビューションを再編する
Social の調査:Twitter と MIT の コラボ が、膨大なソーシャル・ストリームを分析していく
Data Center の調査:大変革を促す4つの要因とは? – Gartner
Security の調査: Google と Dropbox が発表した Simply Secure イニシアティブとは?

Cloud の調査: Docker によるアプリのパッケージ化は、すでに大きな実績を残し始めている!

Posted in Bare-Metal, Container, DevOps, Linux, On Monday by Agile Cat on July 7, 2014

Cloud Computing: The Containerization of Apps
http://wp.me/pwo1E-7DY

By Dick Weisinger – July 1st, 2014
http://formtek.com/blog/cloud-computing-the-containerization-of-apps/

_ formtek

Docker, the ‘Linux Container Engine’, is open-source Linux technology that can package all components needed by an application into a single container which can then be easily moved between cloud platforms, virtual machines, or physical bare-metal servers. 

Docker は Linux Container Engine であり、また、Linux オープンソース・テクノロジーであり、アプリケーションが必要とするすべてのコンポーネントを、シングル・コンテナ内にパッケージ化することを可能にする。さらに言えば、このコンテナは、クラウド・プラットフォームや、仮想マシン、物理ベアメタル・サーバー間を、簡単に移動できるのだ。

Docker allows software to be deployable across a wide range of environments yet doesn’t require platform vendors to conform to specific cloud or VM requirements.  Docker runs on all major Linux distributions, including Red Hat, Debian, Ubuntu, Fedora, Gentoo, Suse and Arch.

つまり、Docker により、幅広い環境におけるソフトウェアのデプロイメント実現されるのだが、そこで要求される移行先が、特定のクラウドや VM であっても、プラットフォーム・ベンダーによる準拠は不要となるのだ。そして Docker は、Red Hat/Debian/Ubuntu/Fedora/Gentoo/Suse/Arch といった、すべての主要 Linux ディストリビューション上で動作する。

Despite Docker being only first released 15 months ago and still only at version ’1.0′, it is already widely used by many internet companies which include eBay, Yelp, Spotify, and Baidu. Additional stats for Docker’s popularity include:

Docker の最初のリリースからは、まだ 15ヶ月しか経っておらず、いまでも Version 1.0 なのだが、たとえば eBay/Yelp/Spotify/Baidu などを含む、数多くのインターネット企業ですでに使用されている。 なお、Docker の人気については、以下のような状況からも判断して欲しい:

  • 2.75+ million downloads
  • 12,000+ stars on GitHub
  • 450+ contributors – 95 percent of whom do not work for Docker, Inc.
  • 14,000+ “Dockerized” applications published on Docker Hub
  • 90+ community-established user groups in more than 30 countries
  • 6,500+ Docker related projects found on GitHub

Ben Golub, Docker CEO, said that ”there’s a groundswell of excitement from the Fortune 10 on down for what Docker can mean for how they build, ship and run applications.  If Docker is successful, we will have enabled the separation of application creation and management from infrastructure management.”

Docker の CEO である Ben Golub は、「 Fortune 10 から中小にいたるまで、Docker が実現するアプリケーションの構築/出荷/実行という方式について、とても大きな興奮の高まりが起こっている。このまま、Docker が成功するなら、アプリケーションの開発と管理を、インフラストラクチャの管理から分離するという、新たな方式が確立するだろう 」と述べている

Scott Johnson, senior Vice President at Docker, said that “we’re from the school of container technology which we simplified along with the packaging and shipping of the container.  There’s been 15 months of rapid innovation. There’s over 440 contributors to the project, including lots of contributions from Red Hat, Google. A lot of rapid change is going on.”

Docker の Senior VP である Scott Johnson は、「私たちは、コンテナ・テクノロジーの学校から生み出されたようなものであり、コンテナによるパッケージングとシッピングにより、ものごとを簡略化していきたいと考えている。そして、この 15ヶ月の間に、とても迅速なイノベーションが生じている。すでに、このプロジェクトには 440人以上のコントリビューターがいるが、Red Hat や Google からも、たくさんのコントリビューションを受けている。つまり、急激な変化が、あちらこちらで、現在進行形で起こっている状況にある」と発言している。

Jay Lyman, senior analyst at 451 Research, said that “enterprise organizations are seeking and sometimes struggling to make applications and workloads more portable and distributed in an effective, standardized and repeatable way.  Just as GitHub stimulated collaboration and innovation by making source code shareable, Docker Hub, Official Repos and commercial support are helping enterprises to answer this challenge by improving the way they package, deploy and manage applications.”

451 Research の Senior Analyst である Jay Lyman は、「 エンタープライズたちは、アプリケーションやワークロードの移植性を高め、また、効果的かつ標準的な方法で繰り返して配布したいと考えているが、とても苦労しているという側面もある。GitHub でソースコードを共有することで、コラボレーションとイノベーションが刺激されたように、Docker Hub および、Official Repos、商用サポートにより、アプリケーションの Package/Deploy/Manage の方式が改善され、この課題に取り組むエンタープライスの支援が促進されている 」と述べている

ーーーーー

絶好調の Docker ですが、これ程の実績を、すでに残しているとは知りませんでした。 そして Docker の良いところは、VM だけではなく Bare-Metal にも対応している点であり、すでに、その方向へと舵を切り始めている SoftLayer  RackSpace などを、側面から強力にサポートしていくはずです。 AWS の大きな功績により、マーケットが開拓され、ビジネス・モデルが確立してきたクラウドですが、そろそろ第二幕が始まりそうで、とてもワクワクしています。

ーーーーー

<関連>

Cloud の調査: すべては Hybrid へと集約されていくのか?
Big Data の調査:未来においても Hadoop の支配は続くのか?
IoT の調査: 依然として見えてこない、セキュリティとプライバシーの方向性
Digital Universe の調査: データの生成は、人間からマシンへ、そして先進国から途上国へ
Data Center の調査: 未来のデータセンターは、小型で手元に置かれるものになる

Android デベロッパーに朗報 : Analytics 機能により Google Play 内でのトラッキングを実現

Posted in .Selected, DevOps, Google, Mobile, Post-PC by Agile Cat on October 16, 2013

Google Developers Finally Get Analytics In Their App-Building Console
http://wp.me/pwo1E-6ME

Dan Rowinski – October 04, 2013
http://readwrite.com/2013/10/04/google-analytics-developer-console

_ Read Write (2)

Google just took another step in its mission to give Android developers better tools to analyze and monetize their apps.

Google は Android デベロッパーに対して、そのアプリを効率よく分析しマネタイズしていくためのツールを提供するという、新たなミッションへ向けて第一歩を踏み出した。

Google makes good on its promise at the I/O developers conference in May.

The company has officially announced that it has integrated Google Analytics into its Google Play Developer Console for Android developers. Google had said that Analytics was coming to the Developer Console at its I/O conference in May this year.

同社のオフィシャル・アナウンスメントによると、Google Play Developer Console に Google Analytics が統合され、Android デベロッパーの便宜が図られるようになる。Google は Analytics について、今年 5月の I/O カンファレンスで、Developer Console に取り込まれていたと発言している。

Android developers can now download the Google Analytics software developer kit (SDK) and place it into an app and upload it to the Google Play Store. The Analytics SDK is also available for iOS apps.

Android デベロッパーは、Google Analytics SDK をダウンロードし、それをアプリに埋め込み、Google Play にアップロードできるようになっている。また、この Analytics SDK は、iOS アプリにも対応できるという。

Google Analytics for the Developer Console has four main aspects:

Google の Analytics for the Developer Console は、以下の 4つの狙いを持つ:

クリックで拡大 ⇒

Google Play Referral Flow: Helps developers figure out where Google Play traffic is coming from (search, marketing campaigns, blogs or media articles etc.). This feature helps marketers figure out how successful their campaigns are and where the best traffic comes from.

Google Play Referral Flow: デベロッパーが、Google Play トラフィックの導線(サーチ/キャンペーン/ブログなど)を理解できるようにする。この機能により、マーケティング担当者は、最適なトラフィックが発生する場所を特定し、キャンペーンを成功へと導いていく。

Views in Google Play: Referral Flow shows how many people have viewed the app in Google Play.

Views in Google Play: 前述の Referral Flow により、どれだけの人々が対象アプリを参照したのかを、Google Play 内で把握できるようになる。

Installs: Once figuring out where the traffic came from through the Referral Flow, Analytics tracks users that actually clicked and downloaded the app through Google Play.

Installs: Referral Flow を介して、トラフィックが生じる場所が把握できると、Google Play でアプリをクリックし、ダウンロードしたユーザーを、Analytics が追跡することになる。

New Users: Goes beyond the straight download numbers to show people that have opened the app and begun to use it and become “Active Users.”

New Users: 単なるダウンロード数ではなく、実際にアプリをオープンして、使い始めている Active Users 数をを表示する。

クリックで拡大 ⇒

The goal for Google is to show not just the raw number of views and downloads, but also how much people have engaged with the app and what version of Android they are using. With the Analytics SDK, developers can know what Android API Level their users are employing. This is beneficial information for developers that need to know how many people are using older versions of Android, such as versions 2.3.7 Gingerbread that may not have certain capabilities that are in newer versions of the operating system.

Google のゴールは、単なる参照とダウンロードの数だけでなく、どのくらいの人々が対象アプリにつなぎとめられ、また、どの Android バージョンが使用されているのかを示すことにある。Analytics SDK を用いることで、ユーザーが利用している Android API Level を、デベロッパーは知ることが可能だ。 つまり、どれだけの人々が、たとえばバージョン 2.3.7 Gingerbread のような、古い Android バージョンを使用していのかを、知る必要のあるデベロッパーにとって、とても有益な情報となる。なぜなら、このオペレーティング・システムの、最新バージョンにおける特定の機能を、旧バージョンはサポートしていない可能性があるからだ。

Google employs “flow visualization” in Analytics to show how a user got to the app and what actions they took within the app.

Google は、Analytics において “flow visualization” を採用し、そのアプリをユーザーが取得する方式や、そのアプリで使用されるアクションなどを示すようにしている。

ーーーーー

image28この 8月にポストした『 Google I/O 2013 の約束 : すべて 順調! PHP もバッチリだ! 』という抄訳では、この Android デベロッパー・サポートに触れられていませんでした。 しかし、さすがは Google 先生、やることが理に適っていて、とても感心してしまいます。言われてみれば、当たり前のことなのですが、この記事を読むまで、アップ・ストアのトラッキング結果がデベロッパーにフォードバックされる世界など、思いもつかなかったことです。 これは、とてもカッコ良いですね!image

ーーーーー

<関連>

Developer の調査: いまふう デベロッパー の 特質とは?
開発環境をクラウドに移行できれば、デベロッパーは幸せになれるはず
Kinvey の Mobile BaaS と、Red Hat の PaaS が統合される!
OpenStack エンジニアに対する、求人の高まりを示すチャートとは?
Google App Engine が PHP をサポートする: 75% の Web をカバーしているから

Developer の調査: いまふう デベロッパー の 特質とは?

Posted in .Selected, DevOps, Research by Agile Cat on October 7, 2013

Software Developers: A Profile of the Modern-Day Developer
http://wp.me/pwo1E-6KQ

By Dick Weisinger, on October 2nd, 2013
http://www.formtek.com/blog/?p=4063

_ formtek

Forrester Research recently looked at the types of projects and technologies that software developers are currently working on to get an idea about  which technologies are gaining traction and what kinds of applications we might expect in the near future.

最近の Forrester Research は、ソフトウェア開発者が現在の時点で取り組んでいる、プロジェクトやテクノロジーの種類に注目している。 それにより、勢いを増しているテクノロジーと、近い将来に望まれるアプリケーションの分類について、アイデアを得ようとしているのだ。

Somewhat surprisingly, the projects that the majority of developers surveyed are working are lagging industry trends.  Less than a quarter of all enterprise developers are developing for the cloud, and only about 30 percent of all developers have ever contributed to the development of a mobile app.  Part of the reason for the slow migration to these newer technologies is that businesses still need to keep their legacy apps running and just don’t have the bandwidth to take on new platforms.  The report found that compared to larger enterprises, small and mid-sized businesses are more likely to dabble with newer technologies like mobile (34 percent) and NoSQL (15 percent).

少し意外なのは、この調査の対象となった、大半のデベロッパーたちが取り組んでいる、それぞれのプロジェクトが業界のトレンドから遅れている点である。つまり、すべてのエンタープライズ開発者のうち、クラウドを開発しているという回答が 1/4 であり、また、これまでにモバイル・アプリを開発したことがあるという回答が 30% になっているのだ。それらの新しいテクノロジーへ向けた移行が遅れている理由として、依然としてエタープライズは、レガシー・アプリケーションの維持が必要であり、また、新しいプラットフォームに取り組むには、余力が不足しているという点が挙げられる。そして、このレポートは、大企業に比べて中小企業の方が、Mobile(34%)や NoSQL(15%)といった、新しいテクノロジーに手を出す可能性が高いとしている。

“read the trade press and you’d think that PCs and laptops have gone the way of the dodo, consigned to the dustbin of history by smartphones and tablets. Developers are certainly building more mobile apps than ever, but web applications and relational database applications are still a primary focus,” says the Forrester report. The report notes some characteristics of developers that have jumped to the cloud, finding them a bit of a different breed:

「 業界紙を読んで、PC や Laptop について考えれば、それらが絶滅への道を進んでいると思うだろう。 つまり、Smartphone や Tablet により、その歴史はお払い箱にされるのだ。 ただし、デベロッパーたちが、これまで以上にモバイル・アプリを構築していても、Web と RDB のアプリケーションが、依然として一番に優先されている」と、Forrester のレポートは述べている。そして、このレポートは、クラウドに飛び込んできたデベロッパーたちにには、いくつかの血統が見いだせると、その特徴について指摘している:

  • Cloud developers tend to be early adopters of technology in general. 19 percent of cloud developers use Windows 8, for example, compared to only 3 percent of non-cloud developers
  • Cloud developers tend to have more years of programming experience than non-cloud developers. 71 percent have been programming for at least six years and 11 percent have been programming for more than 20 years.
  • Cloud developers report greater job satisfaction. 64 percent feel that they are challenged every day while only 36 percent of non-cloud developers do.
  • 一般的に見て、クラウド開発者は、テクノロジーのアーリー・アダプターになるという傾向を持つ。たとえば、クラウド開発者の 19% が Windows 8 を使用しているが、その他の開発者となると、それは 3% のみとなる。
  • クラウド開発者は、その他の開発者と比べて、長年におよぶプログラミング・エクスペリエンスを有する傾向にある。そのうちの、71% は 6年以上の、また、11% は が 20年以上の、プログラミング経験を有している。
  • クラウド開発者は、その仕事の内容に満足している。毎日がチャレンジだと答えている、クラウド開発者は 64% に達するが、その他の開発者となると、36% にまで低下してしまう。

The Forrester report describes developers as follows:  ”Modern software developers are creative, learn socially, and generally enjoy being developers.  They’re creative professionals, not drones – and they’ll function better in co-located ‘feature teams’ of three to five people in a development shop with high transparency and a full understanding of the value business sponsors need them to deliver…  Most developers are intrinsically motivated. The way that developers view their craft adds fuel to the argument that writing software is more creative pursuit than algorithmic endeavor. We constantly speak with professionals who ‘are developers’ — they don’t just ‘develop software.’”

Forrester のレポートは、デベロッパーについて、以下のように説明している。「 一般的に見て、いまふうのソフトウェア・デベロッパーは、創造的であり、また、社会と上手く付き合い、開発者であることに喜びを見出している。 彼らは創造的なプロフェッショナルであり、怠け者ではない。 彼らは、3人~5人で構成される、役割を共有するチームの中で、高い透明性を持ちながら、上手く機能するだろう。 そして、ビジネスの主体(責任者)が持っている、その価値観を完全に理解し、それに応じたものを提供する。 ほとんどのデベロッパーは、本質的なレベルでモチベーションを有している。 デベロッパーが、自身の成果を評価する姿勢が、アルゴリズムへ向けた取り組みよりも、コードのライティングの方が、より創造的な探求であるという議論を促進している。 したがって、私たちは、デベロッパーであるプロフェッショナルとの対話を継続する。  彼らは、単にソフトウェアを開発してるのではないのだ 」

ーーーーー

TAG indexAgile_Catも、この2年ほど、OCDET に参加しており、デベロッパーの人たちと話をする機会に恵まれていますが、そう言えば、みなさん、この Forrester のレポートに書かれているように、とても強いモチベーションを持っているように思えます。 そして、そのベースにあるのが、オープンソースがもたらす広大で安定したエコシステムだと思えるのです。以前に、『 OSS のスキルは、エンジニアの人生を豊かにする 』という抄訳をポストしましたが、そこには、プロプライエタリにもオープンソースが取り込まれ、スキルのハイブリッド化が進むと書かれています。それそれの開発者の、それぞれの気持ちの話なので、傍から言及するのもおこがましいのですが、とても良い方向へ向かっていると感じます。__AC Stamp 2

ーーーーー

<関連>

クラウドの市場調査 : 大手プロバイダーが総売上の 2/3 を占有
SaaS の調査:コラボレーションとモバイルが、その成長を加速させている
Facebook の有償プロモーション : アメリカ政府も御用達だ!
アメリカの職場 : 従業員の 29% が仕事中に Facebook を使っている!
アメリカの職場 : Facebook 禁止は 20% に過ぎない!

Kinvey の Mobile BaaS と、Red Hat の PaaS が統合される!

Posted in .Selected, BaaS, DevOps, Mobile, PaaS, Red Hat by Agile Cat on September 27, 2013

Kinvey Joins Red Hat’s OpenShift Platform as a Service Ecosystem
http://wp.me/pwo1E-6Hk
Sep 16, 2013 –
Kelly Rice
http://www.kinvey.com/blog/3246/kinvey-joins-red-hats-openshift-platform-as-a-service-ecosystem

_ Kinvey

Today, we are excited to announce that Kinvey is integrating with Red Hat’s OpenShift PaaS, allowing developers to mobilize business-critical data from on-premise or cloud environments into their mobile, tablet and web apps.

今日、私たちは、Red Hat の OpenShift PaaS と Kinvey との統合について、発表できたことを嬉しく思っている。それにより、デベロッパーたちは、クリティカルなビジネス・データを、オンプレミスおよびクラウドの環境から、モバイル/タブレット/Web アプリへ向けて、集約できるようになっていく。

Kinvey will make it easier for OpenShift customers to integrate securely with their organizations’ on-premise or cloud systems, such as CRM systems or JBoss environments, thereby accelerating development time for advanced mobile apps. An OpenShift cartridge will automate the process of deploying Kinvey’s Data Link connectors, allowing developers to more efficiently extract business-critical data into their apps.

Kinvey のい提供するテクノロジーにより OpenShift ユーザーは、CRM システムや JBoss 環境といった、クラウドおよびオンプレミスのシステムを、安全かつ容易に統合できるようになる。つまり、先進的なモバイル・アプリの開発時間が大幅に短縮されることになる。OpenShift カートリッジが、Kinvey Data Link コネクタのデプロイメント・プロセスを自動化するため、デベロッパーたちは、クリティカルなビジネス・データの抽出を、これまで以上の効率で達成していける。

Our CEO, Sravish Sridhar, says: “Partnering with OpenShift gives our customers the flexibility to mobilize enterprise backend systems, such as JBoss, using OpenShift’s on-prem and cloud-based PaaS. We’re excited to become a part of their ecosystem, together helping developers build advanced applications.”

当社の CEO である Sravish Sridhar は、「 OpenShift との提携により、私たちの顧客はオンプレミスとクラウドをベースとした OpenShift PaaS を用いて、たとえば JBoss などのエンタープライズ・バックエンド・システムを柔軟に集約していくようになる。彼らのエコシステムの一部となり、デベロッパーによる先進アプリの構築を、一緒になって支援していくことを、とても楽しみにしている」と、述べている。

You can read the full press release here.

ーーーーー

imageなにかにつけて、どこが違うの? ・・・ と、よく比較される BaaS と PaaS ですが、かの Kinvey さんが統合と言うのなら、それなりの意味が、双方にあるのでしょう。 文中で指摘されるように、「 Data Link コネクタのデプロイメント・プロセスを自動化 」というのが、ポイントのように思えます。それと、やはりエコシステムなのですね。 双方のエコシステムが、お互いを理解して協調できれば、Mobile App が簡単かつ安上がりに、どんどんと量産されるのでしょう。素晴らしいことです! image

ーーーーー

<関連>

Google 対 Parse の戦いが始まる : Mobile BaaS 最前線
Google と Kinvey が提携 : Mobile BaaS 最前線
Facebook が買収した、Mobile BaaS の Parse とは?
Facebook – Parse 連合 : 10万タイトルのクラウド・アプリを生み出す
Facebook の Open Graph を用いる、素敵な 5つのモバイル・アプリとは?
モバイル・デベロッパー 6000人に訊きました ⇒ $5000/月くらいは稼いでいるぜ!

 

OpenStack エンジニアに対する、求人の高まりを示すチャートとは?

Posted in .Selected, DevOps, OpenStack, Research by Agile Cat on September 18, 2013

Guess what? OpenStack fans say OpenStack skills are in demand
http://wp.me/pwo1E-6DQ

Sep 16 2013 – By
Barb Darrow
http://gigaom.com/2013/09/16/guess-what-openstack-fans-say-openstack-skills-are-in-demand/

_ Gigaom

Summary: The OpenStack Foundation says the world needs more mad OpenStack skills, so it’s launched a training marketplace to grease the skids.

Summary: OpenStack Foundation が言うには、この世界が大量の OpenStack スキルを必要としているため、すでに立ち上げられているトレーニング市場は、素晴らしい勢いで伸びているとのことだ。

ーーーーー

In what should come as as surprise to no one, the OpenStack Foundation says skills in building and deploying OpenStack cloud technology are very much in demand. (see the charts below).

誰にとっても、それほどの驚きではないと思うが、OpenStack Foundation は、OpenStack クラウド・テクノロジーにおける構築とデプロイのスキルに対して、きわめて大きな需要があると発言している。 (下のチャートを参照)

To address the skills gap, the Foundation is launching a Training Marketplace, with coursework from OpenStack partisans including Aptira, hastexo, The Linux Foundation, Mirantis, Morphlabs, Piston, Rackspace, Red Hat, SUSE and SwiftStack with more courses to come.

そして、こうしたスキル・ギャップに取り組むために、この Foundation は、Aptira/hastexo/The Linux Foundation/Mirantis/Morphlabs/Piston/Rackspace/Red Hat/SUSE/SwiftStack といった、OpenStack パルチザンが提供する授業で構成される Training Marketplace を立ち上げているところである。

OpenStack Jobs Pay
Infographics

Why would you want to bone up on your OpenStack skills? Because you can make more money, according to the foundation:

それまでして、誰もが OpenStack スキルで習得したがる理由について、より多くのビジネスがあるからだと、この Foundation は言っている:

Here’s another data point, there are more job postings mentioning OpenStack skills than there are for rival open-source clouds CloudStack and Eucalyptus, according to SimplyHired.com data, as shown below.

また、以下に示す SimplyHired.com からの別データによると、CloudStack や Eucalyptus といったライバルのオープンソース・クラウドと比較して、OpenStack スキルに対する求人は多いようだ。

Openstack, Cloudstack, Eucalyptus trends
Openstack jobs | Cloudstack jobs | Eucalyptus jobs

But then again, when you talk about job postings requiring cloud skills, you’d be remiss not to include Amazon Web Services which brings us to this, provided Indeed.com knows what AWS is.

しかし、Indeed.com が認識していると思われる、Amazon Web Services に関するデータを取り込み、このクラウド・スキルに対する需要を整理し直すと、以下のようなチャートになる。

Openstack, Cloudstack, Eucalyptus, Aws trends
Openstack jobs | Cloudstack jobs | Eucalyptus jobs | Aws jobs

Data for the last two charts provided by SimplyHired.com, a search engine for jobs.

Related research

ーーーーー

openstack-55a1先月にポストした、『 OpenStack を Next Linux にする : Red Hat が考えるサーティフィケーションとトレーニングとは? 』という抄訳には、ーーー OpenStack には、多様なトレーニングが提供されている。OpenStack トレーニングを立ち上げたプロバイダーは Rackspace だったが、最近では OpenStack Bootcamp の提供者であり、システム・インテグレーターでもある Mirantis が、そのトレーニング・プログラムに関連して、$10 million のファンドを得ている。また、Piston Computing も OpenStack に関連して、クラウドのアドミン/エンドユーザー/デベロッパーのためのコースを提供し、そこには、Cloud Foundry インテグレーションまで取り込まれている。 ーーー と記載されていました。多種多様なトレーニング・コースが提供され、OpenStack への需要を後押ししているように思えますね。__AC Stamp 2

ーーーーー

<関連>

OpenStack に必要なのは有力ベンダーであり、インターオペラビリティではないのだ!
Pivotal と Piston が タッグ : Cloud Foundry を OpenStack 上にアジャイル展開
OpenStack における議論のループ : それを示す1枚のチャート
Android から OpenStack を管理 : Rackspace が専用アプリを提供
成長する OpenStack と 呼応する アジア : 次のサミットは 11月の 香港だ!

%d bloggers like this: