Agile Cat — in the cloud

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 におけるロックインの定量化とは?

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

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

Breaking: Savvis to buy AppFog
http://wp.me/pwo1E-6fy

By
Barb Darrow
http://gigaom.com/2013/06/13/breaking-savvis-to-buy-appfog/

_ 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 エコシステムへの影響が心配だ!

エンタープライズに必要なモバイル・セキュリティ : 6つの階層って知ってました?

Posted in .Selected, BaaS, Mobile, Security, Strategy by Agile Cat on December 12, 2012

The 6 Layers of Mobile Enterprise Security
http://wp.me/pwo1E-5lA

Posted by
Stephen Feloney, Nov 07, 2012
http://thinkmobile.appcelerator.com/blog/bid/240287/The-6-Layers-of-Mobile-Enterprise-Security

_ Appcelerator

Enterprises are starting to take mobile security seriously. That’s a pretty obvious statement to make, but is it really true? I’m not saying that security isn’t a concern, but are enterprises really doing enough to truly secure their mobile applications and data?

各種のエンタープライズが、モバイルにおけるセキュリティというテーマについて、真剣に受けとめ始めている。 それは、明らかに実施すべき事柄であるが、実際にはどうなっているのだろう? なにも私は、セキュリティに関心がないと、言っているわけではない。しかし、それらのエンタープライズは、自身のモバイル環境におけるアプリケーションとデータのセキュリティを、充分に達成できるのだろうか?

Just recently, a report was published by researchers from Leibniz University of Hannover and Philipps University of Marburg, that showed how user credentials could be captured by ‘Man-in-the-Middle-Attacks‘ from mobile services run by American Express, Paypal, Twitter, Google, Microsoft, & WordPress due to their implementations of SSL & TLS. Also according to the Ponemon Institute, 6 out of every 10 cyber-security breaches occur as a result of a laptop or mobile device.

つい先日のことだが、Hannover の Leibniz University および、Marburg の Philipps University の研究者たちから、あるレポートが発行された。そして、American Express/Paypal/Twitter/Google/Microsoft/WordPress などの SSL & TLS 実装方式により、そこで動かすモバイル・デバイスからの Man-in-the-Middle-Attack により、ユーザーの資格証明が見えてしまうとしている。 さらに、Ponemon Institute は、サイバー・セキュリティー侵害における 10回に 6回が、ラップトップあるいはモバイル・デバイスから引き起こされるとしている。

So while enterprises speak loudly about security, it’s not clear that adequate steps are being taken to properly secure the mobile devices and applications. Security for mobile is not all together different from security in any other IT discipline – An holistic approach is the only way the issue can truly and effectively be handled. While many enterprises will tell you about the MAM or VPN products they are using, few of them actually have complete end-to-end coverage from a security perspective, whether it’s for a consumer app or an employee app.

したがって、エンタープライズがセキュリティの重要性について声を大にしても、モバイルにおけるデバイスとアプリケーションをセキュアにするための、適切なステップが取られているのか、その辺りは明確にならない。 モバイルのためのセキュリティは、他の IT 分野から集められてきたものとは、まったく異なる。 つまり、全体論的なアプローチだけが、この問題を本質的かつ効果的に処理していく、唯一の方式となる。 数多くのエンタープライズが、MAM あるいは VPN のプロダクトを使っていると言うだろう。しかし、そのアプリがコンシューマ用であってもエンタープライズ用であっても、セキュリティの視点から見ると、そのうちの僅かしか 、有効な End-to-End の範囲を持っていないのが実情である。

Data in transit between the mobile device and the backend as well as the secure distribution of the apps are really only two pieces of the of an overall mobile security solution that enterprises need to be concerned with. In all, there are 6 different layers of security that need to be addressed:

モバイル・デバイスとバックエンドの間で転送中のデータに加えて、アプリケーションのセキュアな配信という、2つの要素だけが、エンタープライズにとって必要になる、全体的なモバイル・セキュリティのソリューションとなる。 そして、全体的な視点から取り組むべき、6種類のセキュリティ層が存在する:

  • Authentication & Authorization
  • Data at Rest (on device): Data stored on the mobile device
  • Data in Transit: Data being transferred to or from the mobile device
  • Data at Rest (in the cloud/data center): Data stored in the cloud/data center
  • Application Code Security: Obfuscating and signing application code
  • Application Distribution: How to properly distribute the application to users

___space

  • Authentication & Authorization
  • Data at Rest : デバイス上にストアされたデータ
  • Data in Transit : モバイルデ・バイスとの間で、転送途中のデータ
  • Data at Rest : クラウドもしくはデータセンターにストアされたデータ
  • Application Code Security: 判読不能なかたちで書き込まれたアプリケーション・コード
  • Application Distribution: アプリケーションをユーザーに対して、適切に配信するための仕組み

In some cases the problem stems from the fact that the mobile applications are invariably delivered by the different Lines of Business (LOB), with little to any centralized oversight or governance regarding security. The enterprise may have security mandates in place, but because the apps are developed and deployed outside the purview of IT, governance and enforcement is sporadic at best. In other cases, IT doesn’t have the information required to identify an adequate risk profile, so a heavy-handed approach is taken, which unfortunately impacts the usability of the app, leading to its failure.

いくつかのケースにおいて、各種の Lines of Business (LOB) から常に供給されるモバイル・アプリケーションという現実から、ここでの問題点が生じてくる。ただし、それらの LOB は、セキュリティに関する監視あるいは統治を、いくつかの点でセンタライズしていくものとなる。 そこでは、エンタープライズにセキュリティの代表権があるように思われるが、アプリケーションの開発とディプロイが IT 部門の外側で行われるため、その統治と強制力は、上手くいっても散発的なものとなる。 別のケースでは、適切なリスク・プロファイルの識別に必要な情報を、IT 部門が持たないことも考えられる。 したがって、残念なことに、アプリの有用性に悪影響をおよぼし劣化へと導く、不適切なアプローチが取られてしまう。

There’s a similar analogy to the early days of the web over 15 years ago in response to the inconsistencies of application delivery across different LOBs. To address this, organizations began to establish a centralized group to define guidelines around core functions and disciplines such as backend access, security, and testing.

それぞれの LOB をまたいだアプリケーション配信の矛盾への対応として、15年以上も昔の Web の黎明期に、似たような話がある。 それに取り組んでいた個々の組織は、バックエンドにおけるアクセス/セキュリティ/テストといった、コアとなる機能と規律に関するガイドラインを定義するための、センタライズされたグループを設立し始めた。

To address today’s mobile app issues, including security challenges, some of the more progressive enterprises are starting to establish a Mobile Center of Excellence (MCoE). This group is chartered with many roles, one of which is defining the security policies for the mobile apps and devices as well as its enforcement. The MCoE focuses on all the layers of mobile security, as well as industry-specific regulation and market trends, and serves as the corporate voice to all the LOBs.

そして、いま、セキュリティを含むモバイルの問題に取り組むために、いくつかの進歩的なエンタープライズが、Mobile Center of Excellence(MCoE)を設立し始めている。 そのグループは、数々の役割を与えられるが、その 1つには、モバイル・アプリとモバイル・デバイスのためのセキュリティ・ポリシー定義があり、その実施も含まれる。MCoE は、モバイル・セキュリティにおける全レイヤにフォーカスする。そして、さらに、業界における規定やマーケットの傾向も注視し、企業の声を LOB へ伝えるための役割も担う。

To learn more about these 6 layers of mobile security as well as why native apps are inherently more secure than HTML5 apps, click here to read the whitepaper. 

これらの、モバイル・セキュリティのための 6つのレイヤおよび、ネイティブ・アプリが HTML5 アプリより本質的にセキュアな理由については、この Whitepaper を参照されたい

 

 

ーーーーー

imageimageAppcelerator のポジションは Mobile SDK となり、代表的なプロダクトとしては Titanium SDK/Studio が有名です。 また、いつもの Kinvey:Subway Map で調べると、CoCoafish を買収することで、その勢力を BaaS にも広げている様子がわかります。その他にも、PayPal や OpenShift とも関係を持ち、また、Parse ともつながっているようです。 image

ーーーーー

<関連>

BaaS で自由になる? それとも便利になる? そして DoCoMo の i-Concier は?
AWS イベントでの Parse が スゴそう – BaaS の勢いが加速する?
Ray Ozzie の Talko も、$4M の資金で BaaS に参戦!
Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ
Bloomberg 金融アップストアがオープン : Apple みたいに 30% をイタダキ!

 

Comments Off on エンタープライズに必要なモバイル・セキュリティ : 6つの階層って知ってました?

%d bloggers like this: