Agile Cat — in the cloud

NIST Cloud Computing Standards Roadmap ってなに? その_3

Posted in NIST by Agile Cat on April 17, 2012

第3章は、リファレンス・アーキテクチャの説明です ・・・
NIST Cloud Computing Standards Roadmap Spec. Publ. 500-291


3 Cloud Computing Reference Architecture

The NIST cloud computing definition is widely accepted and valuable in providing a clear understanding of cloud computing technologies and cloud services. The NIST cloud computing reference architecture presented in this clause is a natural extension to the NIST cloud computing definition.

NIST のクラウド・コンピューティング定義は広範囲に受け入れられ、また、クラウド・コンピューティング・テクノロジーと、クラウド・サービスに対する明確な理解を促進する上で価値がある。 この章で提示される NIST クラウド・コンピューティングのリファレンス・アーキテクチャは、NIST クラウド・コンピューティング定義をそのまま拡張したものである。

imageThe NIST cloud computing reference architecture is a generic high-level conceptual model that is a powerful tool for discussing the requirements, structures, and operations of cloud computing. The model is not tied to any specific vendor products, services, or reference implementation, nor does it define prescriptive solutions that inhibit innovation. It defines a set of actors, activities, and functions that can be used in the process of developing cloud computing architectures, and relates to a companion cloud computing taxonomy. It contains a set of views and descriptions that are the basis for discussing the characteristics, uses and standards for cloud computing.

この NIST クラウド・コンピューティングのリファレンス・アーキテクチャは、一般的にみて高レベルの概念モデルであり、クラウド・コンピューティングの要件/構造/運用を議論するためのパワフルなツールとなる。 また、このモデルは、特定ベンダーのプロダクト/サービス/リファレンス実装に結び付けられるものではなく、また、イノベーションを抑制してしまうような、規範的なソリューションを定義するものでもない。 そこで定義される、アクター/アクティビティ/ファンクションのセットは、クラウド・コンピューティング・アーキテクチャと、それに関連するクラウド・コンピューティング・タクソノミーの作成プロセスで利用できる。また、クラウド・コンピューティングのための特質/用法/標準を議論するためのベースとなる、ビューと記述のセットも含む。

The NIST cloud computing reference architecture focuses on the requirements of what cloud service provides, not on a design that defines a solution and its implementation. It is intended to facilitate the understanding of the operational intricacies in cloud computing. The reference architecture does not represent the system architecture of a specific cloud computing system; instead, it is a tool for describing, discussing, and developing the system-specific architecture using a common framework of reference.

この NIST クラウド・コンピューティングのリファレンス・アーキテクチャは、ソリューションと実装を定義するためのデザインではなく、クラウド・サービスが提供する要件にフォーカスしている。 クラウド・コンピューティングにおける運用上の複雑さについて、その理解を促進するよう意図される。このリファレンス・アーキテクチャは、特定のクラウド・コンピューティング・システムのアーキテクチャを表すものではない。それに代えて、リファレンスにおける共通フレームワークを用いて、対象システムに特定されたアーキテクチャを記述/議論/展開するための、ツールとして機能する。


TAG indexこの後ですが、NIST クラウド・コンピューティングにおける、リファレンス・アーキテクチャがサポートする項目として、以下のような説明があります。そして、1 Overview/2 Consumer/3 Provider/4 Auditor/5 Broker/6 Carrier という、いわゆるクラウド・ユースケースのアクターごとに詳細が説明されていきます。この辺りについては、以前に訳した「NIST の Cloud Architecture 概要」が参考になるかも知れません。ーーー ac-stamp-232

  1. 全体的なクラウド・コンピューティング概念的モデルのコンテキストで、各種のクラウド・サービスを例証し、理解を促進する。
  2. クラウド・サービスの理解/議論/分類/比較のために、USG 政府機関と他の消費者に対して、テクニカル・リファレンスを提供する。
  3. そして、セキュリティ/インターオペラビリティ/ポータビリティの候補となる、スタンダードとリファレンス実装を提供し分析する。



NIST Cloud Computing Standards Roadmap ってなに? その_2
NIST Cloud Computing Standards Roadmap ってなに? その_1
NIST がクラウドのための Roadmap と Architecture を発表


OpenStack Essex のコントリビューターたちに感謝! – including MIDOKURA

Posted in .Chronicle, .Selected, OpenStack by Agile Cat on April 17, 2012

Who Wrote OpenStack Essex? A Deep Dive Into Contributions
By Joe Brockmeier / April 9, 2012

_ Read Write

It’s always interesting to see who really contributes to open source projects. That’s doubly true when it comes to projects that are corporate-driven, because they provide a lot of insight into which companies are driving a project and have a stake in supporting it. Looking at the numbers for OpenStack’s Essex release, it’s clear that only a small subset of companies involved in OpenStack are driving development.

このオープンソース・プロジェクトに対して、現実にコントリビュートしてきた企業を見ていくのは、常に興味深いことである。 こうした企業がドライブするプロジェクトには、彼らが数多くの洞察を提供し、また、そのサポートにおいて利害を持つという、2つの真実がある。今回の Essex リリースに参加した人数をみれば、OpenStack に関与する企業の一部分だけが、この開発を促進してきたことが明確になる。

clip_image001Mark McLoughlin, an OpenStack contributor and Red Hat employee, took the time to come up with stats  culled from the commits and Gerrit  code reviews for Essex.

OpenStack のコントリビュータであり、また、Red Hat の従業員でもある Mark McLoughlin は、Essex に対してコミットされたコードと、Gerrit レビューから抽出された統計値の解析に時間を費やした

McLoughlin provides several different pieces of the puzzle when looking at the OpenStack picture. He’s looked at the developers who’ve had the most change sets for the release cycle, the most changed lines, and the most lines removed. He’s also looked at lines reviewed, as well as the number of developers by employer.

McLoughlin は、 OpenStack の状況を説明しながら、パズルのような、いくつかの謎も提供している。 そして、彼が注目したのは、リリース・サイクルの更新および、コードの改善と削除において、最も貢献したデベロッパーである。

It’s not a perfect picture, of course. Having the most changes doesn’t mean that the changes were important, for instance. It does give a clearer picture of what’s really going on in OpenStack development.

つまり、OpenStack の開発において、現実に起こっている事象を明らかにするだけのものである。

Developers by Employer

The first figure to consider is the number of developers contributing by company. No one should be shocked to see that Rackspace leads by a wide margin with 51 employees. To put that in perspective, Rackspace’s Stefano Maffulli identified more than 200 people and 50 companies that contributed to OpenStack in the Essex development cycle. McLoughlin’s figures say 226 developers.

最初の図は、コントリビュートしたデベロッパーの数を企業ごとに参照し、考えていくためのものである。 Rackspace が 51人の従業員を参加させ、大差でリードするのを見ても、それに驚く人はいないはずだ。 順番に考えていこう。まず、Rackspace の Stefano Maffulli は、Essex 開発サイクルにおいて OpenStack にコントリビュートしたのは、200人以上の人々と、50社の企業だと認識している。 それに対して McLoughlin は、226人のデベロッパーだとしている。

クリックで拡大 ⇒

This means that more than a fifth of the contributors to OpenStack are on Rackspace’s payroll.

それは、OpenStack へのコントリビュータの 1/5 以上が、 Rackspace からの経費により賄われていることを意味する。

HP has made a big public commitment to OpenStack, and it seems to be living up to it. HP has 19 people identified as contributors to OpenStack Essex.

HP は OpenStack に対して、膨大なパブリック・コミットメントを行なっており、期待に答えているように思われる。 HP は、OpenStack Essex において、19人がコントリビュートしたと認識している。

We told you that Red Hat was contributing heavily to OpenStack in February. But at that time it wasn’t entirely clear where Red Hat fell. Turns out, it’s third in developers, with 12 developers contributing.

2月の時点において、Red Hat が OpenStack にたしいて、大きなコントリビューションを行なっていると説明した。 しかし、その時点において、Red Hat が失速していることを、私は認識していなかった。 結局のところ、12社の デベロッパー・コンロリビューションの中で、同社は第3位となる。

After Red Hat, there’s Citrix (9), Nebula (8), Cisco Systems (6), Canonical (6), Piston Cloud (6), Dreamhost (4) and SUSE (4) in the top 10.

その後に続く Top-10 としては、Citrix (9), Nebula (8), Cisco Systems (6), Canonical (6), Piston Cloud (6), Dreamhost (4),  SUSE (4) の順となる。

The number of bodies, though, can be misleading. It may be that HP and Red Hat developers are not exclusively tasked with OpenStack, though. Some of Red Hat’s developers, for instance, are also doing work packaging OpenStack for Fedora and/or working on OpenShift. A company might only have two employees doing OpenStack work, but they may be doing it full time and/or doing some of the most difficult work.

組織ごとに数えることは、少々紛らわしくもある。しかし、HPと Red Hat のデベロッパーが、専有的に OpenStack の仕事を請け負ったというわけではないだろう。 現実に、何人かの Red Hat デベロッパーも、Fedora および OpenShift のために OpenStack をパッケージングするという作業時従事している。。 ひょっとすると、同社は OpenStack に関して、2人の従業員だけを割り当てているのかもしれない。しかし、もし そうなら、フル・タイムでの作業となり、また、最も困難な作業をこなしているのかもしれない。

Code Influence

To get a clearer picture than we have just by looking at developers, we can also see what companies are responsible for the most code changes and code reviews.


OpenStack uses Gerrit for code review, so it’s possible to see who’s reviewing and approving code. Rackspace dominates here, with 68.1% of reviews. Nebula is next with 12.6% of the reviews, Red Hat has 4.4%, HP has 3.7% and Nicira has 2.4%. When you get to the bottom of the top 10 (Piston Cloud, Canonical) you’re looking at less than 1%.

OpenStack では、コード・レビューのために Gerrit が用いられている。 したがって、コードのレビューを承認を行なってきた企業が分かるようになっている。 Rackspace によるレビューは、全体の 68.1% という圧倒的なものになる。2番手は Nebula であり、レビューの 12.6% を占めている。 そして、その後には、Red Hat の 4.4 %、HP の 3.7%、Nicira の 2.4% が続く。この Top-10 の下位グループ(Piston Cloud と Canonical)に目をやると、その比率が 1% 以下であることが分かるだろう。

クリックで拡大 ⇒

In terms of lines changed by employer, Rackspace is at the top with 46.8%. Nebula has 24.4%, Red Hat has 5.4% and Citrix has 4.0%. Midokura , a company I hadn’t heard of until doing this piece, is in fifth place. Despite Dell’s vocal support for OpenStack, the company doesn’t seem to be contributing a great deal.

コードの改善におけるライン数では、 Rackspace が 46.8% でトップとなる。 2番手の Nebula は 24.4% であり、その後に、Red Hat の 5.4%と、Citrix の 4 % が続く。 この項目を書くまで、私は Midokura を知らなかったが、同社は 5 番手のポジションにある。 (イェーイ!!!) Dell に関しては、OpenStack をサポートする掛け声は高くても、実質的なコントリビュートは行なわれていないようだ。

Change sets are a slightly different story. Rackspace still dominates, with 55.2%. Nebula has 10%, Red Hat has 7.9%, HP has 2.9% and Canonical has 2.6%.

更新の件数になると、少し異なるストーリーとなる。 ここでも、Rackspace が 55.2% でトップとなる。 続いて、Nebula が 10%、Red Hat が 7.9%、HP が 2.9%、Canonical が 2.6% と続く。

Another view we have is bugfixes, out of the Launchpad statistics. Again, Rackspace is at the top with 800, Nebula comes in with 240, Red Hat has 140, Nicira has 69 and Canonical has 50.

バグ・フィックスという視点は、Launchpad 統計から外れたものとなっている。 再び、Rackspace が 800 件でトップであり、Nebula の 240件、Red Hat の 140件、Nicira の 69件、Canonical の 50件が続く。

クリックで拡大 ⇒

In every case, the drop-off after the first five or ten companies is very significant. For example, in terms of lines changed – Canonical is the 11th company by lines changed and only claims 0.6% of changes.

すべてのケースにおいて、トップから 5社~10社に成果が集中しており、その後の落ち込みが顕著である。 たとえば、コード改編における 11番手は Canonical であり、同社が処理したライン数は、全体の 0.6% に留まっている。

What It Means

Despite the effort to paint OpenStack as a widely supported project with lots of developer commitment , it’s still Rackspace that’s doing the lion’s share of the work.

たくさんのデベロッパーがコミットする、広く支援されたプロジェクトとして、OpenStack を見せる労力にもかかわらず、その作業においては、依然として Rackspace が圧倒的な比率を占めている。

Nebula is also pulling a lot of weight in the project, though it has fewer contributors than HP or Red Hat. The top 10 corporate contributors are pulling a disproportionate share of the load in OpenStack.

さらに、このプロジェクトでは Nebula が大きな役割を担っているが、そのコントリビュータは HP や Red Hat より少ない。全体としては、Top-10 の企業コントっリビュータが、OpenStack の作業負荷において、不均衡な比率を占めている。

This isn’t abnormal for an open source project, though. If you look at Linux kernel development , you’ll see that the top contributors are doing more than the long tail of companies that are involved in kernel development.

Linux カーネルの開発に目を向けると、トップ・コントリビュータが、カーネル開発に関与する企業よりも、ロイングテールの観点から、より多くの貢献を達成していることが分かるだろう。

But the disparity is striking. No company is shouldering nearly 50% of kernel development by any measure.

しかし、OpenStack との相違は顕著である。 どんな尺度で測っても、Linux カーネルの開発において、50% 近い負荷を担っている企業はいない。

Looking at recent kernel development, you’ll see Red Hat at the top of companies contributing to the kernel. But Red Hat sits at the top of the list (after developers with no corporate affiliation), with 10.7% of the changes from the 2.6.36 kernel to the 3.2 kernel. Intel has 7.2%, Novell 4.3%, IBM 3.7% and so on – down to a long list of companies contributing tiny bits.

Linux カーネルにおける、最近の開発状況を見てみよう。 そのトップである Red Hat が、カーネルにコントリビュートしているのが分かるだろう。 しかし Red Hat は、カーネル 2.6.36 ~3.2 の間で 10.7% の変更に留まっていることが、そのリスト(after developers with no corporate affiliation)に示されている。その後には、Intel の 7.2%、Novell の 4.3%、IBM の 3.7% と続き、その長いリストの最後には、きわめて低い比率の企業が記されている。

The real contributor community outside of Rackspace doing significant development is smaller than one might think given the figures coming out of OpenStack. It looks like it’s on its way to a healthy mix, but I’m not sure it’s quite there yet.

OpenStack から得られる成果と比較して、Rackspace の外で重要な開発に従事している、実際のコントリビューター・コミュニティは小さいのかもしれない。 そして、健全に混じりあう途上にあるとは思えるのだが、その道程を走破できると信じられる道程には、まだ到達していないと、私は確信している。

See Also


TAG indexこうして、コントリビューション全体が俯瞰できることは、とても良いことですね。 そして、現時点での大きな問題点として、Rackspace への過大な異存が明らかになりました。 文中の、Linux コミュニティとの比較により、OpenStack の特殊性が強調されてしまいますが、まだ走り始めたばかりの若いコミュニティですので、長い目で見てあげたいですね。 それにしても、MIDOKURA の頑張りはスゴイです。 あまり、日本を意識してはイケナイのでしょうが、日本人として嬉しいです! ーーー ac-stamp-232



OpenStack は Essex で、どう変わったのか?
Red Hat と IBM は、OpenStack に参画するのだろうか?
CloudStack は Apache へと走るが、OpenStack に問題は生じないのか?
OpenStack デベロッパーに朗報! Sandbox とAPI Reference






%d bloggers like this: