MesosphereはD2IQに名称を変更しKubernetesとクラウドネイティブにフォーカス

Mesosphereは、オープンソースであるMesosプロジェクトの、商用サービスを提供するために誕生した会社だ。仮想マシン群をより効率的に実行することは、確かに賢いソリューションだったが、時は移り企業も変化する。8月5日に同社は、名前をDay2IQ(略称はD2IQ)に変更し、Mesosの登場後、数年で急速に成長したKubernetesとクラウドネイティブに焦点を当てることを発表した。

D2IQのCEOであるマイク・フェイ(Mike Fey)氏は、新しい名前は会社自身の新しいアプローチを反映していると語る。Mesosプロジェクトだけに焦点を合わせるのではなく、より多くの成熟した組織がクラウドネイティブテクノロジーを採用することを支援することに、焦点を合わせたいと考えているのだ。

「Mesosphereという名前は、いくぶん窮屈なものだと感じていました。その名前では、会社がある技術に特化しているようなメッセージを出すからです。本当は私たちは通常運用(Day Two operations)をサポートすることをコアミッションとしているのです、すなわちクラウドネイティブアプローチを、単にアーリーアダプターたちのものではなくすべてのユーザーのために役立つものにすることが目的なのです」とフェイ氏は説明した。

なお同社が引き続きMesos駆動のDC/OSソリューションのサポートを続けるという点を、フェイ氏は注意深く指摘した。しかし会社の全体的な焦点はシフトし、新しい名称がそれを表現している。「Mesosプロダクトラインはまだ順調に機能しており、他のものでは提供できないものもまだあります。なので、私たちはそれを完全に放棄してしまうわけではありません。とはいえ、私たちは Kubernetesが非常に強力なことを理解しており、それを支えるコミュニティが素晴らしいことも知っています。私たちはそのコミュニティに付加価値を加えるメンバーの一員になりたいのです」と彼は言う。

彼は、この動きはクラウドネイティブの流行に突然跳び乗ろうとしたものではない、と付け加えた。彼の会社は、DC/OS上で実行されているKubernetesプロダクトを1年以上利用しており、クラウドネイティブコミュニティに貢献している立場なのだと指摘している。

今回の動きは、単に名前と会社の目標、そしてブランドの変更だけに留まるものではなく、同社が様々な顧客、より多くの成熟企業を支援するために開発した、いくつかの新しいクラウドネイティブプロダクトも含まれている(こうした新しいプロダクトたちが新しい会社名をインスパイアしたのだ)。

まず手始めに、同社はKonvoyという名の、独自の味付けを行ったKubernetesを提供する。これは「エンタープライズ品質のKubernetesエクスペリエンス」を提供するという。同社はまた、サポートおよびトレーニングサービスを提供する。これは現在世の中に欠けているものであり、クラウドネイティブに移行したい大きな組織が必要としているものだと同社が考えているものだ。

さらに、クラウドネイティブのやり方で、大量のデータを統合できるように設計されたデータ統合レイヤーを提供する。そのために、同社はKudoベータ版を導入する。これは、Kubernetesでステートフルな運用を構築するための、オープンソースのクラウドネイティブツールだ。同社はすでに、このツールを、Kubernetesやその他のクラウドネイティブプロジェクトを管理するオープンソース組織であるCloud Native Computing Foundationに寄付することを提案している。

同社は、この分野で、IBMとRed Hatの組み合わせのような新たな強打者との厳しい競争に直面している。だが同社は、強いオープンソースの精神を保つことで、Mesosの出自を乗り越えてクラウドネイティブ世界のプレイヤーになることができると信じているのだ。それがいい賭けだったかどうかは時間が経てばわかるだろう。

関連記事:Mesosphere hauls in $125 M Series D investment

画像クレジット: Andrey Suslov / Getty Images

[原文へ]

(翻訳:sako)

UberがLinux Foundationに加盟してオープンソースツールへのコミットを強化

Uberが今日の2018 Uber Open Summitで、同社がLinux Foundationにゴールド会員として加盟し、オープンソースのツールの利用と寄与貢献にコミットしていくことを発表した。

UberのCTO Thuan PhamにとってLinux Foundationは、同社がオープンソースのプロジェクトを育(はぐく)み開発していくための場所だ。“オープンソースの技術はUberの中核的サービスの多くを、そのバックボーンとして支えている。会社の成熟とともに、これらのソリューションはますます重要になっている”、と彼はLFへの加盟を発表するブログ記事で述べている。

意外なのは同社が参加したことでなく、それまでに要した年月の長さだ。Uberはかなり前から、その中核的ツールにオープンソースを多用していることで知られていたし、同社の資料によると、これまで320あまりのオープンソースプロジェクトとリポジトリに関わり、1500名のコントリビューターが70000あまりのコミットに関わっている。

Uberのスポークスパーソンは次のように語った: “Uberは何年も前から、オープンソースによる共有的ソフトウェア開発とコミュニティのコラボレーションに有意義な投資をしてきた。その中には人気の高いオープンソースプロジェクト、分散トレーシングシステムのJaegerへのコントリビューションもある。また2017年にはLinux Foundation傘下のCloud Native Computing Foundationに加盟している”。

Linux Foundationの事務局長Jim Zemlinも、Uberの加盟を喜んでいる。声明文に曰く: “彼らの専門的な技能や知識は、これからクラウドネイティブ技術やディープラーニング、データ視覚化など今日のビジネスにとって重要な技術の、オープンなソリューションを進めて行かなければならないわれわれのプロジェクトにとって、きわめて有益である”。

Linux Foundationは数多くのオープンソースプロジェクトがその傘下にある支援組織で、Uberのような企業がオープンソースのプロジェクトをコミュニティに寄与貢献しメンテナンスしていくための、組織構造を提供している。そしてその傘の下には、Cloud Native Computing Foundation, Cloud Foundry Foundation, The Hyperledger Foundation, そしてLinuxオペレーティングシステムなどの専門的組織が並んでいる。

これらのオープンソースプロジェクトをベースとして、コントリビューターの企業やデベロッパーコミュニティが改良やフォークを重ね、自分たちのビジネスに活かしていく。Uberのような企業はこれらの技術を使って自分のバックエンドシステムを動かし、サービス本体は売らないけどオープンソースのオープン性を利用して自社の将来の要求も満たしていく。その際はコントリビューターとして貢献することになり、取るだけでなく与える側に回る。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

PrometheusモニタリングツールがCNCFの新たな‘卒業’プロジェクトとしてKubernetesに加わる

Cloud Native Computing Foundation(CNCF)はまだそれほどメジャーな名前ではないが、今急成長しているコンテナオーケストレーションツールKubernetesなど、いくつかの重要なオープンソースプロジェクトの本拠地だ。今日CNCFは、モニタリングツールPrometheusが、同団体の第二の“卒業”プロジェクトとしてKubernetesに加わったことを発表した。〔*: 卒業プロジェクト, graduated projecとは、育成涵養段階を脱して、単独・独立の“一人前の”プロジェクトとして扱われること。〕

その発表は、今週ミュンヘンで行われているPrometheusのカンファレンスPromConで行われた。CNCFのCTO兼COOのChris Aniszczykによると、卒業プロジェクトとはプロジェクトの全般的な成熟を表していて、コントリビューションやコミュニティや採用が多様になったことを意味している。

Prometheusの場合は、今すでに20名のアクティブメンテナーがおり、1000名以上のコントリビューターが13000あまりのコミットを行っている。コントリビューターの中には、DigitalOcean, Weaveworks, ShowMax, そしてUberなどがいる。

CNCFのプロジェクトはサンドボックスで始まり、インキュベーションの段階へ入り、そして最後に卒業する。卒業の条件は、CNCFのCode of Conduct(行動規範)の遵守、セキュリティ監査に合格、そしてコミュニティの統治構造が定義されていることだ。また、“コードの質とセキュリティのベストプラクティスに持続的にコミットしていること”も必要だ。

Aniszczykによると、Prometheusツールは時系列データベースにクエリー言語を結びつけたシステムで、ユーザー(主にデベロッパー)がターゲットシステムの問題を知るためにはそのクエリー言語で検索し、それに対する分析結果(アナリティクス)を得る。すでに感づいておられたと思うが、それはとくに、コンテナに適したツールだ。

Kubernetesと同様、のちにPrometheusになるプロジェクトも、ルーツはGoogleにある。Googleはコンテナを積極的に採用した初期の企業のひとつで、Kubernetesの前身であるBorgや、Prometheusの前駆システムBorgmonを開発した。Borgの仕事はコンテナのオーケストレーションを管理することで、Borgにmon(monitor)を付けたBorgmonの仕事はそのプロセスをモニタして技術者にフィードバックを提供し、コンテナの全ライフサイクルにおいて、その中で起きていることを察知させる。

ルーツはBorgmonでも、今ある姿のPrometheusは二人の元Googleエンジニアが2012年にSoundCloudで開発した。2016年5月には第二のCNCFプロジェクトとしてKubernetesに加わり、そして当然のように、第二の卒業プロジェクトになった。

その過程におけるCloud Native Computing Foundationの役割は、クラウドネイティブコンピューティングを推進することだ。どんなに違いのあるインフラストラクチャでも共通のやり方で管理できる、とするその概念は、オンプレミスとクラウドのリソース管理に伴う複雑性を大幅に軽減した。CNCFはLinux Foundationの一員であり、そのメンバーにはテクノロジー業界の大物たちが多い。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

コンテナ化アプリケーションの標準パッケージを作るHelmがKubernetesから乳離れして独立

Helmは、コンテナ化したアプリケーションのパッケージをデベロッパーが作って、そのインストールを大幅に単純化するための、オープンソースのプロジェクトだ。これまでは、人気の高いコンテナオーケストレーションツールKubernetesのサブプロジェクトだったが、今日(米国時間6/1)」からそれは、スタンドアローンのプロジェクトになる。

KubernetesとHelmはどちらも、Cloud Native Computing Foundation(CNCF)が管理するプロジェクトだ。CNCFのTechnical Oversight Committee(技術監督委員会)が今週初めに、このプロジェクトを承認した。CNCFの事務局長Dan Kohnによると、二つのプロジェクトは関連性が密なので、Helmをサブプロジェクトにすることは理にかなっていた。

“Helmの良いところは。それがKubernetesのアプリケーションであることだ。KubernetesがAPIでHelmはそのAPIにアクセスする。これをインストールするとKubernetesのAPIにもアクセスすることになり、コンテナやポッド(pod, コンテナの集まり)の操作はすべて、デベロッパーに代わってHelmがやってくれる”、とKohnは説明する。

Helmが一連の要求をまとめて面倒見てくれるから、コンテナ化アプリケーションのインストールを何度繰り返してもその一貫性/整合性は維持される。“HelmはアプリケーションをKubernetesへデプロイするときの共通のユーザーニーズをまとめて引き受け、それらの構成を再利用可能にする”、とGoogleとKubernetesの主席エンジニアBrian Grantが声明で説明している。

パッケージは“charts”(チャート)と呼ばれ、一つまたは複数のコンテナから成る。Kohnによると、たとえば、WordPressとMariaDBを単一のコンテナに収めたチャートをデプロイしたい、としよう。チャートを作ることによってそのインストールプロセスが定義され、そのクラスターではどの部分をどんな順序でインストールするかが決まる。

Kohnによると、今回Helmを単独のプログラムにしたのは、それがKubernetesのリリーススケジュールに従わない場合があるからだ。そこでスタンドアローンしておけば、Kubernetesの毎回のリリースに縛られずにすむ。

またそれによってコミュニティの利点も享受でき、コミュニティが一般的なインストールシナリオのためのチャートを作って提供できる。Helmの共同制作者でMicrosoftの主席エンジニアMatt Butcherは、声明中でこう述べている: “CNCFに参加したことによって、コミュニティの利点を享受でき、またデベロッパーのコミュニティが、ワークロードをKubernetesの上で動かすための既製のチャートの、広大なリポジトリを提供する利点もある”。

このプロジェクトのスポンサーはMicrosoftとGoogleのほかに、Codefresh, Bitnami, Ticketmaster, そしてCodecentricなどだ。プロジェクトのWebサイトによると、現在250名のデベロッパーがこのプロジェクトにコントリビューションしている。CNCFに加わったことによって、その数はさらに増えるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Kubernetesがコンテナ時代のソフトウェア産業を全面的に支配、大企業もCloud Native Computing Foundationに参集する

駅を出て徐々にスピードを増す列車のように、Cloud Native Computing Foundationは急速に強くなり、テクノロジー業界の大物たちを吸引してきた。過去1か月半だけでも、AWS, Oracle, Microsoft, VMwareとPivotalなどがこぞって参加した。

これらの企業は必ずしも毎日仲が良いわけではないが、しかしそんな中でKubernetesは業界の必須のツールへと育ち、どの企業もCNCFに参加してそのミッションをサポートすることが必要だ、と考えている。これは部分的には顧客の要望によるものであり、そして残りの部分は、Kubernetesやそのほかのクラウドネイティブ技術に自分も口出しをしたいという欲求の表れだ。

この団体はLinux Foundationの傘下にあり、最初はGoogleが開発したオープンソースのプロジェクトKubernetesもこの親団体の管理下にある。Kubernetesはコンテナ化されたプログラムのオーケストレーション部分を担う。そしてコンテナは、ソフトウェアを、以前のように大きな一枚岩的なプログラムとしてではなく、マイクロサービスと呼ばれる離散的な小片の集まりとして配布するための形式ないし方法である

過去2年ほどはDockerがコンテナの普及に大きく貢献し、コンテナ化されたプログラムを作るための共通的な方法をデベロッパーに提供してきた。そして今では、企業はこれらのコンテナ化されたアプリケーションを“クラウドネイティブ*に”動かすことを欲している…CNCFの事務局長Dan Kohnはそう語る。〔*: cloud-native, ‘クラウド生まれ’、アプリケーションの作成も実稼働もクラウド上で行われること。〕

彼の説明によると、企業がAWS, Azure, GCPのようなパブリッククラウドへ行くにせよ、あるいはオンプレミスのプライベートクラウドでアプリケーションを動かすにせよ、どちらの場合も同じ技術がベースになる。アプリケーションがどっちにあっても、Kubernetesはそれらを整合性のある形で動かし管理するためのツールを提供する。

コンテナ化されたクラウドネイティブなアプリケーションをローンチする企業にとって、Kubernetesはオーケストレーションとオペレーションのレイヤを提供し、それを軸として驚異的なほど高い生産性が実現する。だから冒頭に挙げた巨大企業ですら、そのことを認識して、今やCNCFというバスに乗り込んでくるのだ。

というわけで、すべての中心にあるものはKubernetesだが、Kohnによるとそれは、見た目ほどシンプルではない。コンテナオーケストレーションツールを採用しCNCFに参加することには、企業目的が伴っている。“全員が輪になって手を握り合い、Kumbayaを歌う、という状況ではない。同じ顧客を奪い合う競合関係もある。しかし彼らは、コンテナオーケストレーションツールをめぐって争っても一文の得にもならないことを、十分に理解している”、とKohnは語る。

Kohnによると、Kubernetesは今やコンテナオーケストレーションのデファクトスタンダードだから、企業はもはやその部分では競合せず、コンテナの管理体験を向上させるそのほかの部分のサービスで優位に立とうとしている。業界の大物たちも、コンテナのオーケストレーションは今や解決済みの問題であり、今さら車輪の再発明に取り組むのは愚かである、という認識を共有している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AWSがKubernetesのホームCloud Native Computing Foundationに参加

噂では、AmazonのクラウドコンピューティングプラットホームAWSが近く、Kubernetesベースの独自のコンテナ管理サービスをローンチする、とされていた。その噂は、今日(米国時間8/9)AWSが、KubernetesプロジェクトのオープンソースのホームであるCloud Native Computing Foundation(CNCF)に、最上位メンバーのプラチナ会員として参加したことにより、かなり具体性を帯びてきた。AWSの参加によって、MicrosoftやGoogle、IBMなどを含むメジャーなパブリッククラウドプロバイダーの全員が、この、Linux Foundationを上位団体とする現代的なクラウド管理技術の推進団体に加わったことになる。

最近の調査によると、Amazon(==AWS)はすでに、Kubernetesを用いたデプロイの大半をホストしているので、Amazonが、ある意味ではKubernetesプロジェクトの本拠地であるCNCFに加わっても、それほど意外ではない。しかも重要なのは、AWSはほかにも大量のオープンソースプロジェクトを利用しているし、また自分のプロジェクトをGitHubで頻繁に公開していることだ。また同社は2013年以来、Linux Foundationのメンバーであり、そこのCore Infrastructure Initiativeの創設メンバーだ。同社が主なコンペティターたちと違うのは、Cloud Foundry Foundationに参加していないことだ〔関連記事〕。

CNCFに関しては、Amazonは同グループのコンテナランタイムcontainerdを提供している。CNCFは今日の声明で、こう言っている: “AWSはクラウドネイティブのコミュニティで積極的な役割を果たし、containerdなどでKubernetesなどのクラウドネイティブ技術に寄与貢献している”。AWSのクラウドアーキテクチャ戦略担当VP Adrian Cockcroftが、CNCFの理事会に加わる。

Cockcroftの発表声明は、Kubernetes関連のAmazonの短期的プランを述べていないが、すでに同プラットホームへの広範な支援を提供し、この急速に拡大している分野において、競合するGoogleやMicrosoftの利益にもなっているわけだから、今後はAWS上でKubernetesをよりダイレクトにサポートしていくことは、ほぼ確実だろう。これまでAWS上でKubernetesを使うためには、サードパーティ製のツールを使う必要があった。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Cloud Native Computing Foundationが抱えるプロジェクトと会員を大幅増、最新コンテナ技術の教育/人材育成にも注力

人気続伸中のコンテナオーケストレーションサービスKubernetesや関連のオープンソースプロジェクトを管理提供するCloud Native Computing Foundation(CNCF)が、例年のデベロッパーカンファレンスを今日(米国時間3/29)から開催し、それを機に、DockerとCreOSのプロジェクト(containerdとrkt)を仲間に加えたことを発表した。

Dockerのcontainerdは同社のコンテナランタイムで、Dockerのコンテナ管理およびオーケストレーションサービスの中核的部分だが、Dockerとしては標準的なコンテナライフサイクル管理の機能を、コンテナの実行を担当するDocker Engineから切り離したかったため、ランタイムを別立てにした。しかし多くの企業ユーザーは、Dockerを使うことを通じて同時にcontainerdも使っている。DockerのPatrick Chanezonは今日からベルリンで始まったカンファレンスのキーノートで、同社がcontainerdをCNCFに寄贈することに決めたのは、その正しい世話役として中立的な機関を探していたからだ、と語った。

一方CoreOSのrkt(‘ロケット’と発音する)は、Linuxのクラスターのための同社のコンテナエンジンだ。containerdと違ってデーモンではなく単一の実行プログラムであり、Kubernetesなど、ほかのコンテナプロジェクトとの統合がねらいだ。CoreOSは最初、rktをDocker Engineの競合製品としてローンチし、同社独自のコンテナ形式を前提していた。でも今では、スタンダードに準拠したコンテナエンジンになっている。

CNCFのディレクターDan Kohnは、こう言う: “Kubernetesなどのコンテナオーケストレーションにとっては、rktのような信頼性の高い、コミュニティベースのコンテナランタイムの方が便利だ。うちのような単一の機関の下にrktのようなコンテナランタイムと、コンテナクラスターの管理システムKubernetesの両方があると、業界に堅実なエンドユーザーソリューションを提供できる。それは巨大な便益だ”。

CNCFの新しい会員も発表された。Linux Foundationが管理しているすべてのプロジェクトと同様に、CNCFの場合も会費が資金源だ。まず、Dellが大型のプラチナ会員になり、年間37万ドルを提供する。そのほか、Cisco, CoreOS, Docker, Google, Huawei, IBM, Intel, Red Hatなどもプラチナ会員だ。SUSEは年会費12万ドルのゴールド会員、HarmonyCloud, QAware, Solinea, TenxCloudはシルバー会員だ(会費は社員数により7000から50000ドル)。

Dell EMCのテクノロジー担当VP Josh Bernsteinが、今日の入会ご挨拶でこう述べた: “今日の環境では、オープンソースがアジリティの鍵だ。環境が、ソフトウェアが求める迅速な変化と進化を支えなければならないからだ。CNCFに参加することにより弊社は、変化の促進にさらに深くコミットでき、エンタープライズITの戦略の核として、ソフトウェアをオープンでアクセス性と利用性の良いものにしていける”。

なお、CNCFは今後、Kubernetes Certified Administrator Exam(Kubernetes認定管理者試験)のカリキュラムを、オープンソースのライセンスで無料提供する。このところオープンソースの世界は、いろんな認定事業がトレンドになっている。OpenStackやCloud Foundryのようなオープンソースプロジェクトも、CNCFと同様の人材枯渇を解消するために、認定事業を検討している(Cloud Foundryの認定事業については別記事あり)。それらは、企業の既存社員の教育〜レベルアップだけが目的ではなく、明確なカリキュラムに基づいた事業により、新しい人材のプールを作ることもねらいだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Googleの大規模分散システムに適した高効率のRPC実装gRPCがCloud Native Computing Foundationに寄贈された

shutterstock_268614635

Googleが今日(米国時間3/1)、同社の高性能なリモートプロシージャコール(remote procedure call, RPC)フレームワークgRPCを、Cloud Native Computing Foundation, CNCF)に寄贈する、と発表した。CNCFはすでに、Google生まれのコンテナオーケストレーションツールKubernetesやそのほかのコンテナおよびマイクロサービス関連のプロジェクトを普及させていくための、ホームになっている。gRPCはCNCFのポートフォリオの6つめのプロジェクトだ。

gRPCやApache ThriftのようなRPCフレームワークは、アプリケーションが自分と同じマシンまたはリモートのサーバーで動いている別のアプリケーションのコード(プロシージャ)を動かしたり、その結果をもらったりするための技術的枠組みだ。その点ではREST APIの仕組みにも似ているが、RPCが実際にリモートのコードを…まるでプログラミング言語が関数/ファンクションを呼び出すときのように…動かす(呼び出す、コールする)のに対して、RESTは特定のリソース(処理の結果)を得ることが主な目的だ。

grpc

GoogleはgRPCを2015年にオープンソースにした。そのとき同社は、このフレームワークを使って自分たちのマイクロサービスの多くを動かしている、と述べた。そのことは、今でも変わらない。2015年の同社の説明では、“gRPCは分散システムの構築における長年の経験がベースになっている。この新しいフレームワークを利用してデベロッパーが、現代的で帯域効率とCPU効率の良い、そしてレイテンシーの低いやり方で、複数のデータセンターにまたがる大規模な分散システムや、モバイルアプリの駆動、リアルタイム通信、IoTデバイス、そしてAPIなどを作ってほしい”、と言っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Cloud Native Computing Foundationが5つ目のホストプロジェクトとしてLinkerdを加える

shutterstock_145340113

よく知られているコンテナ管理システムKubernetesをはじめ、各種のオープンソースのコンテナオーケストレーションサービスを提供しているCloud Native Computing Foundation(CNCF)が、その5つめのサービスとしてLinkerdを加えたことを発表した(“リンカーディー”と発音する)。BuoyantでインキュベートされたLinkerdは、Kubernetes, Prometheus, OpenTracing, FluentdなどそのほかのCNCFのプロジェクトと肩を並べて、ユーザーのクラウドおよびコンテナ管理をサポートすることになる。

diagram-individual-instance

CNCFのミッションは、“現代的な分散システム環境向けに最適化され、何万もの自己治癒型マルチテナントノードへスケールできるような、新しいコンピューティングパラダイムの作成と採用促進を図る”、とされている。

そのような全体像の中でLinkerdの役割は、上記のような、現代的で、もっぱらコンテナ中心型のアプリケーションに、いわゆる“サービスメッシュ”を提供することだ。Linkerdはスタンドアロンのプロキシで、その中心的な機能は、さまざまなサービスの相互コミュニケーションを支えることだ。サービスメッシュとは、何か。

“つまり、サービスAがサービスBに直接話しかけるのではなく、サービスAはLinkerdのインスタンスを介してBに話しかける。ただしそのときでも、正常な状態なら、AはLinkerdが介在したことを知る必要がない”、とBuoyantのCEOで協同ファウンダーのWilliam Morganは語る。彼は前にTwitterにいたとき、この種の問題を体験したことがある。“そして実際には、何十、何百、何千ものLinkerdインスタンスをデプロイすることになり、それらが堅牢で順応性に富むコミュニケーションの‘メッシュ’を形成する”。誰もがすでによく知っている一種のプロキシのように(たとえばWebトラフィックを扱うNginx)、Linkerdはアプリケーションの内部的トラフィックのために、それらと同様の機能を提供するのだ。

Morganによると、現代のアプリケーションは、Webサーバー -> アプリケーション -> データベースといった少数のサービスを単純に呼び出すのではなく、おそらく10以上ものマイクロサービスを呼び出すから、そういうコミュニケーションがなお一層、重要な課題になる。“私たちの基本的な信念として、現代のアプリケーションのアーキテクチャでは、丈夫なアプリケーションの要求がイコール、丈夫なサービスコミュニケーションの要求だ、と言っても過言ではない”、とMorganは述べる。複数のマイクロサービスで成り立つアプリケーションは、サービス間のコミュニケーションが命(いのち)、というわけだ。

Linkerdは言語を特定しないメッセージングレイヤを形成するだけでなく、ロードバランシングやエラー/レイテンシ対応など、マイクロサービス群で成り立つアプリケーションの健康な応答性を維持するための、そのほかのサービスも提供する。

Buoyantはこれまで、350万ドルを調達している。中でもLinkerdは同社の旗艦的オープンソースツールだが、でもいちばん注力しているのは、企業のクラウドネイティブアプリケーション(最初からクラウド育ちのアプリケーション)の、インサイトとコントロールを提供するHeliumだ。

では、その同社がなぜ、LinkerdをCNCFに献呈したのか? Morganによるとそれは、Linkerdをもっとも有効に活用できる企業は、すでに“クラウドネイティブな環境”をITのメインにしている企業だからだ。

“また、私たちにとって本当に重要なのは、

a) 具体的な価値を提供し、コミュニティが元気で、スタンドアロンのプロダクトとして通用する(==単独で機能が完備している)オープンソースのプロジェクトがあること、と、

b) ビジネスとして利益を上げ、優秀な人材を吸引でき、ほかの企業のために重要なインフラストラクチャの問題を解決できること、

このa)とb)のバランスの取れたスタートアップであることだ。CNCFはこのような二重性に対してきわめてオープンであり、またわれわれと同様に、その両方ができる、両方を上手にできる、と信じているからだ”、とMorganは付言した。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Kubernetesがv.1.0に到達、Googleは新組織Cloud Native Computing Foundationに技術を寄贈

container_terminal

Googleが昨年の2月にローンチしたオープンソースのコンテナ管理ツールKubernetesが今日(米国時間7/21)、バージョン1.0を迎えた。このアップデートによりGoogleは、Kubernetesの一般公開を検討している。また、さらに重要なこととして、GoogleはKubernetesを、Linux Foundationの傘下に新たに作られた組織Cloud Native Computing Foundation(CNCF)に寄贈し、Kubernetesのコントロールをそちらへ委譲する。この機関のパートナーはGoogleのほかに、AT&T、Box、Cisco、Cloud Foundry Foundation、CoreOS、Cycle Computing、Docker、eBay、Goldman Sachs、Huawei、IBM、Intel、Joyent、Kismatic、Mesosphere、Red Hat、Switch SUPERNAP、Twitter、Univa、VMware、そしてWeaveworksなどだ。

2015-07-20_0956

この新しい組織のミッションは、“クラウドネイティブなアプリケーションとサービスをデプロイするための共通技術に関して、デベロッパとオペレーターのコラボレーションの便宜を図ること”だ。Linux Foundationの事務局長Jim Zemlinが、今日の発表声明の中でこう書いている。

なんだか前にも聞いたような話だ、とお思いの方も多いと思われるが、それは実は数週間前に、やはり同じような企業、DockerやGoogle、IBM、Intel、Mesosphere、VMwareなどコンテナのエコシステムを支える面々が共同で、Open Container Projectをローンチしたからだ。こちらもLinux Foundationが管理するプロジェクトだが、コンテナ技術のスタンダードを作っていくことが目的だ。CNCFと違ってこのグループにはGoogleのライバルであるMicrosoftやAmazonもおり、逆にCNCFはこの二社がいないことが、顕著に目立つ。

GoogleのシニアプロダクトマネージャCraig McLuckieによると、Kubernetesは一般公開にこぎつけたことを契機に、Googleという一私企業の手を離れて新しい家を見つけることになった。Kubernetesの開発のコントロールを手放すGoogleの基本的な動機は、McLuckieによると、“それをできるかぎり偏在的な(ユビキタス)なものにするためだ。うちとしては、誰もがクラウドを使えるようになってほしい。今うちの顧客の大半がハイブリッドクラウドのユーザだが、そういう方々にも、クラウドネイティブのコンピューティングパラダイムの利点を享受していただきたい”。

彼によると、Googleが今後もKubernetesに関してアクティブであることは変わらない。そして、Googleも新しい組織の成功を期待している。しかもGoogleは、KubernetesがコンテナのためにGoogleが作った、そのほかの社内的なツールの欠陥を克服したものに育ってほしい、と期待している。

McLuckieがとくに指摘するのは、今日のKubernetesが、ノード数が数百ぐらいの小さなクラスタで有効に利用できること。しかし今では、多くの顧客が何千というオーダーのノードを管理したいと願っていることだ。またGoogleのチームは、バッチ処理のような別の種類のワークロードをさらに効果的に統合できることを、期待している。

なお、CNCFの管理下に置かれるのは、初めてのプロダクトであるKubernetesだけではない。同団体の視野はもっと大きくて、Kubernetesの管理だけが目的ではない。むしろ、JoyentのCTO Bryan Cantrillが今日述べているように、CNCFの真のミッションは、“現代的なエラスティックなコンピューティングを構成する重要なオープンソース技術の数々を前進させること”なのだ。

CNCFの統治方式は、まだ細部の煮詰めが必要なようだ。Linux Foundationの理事長Jim Zemlinによると、この組織はサービスを有料で提供することはせず、誰もが参加できる(Linux Foundation傘下のプロジェクトのほとんどが、そうであるように)。基本的な考え方としては、重要な技術を寄与貢献したところが、今後の意思決定にも参加できるようにする。“その席に座る者が、個人の優れたデベロッパであってもかまわない”、とZemlinは述べる。“重要なのは、コアデベロッパの存在だ”。

コンテナエコシステムの一部の大型選手(Microsoft、Amazon、Pivotalなど)がまだ参加していないが、Zemlinは、はぐれ鳥たちもその多くがいずれは参加する、と信じている。“この組織をベースにして作られていく標準クラウド技術は、誰にも拒否できないものになるだろう。今参加していない人たちも、後日、考えが変わるはずだ”、と彼は語る。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa