Agile Cat — in the cloud

PaaS の 調査: もたらすものは、インフラ・コストの削減と、アプリ開発の加速?

Posted in .Selected, PaaS, Research by Agile Cat on December 16, 2013

Platform as a Service (PaaS): One way to Cut Infrastructure Costs and Speed Application Development

By Dick Weisinger – December 11th, 2013

_ FormTek

The public platform-as a service (PaaS) market is expected to double in the next four years, according to research by IDC.

IDC の調査によると、パブリック PaaS(Platform as a Service)市場は、これからの 4年間で 2倍に増大するようだ

PaaS cloud-based provider services include a base computing stack of components, that include the hardware, operating systems, storage, and network capacity. The consumer is responsible for deploying and configuring the software on the PaaS-provided stack.

PaaS クラウドをベースとするプロバイダのサービスには、ハードウェア/オペレーティング・システム/ストレージ/ネットワークといった、いくつかのコンポーネントをベースにした、コンピューティング·スタックが取り込まれている。 そして、利用者は、対象となる PaaS が提供のスタック上に、ソフトウェアをディプロイし、コンフィグレーションしていく。

David Linthicum notes that the line between infrastructure-as a service and PaaS is rapidly blurring.   “PaaS isn’t much good unless you have the infrastructure to support the resulting applications, and IaaS doesn’t really help unless you have the ability to create solutions that run on the infrastructure. PaaS must have infrastructure, and infrastructure must have PaaS.”

David Linthicum は、IaaS(Infrastructure as a Service)と PaaS を識別するラインが、最近になって急速にぼやけてきたことを指摘している。 そして、「あなたが、結果としてのアプリケーションをサポートする、インフラを持っていない限り、PaaS は優れたものにならないだろう。 また、インフラ上で稼働するソリューションを、作り出す能力を持っていない限り、IaaS は本当の助けにならない。つまり、PaaS はインフラを持つ必要があり、インフラ PaaS を持つ必要がある」 と続けている。

IDC forecasts that the global PaaS market will grow from $3.8 billion in 2012 to more than $14 billion by 2017.  Companies see PaaS as a tool for them to cut their infrastructure costs and to speed application development.

IDC の予測によると、グローバル PaaS 市場は、2012年の $3.8 billion から、2017年の $14 billion へと成長していくようだ。そして、いくつかの企業は、そのインフラ・コストを削減し、アプリケーション開発をスピードアップするための、ツールとして PaaS を認識している。

The IDC reports some of the drivers for the rapid growth of PaaS include:

IDC のレポートには、PaaS の成長を加速させる要素として、以下の項目が取り込まれている:

  • Need for real-time interactions with customers and partners
  • Industry-specific requirements like healthcare reform and fiscal reform by governments
  • Increasingly more advanced types of data management applications
  • カスタマーやパートナーとの、リアルタイム・インタラクションに関するニーズ
  • 行政によるヘルスケアや財政の改善にも似た、産業界における要望
  • より先進的な、データ管理アプリケーションの増大

IDC recognizes the following sub-markets within the PaaS category of services:

また、IDC は、PaaS カテゴリ内のサブ・カテゴリとして、以下の各項目を認識している:

  • Application platform-as-a-service
  • Database platform-as-a-service
  • Integration platform-as-a-service
  • Business process management platform-as-a-service
  • Cloud testing and other platform-as-a-service

The report comments about future trends for application developers that “one of the biggest unknowns related to public PaaS is its potential impact on IT staff. Because public PaaS improves developer productivity by a factor of two or more, what happens to the developer workforce? Do enterprises make more use of IT or elect to take some or all of the benefit in terms of reducing the developer workforce? The answer lies somewhere in the middle.”

このレポートは、アプリ開発者に対する、これからのトレンドに関して、「 パブリック PaaS に関連する最大級の未知数として、情シス担当者への潜在的な影響力がある。なぜなら、パブリック PaaS により、開発者の生産性が何倍にも向上する可能性があるため、どのような影響が、労働力としての開発者に生じるのか、その辺りが分からないのだ。つまり、エンタープライズは、情シスの更なる活用を見つけ出すのか? それとも、開発者の労働力を削減するという観点で、一定あるい全体的なメリットを得ようとするのだろうか? その答えは、両者の中間に位置している 」と、コメントしている。


research_55この 6月のことですが、『 Facebook – Parse 連合 : 10万タイトルのクラウド・アプリを生み出す 』と『 Google と Kinvey が提携 : Mobile BaaS 最前線 』という抄訳を、立て続けにポストしましたが、PaaS のキー・コンポーネントとして、MBaaS の存在が挙げられるのかもしれませんね。 そして、『 SAP と HANA が、Open Compute に恋する理由 』などを読むと、それらとは異なるスタックでの、コンポーネントの共有も進むのかと、いろんなことを想像してしまいますね。image



Kinvey の Mobile BaaS と、Red Hat の PaaS が統合される!
Google 対 Parse の戦いが始まる : Mobile BaaS 最前線
Microsoft も Azure で MBaaS : Custom API をクリックするだけ!
Facebook が買収した、Mobile BaaS の Parse とは?
Mobile BaaS なら、ボクらの方が先輩だよ! Salesforce くんへ、Kinvey より
Salesforce も Rackspace も、目指すは モバイル BaaS なのだ!
Facebook の Open Graph を用いる、素敵な 5つのモバイル・アプリとは?

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
Sep 16, 2013 –
Kelly Rice

_ 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/月くらいは稼いでいるぜ!


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

Google が擁護する、App Engine におけるロックインの定量化とは?

Posted in .Selected, Google, Interoperability, PaaS by Agile Cat on September 12, 2013

Google defends, quantifies App Engine lock-in concerns
Derrick Harris – JUL. 9, 2013

_ Gigaom

Summary: Google App Engine’s engineering director, Peter Magnusson, took to Google+ on Tuesday to dispute a lingering reputation the company is trying to lock in developers with its PaaS offering.

Summary: 火曜日のことだが、Google App Engine の Engineering Director である Peter Magnusson は、同社が提供する PaaS により開発者をロックするという、いつまでも消えない評判を戦うために、Google+ に登場した。

photo: Shutterstock / Mopic

Google App Engine engineering director Peter Magnusson has some good news and some bad news about his product. The good news: Contrary to its reputation among some people, Google isn’t locking anybody in by design. The bad news: In practice, it is kind of locking in developers, though.

Google App Engine の Engineering Director である Peter Magnusson は、自身のプロダクトに関して、いくつかの Good News と Bad News を持っている。Good News:何人かの人々が言う悪評に反して、Google はデザイン面で誰もロックしていない。 Bad News:しかし、実際のところ、それは開発者をロックする、ある種のものである。

Magnusson laid out his case in a lengthy Google+ post Tuesday morning in which he explains away lock-in as a case of necessary trade-offs. Essentially, he argues, you can either have access to the guts of the infrastructure and the flexibility — and operational effort — that comes along with that, or you can free yourself of those headaches by using someone else’s abstractions. If you’re using App Engine, that means you also get to use rad features such as Datastore and take advantage of Google’s know-how around things such as load balancing and fending off DDoS attacks.

火曜日の朝の長い Google+ ポストで Magnusson は、必要なトレードオフのケースとして、ロックインとは切り離した自身の経験について説明している。彼の基本的な主張は、インフラとフレキシビリティの本質にアクセスし、また、それに伴う運用上の取り組みを達成できるというものである。さもなければ、他の誰かが考えた、抽象化の概念を用いて、それらの悩みから自身を解放できるという。 つまり、あなたが App Engine ユーザーなら、すでに Datastore などの素晴らしい機能を利用し、また、ロード・バランシングや DDoS 対策といった、先進的な機能を利用していることになる。

With the right practices, portability is possible

Additionally, Magnusson writes, there are generic best practices developers can use to create applications that should be relatively easy to port between modern web application platforms. And, he continues:

それに加えて Magnusson は、アプリケーション構築にデベロッパーが用いる、汎用的なベスト・プラクティスが存在しており、最新の Web アプリケーション・プラットフォームを結びつけるために、それほど難しくなく移植できるはずだと述べている。さらに続けて:

“The stacks that these abstractions map to are replaceable by you. The Google Cloud Datastore is “just” anther NoSQL/NearSQL solution and can be replaced by stacks such as MongoDB; memcache is memcache; MySQL can obviously replace Google Cloud SQL; and the language containers are mostly forward compatible with other containers. Significant portions of the client environment, such as NDB, are open sourced by us already. When we add new building blocks like the Go language, we open source the whole language.”

これらの抽象概念がマップするスタックは、あなたによりリプレースが可能である。たとえば Google Cloud Datastoreは、まさに別の NoSQL/ NearSQL ソリューションであり、MongoDB といったスタックによりリプレースできる。 memcache は memcache のままであが、言語コンテナは他のコンテナに対して上位互換性を持つ。たとえば NDB などの、クライアント環境における重要な部分は、すでにオープンソース化されている。 さらに言えば、Go 言語のような新しいビルディング・ブロックを追加するとき、その言語全体が、オープンソース化されていく。

Want more proof? Magnusson points to Google’s partnership with open-source App Engine implementations such as AppScale, as well its work with Red Hat to bring the App Engine APIs to the JBoss and OpenShift platforms. Oh, and the rollout of the Google Compute Engine platform for users who really do want control at the infrastructural level.

これ以上の証明が、必要とされるだろうか? Magnusson は、オープンソース App Engine 実装する、たとえば AppScale と Google のパートナーシップを指摘するだけではなく、JBoss および OpenShift のプラットフォームに、App Engine の API を取り込むための、Red Hat との協業にも触れている。そして、インフラレベルでのコントロールを必要とするユーザーに対しては、Google Compute Engine プラットフォームを展開しているのだ。

The App Engine homepage.

Now here comes the “but …”

All that said, there is the cold, hard truth that running on a platform like Google App Engine (or, one could argue, almost any other cloud platform) inherently involves some degree of lock-in. Google does exit interviews with large-scale customers when they leave, and it has found the average time for them to successully move their application to a new platform is three to four months. “I would posit that this is not materially worse than any other public-cloud-to-public-cloud transition once you have a complex system up and running,” Magnusson wrote.

ここで述べてきた、すべての事柄を、Google App Engine(大半のクラウド・プラットフォームも同じだといえる)のような、いくつかの点でロックインと本質的に絡み合うプラットフォーム上で実現するにしても、ある種の冷たい響きを拭い去れない。 大口の顧客が Google から去るとき、彼らは出口インタビューを行なっている。 そして、それらの顧客が、新しいプラットフォームへアプリケーションを移動するために、平均で 3~4ヶ月を要しているという事実を見つけた。「それは、複雑なシステムを構築/運用し始めた後に、あるパブリック・クラウドから他のパブリック・クラウドへと移行するのと比較して、大きく悪化することはないと、私は仮定していたのだろう 」と、Magnusson は述べている。

All biases considered, Magnusson does make some good points. I’ve argued essentially the same thing before about Amazon Web Services — it’s a matter of expectation lock-in more than technological lock-in — and it probably holds true for just about every Platform-as-a-Service and Infrastructure-as-a-Service offering around. You could technically rewrite an application for any number of similar database or storage services, for example, but it’s the parts you like about a particular provider’s service that are hard to replicate.

すべてのバイアスを考慮した上で、Magnusson は、いくつかの興味深い点を指摘している。以前に、Amazon Web Services について、本質的に同じことだと主張している。 それは、テクニカルなロックインというより、期待どおりのロックインである。そして、おそらく、ほぼすべての Platform-as-a-Service と Infrastructure-as-a-Service について言えることでもある。 たとえば、技術面で類似したデータベースやストレージ・サービスへ向けて、あらゆるアプリケーションを書き換えられるだろうが、特定のプロバイダが提供するサービスを好むなら、その複製も難しくなってしまう。

Even with an open source project like OpenStack, easy portability isn’t guaranteed. Yes, the underlying code and building blocks might be the same, but it’s the differences among OpenStack-based providers that makes a market. If everyone looked and functioned exactly the same, there would be no reason to consider anything other than Rackspace in the public cloud.

OpenStack のようなオープンソース・プロジェクトであっても、容易なポータビリティが保証されるわけではない。Yes! 基本的なコードやビルディング・ブロックは同じかもしれないが、そこには、市場を構成する OpenStack ベース・プロバイダごとの差異がある。誰もが見ても、まったく同じように機能するなら、パブリック・クラウドにおいて、Rackspace の以外の環境を検討する必要もなくなるだろう。

Beside, moving a serious application from one cloud to another will never be enjoyable no matter how architecturally similar they are. Although, management layers such as RightScale, Scalr or Enstratius (now Dell Multi-Cloud Manager) could help mitigate some of that pain, and the Cloud Foundry community is trying to make portability among Cloud Foundry instances, at least, relatively pain-free.

話はそれるが、きわめて重要なアプリケーションを、あるクラウドから他のクラウドに移行することは、どれほどアーキテクチャが似通っていても、決して楽しい作業ではない。しかし、RightScale や、ScalrEnstratius (現 Dell Multi-Cloud Manager)などのマネージメント・レイヤを用いることで、その痛みも、いくぶんは軽減されるかもしれない。また、Cloud Foundry のコミュニティでは、Cloud Foundry インスタンス間でのポータビリティを実現しようとしている。そうなれば、少なくとも、痛みから開放される。

As with so many things in life, the “which cloud to choose?” debate really boils down to picking your poison. You can probably count on loving some aspects and hating others. But you’re also probably stuck with it for a while, so choose carefully.

人生における数多くの物事と同じように、「どのクラウドを選ぶべきか?」という議論は、「毒を食らわば」という発想に至りやすい。 おそらく、いくつかの側面は好ましく、いくつかは好ましくないという、何らかの判断に依存することになるのだろう。しかし、多くの人びとは、まだ、躊躇しているのだろう。 だからこそ、慎重に選択して欲しい。

Feature image courtesy of Shutterstock user Mopic.

Related research


google-55a昨年の 9月にポストした、『 クラウド・ベンダー・ロックインと闘うための 五箇条の御誓文 』という抄訳には ーーー 数多くの人々が、そうしたように、私も App Engine の学習に、長い時間を費やしてきた。そして、App Engine を使っている多くの人々のように、それは間違いなのかと案じている。なぜなら、あなたの投資と開発の産物である、あらゆるアプリケーションが、App Engine だけで走るのものになってしまうのだから ーーー という、Google Groups フォーラムに書かれたメッセージが引用されていました。抽象度が高まれば、互換性が薄れていく。 だからといって、互換性に固執すれば、イノベーションの速度が落ちていく。とても難しい問題です。__AC Stamp 2



この一年で、OSS への支出が 56% に跳ね上がった
NIST の Cloud Architecture 序文
NIST の Cloud Architecture 概要
NIST の Cloud Architecture – プロバイダとユーザーのスコープ

Comments Off on Google が擁護する、App Engine におけるロックインの定量化とは?

Pivotal と Piston が タッグ : Cloud Foundry を OpenStack 上にアジャイル展開

Posted in .Selected, Cloud Foundry, OpenStack, PaaS, VMware by Agile Cat on August 29, 2013

Piston Provides OpenStack Infrastructure to Cloud Foundry Ecosystem
Maria Deutscher | August 25th

_ Silicon Angle

Piston Cloud has started a new chapter in its partnership with EMC and VMware spin-off Pivotal by setting up an OpenStack environment for the Cloud Foundry development community. The two companies had previously collaborated on an interface that allows the VMware-developed platform-as-a-service (PaaS) solution to run on top of OpenStack.

Piston Cloud は、EMC と VMware からスピンオフし、Cloud Foundry 開発コミュニティに OpenStack 環境を提供する、Pivotal とのパートナーシップにより新しい領域へと飛び込むことになった。この両社は、以前より、VMware が開発した PaaS ソリューションを、OpenStack 上で実行するための、インターフェイスの作成において協力関係にあった。

imagePiston hopes that the deployment will enable “large-scale continuous integration testing” of Cloud Foundry and OpenStack. The goal is to accelerate the growth of the former ecosystem by empowering developers to create and “easily accept contributions from anyone.”

Piston が望むのは、このデプロイメントにより、Cloud Foundry と OpenStack に関する、大規模スケールでのインテグレーション・テストが継続的に展開される状況である。その目標は、デベロッパー達による開発に権限を与え、誰からのコントリビューションも受け入れることで成長してきた、これまでのエコシステムをさらに加速させることである。

Piston Cloud co-founder and CTO Joshua McKenty is joining the Cloud Foundry Advisory Board. The companies will demonstrate the implementation at the upcoming Platform: The Cloud Foundry Conference in Santa Clara.

Piston Cloud の Co-Founder and CTO である Joshua McKenty は、すでに Cloud Foundry Advisory Board に参加している。そして、この両者は、Santa Clara で開催される、The Cloud Foundry Conference で、これから仕上がってくるプラットフォームの実装をデモンストレーションする。

“We believe that the Cloud Foundry platform has the potential to become a remarkable asset that a broader ecosystem can leverage to enable a new generation of applications for the cloud,” said James Watters, the head of product, marketing and ecosystem at Pivotal. “We are already seeing significant traction from joint customers who want to combine the agile Cloud Foundry platform with OpenStack. We are very grateful for Piston’s investment in both Cloud Foundry’s community infrastructure and Joshua’s participation on the advisory board. We look forward to growing and expanding an open Cloud Foundry community together.”

「 私たちは、Cloud Foundry プラットフォームに、きわめて重要な資産となる可能性が秘められていると信じる。それにより、より広範におよぶエコシステムが、クラウドのための新世代アプリケーションを実現していくだろう」と、Pivotal の Head of Product, Marketing and Ecosystem である James Watters は述べている。そして、「 私たちは、Cloud Foundry と OpenStack をアジャイルに接続したいという共通の顧客たちが、このプロジェクトを強力に推進しているのを確認している。Cloud Foundry コミュニティ・インフラとアドバイザリー・ボードへの Joshua の参加という、Piston の取り組みには、とても感謝している。私たちは、オープンな Cloud Foundry コミュニティを、一緒になって成長させることを楽しみにしている」 と続けている。

Pivotal’s decision to adopt OpenStack may undermine VMware, which rightly perceives the project as a threat to its core virtualization business. Chief executive Pat Gelsinger stated in an interview that “we don’t see it having great success coming into the enterprise” because most organizations are heavily invested in their VMware environments, but prominent customers such as PayPal are proving otherwise. The ecommerce giant started rolling out OpenStack in May.

Pivotal が OpenStack を採用するという決定は、VMware を弱体化させるだろう。つまり、そのコアである仮想化ビジネスに対して、脅威をもたらすプロジェクトとして知覚される。CEO である Pat Gelsinger は、「 私たちは、それがエンタープライズで大成功を収めているとは思っていない」と、インタビューで述べている。それは、大半の組織が VMware の環境に対して、大規模な投資を行っているからという理由によるのだろうが、PayPal などの著名な顧客は、他の方向性を明らかにしている。 この eコマース・ジャイアントは、OpenStack の展開を、この 5月に開始している。


image本文中で述べられている Piston と Pivotal の提携という話は、以前にポストした 『 Cloud Foundry と OpenStack の統合は、Piston Cloud が引き受けた! 』という抄訳に関連することだと思います。ただ、この記事で出た 2012年4月の時点での、Cloud Foundry と Pivotal の関係はというと、明らかにはされていたかったはずです。それにしても、オープンな IaaS と PaaS の代表格が、このように接続されていくことに、大きな流れが加速しているような印象を受けますね。__AC Stamp 2



Piston Cloud が提供する、OpenStack ベースのエンタープライズ・プライベートとは?
Cisco が Piston Cloud に出資 : さらなる OpenStack へのコミットか?
Cloud Foundry がフォークする? : その可能性について調べてみよう
VMware は Cloud Foundry に、独自の道を歩ませるべきだ
VMware の Cloud Foundry が、デベロッパーの 人気 No.1 になる理由は?


Google App Engine が提供する、専用 memcache とは?

Posted in .Selected, Google, PaaS by Agile Cat on July 30, 2013

New from Google App Engine just for your busy application: Dedicated memcache

By Barb Darrow – UL. 17, 2013

_ Gigaom

Summary: If your app needs fast query performance, dedicated memcache can help with that and GAE is now offering that capability in preview form.

Summary: あなたのアプリにとって、高速クエリのパフォーマンスが必要なら、専用の memcache で対応することが可能だ。 ちょうど、いま、その機能のプレビューを、GAE が提供している。

If you’re a developer needing fast query performance for your applications, Google App Engine now has a deal for you. The just-released GAE 1.8.2 version includes a preview of dedicated memcache for just that sort of use case.

あなたがデベロッパーであり、自分のアプリのために、高速クエリーのパフォーマンスを必要としているなら、いま、それに、Google App Engine が対応し始めた。リリースされたばかりの GAE 1.8.2 Version は、そのようなユースケースにぴったりの、専用 memcache のプレビューを取り込んでいるのだ。

Memcache is a distributed object store that puts frequently accessed data in memory to ensure that it’s available fast to applications that need it.

memcache とは、分散オブジェクト・ストアのことであり、頻繁にアクセスされるデータをイン・メモリに配置し、それを必要とするアプリからの高速アクセスを保証するものである。

GAE already offered shared memcache as a default but dedicated memcache assigns “a fixed cache capacity exclusively to your application,” and is billed per the GB/hour of cache size, according to Google.

すでに GAE では、共有 memcache がデフォルトとして提供されているが、この専用 memcache は「あなたのアプリに対して、固定されたキャッシュ容量を排他的」に割り当てるというものであり、また、キャッシュ・サイズに応じて GB/時間 という請求が行われると、Google は説明している。

The charge for this service will be 12 cents per GB per hour.

具体的に言うと、このサービスの料金は、1 GB/1 Hour/12 Cent となる。

Google continues to push GAE as a for-real Platform as a Service (PaaS) that is not just a sideline to the company’s bread-and-butter internet search business. In that realm it competes with Microsoft’s Windows Azure, which (I think) offers dedicated Memcache but I’m checking into that and will update this story as appropriate.

Google は、真の PaaS として、GAE をプッシュし続けている。それは、同社の基本を支える、インターネット・サーチ事業に対して、単に付け足されるものではない。その領域では、専用 Memcache を提供している(と私は思う)、Microsoft の Windows Azure と競合していくだろう。この件に関しては、チェックし続けていくし、必要に応じてアップデートしていく。

Related research


google-55a今月の初めに、『 IBM の Flash Memory アプライアンスは、12T Bytes で 3000万円だ! 』という抄訳をポストしたとき、大きな発想の転換が進んでいるのだと実感しましたが、この Google App Engine に関しても、同じように捉えてしまいます。 一方は、資産として保つケースであり、もう一方は、所有から利用へというケースであり、比較することは無理だと思いますが、双方に共通する大きなウネリを感じてしまいますね。image



Google App Engine ケース・スタディ:その API が Angry Birds を元気にする
AWS のコストを分析する:TripAdvisor と Pinterest
Facebook が発表した TAO : これで MySQL と Memcached を接続する
Facebook の超高速ストレージ : TAO の詳細を説明しよう

Comments Off on Google App Engine が提供する、専用 memcache とは?

Microsoft も Azure で MBaaS : Custom API をクリックするだけ!

Posted in BaaS, Microsoft, PaaS by Agile Cat on June 27, 2013

Windows Extends Azure MBaaS: Custom APIs Just a Mouse Click Away
Greg Bates – June 24th, 2013

_ ProgrammableWeb

Windows Azure, the mobile back end as a service platform, has added custom APIs, Git, NPM, Android Push Notifications, along with a free SQL DB. As Scott Guthrie, who builds for Microsoft, demonstrates on his “Scottgu blog,” the creation of custom APIs is extremely simple. Here’s the first shot at the start of building an API that works with a to do list.

Windows Azure は、サービス・プラットフォームとしてのモバイル・バックエンドでもあり、無償の SQL DB だけではなく、Custom API や、Git、NPM、Android Push Notifications なども付け加えてきている。Microsoft のために、きわめてシンプルな API を構築する Scott Guthrie(Corporate Vice President in the Microsoft Server and Tools Business)は、自身の Scottgu blog で、その内容を例証している。以下のスクリーン・ショットは、To Do リストと連携して機能する、API 構築への取りj掛かりを示している。

As he says, just click that little API link on the menu bar (which he highlighted in red) to get started. Similar screen shots mimc this simplicity–anyone can build this. Yet you get a lot of the standard API properties–an auth code, HTTP Post requests that you can switch to GET, and so on. Then, you are done, he says, “After saving the changes, you can now call this API from any Mobile Service client application (including Windows 8, Windows Phone, iOS, Android or HTML5 with CORS).”

彼が言うように、メニューバー上の小さな API リンク(赤の囲み線部分)をクリックするだけでタートする。同様のスクリーン・ショットもあるが、誰もが構築できるという、このシンプルさを示すものである。ただし、標準 API から、数多くのプロパティを取得できる。 つまり、HTTP Post により GETへの切り替えなどを行う、Auth Code である。それで、終わりである。「 変更を保存した後に、あらゆる Mobile Service クライアント・アプリ( Windows 8/Windows Phone/iOS/Android/CORS/HTML5 などを含む)から、この API を呼び出せるようになる」と、彼は発言している。

In three steps you have an API that functions across the mobile universe. Custom APIs can be written in Node.js, with future support for .NET coming. This extension includes the ability to handle any node package module the coder prefers, a client  SDK, Android push notifications and 20 MB of free space. Thanks to integration, scripts and permissions can be stored on Git. Perhaps most powerful of all, custom APIs don’t have to be associated with a data table.

3つのステップにより、モバイルの世界を横断する API を手にできる。一連の Custom API は、Node.js の記述できるが、近々に .NET にも対応する。この拡張機能には、各種のノード・パッケージ・モジュールを処理する能力が備わっている。つまり、コードを書く人が好む、Client SDK と、Android Push Notification と、20 MB のフリー・スペースである。この統合により、スクリプトとパーミッションを Git リポジトリに保存できた。 そして、この Custom API 全体で、最もパワフルなものは、データテーブルとの関連付けらが、まったく必要のない点になるだろう。

This illustration of how you can build custom APIs, while simple and powerful, should not obscure the range of what Azure is capable of. To cite one case study, the company has a fascinating video of a Korean online gaming company, Webzen, who turned to Azure in order to survive (and then thrive on) the intense ramp up of users playing their games (screen shot below).

ここでは、Custom API を構築する方法を例証してきたが、それはシンプルかつパワフルでありながら、Azure の能力のレンジを不明瞭にはしていないはずだ。ケース・スタディを引用するなら、Korean のオンライン・ゲーミング企業であり、素晴らしい描画機能を提供している Webzen が適切だろう。同社は、ユーザーのゲーミング・エクスペリエンスを大幅に向上させ(スクリーン・ショット)、また、競合の激しい世界で生き残るために(さらには成功するために)、Azure に依存している。

From Milliman, a company working to create a cloud-based insurance solution, to BMW Latin America developing prospects with social media, uses for Azure are diverse, to say the least. These additional tools should help.

クラウド・ベースの保険ソリューションを構築する Milliman から、ラテン・アメリカでソーシャル・メディアを用いて市場を開拓する BMW に至るまで、控えめに言っても、多様なユーザーに Azure は利用されている。 そして、これから追加されるツールが役立つはずだ。


TAG indexFacebook による Parse の買収を受けてか、このところ、Mobile BaaS を巡る動きが活発になってきています。つい先日にポストした、『 Google と Kinvey が提携 : Mobile BaaS 最前線 』という抄訳の、「大手のインフラ・プレイヤーたちが Mobile Backend Services を、PaaS 上に戦略的にオーバーレイさせようと考えていることも、より広義なメッセージである。そして、もう1つの要因は、PaaS が BaaS の機能を拡張するという話である」という、説明が気になっていました。そして、それは、Google だけのためにある言葉ではなく、Amazon/Salesforce/Microsoft のための言葉でもあるのです。この領域が、ますます面白くなってきますね。image



Google 対 Parse の戦いが始まる : Mobile BaaS 最前線
Facebook – Parse 連合 : 10万タイトルのクラウド・アプリを生み出す
Facebook が買収した、Mobile BaaS の Parse とは?
Salesforce も Rackspace も、目指すは モバイル BaaS なのだ!
Amazon AWS も、ついに モバイル BaaS に参入か?


Comments Off on Microsoft も Azure で MBaaS : Custom API をクリックするだけ!

Savvis が AppFog を買収? Cloud Foundry エコシステムへの影響が心配だ!

Posted in PaaS, VMware by Agile Cat on June 15, 2013

Breaking: Savvis to buy AppFog

Barb Darrow

_ Gigaom

Summary: With AppFog, Savvis will get a Cloud Foundry-based Platform as a Service to run atop its own VSphere or vCloud Director-based infrastructure.

Summary: AppFog を得ることになれば、Savvis の vSpher および vCloud Director 上で、Cloud Foundry ベースの PaaS が動き出すことになる。

Savvis is about to buy AppFog, a Platform-as-a-Service startup based in Portland, Ore., according to several sources. Savvis, a data center operator, was acquired itself two years ago by CenturyLink in a $3.2 billion bid to build a cloud and hosted managed services powerhouse.

いくつかの情報源によると、Portland, Ore ベースの PaaS である AppFogを、Savvis が買収しようとしているらしい。 このデータセンター・オペレーターである Savvis も、クラウドとマネード・ホスティングのサービスを構築するために、2年前に CenturyLink  により、$3.2 billion で買収されている

Details are scarce since AppFog had no comment and Savvis could not be reached for comment but sources with knowledge of the deal expect the news to be announced Monday. Founded in 2010, AppFog garnered about $10 million in venture funding from Ignition Partners, Xen founder Simon Crosby, Madrona Venture Group, First Round Capital and Founders Co-Op.

AppFog からはコメントがなく、Savvis にはコンタクトさえ取れないので、詳細な情報が不足しているが、この買収劇に精通しているニュース・ソースは、月曜日には発表されると予想しているようだ。AppFog 自身は、Ignition Partners および、Xen founder Simon Crosby、Madrona Venture Group、First Round Capital、Founders Co-Op といった、VC からの $10 million ほどの出資により、2010年に設立されている。

Given that Savvis is a big VMware vSphere and vCloud Director partner, AppFog could give it a “house brand” PaaS of its own. AppFog’s PaaS builds atop standard Cloud Foundry technology, which came out of VMware. Its pitch was that AppFog abstracted out messy details of base cloud infrastructure so developers could move their apps from Amazon to Rackspace to HP or other public clouds at will. That eliminated cloud lock-in at least at the Infrastructure-as-a-Service (IaaS) layer. In April, however, AppFog dropped support for Rackspace and seemed to be narrowing its focus.

Savvis が、VMware vSphere および vCloud Director のビッグ・パートナーであることを考えると、AppFog により自社ブランド PaaS が登場する可能性もある。AppFog の PaaS は、VMware から提供される、標準的な Cloud Foundry テクノロジーの上に構築されている。そして、その宣伝文句は、AppFog が抽象化を進めることで、基本的なクラウド・インフラにおける煩雑さがなくなるため、Amazon から Rackspace や HP などのパブリック・クラウドへと、開発者たちは自分のアプリを、思いのままに移行できるちいうものだった。それは、少なくとも、IaaS におけるクラウド・ロックインを排除しようというものだった。しかし、4月に入ると、AppFog は Rackspace のサポートを取りやめ、フォーカスする対称を絞り込んでいくように見えた。

At the time, word was that VMware’s decision to spin off Cloud Foundry to Pivotal and offer it as a commercial PaaS hurt members of the ecosystem — including ActiveState, Uhuru and AppFog — it had recruited to build PaaSes atop that technology. That led to talk of a possible fork of Cloud Foundry.

VMware の決定が、Pivotal に Cloud Foundry をスピンオフさせ、商用 PaaS がエコシステムのメンバー(ActiveState/Uhuru/AppFog を含む)を傷つけると言われていたころ、このテクノロジー上での PaaS を構築する勢力が求められていた。 そして、Cloud Foundry がフォークするかもしれないという話に結びついていった。

Given this news, it looks like AppFog technology will be more tightly wedded to Savvis/VMware infrastructure, but no one’s saying.

したがって、今回のニュースを考えると、AppFog のテクノロジーと Savvis/VMwareのインフが密着していくように見えるが、それを、誰も指摘していない。

PaaS as a category hasn’t gained a ton of traction in the enterprise — even some in the market concede that it lacks a killer app to convince CIOs to buy into the concept. Developers at companies often use these platforms hosted on outside cloud infrastructure to build and test software but when the time comes to deploy, the apps typically come in-house.

カテゴリーとしての PaaS は、エンタープライズを変化させるだけの推進力を得ていない。さらに、PaaS コンセプトの導入においては、CIO たちを説得するたけのキラー・アプリが欠落していると、いくつかの市場で確認されている。 それらの企業における大半の開発者たちは、ソフトウェアの構築/テストを進めるために、外部のクラウド・インフラ上にホストされるプラットフォームを使用する。 しかし、一般的には、デプロイを行う段階で、インハウスへと移行することになる。

Pivotal trotted out General Electric’s $105 million investment in its new venture as proof that enterprise adoption of PaaS is on the upswing. Red Hat this week made its enterprise-focused OpenShift PaaS generally available. OpenShift adoption could be a bellwether for the category.

エンタープライズでの PaaS 採用が、回復基調にあることを証明するものとして、Pivotal が引き合いに出しているのは、General Electric が $105 million を新事業に投資していることだ。 その一方で、今週の Red Hat は、エンタープライズにフォーカスする OpenShift PaaS を、一般的に提供し始めた。 このカテゴリーでリードするために、OpenShift と採用するという可能性も生じてくるだろう。

Related research


PaaS の特質は、その生産性の高さと、ロックインによる制約にあるのでしょう。 先日に、『 Google App Engine ケース・スタディ:その API が Angry Birds を元気にする 』という抄訳で、Google App Engine が好調だと伝えましたが、『 Elastic Beanstalk とは? 』で Amazon CTO の Werner Vogels が語っていた、ロックイン排除の難しさを思い出しました。その意味で、複数のプロバイダーが、Cloud Foundry を提供する形態は、ある種の理想だと思っていたのですが、なかなかうまく行かないようですね。 image



Cloud Foundry がフォークする? : その可能性について調べてみよう
VMware は Cloud Foundry に、独自の道を歩ませるべきだ
Cloud Foundry と OpenStack の統合は、Piston Cloud が引き受けた!
Cloud Foundry が .NET をサポートする!
VMware の Cloud Foundry が、デベロッパーの 人気 No.1 になる理由は?


Comments Off on Savvis が AppFog を買収? Cloud Foundry エコシステムへの影響が心配だ!

Google App Engine ケース・スタディ:その API が Angry Birds を元気にする

Posted in .Selected, Google, PaaS by Agile Cat on June 5, 2013

Google App Engine Case Studies: The API that Helps Create Groundbreaking Work

Greg Bates, April 12th, 2013

_ ProgrammableWeb

What do Angry Birds, car sharing, the game Ruzzle, and Khan Academy all have in common? They’ve boosted their operations as clients of the Google App Engine. Apps are implemented using Python, with Java as a second language, making AJAX web applications feasible.

Angry Birds と、カー・シェアリング、ゲーム・パズル、そして、Khan Academy に共通するものは、いったい何なのだろう? それらは、Google App Engine のクライアントとして、その運用をブーストしているのだ。 そして、アプリの実装は Python により行われ、第二言語として Java も提供され、AJAX Web アプリケーションを量産しているのだ。

The App Engine API claims to help their developers do groundbreaking work. As Programmableweb’s own Romin Irani shows the reason is they work at it. Google App Engine has been consistently releasing updates month after month, and he notes one particularly significant one at the  end of 2012, “release 1.7.4 is significant in the fact that several APIs that were experimental in nature till now have been upgraded to General Availability (GA) Status.” In a followup post, Irani notes that Google added cloud endpoints and Java 7 support.

この App Engine API により、素晴らしい開発効率が達成されると、Google は主張している。 ProgrammableWeb の Romin Irani が、それを仕事に使う理由を示している。 これまでの Google App Engine は、毎月ごとにアップデートをリリースしている。 「 その中でも、2012年の最後にあたる Release 1.7.4 は重要であり、それまでは実験的なものであった、​​いくつかの API が、General Availability (GA) Status にアップグレードされた 」と、Romin Irani は述べている、 そして、それに続くブログ・ポストで、Google がクラウド·エンドポイントと、Java7 のサポートを追加したと指摘している。

Google posted a series of case studies on how these companies use the App Engine. Let’s take a look at Khan Academy first.

Google は一連のケース・スタディとして、前述の企業が App Engine を用いた手法についてポストしている。まず、 Khan Academy  から見ていこう。

The Khan Academy case study has been instrumental in being able to turn out top quality learning videos for high school and college students to use–for free. Founder Salman Khan has rocketed to fame on their popularity, getting funding from Bill Gates, and according to Forbes, grabbing the attention of 10 million students. But such growth poses problems, not the least of which are back end service issues like keeping your servers running, not something you can focus on when you’re creating some of the best videos out there every day. As the nonprofit’s lead developer , Ben Kamens, put it, keeping things inhouse would have diminished the quality of what they do, he told Forbes.

Khan Academy のケーススタディ は、高校と大学の学生たちのために、無償で利用できる最高品質のラーニング・ビデオを作成することに注力している。  Forbes によると、Founder である Salman Khan は、Bill Gates から資金を得たことで知名度を急上昇させ、その結果として 10万人の学生に注目されるようになった。しかし、このような成長がもたらす問題として、サーバーを走らせてバックエンド・サービスを供給することができなくなり、日課であるビデオ作成を行うべきときに、なんらかの別のことに時間と神経を取られてしまう状況がある。 無給のリード開発者である Ben Kamens は、彼らの望みをインハウス・システムで実現しようとしても、その品質を劣化させてしまうと、Fobes に語っている。

“With Google App Engine, we don’t need a system administrator or anyone dedicated to deploying our app, so 99 percent of our time is spent working on our application…A lot of what the Khan Academy is about is collecting data on student behavior so we can teach them better,” Kamens says. “Did they use a hint? Have they watched the video before? That data is being stored on Google App Engine so we can figure out what the most effective videos are, or where students struggle the most.”

「 Google App Engine を使用すると、アプリをディプロイするためのシステム管理者などが不要になり、私たちの時間の 99% と、アプリケーション開発に費やすことができる・・・  Khan Academy は、学生の行動に関する、大量のデータを収集しているからこそ、適切な学習を推進できる。彼らはヒントを活用しているか? 以前にビデオを見ているか? Google App Engine 上にデータがストアされていれば、最適なビデオや、学生が苦労しているところを把握できる」と、Kamens は発言している。

The Khan Academy provides individual profiles to students so they can analyze their learning progress, which means the organization needs systems running in the background to collect and track of all this data. Because Google App Engine takes care of server support, the Khan Academy’s five developers can spend almost all of their time improving site functionality.

Khan Academy は、それぞれの学生にプロファイルを提供することで、彼らが学習の進捗状況を分析できるようにしている。 そのためには、すべてのデータを収集し、トラッキングするための、バックグラウンドで動作するシステムが必要となる。その点、Google App Engine は、サーバーのサポートを自動化してくれるので、Khan Academy の 5人の開発者は、その時間の大半を、サイトの機能改善に費やすことができる。

In the friendliest form of gotcha journalism I’ve seen in a while, the Forbes article quotes him responding, again, to the suggestion that he should have been for-profit.

しばらくの間で見てきた中で、最もフレンドリーなジャーナリズムは Fobes である。 その記事では、彼のコメントを引用しながら、もっと利益を追求すべきだと、繰り返して示唆しているのだ。

Khan is nonplussed. “Being a billionaire is sort of passé,” he shrugs. “It’s ironic. When I used to try and describe what the Khan Academy was, I would tell people that if I were a for-profit, I would be on the cover of Forbes.”

Khan は当惑しながら、「 億万長者になることは、時代遅れのようなものだ」と肩をすくめる。 そして、「 それは皮肉なことだ。 Khan Academy の意味について、これまでに私が説明してきたとき、もし、利益を追求したいのなら Fobes の表紙に出ると、人々に言ってきたのだから」と続けている。

All of the case studies are worth the read, but let’s just look at one more here, Rovio and Angry Birds. Surprisingly like Khan Academy, Rovio faces a herculean task of scaling up so that its infrastructure supports demand. The Google App Engine became imperative as soon as Rovio expanded from mobile to web browsers. As Stefan Hauk, the lead server developer for Rovio’s web games put it, these days things start big,

すべてのケース・スタディには、それを読むだけの価値があると思うが、ここでは Rovio と Angry Birds について、取り上げてみたい。驚くべきことに、Rovio も Khan Academy と同様に、需要に対応するインフラをサポートするために、スケールアップという困難なタスクに直面している。 モバイルから Web にいたるまでのブラウザに、Rovio が対応し始めるとすぐに、Google App Engine が不可欠になった。Rovio におけるサーバー開発者として、Webゲームをリードする Stefan Hauk は、そのときから、私たちは大きな存在になったと表現する。

“Our web games tend to be popular immediately, so we don’t have the option of scaling them over time. Google App Engine makes the process painless, since it can instantly launch as many servers as we need…There have been times when we’ve been asked to build a customized game in a week or two. We know that App Engine will enable us to do this and that it will scale for us no matter how many users we get.”

「 私たちの Web ゲームは、すぐに人気者になるという傾向にあった。 したがって、時間をかけながらスケールしていくという、選択肢は存在しなかった。Google App Engine であれば、必要とするだけのサーバーを、瞬時に立ち上げられるため、そのプロセスにおける痛みを取り除くことが可能であった・・・ カスタマイズされたゲームを、1~2 週間で構築しなければならないときもあった。しかし、App Engine であれば、それに対応できることが分かっていたし、どれだけのユーザーが押し寄せてきても、スケールしていくことが可能だと、私たちは認識していた」

Features of Google App Engine that are popular with Rovio include the perfomance boosting Memcache API, High-Replication Datastore, task queues, and authentication through the users API. But the best feature? That’s probably the end of all that after-hours on call work dealing with server issues. That’s disappeared, Hauk says, because “Google App Engine just works.”

Rovio が注目する Google App Engine の特徴には、Memcache API および、High-Replication Datastore、タスク・キュー、ユーザー API を介した認証という、パフォーマンスを高める機能が含まれる。しかし、一番の特徴は何なのだろう? それは、おそらく、サーバーを立ち上げた後に行うべき確認の作業が、完全に姿を消したということだ。 その、すべてを、Google App Engine が肩代わりしてくれると、Hauk は発言している。


TAG indexちょっと、ポストの順序が前後してしまいましたが、先日の『 なんと! 2013 Q1 のクラウド売上は $2B : 順位は AM>SF>MS>IBM>GO 』 よりは、こちらの方を先に訳していたのです。 そのときは、へぇ~ っと思っていましたが、なかなか、どうして、しっかりとシェアも確保しているようで、予想以上の大健闘というのが、正直なところの感想です。 いろいろな説が飛び交っていますが、PaaS が、着実にシェアを伸ばしているのでしょうね。面白くなりそうです! image



アプリケーション・ベンダーのシフトにより、PaaS 市場は成長していく
PaaS をリードする : Top-10 プロバイダー とは?
単純/安価/高速 : .NET から Node + Heroku に乗り換えた Playtomic
f8 終了後の 24時間で、34000本の Facebook アプリが Heroku 上で量産
NIST による SaaS/PaaS/IaaS の最新定義 – Jan 2011
SaaS/PaaS/IaaS とセキュリティの責任範囲 – NIST

Comments Off on Google App Engine ケース・スタディ:その API が Angry Birds を元気にする

%d bloggers like this: