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 の調査: 利便性においてクラウドがオープンソースを上回る?

Cloud の調査: 80% の プライベート PaaS が、失敗にいたるという理由を説明しよう

Posted in .Selected, IoT, On Monday, PaaS by agilecat.cloud on April 18, 2016
Cloud Computing: 80 Percent of Private-Cloud PaaS Initiatives will Fail
Dick Weisinger – April 12th, 2016
http://formtek.com/blog/cloud-computing-80-percent-of-private-cloud-paas-initiatives-will-fail/
_ formtek
Many enterprises that value security have taken the path of adopting private-cloud PaaS frameworks.  But a recent report by Gartner expects that this approach may lead to trouble.  In fact, the report estimates that as many as 80 percent of private-cloud PaaS initiatives will end in failure.
 
セキュリティを重視する数多くの企業が、プライベート・クラウド上の PaaS フレームワークを採用するという道筋を歩んでいる。しかし、Gartner の最新レポートにおいては、この種のアプローチがトラブルを抱え込むという可能性が指摘されている。 実際のところ、このレポートは、プライベート・クラウド PaaS における、80% に相当する取り組みが、失敗に終わるだろうと推定している。
 
Chagall_18Yefim V. Natis, vice president and Gartner Fellow, said that “in the next three years, many self-managed private PaaS initiatives will fail to meet the IT organisation leadership’s expectations of cloud characteristics. The tension between the forces in favour of private PaaS and those demanding the full public cloud experience will intensify as self-managed private cloud disappoints.
 
Gartner の VP である Yefim V. Natis は、「これからの 3年間で、数多くのセルフ・マネージド・プライベート PaaS が、IT 部門が期待するクラウドの特性と矛盾を起こし、失敗だったと評価されていくだろう。つまり、フル・パブリック・クラウドのエクスペリエンスを要求する勢力と、プライベート PaaS を支持する勢力との緊張関係が、セルフ・マネージド・プライベート・クラウドへの失望が顕在化するにつれて、高まっていくことになる」と述べている。
 
Success with a private cloud (including PaaS) requires a recognition of the essential cultural and organizational changes to IT organizations, as well as technology changes.  Lacking this understanding leads many organizations to stop their PaaS investment at the point of technology deployment — leading to disappointing results down the road.”
 
そして、彼は、「PaaS を含むプライベート・クラウドを成功へと導くためには、テクノロジーに関する変化だけではなく、IT 企業の文化と組織に対しても、本質からの変化が求められていく。そこへの理解が欠落していると、テクノロジーの導入という視点から、プライベート PaaS への投資を停止されることになる。 つまり、数多くの企業がにおいて、不本意な結論が導かれることになる」とも発言している。
 
ーーーーー
On Mondayちょっと難解なところがありますが、文中に示される Gartner のレポートを参照すると、IoT が浸透するにつれて変化していく PaaS という側面を捉えているようです。まず、従来からのマスター・データを用いるアーキテクチャから、イベント・ドリブンな IoT データ・アーキテクチャへと、移行していく必要があります。 もちろん、さまざまなプロセスを、センターからエッジへと移行させる必要もあります。クラウドの成長があればこそ、IoT が成り立ってくのでしょうが、そこで要求されるクラウドは IaaS ではなく PaaS であり、新たなセキュリティ・ポリシーなども取り込んでいく必要があるのでしょう。そこまで含めて、プライベート PaaS で対応できるのかどうか、その辺りが、これからの論点に加わっていくのでしょうね。 _AC Stamp
ーーーーー
<関連>
Security の調査: FBI と Apple の争いに、根本からの解決はあり得るのか?
Security の調査: クラウドとデータの機密性:これからは、暗号化がトレンドになるのか?
IoT の調査: これからの2年間で IoT に不可欠な、10種類テクノロジーを列挙してみた
Security の調査: 2016年は最悪の年になるという、いくつかの予測を整理する
Cloud の調査:ユーザー企業が感じる、クラウドのメリットは何処に? すでにコストは番外に?
 

Comments Off on Cloud の調査: 80% の プライベート PaaS が、失敗にいたるという理由を説明しよう

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
http://wp.me/pwo1E-71R

By Dick Weisinger – December 11th, 2013
http://formtek.com/blog/platform-as-a-service-paas-one-way-to-cut-infrastructure-costs-and-speed-application-development/

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

 

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
http://wp.me/pwo1E-6Cw
By
Derrick Harris – JUL. 9, 2013
http://gigaom.com/2013/07/09/google-defends-quantifies-app-engine-lock-in-concerns/

_ 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
http://wp.me/pwo1E-6xZ
Maria Deutscher | August 25th
http://siliconangle.com/blog/2013/08/25/piston-provides-openstack-infrastructure-to-cloud-foundry-ecosystem/

_ 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
http://wp.me/pwo1E-6qr

By Barb Darrow – UL. 17, 2013
http://gigaom.com/2013/07/17/new-from-google-app-engine-just-for-your-busy-application-dedicated-memcache/

_ 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
http://wp.me/pwo1E-6il
Greg Bates – June 24th, 2013
http://blog.programmableweb.com/2013/06/24/windows-extends-azure-mbaas-custom-apis-just-a-mouse-click-away/

_ 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 をクリックするだけ!

%d bloggers like this: