Agile Cat — in the cloud

Google Cloud CDN というサービスが始まる: Google は Akamai とも競合していくのか?

Posted in .Selected, Amazon, Google, Microsoft, Network by agilecat.cloud on December 16, 2015
Google has quietly launched an Akamai competitor
JORDAN NOVET – Dec 9, 2015
http://venturebeat.com/2015/12/09/google-cloud-cdn/
 
_ VB
 
Google has quietly started offering Google Cloud CDN service, a new content-delivery network (CDN) that should appeal to independent developers who want their applications to load quickly.
 
Google Cloud CDN というサービス、静かに立ち上げられている。この、新しい CDN (content-delivery network) は、自身のアプリケーションを迅速に配信したい、独立系のデベロッパーにアピールするものになるはずだ。
 
GoogleFlickr
brionv
 
For its “alpha” release, Google is now accepting applications from people who want to try the new service, which is limited in geographical availability. More locations will be added when the service becomes generally available.
 
この新しいサービスにおいて、Google はアルファ・リリースを提供することで、試してみたいという人々から申請を受け付けているが、現時点では地理的な制約があるようだ。ただし、このサービスが一般に公開されるときには、より多くのロケーションが追加されることになる。
 
“Google Cloud CDN (Content Delivery Network) uses Google’s globally distributed edge caches to cache HTTP(S) Load Balanced content close to your users,” the product description states. “Caching content at the edges of Google’s network provides faster delivery of content to your users while reducing the load on your servers.”
 
Google のプロダクト説明によると、「 HTTP (S) Load Balanced コンテントを、あなたのユーザーの近くにキャッシュするために、グローバルに分散された Google Cloud CDN エッジを活用するものだ。Google のネットワーク・エッジに、対象となるコンテントをキャッシュすることで、それぞれのユーザーにに対して高速でコンテントを配信できるようになる。 また、それと平行して、サーバーに対する負荷も軽減される」となる。
 
This is yet another piece of the puzzle that will allow the Google Cloud Platform to compete with other major cloud providers, specifically market leader Amazon Web Services, which offers the CloudFront CDN.
 
この試みは、Google Cloud Platform が、主要なクラウド・プロバイダーと競合していく上で必要な、パズルのピースでもある。とりわけ、クラウド・リーダーとして CloudFront CDN を提供している、Amazon Web Services と戦うためには、不可欠なものとなるだろう。
 
Microsoft Azure has a CDN, as well. To broaden its public cloud portfolio, Google has been steadily adding features, including a tool for storing and editing application code. In addition to features, the Google cloud also competes on the price of raw cloud computing and storage infrastructure. Recently, Google made it possible for people to adjust the resource sizes of individual virtual machines they use in the Google Compute Engine.
 
同様に、Microsoft Azure も、CDN を持っている。それに対して Google は、パブリック・クラウドのポートフォリオを着実に拡大するために、アプリケーション・コードを格納/編集するためのツールなどを追加している。それらの機能に加えて、クラウドにおけるコンピューティングとストレージといったインフラに関しても、 Google は価格競争を仕掛けている。また、最近のことだが、Google Compute Engine を利用するユーザーが、個々の仮想マシンのリソース・サイズを調整できるよう、Google は改善を施している
 
Google already has partnerships with CDN providers like Fastly, CloudFlare, Highwinds, and Level 3.
 
すでに Google は、Fastly/CloudFlare/Highwinds/Level 3 といった、CDN プロバイダーとパートナーシップを結んでいる。
 
Google has also partnered with Akamai, the biggest company in the CDN business. AWS CloudFront has become big with web services that need to perform well around the world, which has challenged Akamai, to a degree. Now Google will also be competing, rather than just partnering.
 
さらに Google は、CDN 業界の最大手である Akamai とも提携している。 また、グローバルな CDN プラットホームを必要とする、各種の Web サービスと伴に、AWS CloudFront は次第に大きな存在へと成長している。 そして Google は、この新しいサービスにより、それらと協調するのではなく、競合していく道を選んだことになる。
 
ーーーーー
google-55a先月のことですが、「Google と Akamai が 提携: Google Cloud Platform のスピードとコストは、どのように変化するのか?」という抄訳をポストしています。そのときに、Google の CDN 戦略が定まったと思ったのですが、さらに新しい局面へと突入していくようです。 Akamai は、「世界で最大の分散 CDN プラット・フォーム・オペレーターとして、私たちは Google Cloud Platform と協調していく」と発言していたのですが、その辺りは、どうなるのでしょうかね? その一方で、中小の SaaS プロバイダーが、AWS 上で成長しているという記事を、先日に紹介していますが、CDN サービスが多様化していくことで、こうした動きがさらに加速していくはずです。 クラウドのためのインフラが、ものすごい勢いで整備されていきますね! _AC Stamp
ーーーーー
<関連>
Google の 60Tbps 太平洋海底ケーブルは、どのような未来を見せてくれるのか?
Microsoft も参加する 海底ケーブル NCP は、太平洋を 80T bps で横断する!
Akamai と OpenDNS が提携:もっと もっと Web を速くしたい!
Akamai の 61,000 台のサーバーは、70カ国で 1,000 Networks をサポートする
Akamai がダウンすると、インターネットも道連れに?
 

Comments Off on Google Cloud CDN というサービスが始まる: Google は Akamai とも競合していくのか?

CoreOS の調査:足し算から引き算へと、Linux ディストリビューションを再編する

Posted in Container, Linux, On Monday, Red Hat by Agile Cat on November 17, 2014

CoreOS: Linux Vendors in the Crosshairs of Disruption
http://wp.me/pwo1E-81Z
By Dick Weisinger – November 11, 2014
http://formtek.com/blog/coreos-linux-vendors-in-the-crosshairs-of-disruption/

_ formtek

Linux distribution vendors like Red Hat, Canonical, and Suse are under threat of disruption from a repackaged and streamlined minimalist product from CoreOS.

Red Hat および、Canonical、SuSE といった Linux ディストリビューション・ベンダーたちは、CoreOS が合理化と最小化を念頭に再考した、新たなプロダクトの脅威にさらされ、混乱に陥っている。

Cloud providers are intrigued with the technology, and CoreOS is now offered on AWS, Google Compute Engine, Rackspace, OpenStack and VMware.

クラウド·プロバイダーたちは CoreOS のテクノロジーに興味を覚え、いまでは AWS および、Google Compute EngineRackspaceOpenStackVMware が提供するという状況にある。

Traditional Linux distributions have become increasingly bloated as vendors have added ever more features.  Matt Assay in an Infoworld article quotes a Linux industry observer as saying that ”CoreOS is the first cloud-native OS to emerge. It is lightweight, disposable, and tries to embed devops practices in its architecture. RHEL has always been about adding value by adding more. CoreOS creates value by giving you less.”

従来からの Linux ディストリビューションは、そのベンダーたちが機能を追加し続けるにつれて、肥大化の一途を辿っている。Infoworld の記事において Matt Assay は、Linux 業界オブザーバーの発言をを引用し、「CoreOS は、初めてのクラウド・ネイティブ OS として登場している。それは、軽量で使い捨てであり、クラウド・アーキテクチャにおける DevOps プラクティスと強く結びついている。RHEL は、常に機能を追加することで、その価値を高めるという方式を取ってきた。 しかし、CoreOS は機能を削ることで、価値を生み出している」と述べている

CoreOS is designed to be cluster ready and easily maintainable.  The ideas behind the CoreOS Linux distribution, which is a fork of Google’s Chrome OS, include:

CoreOS は、クラスタに対応し、その維持が容易になるよう、デザインされている。その背景となるのは、Google Chrome OS からフォークした、CoreOS Linux ディストリビューションであり、以下のように要約できる:

  • Minimalist, consuming less than 40 percent RAM than the average Linux distribution
  • Quick updates to new versions, rather than package by package updates
  • Docker Containers used by most applications
  • Designed for clustering
  • 一般的な Linux ディストリビューションとの比較で、40% 以下の RAM 消費という、最小化のデザイン
  • パッケージのアップデートよりも高速な、新バージョンへのアップデート
  • 数多くのアプリケーションが使用する、Docker Containers に対応
  • クラスタリングに対応したデザイン

The easy upgradability is one of the shining features of CoreOS.  Patches and upgrades to OSes can be disruptive and difficult.  Recent OS vulnerabilities like Shellshock and Xen hypervisor were particularly difficult to guard against because they struck at components of the OS.  CoreOS’s design allows the OS to be non-disruptively patched, minimizing headaches related to installing patches.

容易なアップグレードは、CoreOS の輝ける特徴の1つである。時として、OS へのパッチとアップグレードは破壊的なものとなり、また、困難を伴う場合がある。ShellshockXen hypervisor といった、最近の OS に見られる脆弱性は、とりわけ OS コンポーネントの保護が困難なことに起因している。CoreOS のデザインであれば、パッチによる混乱を排除した OS が実現され、パッチのインストールに関連する問題を最小限に抑えられる。

A year ago, Lew Moorman, former Rackspace president, predicted that CoreOS “is the way a lot of modern applications are going to get built — though it’s very early days.  This is not super-mainstream today… but having a lightweight system like this where you can easily manage a huge number of machines will be very, very valuable.”

Rackspace の President を務めていた Lew Moorman は、「CoreOS は、現代的なアプリケーションを、大量に構築する方法を提供するだろうが、いまは、きわめて初期の段階にある。つまり、いまは主流というわけではないが、大量のマシンを容易に管理できる、この種のライトウェイト・システムは、とても大きな価値を持つものとなるだろう」と、1年ほど前に CoreOS の将来を予測していた

参照: InfoQ:CoreOSの最初の安定版がリリース

参照: deeet:CoreOSに入門した

ーーーーー

話は Open Compute Project に飛びますが、2013年1月の Summit のキーワドは、サーバーやラックの構成要素をゼロから再編していく、Disaggregation という概念に集約されていました。 つまり、これからの時代に必要なハードウェアとは、いったい何なのかという観点で、従来からの常識に因われることなく、再考していこうという取り組みです。 その背景には、クラウドの Before/After で激変してしまったデータセンターのデザインという視点があります。 そして、新しくデザインされるデータセンターに大量導入されるラックやサーバーを、再定義する必要性が生じたのですが、それは、Linux ディストリビューションについても言えることなのですね。 この両者の間に、とても似かよった流れを感じます。

ーーーーー

<関連>

Social の調査:Twitter と MIT の コラボ が、膨大なソーシャル・ストリームを分析していく
Data Center の調査:大変革を促す4つの要因とは? – Gartner
Security の調査: Google と Dropbox が発表した Simply Secure イニシアティブとは?
Gartner の調査:これからの5年間で、私たちの働き方を変える 10のテクノロジーとは?
IoT の調査:BitCoin のテクノロジーを、IoT のアーキテクチャーに応用できるはずだ!

Comments Off on CoreOS の調査:足し算から引き算へと、Linux ディストリビューションを再編する

Microsoft への提言:Red Hat を買収して クラウドを強化したら どうだろう?

Posted in Microsoft, OpenStack, Red Hat by Agile Cat on May 14, 2014

Why Microsoft should just pack it in and buy Red Hat
http://wp.me/pwo1E-7uz

By
Barb Darrow – Feb 28, 2014
http://gigaom.com/2014/02/28/why-microsoft-should-just-pack-it-in-and-buy-red-hat/

_ Giga Om

Summary: Sure it would make for strange bedfellows, but Microsoft needs Red Hat Enterprise Linux and an acquisition would signify a bold move by new CEO Satya Nadella.

Summary: たしかに、それは、ちょっと奇妙な関係と言えるだろうが、Microsoft は Red Hat Enterprise Linux を必要としている。 そして、もし、買収にいたるなら、新しい CEO である Satya Nadella の大胆な行動と評価されるだろう。

photo: Jorge Salcedo

Over the past 40 years Microsoft has built its mega-billion-dollar business around the Windows operating system and Windows applications. But as the company seeks to preserve its enterprise power in the cloud era, where Windows is not as huge a deal, here’s a bold proposal: Microsoft should buy Red Hat.

これまでの 40年間において Microsoft は、Windows オペレーティング・システムおよび Windowsアプリケーションを中心にして、巨億のビジネスを構築してきた。しかし、Windows が大きな勢力を持ち得ないクラウドの時代で、その企業の力を同社が維持したいなら、ちょっと大胆な提案をしてみたいと思う。 それが、Microsoft による Red Hat の買収という、必要性の話である。

It’s a counterintuitive move for a company whose former CEO likened Linux to cancer, but here’s why I think Microsoft might want to do it. First, Microsoft is an enterprise software company that hopes to transition its strength in that segment into the cloud-and-mobile era. And for Microsoft’s new CEO Satya Nadella, who will orchestrate that transition, an acquisition of Red Hat would be a bold stroke. Talk about thinking outside the box.

前 CEO が Linux をガンになぞらえていた企業にしては、反対の方向への動きに思えるが、それを Microsoft が望んでいるかもしれないと、私が思う理由を示していく。 まず、Microsoft は、これまでの強みを、クラウドとモバイルの時代におけるセグメントへ向けて、移行したいと考えているエンタープライズ・ソフトウェアの会社である。そして、Microsoft の新しい CEO である Satya Nadella は、その移行を周到に準備するだろうし、その意味で Red Hat の買収は大胆な一撃となる。ただし、いま話していることは、かなり常識はずれなことかもしれない。

Source: IDC

Microsoft is pitching Windows Azure as the public cloud of choice for businesses. A major stumbling block there is the fact that Red Hat Enterprise Linux, the de facto standard Linux in businesses, does not run on Azure. Why not? No one’s really saying, but my take is that Red Hat is dragging its feet because RHEL competes with Windows Server. Red Hat has no such compunction about putting RHEL on AWS, which does run RHEL, because Amazon is not an OS competitor per se — at least as the market is defined now.

Microsoft は、企業向けパブリック・クラウドの選択肢として、Windows Azure を投入している。しかし、ここでの大きな障害は、それらの企業が Linux のデファクト・スタンダードとする Red Hat Enterprise Linux が、Azure では走らないという現実である。当たり前じゃないかい? 誰もが本当のことを言っていないが、RHEL を Windows Serverと競合するため、Red Hat が足を引っ張っているというのが、私の感想である。Red Hat は、AWS 上で RHEL を走らせることについて、そのような躊躇がまったく無い。なぜなら、Amazon は OS の競争相手ではないので、大歓迎なのである。少なくとも、そのような形で、いまのマーケットは構成されてる。

The lack of RHEL on Azure is a big issue for Microsoft. Given that Microsoft has bent over backwards to make Azure hospitable to third-party OSes and tool sets (Ubuntu Linux and SUSE Linux run on it), RHEL’s absence is particularly glaring because when you talk enterprise applications from Oracle, SAP et al., RHEL is Linux (sorry Oracle Linux, you’re not there yet.)

Azure で RHEL が欠落していることは、Microsoft にとって大きな問題である。サードパーティの OS や Tool Set を Azure 上でホストしようと、Microsoft が懸命に努力していることを考えると(Ubuntu Linux と SUSE Linux には対応)、RHEL の不在が目立ってしまう。なぜなら、Oracle や SAP などのエンタープライズ・アプリケーションを前提にすると、RHEL が Linux だからだ(残念ながら Oracle Linux は発展途上)。

Neither Red Hat nor Microsoft would comment on why RHEL won’t run on Azure but sources close to Microsoft said customers ask the company about Red Hat support all the time and it has to refer customers back to Red Hat. Their thinking is that nothing can pressure a company to action more than customer pressure, but still, no dice.

Red Hat も Microsoft も、RHEL が Azure で走らない理由についてはノー・コメントだろう。しかし、Microsoft に近い情報筋によると、いくつかの顧客は Red Hat をサポートするよう要求しており、そのことが Red Hat にも伝わっているようだ。どちらも、顧客からのプレッシャーに勝るものはないと捉えているはずだが、まだ、サイコロは回り始めていない。

Red Hat is affordable

If you look solely at the numbers, Microsoft could do this deal easily. The market value of Red Hat stock is about $11.2 billion. Subtracting its $1.3 billion in cash, Red Hat would cost $9.9 billion. A 20 percent premium would put the purchase price at more like $12 billion. As one of my Wall Street friends put it, since Microsoft has about $84 billion cash in the bank, it could do this acquisition with its eyes closed.

単に数字だけを見るなら、Microsoft は簡単に買収できるだろう。Red Hat の市場評価額は、$11.2 Billion である。そこから、手持ちのキャッシュである  $1.3 Billion を差し引けば、Red Hat の買収に費やされるコストは $9.9 Billion となる。さらに、20% のプレミアムを付けても、$12 Billion で収まる。私の Wall Street フレンドによると、Microsoft の銀行預金は $84 Billion ほどなので、その支出に目をつむれば、買収は可能となる。

Antitrust hurdles are big but not insurmountable

Analysts, including Gigaom Research’s own MSV Janakiram, said no such transaction would pass regulatory muster. Taken together, Red Hat Enterprise Linux (RHEL) and Windows Server would comprise 87 percent of the server operating environment market, according to IDC analyst Al Gillen — who was also dubious about my premise.

Gigaom Research が所有する MSV の Janakiram や、その他のアナリストたちは、そのような取引が、当局に規制されないはずがないと言う。そして、Red Hat Enterprise Linuxに(RHEL)と Windows Server を合算すると、サーバー・オペレーティング市場の 87% に達してしまうと、私の考えに疑問を呈していた、IDC のアナリストである Al Gillen は述べている。

That number would give regulators pause if they define the market as server operating systems running inside company data centers. But if they were to factor in what’s running in Google and Amazon Web Services and other clouds, the picture could be much different. And we all know that lawyers can redefine the affected market when it painting a prospective acquisition in a rosy, competitive light.

この数字の捉え方だが、企業のデータセンター内で実行されるサーバー OS を前提に市場を定義するなら、当局は規制を行うだろう。しかし、Google や AWS といったクラウドで、どのような比率で、何が動いているのかを計算するなら、そのイメージは大きく異なるものになるだろう。買収劇を押し通すことに価値があり、すべてがバラ色に塗り替えられるとなったとき、弁護士たちが影響をうけるだろう市場を再定義してしまうことを、私たちは知っている。

In that universe, Windows Server plus RHEL might not be dominant at all. According to figures from The Cloud Market, nearly 60 percent of all Amazon Machine Images (AMIs) run Ubuntu Linux, while 6.3 percent run Windows and 5.9 percent run Red Hat. And I’m pretty sure Google runs zero Red Hat Linux or Windows.

この世界では、Windows Server だけではなく RHEL も、支配的だとは言えないだろう。The Cloud Market の統計によると、Amazon Machine Images(AMI)の約 60% は Ubuntu Linux を実行しており、Windows と Red Hat の比率は 6.3% と 5.9% に過ぎない。さらに言えば、Google が Red Hat Linux と Windows を実行している確率はゼロだと、私は確信している。

Source
The Cloud Market

And, if regulators can approve the US Airways and American Airline or Comcast and NBC Universal mergers, I think all bets are off. I’ve seen strange things happen in the software world, including Oracle’s acquisitions of Siebel Systems and PeopleSoft in blockbuster deals that consolidated much of the enterprise applications market.

たとえば、US Airways と American Airline もしくは Comcast と NBC Universal の合併を、規制当局が承認するかとなると、そこに一銭も賭ける気はしない。しかし、ソフトウェアの世界では、Oracle による Siebel Systems PeopleSoft の買収といった、エンタープライズ・アプリケーションの市場を統合してしまう、奇妙な光景を目の当たりにしている。

Those transactions taught me to never say never. So go ahead, use the comments below to (politely, please) to let me know what you think.

これらの取引が教えてくれたのは、Never Say Never である。そう、前へ進むしか無いのだ。 あなたの考えがあるなら、以下のコメントで、なるべく丁寧に教えて欲しい。

Feature photo courtesy of Shutterstock user Jorge Salcedo

Related research

An analysis of Windows Azure’s strengths and weaknesses February 2014
How tomorrow’s mobile-centric data centers will look December 2012
The promise of SDNs in the enterprise November 2012

ーーーーー

TAG indexなかなか、面白い視点からの考察です。 先日に、「 Open Source の調査:ユーザーによる主導性の確立が、人々と組織を惹きつける 」という抄訳をポストしましたが、オープンソースを活用することで、ユーザーだけにではなくクラウド・プロバイダーにも、計り知れないメリットがもたらされるはずです。 その名称が、Windows Azure から Microsoft Azure に変わったのも、 Windows の枠組みに制約されない、新たなクラウド戦略の確立という意志の現れだと思います。 Linux は ガンだと言ってしまった CEO も退任したわけですし、これまでのシガラミを解いて、いろいろなことに柔軟に対応して欲しいですね。 image

ーーーーー

<関連>

Microsoft クラウド・パートナーが、そのメニューに OpenStack を加えた!
OpenStack のデベロッパーたちに、ひじ鉄を食らってしまった Microsoft Hyper-V
Microsoft が OpenStack に参加する背景を GIGAOM が解説
OpenStack が Microsoft から、Hyper-V サポートを獲得 – All About Microsoft
Nokia の Android フォン:生産ラインが止まらないが、事件なのか? それとも、予定調和なのか?
Nokia X という Android フォンのウワサは本当なのか? ベトナムでは価格まで公表されている

Comments Off on Microsoft への提言:Red Hat を買収して クラウドを強化したら どうだろう?

Google Cloud Platform のアジア展開が、ついに本格化してきた! from 台北

Posted in .Selected, Asia, Google, Strategy by Agile Cat on April 16, 2014

Cloud platform for Taiwanese enterprises rolled out by Google
http://wp.me/pwo1E-7pr
The China Post – April 16, 2014
http://www.chinapost.com.tw/business/company-focus/2014/04/16/405461/Cloud-platform.htm

TAIPEI — Google Inc. rolled out its cloud computing-based platform for enterprises in Taiwan yesterday on its first stop of an Asian tour to promote its cloud business services.

TAIPEI — クラウド・ビジネス・サービスを促進するために、アジア・ツアーを展開している Google だが、その最初の訪問国である Taiwan で、クラウド・コンピューティングをベースにした、ローカル企業のためのプラットフォームを披露した。

The Web search giant said the Google Cloud Platform will enable developers to build, test and deploy applications on Google’s infrastructure, including computing, storage and application services designed for Web-based, mobile and backend solutions.

この Web サーチの巨人が言うには、Google Cloud Platform によりデベロッパーたちは、アプリケーションの構築/テスト/ディプロイを、Google インフラ上で実現することになる。そして、このインフラには、Web/Mobile/Backend ソリューションのためにデザインされた、コンピューティング/ストレージ/アプリケーションのサービスなどが含まれる。

Google said it has added new language support for traditional Chinese and Japanese versions of the cloud platform’s website, and will later introduce the platform to more Asian markets, including Japan, South Korea and Hong Kong.

さらに Google は、このクラウド・プラットフォームの Web サイトで、新たな言語として Traditional Chinese と Japanese をサポートし、また、Japan/South Korea/Hong Kong などを含むアジア市場へ向けて、このプラットフォームを紹介していくことになる。

Daniel Powers, director of global sales for the Google Cloud Platform, told a press conference in Taipei that Google has spent 15 years building its cloud computing infrastructure.

Google Cloud Platform の Director of Global Sales である Daniel Powers は、Taipei で開催されたプレス・カンファレンスにおいて、同社が 15年を費やしてきた、そのプラウド・プラットフォーム・インフラについて説明した。

The company is glad to make that infrastructure available for developers and businesses around the world to help them build applications and scale up their businesses, he said.

そして、Daniel Powers は、世界中のデベロッパーやエンタープライスによる、アプリケーション構築とビジネス展開を支援するために、このインフラストラクチャを利用してもらえることを、嬉しく思うと述べている。

Google charges a basic fee for the business services based on the number of e-mail accounts opened. It said that businesses using the services can save money compared to the amount it would cost them to set up the same infrastructure on their own.

Google が言うには、それらのエンタープライスがすでに開設している、電子メールのアカウント数をベースにして、このビジネス·サービスをディスカウントしていくようだ。つまり、このサービスを利用するエンタープライズは、同一のインフラを活用するため、全体的な費用を低減できることになる。

Paid services on the platform, such as the Cloud Storage online storage solution and the Google BigQuery analytics tool for multi-terabyte datasets, are also now priced 30 to 85 percent lower than their previous versions, Google said.

このプラットフォーム上の有償サービスである、オンライン・ストレージ·ソリューションの Cloud Storage や、テラバイト・データセットのための分析ツールである Google BigQuery なども、以前のバージョンと比べて 30%〜85% ほど値下げされていると、Google は述べている。

The Google Cloud Platform currently supports more than 4.75 million applications, and the platform’s App Engine handles 28 billion online requests for computing per day, according to Google.

Google によると、現時点における Google Cloud Platform は 4.75 Million 以上のアプリケーションをサポートし、また、このプラットフォーム上の App Engine は 28 Billion/Day のオンライン・リクエストを処理しているようだ。

Research firm IDC has forecast that the cloud computing industry will grow to US$107 billion by 2017, more than double from an estimated US$47.4 billion in 2013.

調査会社である IDC が予測するには、クラウド・コンピューティング業界の売上は、2017年には $107 Billion に至るようだ。それは、2013年の $47.4 Billion と比較して、二倍以上の成長となる。

ーーーーー

imageいまは、16日の 5AM ですが、この China Post の他にも、以下のニュース・サイトが Google のアジア展開を報じています。また、 Google の日本語サイトも見てみましたが、上記の「ディスカウント」に関する記載は見つかりませんでした。どのような料金体系にしてくるのか、とても気になりますね。ac-stamp-232

Google Cloud expands footprint into Asia Pacific zones ZDNet 
Google steps up competition with Amazon, expands Cloud Platform to Asia InfoWorld 
Google Cloud Platform Expands To Asia Pacific With 2 New Compute Engine TechCrunch
Google fires up Asia Pacific region Cloud Platform ZDNet
Google bolsters global cloud presence with Asian data centers SiliconANGLE

ーーーーー

<関連>

Google Compute Engine が正式にリリースされた : どのようにして、AWS と戦っていくのか?
Google Compute Engine 対 Amazon EC2 : 性能をチャートで比較する
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _2
Google Compute Engine は、どこで Amazon AWS を上回るのか?
Google Compute Engine の登場で、どのような影響が IssS 業界に?

Comments Off on Google Cloud Platform のアジア展開が、ついに本格化してきた! from 台北

Snapchat の CTO が、Google Cloud Platform Live に登壇するということは?

Posted in Events, Google, SnapChat, Social, Web Scale by Agile Cat on March 15, 2014

Snapchat CTO and co-founder Bobby Murphy to appear at Google Cloud Platform Live on March 25
http://wp.me/pwo1E-7jG

Posted: Tuesday, March 4, 2014
http://googlecloudplatform.blogspot.jp/2014/03/snapchat-cto-and-co-founder-bobby.html

Bobby Murphy, CTO and co-founder of Snapchat, will be joining Google Senior Vice President Urs Hölzle on stage during the keynote of Google Cloud Platform Live. Bobby will be sharing his experience building one of the world’s most popular apps on Google Cloud Platform.

Snapchat の CTO and  Co-Founder である Bobby Murphy だが、Google Cloud Platform Live でキーノートを務める Senior VP Urs Hölzle のステージに登壇するようだ。 そして、Bobby は、この世界で大人気のアプリを Google Cloud Platform で、構築したときのエクスペリエンスを共有することになる。

Snapchat’s users share over 400 million snaps everyday.

なんせ、Snapchat のユーザーたちは、400 million 以上のスナップを、毎日のように飛ばし合っているのだ。

Google Cloud Platform Live is taking place 3 weeks from today. Bobby will be joining a great line up of other speakers, including Google Senior Fellow Jeff Dean. We’ll announce new features, take a deep dive on tips, tricks and technology, and share our vision for the future of cloud computing.

Google Cloud Platform Live は、3週間後に開催される。そして Bobby は、Google の Senior Fellow である Jeff Dean といった、素晴らしいスピーカーたちによるラインナップに参加する。私たちは、そこで提供される新しい機能や、ティップス、テクノロジーを追いかけ、また、このクラウド・コンピューティングにおける未来のビジョンを共有していく。

We are nearly at capacity in all our locations, but for people who are still interested in attending you can request an invitation to join us in-person in San Francisco or attend a livestream of the keynote at Google New York City, Google Seattle or Google London. And for those who can’t make it in person, you can always tune in online.

すべてのロケーションにおいて、私たちのキャパシティは満杯に近いが、参加したいのなら San Francisco にリクエストして欲しい。 また、 Google New York City および、Google SeattleGoogle London でも、ライブ・ストリームが提供される。それも無理な人は、オンラインで参加することも可能だ。

ーーーーー

imageSnapchat が Google Cloud Platform というのは意外ですが、ウルトラ・ハイパー・スケールを狙っている同社が、このようなスター・プレイヤーを誘致したとしても、それは、それで、ナルホドと思える話です。 Nameservers を調べてみたら GoDaddy なのですが、システムの本体は Google にあるということなのでしょうか? ついでに、Whatsapp も調べたら、Nameservers は SoftLayer になっていました。 なんか、ワクワクする展開ですね。ac-stamp-232

ーーーーー

<関連>

Google Compute Engine 対 Amazon EC2 : 性能をチャートで比較する
GCE が正式にリリースされた : どのようにして、AWS と戦っていくのか?
Google Compute Engine は、どこで Amazon AWS を上回るのか?
GCE の登場で、どのような影響が IssS 業界に?
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _2

Comments Off on Snapchat の CTO が、Google Cloud Platform Live に登壇するということは?

Google Load Balancing のベンチマーク : 100万リクエスト/秒を達成!

Posted in .Selected, Google, Web Scale by Agile Cat on December 10, 2013

Compute Engine Load Balancing serves 1 million requests per second, here’s why you should care
http://wp.me/pwo1E-70t

Dec 7, 2013
http://blog.scalr.com/post/68286517190/compute-engine-load-balancing-serves-1-million-requests

Scalr Blog

A couple days ago, Anthony of the Google Cloud Platform team announced a benchmark that showed Google Cloud Load Balancing routing 1 million requests per second.

何日か前のことだが、Google Cloud Platform チームの Anthony が、1秒あたり 100万リクエストをルーティングするという、Google Cloud Load Balancing のベンチマークを発表した。

That’s no small feat, but Google was nonetheless called out — at least on Hacker News — for a “Marketing blog post”! Why is that, you ask? Because Google wasn’t doing anything in the backend, and serving constant 1 byte (plus headers) HTTP responses from their upstream servers.

それは、なかなか大変なことなのだが、それにもかかわらず Google は、Marketing ブログ・ポスト(Hacker News だけ)で、簡単に触れているだけなのだ!

だからこそ、その理由が知りたくないか? Google のベンチマークで、バックエンドが何もしていなくても、さらには、上流のサーバーから 1 Byte(+Header)の HTTP レスポンスを供給していなくても、スゴイんじゃない?

Thing is, this benchmark isn’t about backend performance. It’s about load balancer performance, and it shows two interesting results.

つまり、このベンチマークは、バックエンドの性能ではなく、ロード・バランサーの性能を測るものなのだ。 そして、以下の 2つの、興味深い結果を示している。

Compute Engine Load Balancing scales very, very fast

On Twitter, @cloudpundit pointed out that unlike Amazon’s ELB, Google’s Load Balancer doesn’t need pre-warming to deliver stellar performance:

それについて @cloudpundit は、Amazon ELB とは異なり Google の Load Balancer は、その優れた性能を引き出すための、 pre-warming を必要としない、と指摘している:

Well, there’s not much more to say here… Except that you should follow Lydia on Twitter!
If you want a more detailed rundown, you can check out
Reuven Cohen’s take, published in Forbes.

そう。 Twitter で Lydia をフォローすべきだということを除いて、もう、何も言うことはない! そして、さらに詳細な情報が必要だというなら、Forbes に掲載された Reuven Cohen 記事をチェックして欲しい。

Now, let’s move on to another feature that we think has been overlooked in recent coverage. Compute Engine Load Balancing uses a single IP

続いて、最近の報道では見過ごされてきた、もう 1つの特徴に移りたい。 それは、Compute Engine の Load Balancing が、シングル IP を使用している点である。

Here’s a bit of context from our experience using Google Compute Engine to power the Eurovision Song Contest mobile backend:

ここでは、Eurovision Song Contest のモバイル・バックエンドにパワーを供給するために、Google Compute Engine を用いている、私たちのエクスペリエンスを説明したい。 それは、以下のようなコンテキストを持っている。

  • We were running the backend for a mobile application
  • Our frontend servers were Nginx instances
  • We had one DNS record set up to point to these Nginx frontend servers
  • 私たちは、モバイル・アプリケーションのためのバックエンドを走らせている
  • その、フロントエンド・サーバーとして、Nginx のインスタンスを走らせていた
  • それらの Nginx サーバー群を指し示すために、1つの DNS レコードを設定していた

Now, a problem we had was that our users were on mobile devices, so most of them shared DNS resolvers (their ISPs’). Naturally, we didn’t control those resolvers or their caching policy.

そこでの問題は、私たちのユーザーがモバイル・デバイスを使っているため、その大半が(彼らの ISP の)DNS Resolvers を共有している点であった。 当然のことながら、それらの Resolvers や キャッシュ・ポリシーを、私たちはコントロールできなかった。

Consequently, when we needed to scale up our frontend, the end users didn’t immediately connect to new instances. Ultimately, we saw largely uneven load on our frontend instances.

その結果として、私たちにはフロントエンドをスケール拡大する必要性が生じたが、それでもエンド・ユーザーたちは、直ちに新しいインスタンスに接続できないという事態に陥った。 最終的に、私たちのフロントエンド・インスタンスには、きわめて不均衡な負荷が発生することになった。

Compute Engine Load Balancing uses a single IP, and this benchmark demonstrates that this IP can route at least one million requests per second (that’s a lot!).

This seemingly minor feature means that, using Compute Engine Load Balancing, you are in full control of scaling your frontend. All your end users will ever see is a single IP.

この、Compute Engine Load Balancing を活用する、ちょっとマイナーな機能だが、あなたのフロントエンド・スケーリングを完全にコントロールするという意味を持つ。そして、すべてのエンド・ユーザーは、いつも シングル IP を参照することになる。

Compute Engine LB is a tool, not the solution

Compute Engine Load Balancing isn’t the “solution to scaling”, and we will still need to carefully architect our applications so that they scale horizontally.

Compute Engine の Load Balancing は、「スケーリングのためのソリューション」ではない。 そして、私たちのアプリケーションについては、水平にスケールするよう、慎重に構築していく必要性が残る。

Nonetheless, those benchmarks show that Google has delivered a tool we certainly needed to “solve scaling” — at the very least for the frontend!

それにもかかわらず、これらのベンチマークは、フロント・エンドという範囲に限定されたものでもあっても、「スケーリングの解決」に必要なツールを、Google が提供していることを示しているのだ!

And it’s available to just about anyone. So, hats off to the Google Compute Engine LB team!

そして、それは、誰もが利用できるものである。だから、Google Compute Engine LB チームには、脱帽なのである!

— Thomas

If you enjoyed this read – why don’t you sign up for email updates?

We’ll let you know when we publish new blog posts, we won’t spam you.
Posted in:
#opinion #gce

ーーーーー

image先週ですが、Twitter で @kazunori_279 さんが紹介していたブログ・ポストです。たしかに、Scalr サイトなのですが、背景は真っ黒で、そこに Lydia Leong さんのツートと、ドラゴンボールが並んでいるという、ハッキング・マインドがプンプンと臭っているコンテントです。 この、100万リクエスト/秒 というベンチマーク結果が、どれ程のものなのか、Agile_Cat 的には実感が持てませんが、さぞかしスゴイものなのだろうと想像しています。image  

ーーーーー

<関連>

Google Compute Engine が正式リリース : どのようにして、AWS と戦っていくのか?
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _2
Google Compute Engine 対 Amazon EC2 : 性能をチャートで比較する
Google App Engine が提供する、専用 memcache とは?
Google が擁護する、App Engine におけるロックインの定量化とは?

 

Comments Off on Google Load Balancing のベンチマーク : 100万リクエスト/秒を達成!

Google Compute Engine が正式にリリースされた : どのようにして、AWS と戦っていくのか?

Posted in .Selected, Google by Agile Cat on December 4, 2013

Google Compute Engine is “generally available” and it’s still not Amazon Web Services
http://wp.me/pwo1E-6Yx
By
Derrick Harris – Dec 3, 2013
http://gigaom.com/2013/12/03/google-compute-engine-is-ga-and-its-still-not-amazon-web-services/

_ Giga Om

Summary: Google probably does need to become feature-competitive with AWS sooner rather than later, but that doesn’t mean it necessarily needs to match AWS tit for tat. Maybe being Google will actually pay off in the end.

Summary: Google にとって、直ちに AWS と機能を競い合う必要はないが、AWS と同じフィールドで戦わなくても良いという話でもない。おそらく、最終的には、Google は具体的なかたちで報われるだろう。

ーーーーー

Google finally designated its Compute Engine infrastructure-as-a-service offering as generally available on Monday, about 18 months after announcing the service at its I/O conference in June 2012. It’s not clear how, exactly, generally available is different than the “available for anyone to use” status Google donned Compute Engine with in May (perhaps it has to do with support and SLAs), but Monday’s announcement does come with a collection of new features.

Google だが、その IaaS である Compute Engine を、一般に提供する日として、この月曜日(12/2)を指定した。それは、2012年 6月に I/O Conference で、このサービスを発表してから、約 18ヶ月後の立ち上げとなるが、正確なことは、まだ把握できていない。ただし、この、「一般への提供」という表現は、昨年 5月の時点で Google が示した「誰もが利用できる」という状況とは異なるものとなる(おそらく、サポートとの SLA に関係している)。 そして、月曜日の発表では、新らしい機能のコレクションが追加されている。

The new features vary from standard stuff like bigger instance types and support for more varieties of Linux to higher-level capabilities such as live migration of virtual servers during scheduled maintenance and automatic restart of those servers should they go down. Google also lowered the price of computing resources by 10 percent across the board and lowered the price of persistent disk capacity by 60 percent. IO performance on the biggest persistent disk instances is up to 700 percent faster, the company claims, and IO is now included in the price of data storage.

それらの新機能とは、より大きなインスタンス・タイプといった、標準的なものとは異なる。たとえば、仮想サーバーのライブ・マイグレーションや、サーバーの定期的なメンテナンス、そして、サーバーの自動的な停止/再起動といった、より高いレベルでの、Linux における多様な機能のサポートとなる。また、Google は、コンピューティング・リソースの価格を全体的に 10% 引き下げ、また、パーシスタント・ディスクの価格については 60% も引き下げている。さらに、大容量パーシスタント・ディスク・インスタンスにおいては、その IO パフォーマンスが 700% も高速化されているが、この IO に関する対価も、データ・ストレージの価格に含まれると、同社は発言している。

Although the new features will certainly make Compute Engine more palatable to some potential users, it’s still nowhere near comparable to cloud leader Amazon Web Services in terms of breadth of capabilities and services. Gartner analyst Lydia Leong has written a post looking at the feature gap between the two platforms as they exist today and expresses an opinion that Google will ultimately start closing it by exposing some of the impressive technologies it has developed to run the rest of its services (e.g., search, Gmail, Apps and the like). I tend to agree with her assessment, and have said as much before.

たしかに、それらの新機能により、高いスキルを持った一部のユーザーにとって、Compute Engine は心地よいものになるだろうが、機能とサービスの幅広さという点では、クラウド·リーダーである Amazon Web Services から、遠く引き離されたところにいる。Gartner のアナリストである Lydia Leong は、この 2つのプラットフォームにおける、現時点での機能に違いに注目し、また、自身の意見を表明している。それは、「 最終的に Google は、他のサービス(たとえば Search/Gmail/Apps など)を実行するために開発した、いくつかの素晴らしいテクノロジーを公開することで、その完成形へ向けて進み始めるだろう」というものだ。私の見方は、以前にも述べているように、彼女の評価を同じ方向性を持つものとなる。

Google probably does need to become feature-competitive with AWS sooner rather than later, but that doesn’t mean it necessarily needs to match AWS tit for tat. While AWS is rolling out new stuff pretty much weekly and has “two-pizza” teams focused on specific services, maybe Google can compete by focusing on the bigger picture and features that let it establish its own identity. Compute Engine’s live migration feature, for example, is a meaningful step toward the kind of resiliency that Netflix has architected itself on top of AWS but AWS doesn’t yet provide itself.

Google にとって、直ちに AWS と機能を競い合う必要はないが、AWS と同じフィールドで戦わなくても良いという話でもない。AWS は、ほとんど毎週のように、新しい機能を提供し続け、また、特定のサービスに関しては、2つのチームで対応している。 それに対して、おそらく Google は、自身のアイデンティティを確立させる、大がかりな構想と機能を中心に据えた戦略により、戦い続けていけるだろう。たとえば、Compute Engine のライブ・マイグレーション機能は、ある種の弾力性へ向けた、意味のあるステップだ。それは、Netflix が AWS 上でデザインしているアーキテクチャのようなものであり、また、AWS 自身が提供していないものでもある。

The cloud computing market is still very much a one-horse race, and it very likely will be — at least in market share and revenue at the top — for some time to come. If Google is ever going to make a big push to dent AWS’s lead (or at least duke it out with Microsoft for a chance to become the solid No. 2 in the space), perhaps the answer isn’t replicating AWS every step of the way but focusing on the stuff it does best. It does need to get some table stakes in place — better instance variety and maybe some more advanced data analysis services — but after that perhaps actually delivering on being Google can pay off.

クラウド・コンピューティング市場で行われているのは、依然として一頭立てのレースであり、少なくとも、シェアと売上という観点では、その状況が、当面は続いていくと思われる。もし Google が、AWS のリードにキズを付けようとするなら(また、No.2 の座をめぐり、Microsoft と決着をつけるなら)、おそらく、その答えは、AWS の全ステップを複製するのではなく、自身が最も得意とする領域にフォーカスするものになるはずだ。つまり、多様なインスタンスや、高度なデータ分析サービスといったものに対して、いくらかの投資が必要となるが、その後には、Google に現実的な利益をもたらすものが、提供できるようになるだろう。

ーーーーー

image28ついに、正式にリリースですね! スキのない AWS に対して、まだまだ未成熟で荒削りな GCE ですが、その基礎的な身体能力は、きわめて高いレベルに到達しているように思えます。 よろしければ、以下の性能比較チャートを参照してください。 そして、Gartner の Lydia Leong が、「 Search/Gmail/Apps などを実行するために開発した、いくつかの素晴らしいテクノロジーを公開することで、その完成形へ向けて GCE 進み始めるだろう 」と言うように、EC サイト用のサービスのために構築された、AWS とは異なるものになるはずです。 クラウドの評価軸に多様性が生じることは、とても良いことだと思います。 だから、GCE には頑張って欲しいですね! image

ーーーーー

<関連>

Google Compute Engine 対 Amazon EC2 : 性能をチャートで比較する
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _2
Google Compute Engine の登場で、どのような影響が IssS 業界に?
Google Compute Engine は、どこで Amazon AWS を上回るのか?

 

Comments Off on Google Compute Engine が正式にリリースされた : どのようにして、AWS と戦っていくのか?

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

%d bloggers like this: