Agile Cat — in the cloud

クラウド・ベンダー・ロックインと闘うための 五箇条の御誓文

Posted in .Chronicle, .Selected, Businesses, PaaS, Research by Agile Cat on October 18, 2011

5 ways to protect against vendor lock-in in the cloud
By Alex Salkever Sep. 24, 2011
http://gigaom.com/2011/09/24/5-ways-to-protect-against-vendor-lock-in-in-the-cloud/

_ Gigaom

Two weeks ago, Google announced a significant price increase for use of its App Engine Platform-as-a-Service. The increase itself was not a huge surprise. Google had been making noises that something like this was in the offing for a number of months. But the size of the increase shocked the Web development and cloud applications community. For most users, the cost of using the Google runtime environment effectively increased by 100% or more.

2週間ほど前のことだが(9月上旬)、Google は App Engine PaaS の使用料を大幅に値上げすると発表した。 この値上げ自体は、大きな驚きではなかった。 なぜなら Google は、これまでの数カ月間において、このような出来事が生じるというノイズを掻き立てていたからだ。しかし、その値上げ幅の大きさは、Web 開発およびクラウド・アプリケーションのコミュニティに衝撃を与えた。 大半のユーザーにとって、Google ランタイム環境を効果的に利用するためのコストはが、100% 以上も増大したのだ。

A huge online backlash ensued. For its part, Google put off the increase by a month and moderated some of the increases. But the whole incident brought many nagging doubts about the cloud to the surface. Said one poster on one of the many threads that lit up the Google Groups forums after the increase:

そして、オンライン上では、強い反発が生じた。 そのため、Google は、値上げ開始を 1カ月延期し、また、いくつかの料金体系を修正した。 しかし、この出来事により、クラウド全般に対する疑念が、表面化することにもなった。 以下の文言は、この値上げに関する Google Groups フォーラムに火をつけた、数多くのスレッドの 1つに書かれた、いわばポスターである

I like so many of us have spent a lot of time learning app engine – i have been worried like so many that using app engine is a mistake because any app you invest/build can only be run on… app engine.

数多くの人々が、そうしたように、私も App Engine の学習に、長い時間を費やしてきた。そして、App Engine を使っている多くの人々のように、それは間違いなのかと案じている。なぜなら、あなたの投資と開発の産物である、あらゆるアプリケーションが、App Engine だけで走るのものになってしまうのだから。

imageBecause the Google PaaS requires that developers customize code specifically to run in that environment and nowhere else, rewriting that code takes a lot of time, effort and money. With salaries for programmers hitting record highs in the Bay Area and recent CS graduates pulling in $120,000 or more to code, any big move that forced major code rewrites would ultimately wallop the bottom line. Ironically, these increases disproportionately affected numerous hobbyists and small developers running interesting applications – the creators of the next proverbial Google. Certainly corporate IT departments took notice, as well.

この Google の PaaS は、他のどこでもなく、その環境で動作するコードにカスタマイズするよう、デベロッパーに対して要求する。 したがって、そのコードを書き直すには、膨大な時間と、作業と、費用を必要とする。  Bay Area におけるプログラマーの給料が最高記録に達し、また、最近の CS(Conputer Science)卒業生の初任給が120,000ドル以上になった。 そのような状況では、主要なコードのリライトを強制する、いかなる移行作業であっても、最終的には損益構造を破壊するだろう。 そして、皮肉なことに、こうした料金の引き上げは、興味深いアプリケーションを走らせる、多数のホビーストや少数のデベロッパーにも、不均衡な影響をおよぼすことになる。つまり、言い古された言葉であるが、次の Google を作っていく彼らから、機会を奪い取ってしまうことになり兼ねない。 さらに、コーポレート IT 部門も、収益性への影響を気にかけている。

Vendor lock-in will make you vulnerable

Unquestionably, Google App Engine price increase revealed a key fundamental weakness of many cloud businesses.  Namely, vendor lock-in does exist in the cloud. This seems odd because one of the benefits of the cloud specifically was to obviate the advantage of vendor lock-in and make applications more portable. In that worldview, no cloud rules them all (not even Amazon) and companies operating applications in the cloud can quickly and easily port their applications to other PaaS offerings or to other IaaS providers.

間違いなく、 Google App Engine の値上げが、多様なクラウド・ビジネスのカギとなる、基本的な弱点を露呈させた。  すなわち、このクラウドには、ベンダー・ロックインが存在するのである。 クラウドのメリットとして、とりわけ、ベンダー・ロックインという難敵を取り除き、さらにポータブルなアプリケーションを実現できるはずだから、いまの状況は奇妙に思える。 その世界観において、いかなるユーザーであっても、クラウド(Amazon さえ)に制約される必要はない。そして、クラウドを運用する企業のアプリケーションは、他の PaaS や IaaS を提供するプロバイダのサービス上に、迅速かつ容易にポートできるはずだ。

With vendor lock-in comes vulnerability to price increases. In all likelihood, Google – a data-driven business if there ever was one – was rebalancing pricing to reflect its own need for profitability. But for developers and app makers, this drastic shift effectively turned their decision to go with Google App Engine into what may have been a “bet-the-company” decision without ever realizing it.  For the PaaS industry in general, the move raises significant uncertainty. If Google has to raise its prices this much, who’s next?

ベンダー・ロックインと伴に、料金の引き上げへの追随という弱点が生じてしまう。 おそらく、 Google は( データ駆動型ビジネスを実施する場合には必ず)、収益に関する自社の必要性を反映するために、価格体系について何度もバランスを撮り直してきているた。 しかし、デベロッパーとアプリケーション・メーカーにとって、今回の極端なシフトは、これまでの Google App Engine に対するコミットを、Google という企業に対する大きな賭けに、そのことを知らしめることなく、置き換えてしまう。  一般的に見て、PaaS 業界にとって、この動きにより、大きな不確実性が生じている。 それほどまでに、Google が価格を引き上げる必要があるなら、次は誰なのだろうか?

Start thinking defensively before you choose a platform

In a similar vein, developers who put their applications up on Heroku may not have realized that their business fate depended on the fidelity of the Amazon EC2 cloud. If a company had been planning a big sales event or promotion during the extended EC2 outage, those three days of hard downtime may have had an outsized impact.

それに類似する話として、アプリケーションを Heroku 上に展開しているデベロッパーが、自身のビジネスにおける命運を、Amazon EC2 クラウドに委ねていると認識していなかった、ひとつの事実が挙げられるだろう。 ある会社が、拡大してしまった EC2 ダウタイムの期間において、大規模なセールス・イベントやプロモーションを画していたなら、その 3日間が計り知れない損害をもたらしただろう。

So clearly the rules of the game have changed for anyone who wants to put an app in the cloud and run a real business. Defensive thinking is in order. Here are five key rules to avoid getting gouged by Google App Engine or eviscerated by an EC2 outage:

したがって、クラウドにアプリケーションを展開し、重要なビジネスを運用する人々に対して、すでに変更されているルールがあるなら、それを明らかにすべきである。 防御的な発想について、順番に整理していく。 Google App Engine からの強要や、EC2 のダウンタイムを回避するための、5 つの重要なルールがある:

  1. Avoid vendor lock-in at all costs. This is now a no-brainer. Make sure that your app can be easily ported to other clouds if you need to move due to service outages. If you must write apps that require serious customization, make sure you have a back-up plan and, if you can swing the cost, an alternative cloud running your code as a backup.
    いかなる代償を払っても、ベンダー・ロックインを回避せよ。これは、簡単にできることである。サービス停止において、他のクラウドへの移行が必要であるなら、あなたのアプリケーションを容易にポートできることを、確認すべきである。 大規模なカスタマイズを必要とする、アプリケーションを書く必要があるなら、バックアップ・プランの存在を確認すべきである。そして、コストについて揺さぶりを掛けられるなら、あなたのコードをバックアップとして、代替えのクラウドで走らせてみよう。
  2. Know thy PaaS. Spreading the risk among multiple PaaS providers makes a lot of sense – unless they are all totally dependent on one big cloud to deliver your applications and cloud business. Explore installable PaaS options that you yourself control. So ask pointed questions about where your PaaS is running and how they are managing their risks of failure of a big cloud.
    汝の PaaS を理解せよ。マルチ PaaS プロバイダをまたぐ形で、リスクを分散することに意味がある。ただし、あなたのアプリケーションとクラウド・ビジネスを供給するために、単一のビッグ・クラウドに依存していないことが前提となる。インストールできる PaaS の選択肢を探究し、それにより、自身でコントロールすべきである。 したがって、あなたの PaaS が動作している状況と環境について、また、ビッグ・クラウド・プロバイダーにおける、障害のリスク管理について、鋭く質問すべきである。
  3. Ask hard questions about redundancy and system architecture. Deep under the covers of most clouds are core system architectures that may replicate single-points-of-failure. That’s because, at its core, the cloud infrastructure ecosystem is not a terribly diverse environment. Only a few hardware and software companies rule the roost. Similarly, ask your cloud provider to completely open their architecture and software kimono and let you examine everything. If they won’t, then you caveat emptor. If they will, you can judge their redundancy steps for yourself. So ask for specific architecture diagrams if you are going to be dependent on a cloud environment and its reliability. And get a network engineer or system architect buddy to review the diagrams. Think this is overkill? Ask FourSquare, Reddit and the other huge sites that have corporate backing or VC money and went down hard in the EC2 outages.
    冗長性とシステムのアーキテクチャについて、しつこく質問せよ。シングル・フェイル・ポイントを複製するコア・システム・アーキテクチャが、そのクラウドの奥深くに、潜んでいる可能性がある。 なぜなら、そのコアにおいては、クラウド・インフラストラクチャ・エコシスエムが多様性を持たないからである。 ごく少数の、ハードウェアとソフトウェアの企業だけが、その根底を支配する。 ここでも同様に、クラウド・プロバイダに対して、そのアーキテクチャとソフトウェアを、完全にオープンにするよう求めるべきだ。 それにより、あなたは全てをを調べるだろう。 プロバイダが対応しない場合には、買い手の危険負担となる。 また、対応する場合には、その冗長性のステップを、あなたのケースにおいて判断することが可能になる。 したがって、クラウド環境と、その信頼性に依存している場合には、そのアーキテクチャ・ダイアグラムを求めるべきだ。 そして、仲間であるネットワーク・エンジニアとシステム・アーキテクトも、そのダイアグラムをレビューさせる。それは、過剰だと思うだろうか? 支援企業や VC からの資金を有しながら、EC2 のサービス停止でダウンした、FourSquare や Reddit などの、大手サイトに尋ねればよい。
  4. Pick code that’s easier and faster to modify. Not all runtime environments and frameworks are alike. Certain flavors and types of frameworks and Web scripting environments are more difficult to change in a pinch due to the core architecture of the way the scripting language works. Until recently, PHP was far harder to clean up than RoR, and Python, pre-Django, was more unwieldy.
    迅速かつ容易に修正できるコードを選べ。 すべてのランタイム環境とフレームワークが、一致することは稀である。フレームワークにおける特定のフレーバーやタイプおよび、Web スクリプティングの環境は、スクリプト言語を機能させるコア・アーキテクチャの方式により、その変更が困難になっている。つい 最近まで、PHP のクリーンアップは、RoR よりも遥かに難しかった。そして Physon や pre-Django は、さらに取り扱いにくかった。
  5. The most popular code may not be the cheapest code. Think about the availability of coders. Many applications companies have a horror story about how their iOS app needed modifications and they either had to pay a high-end dev shop $200 per hour or had to wait for weeks to make the mods. At the same time, some runtime environments like Node.js can be built with Javascript code throughout the application stack. (We’re biased as we are strong backers of Node.js). That means you eliminate the need for differentiated front- and back-end coding teams, in a best case scenario. When building your cloud app, think hard about the code selection before you start filling up your GitHub repository.
    人気のコードが、安価なコードとは限らない。 プログラマの対応力について、考慮すべきである。 iOS アプリケーションの修正に、何が必要だったのかという点において、数多くのアプリケーション会社が、恐怖の物語を有している。 彼らは最先端を得るために、最高級の Dev Shop に $200/1時間を支払うか、何週間も時間を費やす必要があった。 その一方で、アプリケーション・スタック全体をまたぐ Javascript コードにより、Node.js などのランタイム環境が構築できる。 (私たちは Node.js を支援するため、バイアスがかかっている)つまり、ベストケースのシナリオでは、フロント・エンドとバック・エンドに、コーディング・チームを切り分ける必要性を排除できる。 クラウド・アプリケーションを構築するなら、自身の GitHub リポジトリを満たし始める前に、コードの選択について、慎重に検討すべきである。

By no means are these five steps comprehensive. And for the most part they are obvious. But in the cloud things move pretty quickly and sometimes slowing down to think about what your cloud application will be in six, 12 or 24 months is hard to do. So put on your crash helmet, watch your wallet, and be careful out there, people.

上記の 5ステップは、決して包括的なものではない。しかし、その大部分は、明白な事柄である。 だたし、クラウドでは、物事が急激に変化する。 そして、あなたのクラウド・アプリケーションについて、6ヶ月/12ヶ月/24ヶ月の間で、考えるスピードを緩められるかといえば、それは、かなり難しいことだ。したがって、人々は、叩かれても大丈夫なヘルメットをかぶり、財布のひもを引き締め、注意深く行動する必要がある。

Alex Salkever is Director of Product Marketing at Joyent Cloud (@Joyent). He was formerly a technology editor at BusinessWeek.com.

Related research and analysis from GigaOM Pro:

ーーーーー

research辞書を引いたところ、[ at all costs ]とは [ いかなる代価(代償・犠牲)を払っても ]という意味なんだそうです。この 慣用句は、項目 1のタイトルで使われているのですが、この項目を含めた、1~5 で必要とされるコストを積み上げて、クラウドの総額に加えるべきだと、言っているように聞こえます。 それにしても、誰が書いているのかと思えば、Joyent の人だったのですね。 以下の関連リンクも、ぜひ ご覧ください。 ーーー __AC Stamp 2

ーーーーー

<関連>

未来派 クラウド OS を、かたちにする Joyent とは?
クラウドに潜む、見えないコストについて言及しておこう
この一年で、OSS への支出が 56% に跳ね上がった
NIST の Cloud Architecture 序文
NIST の Cloud Architecture 概要
NIST の Cloud Architecture – プロバイダとユーザーのスコープ

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: