Agile Cat — in the cloud

単純/安価/高速 : .NET から Node + Heroku に乗り換えた Playtomic

Posted in .Selected, API, Research by Agile Cat on October 24, 2012

Simpler, Cheaper, Faster: Playtomic’s Move from .NET to Node and Heroku
http://wp.me/pwo1E-54r

Monday, October 15, 2012 at 9:15AM
http://highscalability.com/blog/2012/10/15/simpler-cheaper-faster-playtomics-move-from-net-to-node-and.html

_ highscalability

This is a guest post by Ben Lowry, CEO of Playtomic. Playtomic is a game analytics service implemented in about 8000 mobile, web and downloadable games played by approximately 20 million people daily. Here’s a good summary quote by Ben Lowry on Hacker News:

Playtomic が提供する分析サービスは、2000万の人々が毎日のようにプレーする、モバイル/Web/ダウンロードを前提とした、約 8000 種類のゲームにインストールされたものである。以下は、Ben Lowry が Hacker News で発言した、きわめて明快な概要である:

Just over 20,000,000 people hit my API yesterday 700,749,252 times, playing the ~8,000 games my analytics platform is integrated in for a bit under 600 years in total play time. That’s just yesterday. There are lots of different bottlenecks waiting for people operating at scale. Heroku and NodeJS, for my use case, eventually alleviated a whole bunch of them very cheaply.

20,000,000人以上の人々が、昨日は 700,749,252回も、私の API にアクセスした。その解析プラットフォーム上の、8000弱のゲームをプレーすることは、600年分の時間を費やすに等しくなる。 ただし、それは、昨日の利用だけに過ぎない。 大規模スケールに取り組む人々にとって、それぞれのボトルネックが、たくさんの位置に存在している。 私のユース・ケースにおいては、最終的に Heroku と NodeJS が、きわめて低コストで、その多くを緩和している。

Playtomic began with an almost exclusively Microsoft.NET and Windows architecture which held up for 3 years before being replaced with a complete rewrite using NodeJS.  During its lifetime the entire platform grew from shared space on a single server to a full dedicated, then spread to second dedicated, then the API server was offloaded to a VPS provider and 4 – 6 fairly large VPSs.   Eventually the API server settled on 8 dedicated servers at Hivelocity, each a quad core with hyperthreading + 8gb of ram + dual 500gb disks running 3 or 4 instances of the API stack.

NodeJS を用いて完全に書き換えられる以前の Playtomic は、Microsoft の .NET と Windows のアーキテクチャを、ほとんど排他的な形式で、3年も採用してきた。この  プラットフォーム全体は、専用のシングル・サーバー上の共有スペースから、専用の分散サーバーへと成長してきた。 そして、さらに、API サーバーは、4~6 社の大手 VPS 上へと、均等にオフロードされた。 最終的に、この API サーバーは、Hivelocity が提供する 8台の専用サーバー上に落ち着いたが。 しかし、その API スタックでは、Quad-Core のハイパー・スレッディング + 8GB の RAM + 二重化された 500 GB により、3 ~ 4 個のインスタンスを走らせるという状況であった。

These servers routinely serviced 30,000 to 60,000 concurrent game players and received up to 1500 requests per second, with load balancing done via DNS round robin.

これらのサーバーは、DNS ラウンド・ロビンを介したロードバランシングを用いて、30,000 ~ 60,000人のゲームプレイヤーに対して、コンカレントなサービスをルーチンとして提供し、また、1秒あたり 1500 のリクエストを受けている。

In July the entire fleet of servers was replaced with a NodeJS rewrite hosted at Heroku for a significant saving.

そして、この 7月には、全体的なサーバーの構成を、Heroku 上にホストされる NodeJS で、書き換え、また、リプレイスすることになった。 そして、大幅なコストの削減が実現されたのだ。

Scaling Playtomic with NodeJS

There were two parts to the migration:

Dedicated to PaaS:  Advantages include price, convenience, leveraging their load balancing and reducing overall complexity.  Disadvantages include no New Relic for NodeJS, very inelegant crashes, and a generally immature platform.

Dedicated to PaaS: アドバンテージとしては、価格/利便性/ロードバランシングの活用/全体的な複雑さの低減などが挙げられる。  ディス・アドバンテージとしては、NodeJS 用の New Relic の不在/とてもエレガントとは言えないクラッシュ/全般的に見て未熟なプラットフォームなどが挙げられる。

.NET to NodeJS: Switching architecture from ASP.NET / C# with local MongoDB instances and a service preprocessing event data locally and sending it to centralized server to be completed; to NodeJS on Heroku + Redis and preprocessing on SoftLayer (see Catalyst program).

.NET to NodeJS: ASP.NET / C# からローカルな MongoDB インスタンスへの、アーキテクチャの置き換え。 そして、ローカルでのイベント・データの処理と、処理を完了されるための、センタライズされたサーバーへの送信。具体的には、NodeJS on Heroku + Redis と、SoftLayer 上でのプリ・プロセシング( Catalyst プログラムを参照)。

< 続きは原文で ど~ぞ >

ーーーーー

image.NET と NodeJS の比較ということですが、この Playtomic のアプリケーション・モデルとビジネス・モデルにおいては、NodeJS の方が適しているという事なのでしょうね。 そして、このようなアプリケーション・モデルが、ものすごい勢いで増えてきているのだと思います。さまざまなサービスが、API という形式で提供され、さらに、それらを分析するためのプラットフォームが加わっていくわけです。こういう記事を読むと、理想的なコンピューティングが具体化しているのだと感じられますね。 image

ーーーーー

<関連>

NY の地下鉄では、スマホ・チケットの試みが始まるらしい
エンタープライズ・ソーシャルって、どう捉えたら良いの?
Apigee は、テレコムのための SDN を考える
分散オブジェクト・ストアの Basho が CloudStack に参加
次世代ビジネスとして、Data as a Platform に注目する _1

Windows 8 on ARM は .NET とサヨナラしてしまうのか?

Posted in .Selected, Microsoft, Post-PC by Agile Cat on February 23, 2012

Windows on ARM: Yes, There’s a Desktop; No, It’s Not Compatible
http://wp.me/pwo1E-3WP
By
Scott M. Fulton, III / February 9, 2012
http://www.readwriteweb.com/archives/windows_on_arm_yes_theres_a_desktop_no_its_not_com.php

_ Read Write

While Apple’s preferred method for introducing customers to new products is with a gala stage event, Microsoft’s method has become the doling out of information in carefully timed lumps through corporate blog posts. Today, a rather hefty lump (almost the size of one of my analysis articles) was doled out by Microsoft’s Windows Division President Steven Sinofsky, shedding considerable new light on how Windows 8 will work on systems with ARM-based processors.

Apple は、華やかなステージ・イベントで、カスタマーに新製品を紹介するという方式を好む。 それに対する Microsoft の方式は。コーポレート・ブログのポスト介して、慎重にタイミングを見ながら、情報を小出しにするようになってきている。 そして、今日(2/9)、Microsoft の Windows  Division President である Steven Sinofsky から、 どちらかと言うと大量の情報が提供されたが(この分析記事と同じくらい)、どのようにして Windows 8 が ARM ベースのプロセッサで操作するのかという、新たな論点については、依然として光が当てられていない。

クリックで拡大 ⇒

ARM is not a processor, like Intel or AMD; rather, it’s a selection of technologies that a manufacturer licenses from an extensive ARM portfolio, that are condensed into a very small system – usually a system-on-a-chip (SoC). In Sinofsky’s blog post today, as well as in an accompanying video – a shot of which is shown above – Microsoft showed three examples of ARM-based devices from (left to right, above) Nvidia, Qualcomm, and Texas Instruments, which don’t use CPUs the way we know them, but behave enough like a PC to run Windows 8. Or at least, a new form of Windows 8 that resembles the Windows we use today only partly.

ARM は、Intel や AMD のようなプロセッサではない。 どちらかと言えば、広範囲におよぶ ARM ポートフォリオから、マニファクチャ・ライセンスとして選ばれたテクノロジーを、SoC(System-on-Chip)という小さなシステムの中に凝縮するものとなる。Sinofsky の今日ブログ・ポストだけではなく、それに伴うビデオと写真により、Microsoft は ARM デバイスのサンプルを紹介している。 左から右へと並ぶ Nvidia/Qualcomm/Texas Instruments 搭載の各デバイスは、これまでとは異なる方式で CPU をドライブするが、これまでの PC のように Windows 8 を充分にドライブする。 少なくとも、この新しい Windows 8 は、私たちが使用してきた Windows と部分的に似ている。

クリックで拡大 ⇒

“Using WOA [Windows on ARM] ‘out of the box’ will feel just like using Windows 8 on x86/64,” writes Sinofsky. “You will sign in the same way. You will start and launch apps the same way. You will use the new Windows Store the same way. You will have access to the intrinsic capabilities of Windows, from the new Start screen and Metro style apps and Internet Explorer, to peripherals, and if you wish, the Windows desktop with tools like Windows File Explorer and desktop Internet Explorer. It will have the same fast and fluid experience. In other words, we’ve designed WOA to look and feel just like you would expect. WOA enables creativity in PC design that, in combination with newly architected features of the OS, will bring to customers new, no-compromise experiences.”

「梱包を解いた WOA[ Windows on ARM ]を使うときも、x86/64 上の Windows 8 と、その感覚は変わりない。これまでと同じように Sign-in できる。 アプリケーションの起動方式も同じである。そして、これまでと同じように、新しい Windows Store を利用できる。あなたは、Start スクリーンから、Metro スタイル・アプリ、Internet Explorer、そして、周辺機器にいたるまで、Windows の本質的な機能にアクセスできる。そして、望むなら、この Windows デスクトップで、Windows File Explorer や、デスクトップ Internet Explorer といったツールを使用し、高速で滑らかなエクスペリエンスを得るだろう。 言い換えれば、まさにユーザーが期待するような、ルック&フィールのために、私たちは WOA をデザインしている。 WOA は、PC のデザインに創造力をもたらす。それは、新たにデザインされた OS の機能と組み合わされるものであり、カスタマに新しい世界を提供し、妥協しないエクスペリエンスをもたらすだろう」と、 Sinofsky は書いている。

Another World

Yet while Sinofsky made it very clear – in an abundance of words – that Microsoft will not be compromising on what it has not compromised on, today’s blog post does also reveal that those parts of WOA that don’t work “the same way” will work a different way. Most different of all will be the Desktop, which is the part of Windows 7 that used to go by the name “Windows.” As we noted when the Windows 8 Developer Preview was rolled out last September, the Desktop has become just one of two “worlds” where Windows 8 applications will run. The other is a completely new class of “Metro-style” apps, based on a new runtime called WinRT that is not downwardly-compatible. It’s not made for Windows 7, and it’s not compatible with Windows Phone 7.

いまのところ、Sinofsky は多彩な言葉づかい明確にしようとする一方で、Microsoft は諦めていないことについて、妥協することはないと思われる。つまり、今日の Sinofsky のブログ・ポストでは、WOA パートは同じようには機能せず、異なる方式で動作することが明らかにされたのだ。 最大の違いは、Windows という名前で使用する、Windows 7 のパートとしての Desktop である。 昨年の 9月に、Windows 8 Developer Preview が始まったとき、この Desktop は Windows 8 アプリケーション実行する、まさに 2つの世界のうちの 1つになったと、私たちは指摘した。 もう 1つの世界は、Metro-style アプリケーションのための、WinRT という新しいランタイム用の完全に新しいクラスだが、下位互換というわけではない。 それは、Windows 7 のために作られたものではなく、また、Windows Phone 7 と互換性を持つものでもない。

But at least with Windows 8 on PCs running Intel and AMD architectures (x86/x64), most Windows apps since version 3.0 will run on the Desktop. This will not be the case on Windows for ARM for an obvious and unavoidable reason: Applications compiled to run on these processors are not code-compatible with ARM-based platforms. And managed apps made for the .NET Framework – which as late as Spring 2011 was still being touted as the platform of Windows’ future – will not run on WOA because the .NET Framework is not code-compatible with ARM, at least not at this time. Sinofsky did not state these facts outright, though he gave plenty of information for an eight-year-old to make the correct deduction.

しかし、少なくとも、Intel と AMD のアーキテクチャ (x86/x64) 上の Windows 8 であれば、Version 3.0 以降の大半の Windows アプリケーションを、この Desktop 上で実行できるだろう。ただし、避けることのできない明白な理由により、この事実は Windows for ARM には当てはまらないだろう。 つまり、それらのプロセッサ上で実行するためににコンパイルされたアプリケーションは、ARM ベースのプラットフォームに対してコードの互換性がないからだ。 そして、未来の Windows プラットフォームとして推奨されていた、2011 Spring 以降の .NET Framework 対応のマネージド・アプリケーションも、WOA 上では実行できないだろう。なぜなら、少なくとも現時点においては、.NET Framework は ARM コード・コンパチブルではないからだ。これらの事実について、Sinofsky は完全に説明しなかったが、8歳の子供でも正しく推論できる、たくさんの情報を与えてくれた。

クリックで拡大 ⇒

“WOA does not support running, emulating, or porting existing x86/64 desktop apps,” the blog post reads. “Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64.” It also states that if a developer wishes to target WOA as a platform, all he really needs to do is write a Metro-style app using WinRT and regular OS services.

「WOA が、既存の x86/64 デスクトップ・アプリケーションを、実行/エミュレート/ポートすることはない。システムあるいは OS のサービスを、WinRT から呼び出すコードだけがアプリケーションの中で使用され、また、Windows Store を介して WOA と x86/64 の双方にディストリビュートされる」と、Sinofsky のブログ・ポストからは読み取れる。さらに、デベロッパーが WOA をターゲット・プラットフォームにするなら、そこで必要となる全ての事柄は、WinRT もしくは通常の OS サービスを用いて、Metro-Style のアプリケーションを書くことだ、とも述べている。

Another Office

So what is the Desktop for in WOA? Why is it there if it can’t run a great majority of the Windows apps we’ve come to know? Sinofsky states that the WOA Desktop will run built-in versions of Word, PowerPoint, Excel, and OneNote from the new “Office 15″ (probably Office 2013). It will also run a desktop version of Internet Explorer 10 (as indicated by a blue “e” icon on the taskbar in the screenshot), as well as the Windows Explorer file manager.

そうだとすると、WOA の Desktop とは、いったい何なのだろう? これまでに認識してきたように、従来からの大量の Windows アプリケーションを、そこで実行できないなら、なんのために存在するのだろうか? Sinofsky の説明によるとでは、新規の Office 15(おそらく Office 2013)として提供される、ビルトインの Word/PowerPoint/Excel/OneNote を、WOA Desktop 実行できるようだ。さらに、Internet Explorer 10 の Desktop バージョン(スクリーン・ショットに青い[e]アイコンがある)だけではなく、Windows Explorer のファイル・マネージャーも実行できる。

imageクリックでジャンプ ⇒

The division president characterizes this degree of resemblance as “supporting the Windows Desktop experience,” adding that applications which can run on the WOA Desktop have been significantly re-architected to support ARM features such as low power consumption and multitouch. At one point, Sinofsky said, the question of how to approach the role of the Desktop for ARM architectures seems ever so faintly like a certain scene from Hamlet:

ディビジョン・プレジデントである Sinofsky は、ある程度は「Windows  Desktop エクスペリエンスのサポート」に類似する表現を用いるが、WOA Desktop 上で実行可能なアプリケーションは、低電力消費とマルチ・タッチ・パネルといった、ARM の特徴をサポートするために、アーキテクチャの大幅な再編を行なっていると、付け加えている。Desktop for ARM アーキテクチャにおける役割を、達成するためのアプローチの方式は、ハムレットの場面のように、ぼんやりしたものであるとも、Sinofsky は発言している:

“To us, giving up something useful that has little cost to customers was a compromise that we didn’t want to see in the evolution of PCs. The presence of different models is part of every platform. Whether it is to support a transition to a future programming model (such as including a virtualization or emulation solution if feasible), to support different programming models on one platform (native and web-based applications when both are popular), or to support different ways of working (command shell or GUI for different scenarios), the presence of multiple models represents a flexible solution that provides a true no-compromise experience on any platform.”

「私たちにとって、有用な何かを諦めるということは、カスタマにおける妥協という損失を伴うものであり、PC 革命において経験したくなかった出来事である。 それぞれのモデルにおけるプレゼンスは、プラットフォーム全体の一部である。 そこでは、将来のプログラミング・モデルへ向けた移行のサポートや(実現可能であれば、仮想化やエミュレーションといったソリューションを含む)、プラットフォーム上での異なるプログラミング・モデルのサポートがあるかもしれない(ネイティブと Web ベースのアプリケーションが、ともに好まれる場合)。もしくは、あらゆるプラットフォーム上で全く妥協しない、真のエクスペリエンスを提供する、複数の異なる方式での動作のサポートや(異なるシナリオのための コマンド・シェル と GUI)、マルチ・モデルによるフレキシブルなソリューションのサポートがあるかもしれない」

Which must give us pause, Sinofsky might have added.

つまり、それらが躊躇いを与えるはずだと、Sinofsky は付け加えているのかもしれない。

Another Form Factor

In a statement to ReadWriteWeb this afternoon, IDC program director for applications development software, Al Hilwa, calls WOA “separate but equal… a different OS on its own schedule, but Microsoft is doing its best to deliver it at the same time.”

今日の午後(2/9)だが、IDC の Program Director for Applications Development Software である Al Hilwa は、ReadWriteWeb へのステートメントの中で、WOA について「分離されているが同じである、独自のスケジュールを持った異なる OS を同時に提供するために、Microsoft は最善を尽くしている」と称していた。

Hilwa believes that the first WOA-based tablets will be released some time following the first Windows 8-based tablets with Intel and AMD processors, which means this class won’t be ready for back-to-school until 2013. In the meantime, he points out that AMD and Intel are feverishly working to improve the power consumption and efficiency of their CPUs.

Hilwa が確信しているのは、最初の WOA ベースのタブレットは、Intel と AMD のプロセッサを搭載した Windows 8 に続くかたちでリリースされという点である。 つまり、2013 年までは、新調されないということだ。 その一方で、AMD と Intel が、CPU の消費電力と効率を改善するために、必死で作業を進めていることを、彼は指摘している。

Assuming PC manufacturers – especially including those who produce Intel’s Ultrabook form factor – beat ARM producers to market with competitive street prices, and that their Windows 8 PCs run all the existing software (there’s no reason to think they won’t), then they could retain a distinct advantage. Today, Microsoft’s spokesperson told RWW that the work being done by competitors to produce AMD- and Intel-based PCs represents “an equally strong commitment, new designs, and improved architecture for Windows on this hardware. Microsoft could not be more excited or supportive of the new products from Intel and AMD that will be part of Windows 8 across a full spectrum of PC form factors.”

とりわけ、Intel の Ultrabook フォーム・ファクターを生産しようとする企業を含めた、マニファクチャたちの考え方を推測すると、彼らは競争力のある販売価格で ARM デバイスを叩きたいと思っているはずだ。 そして、Windows 8 を搭載する PCが、すべての既存ソフトウェアを実行できるなら(それを望まない理由は無い)、明確なアドバンテージを維持できる。 今日、 Microsoft のスポークスマンが RWW に語ったところによると、そのための作業は、AMD と Intel をベースにした PC を生産するマニファクチャたちにより完了し、「このハードウェア上の Windows のための、強いコミットメントと、新しいデザイン、そしてアーキテクチャの改善」が示されているとのことだ。「 しかし、Intel と AMD に基づく新しいプロダクトは、PC フォーム・ファクター全体を示す Windows 8 の一部であるため、Microsoft は、それほど熱狂的にサポートできない 」とも発言していた。

Nevertheless, besides the myriad, perhaps countless, ways in which Windows for ARM is completely different from Windows, it’s just the same as the product you haven’t come to know yet because it hasn’t been released. Because many consumers choose Windows because they need to run Office, Microsoft is making sure that four key Office apps are distributed with WOA. They will use different code bases, but because they’re pre-installed, that fact won’t matter. What will matter is whether consumers feel they’re running Windows while they’re using the applications that are the very reason they use Windows.

それにもかかわらず、Windows for ARM と Windows が、完全に異なると証明する、多数と言うより無数の方式がある。そして Windows 8 は、まだリリースされていない、私たちが知ることのない、未知のプロダクトでもあるのだ。数多くのコンシューマが Windows を選択するのは、彼らが Office を動かしたいがためである。 したがって Microsoft は、4つの主要 Office アプリケーションを、WOA 上に提供すると約束している。そこでは、異なるコードベースが用いられるが、新しい Office はプリ・インストールされているため、重要な事柄にはならないではない。何が重要になるかといえば、アプリケーションを動かすために Windows を使用するコンシューマが、Windows を実行していると実感するか、しないかである。

See Also

ーーーーー

TAG indexWindows 8 は、これまでのデスクトップから、Metro デスクトップへと向けた、ブリッジ的な役割を担うのでしょうかね? そして、ここで説明されている WOA(Windows on ARM)は、Windows Phone にも搭載されていくのでしょう。 .NET から WinRT への移行という、大きな戦略の変更も見え隠れする、Windows 8 に注目したいですね。 以下の<関連>も、あわせて ご覧下さい。ーーー __AC Stamp 2

ーーーーー

<関連>

Microsoft が新たに考えるべき、post-PC 時代の Office とは
次期 Windows Phone には、Windows 8 が搭載されるらしい
iPad の OnLive Desktop から Windows 7 を操作する – これは使えそう!
Windows Phone の リーダーは、なぜ Amazon に行ってしまうのか?

 

Cloud Foundry が .NET をサポートする!

Posted in .Selected, Microsoft, PaaS, VMware by Agile Cat on December 14, 2011

.NET comes to Cloud Foundry
By
Derrick Harris – Dec. 13, 2011
http://gigaom.com/cloud/net-comes-to-cloud-foundry/

_ Gigaom

Up-and-coming Infrastructure-as-a-Service provider Tier3 has made a significant contribution to the Platform-as-a-Service world by releasing a .NET implementation of the Cloud Foundry PaaS project. Launched by VMware in April, Cloud Foundry initially supported a variety of languages and frameworks, but it was by no means representative of the entire development community. It’s getting there, however: Tier3′s .NET contribution joins ActiveState’s addition of Python and Django and AppFog’s PHP stewardship.

前途有望な IaaS プロバイダ Tier3 は、Cloud Foundry PaaS プロジェクトにおける .NET 実装をリリースすることで、この PaaS の世界に重要なコントリビューションを行うことになった。 この 4月に VMware が立ち上げた Cloud Foundry は、当初から各種のプログラミング言語とフレームワークをサポートしてきたが、すべての開発コミュニティを代表するような存在では、決して無かった。 しかし、それが変化しようとしている。 つまり、Tier3 による .NET コントリビューションが、ActiveState による Python や、DjangoAppFog による PHP というイニシアティブに、仲間入りしようとしているのだ。

imageSupport for .NET is particularly critical given the large number of enterprise programmers that rely on the framework for developing Windows applications. Presently, Microsoft Windows Azure is the most widely known PaaS offering touting strong .NET support, but it is hindered in part by the platform’s usability and in part because it’s only a public cloud. Startup AppHarbor is also pushing a .NET PaaS. Iron Foundry, Tier3′s Cloud Foundry implementation, will allow new PaaS providers to offer support for .NET applications and also will give companies wanting to build their own internal PaaS offerings the code to get started (something Apprenda already does via its SaaSGrid Apprenda Platform product).

Windows アプリケーションを開発するために、このフレームワークをに依存する多数のエンタープライズ・プログラマーを前提とすると、きわめて重要になるのが .NET のサポートである。 現時点において、.NET サポートを強力にプッシュする PaaS として広く認識されているのは、Microsoft の Windows Azure である。しかし Windows Azure は、そのプラットフォームの有用性における一部において、また、パブリック・クラウドのみをサポートするという戦略において、先手を取れずにいる。 さらには、別のスタートアップである AppHarborも、.NET PaaS をプッシュしている状況にある。Tier3 の Cloud Foundry 実装である Iron Foundry により、.NET アプリケーションをサポートする、新しい PaaS プロバイダが誕生するだろう。そして、手持ちのコードを用いて、インターナル PaaS を構築したいと考えている企業群にも、チャンスを提供するようになるだろう(すでに Apprenda プラットフォーム・プロダクトが実現しているように)。

Technically, Iron Foundry and Cloud Foundry are separate at this point, but Tier3 and VMware acknowledge they are working together to align Iron Foundry with the core Cloud Foundry code and developer tools, and I have been told that VMware will officially support .NET within Cloud Foundry at some point.

テクニカルな面においては、現時点における Iron Foundry と Cloud Foundry は、切り分けて考えるべきだろう。 しかし Tier3 と VMware は、Cloud Foundry のコア・コードと開発ツールにおいて、Iron Foundry を取り入れるための共同作業を推進していると認めている。そして VMware が、Cloud Foundry における .NET を、オフィシャルにサポートするという話を聞いたこともある。

Developers can access Iron Foundry via a Windows version of Cloud Foundry Explorer or a Visual Studio plug-in for Cloud Foundry, and the code will be available on GitHub under the Apache 2.0 license. The company is also offering a “full testbed environment” that lets programmers experiment with Iron Foundry free for 90 days, although applications are limited to one web and one database instance apiece.

デベロッパーたちは、Cloud Foundry Explorer の Windows バージョン、あるいは、Visual Studio plug-in for Cloud Foundry  を介して、Iron Foundry にアクセスできる。 そして、そのコードは、Apache 2.0 ライセンスの下で、GitHub から入手できるようになる。 さらに Tier3 は、プログラマーたちに Iron Foundry を実験させるために、90日間にわたり無償で利用できる「フル・テストベッド環境」を提供している。ただし、そこで試すことが可能な範囲としては、1つの Web アプリケーションと、1つのデータベース・インスタンスに限定される。

Tier3 is an IaaS provider by nature, and Iron Foundry is its foray into PaaS, which many consider the future of cloud computing. While Iron Foundry is still just a project like its Cloud Foundry namesake, Tier3 founder and CTO Jared Wray told me that Tier3 will have a PaaS product at some point, and Iron Foundry almost certainly will be at the core.

本質的に、Tier3 は IaaS プロバイダであり、また、Iron Foundry は PaaS へ向けた斬新な試みである。 そして、このような動きが、クラウド・コンピューティングの未来であると、多くの人々が捉えているはずだ。いまの Iron Foundry は、Cloud Foundry の名前をもらったプロジェクトに過ぎないが、Tier3 の Co-Founder であり CTO でもある Jared Wray は、ある時点で Tier3 は PaaS プロダクトを持つことになり、そのコアには Iron Foundry が座るだろうと、私に教えてくれた。

Related research and analysis from GigaOM Pro:

ーーーーー

TAG indexOS というプロダクトを第一義に考えるのか、クラウドというサービスを優先していくべきなのか、そこに Microsoft の悩みが縛り付けられている間隙を縫って、VMware が勢力を拡大しています。 以前に、[VMware を分析すると、OS を持たない 新しい Microsoft に見えてくる]という、やはり Gigaom の記事を訳したことがありますが、この謎めいたタイトルの意味が、だんだんと理解できるようになってきました。それと、この Iron Foundry ですが、u1 さんのブログで Jaco さんが、[ Windows で動くCloud FoundryベースのPaaS、その名もIron Foundry ]という、とても詳しい解説を提供しています。 そちらも、ぜひ、ご覧下さい。 ーーー __AC Stamp 2

ーーーーー

<関連>

クラウドにより OS は死に絶える(要旨)
VMware の Cloud Foundry が、デベロッパーの 人気 No.1 になる理由は?
VMworld – Maritz – レガシー・アプリケーションは、もう口紅では繕えない
VMware が目指す、クラウド OS への道とは?
コンシューマ と エンタープライズ の、IT 交差点 は存在し得るのか?

 

MySpace を殺したのは Microsoft ソフトウェア・スタックなのか? いや、それは違うだろう。

Posted in .Selected, Big Data, Facebook by Agile Cat on April 6, 2011

Did The Microsoft Stack Kill MySpace?
transparentFRIDAY, MARCH 25, 2011
http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html

_highscalability

Robert Scoble wrote a fascinating case study, MySpace’s death spiral: insiders say it’s due to bets on Los Angeles and Microsoft, where he reports MySpace insiders blame the Microsoft stack on why they lost the great social network race to Facebook. 

Robert Scoble が書いた魅力的なケース・スタディである MySpace’s death spiral: insiders say it’s due to bets on Los Angeles and Microsoft は、Facebook とのソーシャル・ネットワーク・レースで負けた理由について、Microsoft スタックに賭けたせいだと、MySpace の関係者が責任転嫁している様子をレポートしている。

Does anyone know if this is true? What’s the real story?

それが事実であると、いったい誰か分かるのだろうか? 真実は、どこにあるのだろうか?

5558830752_4c895c0b76_m

I was wondering because it doesn’t seem to track with the MySpace Architecture post that I did in 2009, where they seem happy with their choices and had stats to back up their improvements. Why this matters is it’s a fascinating model for startups to learn from. What does it really take to succeed? Is it the people or the stack? Is it the organization or the technology? Is it the process or the competition? Is the quality of the site or the love of the users? So much to consider and learn from.

私が 2009年にポストしたとき、この問題と MySpace Architecture が関係しているとは考えなかった。 さらに、MySpace は自身の選択に満足し、その改善が促進されるように見えていただけに、私は不思議だった。 この問題は、スタートアップが学ぶべき魅力的なモデルである。だからこそ重要なのだ。 本当に成功するためには、何を行うべきなのか? それは、人々に依存すべきことなのか? それとも、ソフトウェア・スタックに依存すべきことなのか? それは、組織的なことなのか? それとも、技術的なことなのか? それは、プロセスの問題なのか? それとも、コンペティションの問題なのか? それは、サイトの品質なのか? それとも、ユーザーの好みなのか? そこには、検討し学習すべき、多くの事柄がある。

Some conjectures from the article:

  1. Myspace didn’t have programming talent capable of scaling the site to compete with Facebook.
  2. Choosing the Microsoft stack made it difficult to hire people capable of competing with Facebook. .Net programmers are largely Enterprise programmers who are not constitutionally constructed to create large scalable websites at a startup pace. 
  3. Their system had ” “hundreds of hacks to make it scale that no one wants to touch,” which hamstrung their ability to really compete.
  4. Because of their infrastructure MySpace can’t change their technology to make new features work or make dramatically new experiences.
  5. Firing a lot of people nose dived morale and made hiring tough. (duh)
  6. Los Angeles doesn’t have startup talent capable of producing a scalable social network system.
  7. Facebooks’ choice of the LAMP stack allowed them to hire quicker and find people who knew how to scale.

この記事から、いくつかの事柄が推測できる:

  1. Myspace には、Facebook と競合するために、自身のサイトをスケールしていくだけの、プログラミングに関する能力が備わっていなかった。
  2. Microsoft スタックの選択は、Facebook と競合するために必要な、人材の確保を困難にした。.Net プログラマの大半はエンタープライズ・プログラマであり、スタートアップのようなペースで、大規模でスケーラブルな Web サイトを構築していける状況にはなかった。
  3. 彼らのシステムには、誰も触りたがらないほどの、スケールアップのためのハッキングの痕跡が残されていた。それにより、彼らの競争力が削がれていった。
  4. そのインフラストラクチャにより、新しい機能やエクスペリエンスをもたらすために、MySpace はテクノロジーを変更することが出来なかった。
  5. モラルを失った大量の従業員を解雇し、扱いにくい人々を雇うはめになった。(あたりまえ)
  6. Los Angeles という土地柄は、スケーラブルなソーシャル・ネットワーク・システムを作り出すための、スタートアップ的な人材を雇用しにくい。
  7. Facebook の選択である LAMP スタックは、スケーラブルを知っている人材の確保を容易にし、それを迅速に実現する。

Some very interesting points in the comments (from the article, email, Hacker News):

注記: 原文では、ここに 30人以上からのコメントが寄れられています。 それを踏まえた上で、以下のように Todd Hoff さんはマトメています。

Some of my observations:

Todd Hoff の視点:

  • The stack isn’t the real problem. That’s almost silly. Look at Windows, .Net, etc and they are all quite capable of scaling if used correctly. Facebook started with LAMP, but along the way they changed everything about it such that it would be hard to say they were still using LAMP in the end. Twitter went through a similar phase with RoR. You can’t exist at this scale without transforming everything you touch to meet your specific needs. Facbook also uses very small teams of people, so you don’t really need great hoards of talented people. You need some talented people backed up by the right vision, support, and a management who sets them free to solve problems.

 

  • ソフトウェア・スタックに、問題の本質があるわけではない。その大半は、思慮に欠けた行為にある。 Windows を確認してみよう。それを正しく用いれば、.Net などのスタックは、充分にスケーリングを達成する。 Facebook は LAMP から開始したが、すべてを LAMP で達成することは困難であるという考え方にしたがって、すべてを途中で切り替えた。 Twitter は、RoR(Ruby on Rails)が用いているが、同じようなプロセスを通り抜けることになった。 そのスケールにおいて、特定のニーズを充たすためには、すべての必要とされる要素を変更しなければならない。 さらに、Facebook では、きわめて小規模なチームが用いられる。 したがって、本当に才能がある人々を、大量に抱え込むことが必要というわけではない。 必要なことは、正しいビジョン/サポート/マネージメントにより、何人かの才能のある人々をバックアップし、問題を解決しやすい環境を作ることである。

 

  • The question is why wasn’t the technology used correctly? The comments point to a lot of different reasons, but they all eventually get down to people. Were they bought by a management team that didn’t value technology? That seems likely if some of the development, release, and design decisions are to be believed. Core competencies seemed to be farmed out to third parties. Technoligies like SANs were brought into to solve problems instead of dealing with the problems directly. Both are deadly. Whatever makes you a success you must own completely. Maybe being an “entertainment” company rather than a technology company fosters that sort of approach. But that again would get back to ownership and management. People seem to forget that talent can’t work in a straight jacket, unless they are magicians.

 

  • そのテクノロジーが正確に使われなかった点に、問題の本質があるのだろうか?提供されたコメントは、数多くの異なるポイントを指し示すが、その大半は人的な問題に帰結している。 それらのテクノロジーは、技術を高く評価しない経営陣により導入されたのだろうか? 開発/リリース/デザインに関する判断が、信じられる場合は、それもあり得る。 また、コア・コンピテンシーが、サードパーティに外注されていたようにも思われる。 さらに、生じてくる問題をダイレクトに取り扱う代わりに、たとえば SAN のようなテクノロジーが購入され、問題を解決していった。どちらも、命取りである。 成功したいならば、すべてを把握する必要がある。 おそらく、テクノロジーの会社であるも、エンターテイメントの会社である方が、この種のアプローチを促進する。 しかし、それもオーナーシップとマネージメントの話に戻るだろう。才能を有する人々に拘束衣を着せてしまっては、彼らがマジシャンでも無いかぎり、仕事が出来ないことを、人々は忘れがちである。

 

  • The innovation question is interesting. We see companies like Facebook, Amazon, Google, and Apple constantly innovating. How important was that in MySpace’s fate? And why wasn’t innovation important to them? 

 

  • この、イノベーションの問題は興味深い。 Facebook や、Amazon、Google、Apple といった企業が、イノベーションを継続しているのを、私たちは見ている。 MySpace の運命において、どれほどにイノベーションは重要だったのだろうか? そして、彼らにとって、イノベーションが重要ではない理由は、何処にあったのだろうか?

So, what happened? More importantly, how can new startups and groups within companies avoid this fate? We see this all the time. It’s depressing for everyone involved. Shouldn’t we be past this sort of thing by now?

そして、何が起こったのだろうか? さらに重要なことは、新しいスタートアップやグループは、どのようにして、このような運命を避けるべきなのだろうか? それは、常に繰り返されることである。 それは、すべての関係者を憂うつにさせる。 これまで、この種の問題を、私たちは見過ごしてきたのではないだろうか?

ーーーーー

MySpace の凋落(Pingdom)より ⇒

読んでみて、訳してみて、自分の中にあった漠然とした疑問が、氷解したように思えます。如何に優れたプラットフォームであっても、そのフィールドに適したカルチャーを持つ、経営者/技術者により正しく利用されないことには、対象となるサービスを成功させることはできない、、、ということなのでしょう。 以下の関連リンクですが、まだ、お読みではない方には、強くお勧めしたいと思います。 面白いですよ! ーーー __AC Stamp 2

 

ーーーーー

<関連>

Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
10億人のユーザーを目指す、Twitter の 6つの戦略とは?

 

Windows Azure と インターオペラビリティ

Posted in Interoperability, Microsoft by Agile Cat on February 10, 2010

Windows Azure Platform and Interoperability
http://www.microsoft.com/windowsazure/interop/

Windows Azure

As part of Microsoft’s continued commitment to interoperability, the Windows Azure platform has been built from the ground up with interoperability in mind. As an open platform, Windows Azure offers choices to developers. It allows them to use multiples languages (.NET, PHP, Ruby, Python or Java) and development tools (Visual Studio or Eclipse) to build applications which run on Windows Azure and/or consume any of the Windows Azure platform offerings from any other cloud or on premise platform. With its standards-based and interoperable approach, the Windows Azure platform supports multiple Internet protocols including HTTP, XML, SOAP and REST —key pillars of data portability.

Microsoft におけるインターオペラビリティへの継続的なコミットメントの一部として、Windows Azure プラットフォームは徹底的にインターオペラビリティに対応するよう構築されている。 つまり、オープンなプラットフォームとして、 Windows Azure はデベロッパーに対して選択肢を提供する。 そこでは、 Windows Azure 上で実行するアプリケーションを構築するための、マルチ言語(.NET、PHP、Ruby、Python、Java)や、マルチ開発ツール(Visual Studio、Eclipse)が提供され、また、あらゆるクラウドやオンプレミスのからの、Windows Azure プラットフォームの利用も実現される。 スタンダード・ベースのインターオペラビリティに対応したアプローチにより、 Windows Azure プラットフォームは 、HTTP や、XML、SOAP、REST などの、データ・ポータビリティのカギとなるインターネット・プロトコルをサポートする。

Azure Interop

Interoperability made easier for developers

From the developer’s standpoint, interoperability creates opportunities to combine new Azure cloud-based applications with other platforms. Developers can easily combine applications living on other clouds or on-premise using services offered by the Windows Azure platform. They can also build and enhance applications using their existing skills with the Microsoft Visual Studio development environment and the .NET Framework, or with other development environments like Eclipse. Developers have the choice of several languages for building their applications, including:

デベロッパーの視点から見ると、新しい Azure クラウド・ベースのアプリケーションと、他のプラットフォームと組み合わせる機会が、インターオペラビリティによりもたらされる。Windows Azure プラットフォームが提供するサービスを用いて、他のクラウドやオンプレミスに配置されたアプリケーションとの結合を容易に実現できる。 さらに、Microsoft Visual Studio と .NET Framework に加えて、Eclipse のような他の開発環境を用いて、その構築と拡張が可能となる。 以下の開発言語を用いて、デベロッパーはアプリケーションを開発できる:

  • .NET (C# and Visual Basic), C++
  • PHP, Ruby, Python
  • Java,

In addition, interoperability with other platforms is made easier through community-based libraries:

それに加えて、他のプラットフォームとのインターオペラビリティは、以下のコミュニティ・ベースのライブラリを介して容易に実現される:

  • Plug-in for Eclipse,
  • SDKs for Java, PHP, and Ruby.

ーーーーー

このページ、いつからあったんでしょうかね? いずれにしろ、スバラシイ! ーーー A.C.

こっそりリリースされてた AppFabric SDK 1.0

Posted in Microsoft by Agile Cat on December 21, 2009

ダウンロードが開始されましたよ~~~

http://www.microsoft.com/downloads/details.aspx?FamilyID=39856a03-1490-4283-908f-c8bf0bfad8a5&displaylang=en

Windows Azure

Microsoft はオンプレミスとクラウドにおいて、大まかなところで同じように機能するツールを提供しようとしています。 それにより、エンタープライズ・プログラマーをクラウド開発に取り込もうとしているわけです。 Visual Studio 2010 と .Net 4.0 の次期バージョンの背景には、PDC 2009 の目玉としてデビューした AppFabric があり、それらのツールをエンタープライズだけではなく、クラウドにおいても同様に機能させるための、いくつかの接続を提供していきます。

AppFabric SDK DL 
その Windows Azure platform AppFabric SDK V1.0 のダウンロードが、12月19日の土曜日から、こっそりと開始されたとのことです。

ーーーーー

この情報は、http://twitter.com/louisville0919 さんから頂いたもので、ポストのタイトルも、ほとんど、そのまま、頂戴しちゃいました(笑) ーーー A.C.

<関連>
AppFabric とは?
Gartner : Ray Ozzie – Interview 0

%d bloggers like this: