コンテナ仮想化のDockerがAWSと提携しワークフローを改善

DockerとAWSは米国時間8月9日、DockerのComposeとDesktopの開発者ツール、およびAWSのElastic Container Service(ECS)とECS on AWS Fargateの深い統合を発表した。これまでComposeファイルを取り込んでECS上で実行するワークフローは、開発者にとって困難なことが多かったと両社は指摘している。今回両社はこのプロセスを簡素化し、ローカルで実行中のコンテナとECS上で実行中のコンテナの切り替えを容易にした。

「Dockerと協力して、コンテナ化されたアプリケーションの構築とAWSへのデプロイに関する開発者の経験を単純化できることに非常に興奮している」 と、AWSのCompute Services担当VPであるDeepak Singh(ディーパック・シン)氏は語った「これにより顧客は、コンテナ化されたアプリケーションをローカルのDocker環境からAmazon ECSに直接デプロイすることが容易になった。このようにアプリケーション開発とデプロイメントが迅速になることで、顧客はアプリケーションの独自の価値に集中することが可能になり、クラウドへデプロイする方法を考える時間を削減できる」。

なお意外なことにDockerは昨年、エンタープライズ事業をMirantisに売却し、クラウドネイティブの開発者体験にのみ注力していた。

DockerのCEOであるScott Johnston(スコット・ジョンストン)氏は今年、TechCrunchのRon Miller(ロン・ミラー)に対し、「11月には業務や経営幹部、直販モデルに重点を置いていたエンタープライズ事業を切り離し、Mirantisに売却した」と語った。「その時点で残りのビジネスに開発者を注力させることが、2013年と2014年におけるDockerの本当の目的だった」。

このパートナーシップによって解決されるワークフローの問題は、すでにかなり前から存在していたことを考えると、本日の動きは新しい提携の一例といえるだろう。

Dockerは最近Microsoft(マイクロソフト)と戦略的パートナーシップを結び、Dockerの開発者エクスペリエンスをAzureのContainer Instancesと統合したことも注目に値する。

[原文へ]

(翻訳:塚本直樹 Twitter

B2BクラウドコンピューティングサービスのMirantisがDocker Enterpriseのメジャーアプデを公開

Mirantis(ミランティス)が、昨年末にDocker(ドッカー)のEnterpriseプラットフォームビジネスを買収したのは大変な驚きだった。そのDocker自身は開発者に再び焦点を合わせている一方で、MirantisはDocker Enterpriseの名前と製品を引き継いできた。そして米国時間5月28日、MirantisはDocker Enterpriseの初のメジャーアップデートであるバージョン3.1をロールアウトした。

このアップデートの大部分は、ここ数カ月の間にコンテナエコシステムで起こっていたことと一致している。内容としては、Kubernetes 1.17 のサポートとWindows用Kubernetesのサポートの改善だ。後者は、Kubernetesコミュニティが昨年あたりからかなり熱心に取り組んできたものだ。また、プリインストールされたデバイスプラグインによる、Docker EnterpriseへのNvidia GPUの統合、Kubernetes用のIstio Ingressのサポート、Docker Engineを使ったクラスタをデプロイするための新しいコマンドラインツールも新たに追加された。

製品のアップデートに加えて、Mirantisは顧客向けに3つの新しいサポートオプションや、リモート運用管理のSLA、専任のカスタマーサクセスマネージャー、積極的な監視とアラートの提供なども発表している。サポートオプションとしては、すべてのサポートプランに対して24時間365日のサポートを受けられるなど。これによってMirantisは、マネージドサービスプロバイダーとしての性格を明確にした。

しかし、もっと興味深いのはDocker Enterprise買収がMirantis自体にどのような影響を与えたのかだ。結局のところ、この数年の間にMirantisはOpenStackプラットフォームによる上昇からレイオフに至るさまざまな出来事などのあらゆる浮き沈みを経験してきた。

「そもそもなぜこのようなことをするのか、また、ある時点で私が絶対にこれをやりたいと感じたのかというと、たとえ短期的な課題があったとしても、これがより競争力のある面白い会社を作ることになると感じたからです。そしてそれは真実でしたし、素晴らしいことでした」と私に語ったのは、MirantisのCEOで共同創業者のAdrian Ionel(エイドリアン・イオネル)氏だ。「私たちが買収以来知ったことは、まず第一に、顧客ベースは、私たち自身も含めて皆が考えていたよりも、はるかに忠実だったということです」。

イオネル氏は、少なくとも顧客の観点からすると、これは明らかに大きな変更であるために、一部のユーザーは離脱するだろうと考えていたことを認めた。「もちろん、私たちはお客様方に本当に説得力のある何かを提供するために、可能な限りのことを行いました。買収後の12月には新しいロードマップをすぐに公開して、そしてお客様方には、大々的にそれを受け入れていただきました」と彼は語る。これによってMirantisは、顧客ベースの90%以上とDocker Enterpriseの大規模ユーザーのほとんどを維持することができた。

これには少し驚かされたように見えるイオネル氏は、このことが会社が2つの「素晴らしい」四半期を迎えるのに役立ち、新型コロナウイルス(COVID-19)にもかかわらず前四半期に利益を上げることができた理由だと指摘した。

「私たちは、リスクに対する冷静な評価でこの買収に取り組みたいと考えました、多くの買収が失敗したことはよく知っていたので、それを成功させたかったのです」と彼は説明した。「私たちは決して超楽観的なアプローチでこれに取り組みたくはありませんでしたし、実際にそうしませんでした。おそらくそれが、私たちが良い意味で驚いた理由の1つなのです」。

現在の成功の理由は、企業がコンテナへの移行へさらに注力していることと、彼らが本当にDocker Enterprise プラットフォームを愛してくれているからだと強調した。愛される理由として彼が挙げたのは、インフラストラクチャの独立性、開発者向けの注力、セキュリティ機能、そして使いやすさだ。多くの大規模な顧客が求めていたことの1つは、今回のアップデートが提供する、大規模なマルチクラスター管理に対するさらに良いサポートだった。

「現在立つ場所に、私たちは1つの製品開発チームを持っています。1つの製品ロードマップを持っています。そして私たちはDocker Enterpriseの、非常に大規模な新しいリリースを行っています。すべてが完全に統合されていて、1つの営業部隊として運営され、実績を上げています。そのため、日々非常に忙しいですが、素晴らしくエキサイティングです」。

関連記事:Kubernates利用のクラウドサービス、MirantisがDocker Enterpriseを買収

画像クレジット: Jorg Greuel / Getty Images

原文へ]

(翻訳:sako)

エンタープライズ事業を売却したDockerが新たに40億円相当を調達し新CEOを任命

Dockerの多忙な一日の総仕上げとして同社は、以前からの投資家Benchmark CapitalとInsight Partnersから3500万ドルを調達したことを発表し、さらに、今年3人目のCEOとして長年同社のプロダクト担当最高責任者(Chief Product Officer, CPO)だったScott Johnston氏の任命を発表した。氏は、5月に退任したSteve Singh氏を継いだRob Bearden氏に代わり、Dockerの新CEOになる。

関連記事: Steve Singh stepping down as Docker CEO…Steve SinghがDockerのCEOを退任(未訳)

このニュースの直前にはMirantisが、Dockerのエンタープライズ事業を買収したことを発表した。そのことは控えめに言っても奇妙だが、Johnston氏によればDockerにはまだデベロッパー支援の部分で機会があるという。コンテナ化のためのエンジンとして定評のあるDockerはこれまで、適切なビジネスモデルを見いだせずに苦戦していた。

Johnston氏は声明でこう言っている: 「具体的には、クラウドサービスの拡張に資金を投じて、デベロッパーがアプリケーションの構築に用いる技術を手早く発見でき、アプリケーションをチームメイトやコミュニティと容易に共有できるようにしたい。そしてローカルでもクラウドでもKubernetesのどんなエンドポイントでもアプリケーションを円滑に動かせるようにしたい」。

前CEOのBearden氏はこう言っていた: 「既存のビジネスモデルを慎重に検討した結果、この方向(エンタープライズ事業の切り離し)を決めた。経営陣と取締役会を全面的に分析して得た結論は、Dockerには互いにまったく異なる2つの事業があるということだ。ひとつは活発なデベロッパー向け事業であり、他は成長中のエンタープライズ事業だ。両者で、プロダクトも財務モデルも大きく異なっている。このような分析結果により、会社をリストラして二つの事業を分離する決定に至った。それが顧客にとっても最良であり、Dockerの業界をリードする技術をさらに繁栄させることができるだろう」。

Crunchbaseのデータによると、今日の発表の前までに同社は2億7200万ドルあまりを調達している。そして今回はBenchmarkとInsightが3500万ドルのライフラインを投じて、オープンソースのDockerプロジェクトをベースとするビジネスに、再起の機会を与えようとしている。

関連記事: Kubernates利用のクラウドサービス、MirantisDocker Enterpriseを買収

画像クレジット: Ron Miller/TechCrunch

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

Kubernates利用のクラウドサービス、MirantisがDocker Enterpriseを買収

米国時間11月13日、Mirantis日本サイト)はDockerのエンタープライズ事業を買収したことを発表した。

Docker EnterpriseはDockerのビジネスの中心だった。この売却の結果、評判の高いユニコーンだったDockerのビジネスはいわば以前の抜け殻となった。 残されたDocker自体は今年初めに就任した新CEOの指揮で開発ワークフローを効率化させるツールに引き続き注力するという。一方、MirantisはDocker Enterpriseというブランドを存続させるため混乱が生じることないという。

今回の買収により、MirantisはDocker Enterprise Technology Platformおよび関連するすべての知財(Docker Enterprise Engine、Docker Trusted Registry、Docker Unified Control Plane、Docker CLI等)を取得した。Docker Enterpriseのすべてのクライアント、既存の契約、戦略的技術提携、パートナープログラムも継承する。Docker、MirantisはともにDockerプラットフォームのオープンソースプロダクトの開発を継続するとしている。

両社は買収価格を明らかにしていないが、最近の資金調達ラウンドにおけるDockerの会社評価額を大幅に下回ることは間違いない。Dockerの評価額がこのところ下降を続けてきたことは公然の秘密だった。コンテナ革命のリーダーとして出発したものの、GoogleがKubernetesをオープンソース化し、業界が一斉にに殺到した後は付録のような存在に落ち込んでいた。ただしエンターブライズ事業は多数の大企業をクライアントにもち、健全な運営を続けていた。

Dockerによれば、Fortune 100の3分の1、Global 500の5分の1の大企業がDocker Enterpriseを使用しているという。これはどんな基準からしても高く評価できる成果だろう。Dockerが今回中核ビジネスの売却を急いだということは、こうしたクライアントの大分はDockerのテクノロジーに見切りをつけようとしている同社が考えたことを意味するのかもしれない。

アップデート:Dockerの広報はBenchmark Capitalから3500万ドル(約38億円)の資金を調達したことも発表した。 これは以下の記事の内容に影響を与えるものではないが、Dockerの今後の方向性を考える上で参考になる。なおTechchCrunchはこの資金調達について事前に情報を入手していない。

Dockerは以下のように声明している。

「Dockerは、新しい時代に対応するため、アプリケーションの構築、共有、実行に際して開発者のワークフローの効率化を進めることに焦点を当てることで我々の出発点に戻る。我々のビジネスの重点を再調整する一環として、MirantisはDocker Enterpriseプラットフォーム事業を買収し、このことを発表した。今後我々はDocker DesktopとDocker Hubの役割を拡大することによってアプリの開発者ワークフローを助けていく。具体的には、クラウドサービスの拡大に注力し、開発者がアプリケーションを構築する際に使用するテクノロジーを容易に発見し、アプリを関連する部署、コミュニティと簡単に共有し、オンプレミスであれ、クラウドであれ、Kubernetesが稼働するエンドポイントでアプリをスムーズに実行できるようにしていく」。

一方Mirantis自身もこれまでに相当の波乱を経験している。 Mirantisは十分な資金を調達してOpenStackのディストリビューターとしてスタートしたが、現在ではKubernetesベースのオンプレミスクラウドプラットフォームと関連するアプリケーション配信をサービスの中心としている。CEOのAdrian Ionel(エイドリアン・イオネル)氏は今日の発表に先立って私の取材に答え、「この買収は我々にとって最も重要な決定となるかもしれない」と述べた。

ではMirantisはDocker Enterprise買収で正確に言って何を目指したのだろうか?イオネル氏は 「Docker Enterpriseは我々がすでに目指している方向完全に合致し、また加速するものだ。Mirantisは の方向に大きく踏み出している。目標はKubernetesとコンテナテクノロジーの利用により、 マルチレイヤーのクラウド、エッジコンピューティングとクラウドのハイブリッドを含むあらゆるユースケースに対応することだ。いついかなる場合にもデベロッパーのインフラを開発を助ける一貫したエクスペリエンスを提供する。デベロッパーやクラウド運用者に使いやすいツールをオンデマンドで提供しその負担となるフリクションを最小化する」と述べた。

現在Mirantisの社員は450人ほどだ。買収により新たに元Dockerの社員300人程度を組織に新しく統合する必要がある。Ionel氏によると、当面Dockerのマーケティング部門と営業部門は独立の存在となるという。「我々にとって最も重要なのはクライアントに混乱をもたらさないことだ。そのためチームの統合においても優れたカスタマーエクスペリエンスを維持しなければならない」という。

このことはつまり現在のDocker Enterpriseのクライアントにとっては当面大きな変化はないことを意味する。 Mirantisによれば「Kubernetesとライフサイクル管理テクノロジーの開発、統合を加速すると同時に将来はDocker Enterprise向けのマネージドサービスソリューションを提供していくという。

MirantisとDocker Enterpriseのカスタマーの一部は重複しているものの、この買収によりMirantisは新たに700社のエンターブライズをクライアントに追加することになる。

イオネル氏は「MirantisのライバルはVMware、IBM/Red Hatのような巨大企業だが、我々はクラウドネイティブであり、レガシーのテクノロジーにクライアントをしばりつけることなく、クライアントのコンピューティングをスケールさせることを可能にする」と主張した。

MirantisにとってDockerのエンターブライズ事業の買収が大きな勝利であると同時にDocker時代の終わりを告げるものであることも間違いない。Dockerでは将来に向けた戦略についてさらに発表するとしているが、我々はまだ説明を受けていない。

画像: Chantip Ditcharoen / Getty Images

原文へ

(翻訳:滑川海彦@Facebook

Dockerが新たに9200万ドルを調達

米証券取引委員会(SEC)への提出文書によれば、他のいかなる独立企業よりも現在のコンテナコンピューティング環境の創出に貢献してきたDockerが、目標1億9200万ドルのラウンドで9200万ドルを調達した。

この新しい資金調達ラウンドが示すものは、サンフランシスコを拠点とするDockerは、そのツールキットの普及度という意味では、GoogleのKubernetesとの競争に負けたかもしれないが、アプリケーション開発とプログラミングの情報技術運用モデルの、現代的なハイブリッドに移行したい企業たちのための援軍となったということだ。

現代のプログラミングにおけるコンテナの重要性を理解するためには、まずそれが何であるかを説明することが役立つだろう。簡単に言えば、それは動作のためにオペレーティングシステムを必要としない仮想アプリケーション環境である。かつては、この種の機能は、アプリケーションソフトウェアとオペレーティングシステムの両者を含む仮想マシンを使用して作成されていた。

対照的に、コンテナはより効率的だ。

それらは単にアプリケーションと、それが依存するライブラリやフレームワークなどだけを含むので、1つのホストオペレーティングシステム上に沢山のコンテナを置くことができる。サーバー上のオペレーティングシステムは、1つのホストオペレーティングシステムだけで、コンテナたちはそれと直接対話をすることができる。これによって、コンテナを小さく、オーバーヘッドも著しく低く保つことが可能になる。

関連記事:いまさら聞けないコンテナ入門

企業たちは、ソフトウェアの開発および管理方法を改善するために、急速にコンテナに移行しており、その動きはますます速くなっている。しかし、彼らは単独でそれを実現することはできず、そうした移行の手助けをするDockerのようなパートナーを必要としている。

多くの人たちが見逃している点は、Dockerは単なるコンテナオーケストレーションレイヤー(このレイヤーではKubernetes が覇権を握ったが)にとどまらず、コンテナを作成し管理するための完全なツールチェーンを提供するということである。

どんなオープンソースプロジェクトでも、テクノロジー企業たちはオープンソースプロジェクトを迅速に採用(そして適応)し、その使用方法に精通する。そうしたハイテクに精通していない大手の企業たちは、そうしたツールキットで開発されたプロジェクトを管理するために、Dockerのような企業の助けを借りることになる。

大企業顧客を相手にするテクノロジースタートアップが、より多くの利益を上げるにつれて退屈なものになるのは、自然な進化である。大企業が彼らを使い。彼らはお金を稼ぐ。誇大宣伝は終わる。もしある企業が大企業の顧客に売り込むことができれば、顧客はそのベンダーとずっと付き合ってくれるのだ。

Dockerの創業者で元最高経営責任者のSolomon Hykesは、今年初めに退社した際に、以下のように語った

…Dockerは、私たちのCEOである素晴らしいSteve Singhのリーダーシップの下、爆発的な収益性の増大と数百万人の開発者コミュニティに支えられた、エンタープライズビジネスへと静かに変容を遂げました。私たちの戦略は単純です。世界のすべての大企業は、アプリケーションとインフラストラクチャを、一気にクラウドに移行する準備をしています。高価なコードやプロセスの変更や、単一のオペレーティングシステムやクラウドへのロックインなしに、信頼性と安全性を確保しながら移行を行うソリューションが必要なのです。現在、これらの要件を満たす唯一のソリューションがDocker Enterprise Editionです。これはDockerを大きな成長の機会の中心に置くことになります。この機会を活用するには、Steveのそばに、世界最大の企業たち向けに、数十年に渡るソフトウェアの出荷とサポートをしてきた経験を持つCTOが必要です。そのため現在の私は、新しい役割を担っています:理想的なCTOを探すことを助けること、時々助言を行うこと、そして大きなビジネスの構築を続けるチームの邪魔をしないことです。株主として、私はこの役割を、この上なく嬉しく受け入れます。

今回調達した資金で、Dockerは、販売およびマーケティング担当者を増やし、2019年の公開に向けて必要な収益などの確保を始めることだろう。同社は、独立した指名取締役たちを選定した(公開に向けての窓を開こうとしている、また別の明確なサインだ)。

Dockerは既に10億ドル以上の価値を持つ「ユニコーン」である。前回Dockerが資金を調達したと言われているのは、同社が7500万ドルの目標に対して6000万ドルを調達したことを示すSECの文書を、ウォール・ストリート・ジャーナルが明らかにした2017年に遡る。その時の投資家には、AME Cloud Ventures、Benchmark、Coatue Management、Goldman Sachs、そしてGreylock Partnersが含まれていた。また当時、同社の評価額は13億ドルであった。

私たちは同社にコメントを求めている。何らかの回答が得られたときにはこの記事を更新する。

[原文へ]
(翻訳:sako)

画像クレジット: DOCKER WHALE LOGO (MODIFIED BY BRYCE DURBIN)

Dockerは複数のクラウドにまたがるコンテナの連合的管理をDocker EEで提供

2013年に急に頭角を現したDockerは、その後のコンテナの普及の中心的な勢力になった。さらにその後Kubernetesが、コンテナ化されたアプリケーションのデリバリーを制御する(オーケストレーションする)ツールとして登場したが、Dockerは、同社が追究する純粋なコンテナのデプロイと、それらツールとの間にギャップを感じていた。今サンフランシスコで行われているDockerConで同社はDocker Enterprise Editionの次のリリースを発表し、そのギャップを埋めようとしている。

Dockerのチーフプロダクトオフィサー(CPO) Scott JohnstonによるとDocker Enterprise Editionに新たに導入された連合的(federated)アプリケーション管理機能により、オペレーションは複数のクラスターを管理でき、それらのクラスターはオンプレミスでも、クラウド上でも、そして複数のクラウドプロバイダーに散在していてもよい。この連合的アプリケーション管理は、アプリケーションがどこにあってもよく、そして三大クラウドプロバイダーのマネージドKubernetesツール、Azure AKS, AWS EKS, Google GKEをサポートする。

Johnstonによると、コンテナのデプロイは問題の最初の部分にすぎない。アプリケーションをデプロイするときには、Kubernetesなどオーケストレーションツールの外にも多くの問題が存在する。“そこで、DockerフォーマットのコンテナとKubernetesやComposeのデスクリプションファイルでコンテナのポータビリティは得られるが、いったんそれらがひとつの環境へ上陸すると、その環境独自のデプロイスクリプトやセキュリティモデル、ユーザー管理などがある。だからアプリケーションがポータブルでも、それらのアプリケーションのアプリケーション管理はそうではない”、と彼は説明する。

彼によると、これによって、さまざまなデプロイメントツールが新たなレベルの複雑性を持ち込む。それらは、コンテナの使用によって排除されるはずだった複雑性だ。この問題は、複数のクラウドにデプロイするときにとくに顕著だ(ときにはオンプレミスでも)。オペレーションチームが自分たちの仕事であるロードバランシングやセキュリティ、テストなどの仕事に取り組むときは、環境によって異なることのない、一貫したやりかたで行いたい。そこでJohnstonによれば、複数の環境を一箇所で管理できる場所をDocker EEが作り出し、すべてのアプリケーションとデータとインフラストラクチャを統一的に管理するという、クラウドネイティブの目標を達成する。

この連合的アプリケーション管理に加えてDockerは、Kubernetes for Docker Enterprise Edition上のWindows Serverコンテナを発表した。Linuxコンテナのサポートは、昨年発表している

そして同社は、技術系でない社員でも、コマンドラインでなくグラフィカルな画面のガイドに従って容易にデプロイができるよう、Dockerのデプロイメントにテンプレートベースの方式を導入した。

連合的アプリケーション管理は、今年後半にベータが始まる。Windows Server Containersは、Docker Enterprise Editionの次のリリース(今年の終わりごろ)に含まれ、Templatesは、今年の終わりごろのDocker Desktop Betaで提供される。

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

Sumo Logicのアプリケーションモニタリングとリアルタイムデータ分析がコンテナをサポート

アプリケーションの状態をリアルタイムで分析するSumo Logicの長年の目標は、顧客企業のデータの理解を助けることだ。そのデータが、どこに潜んでいても。しかしコンテナの時代になると、コンテナは本質的に短命だから、その目標がさらに難しい。そこで同社は、にもかかわらず、コンテナ化されたアプリケーションでも扱えるように、プロダクトの強化を発表した。

その新しい機能は、DockerのユーザーカンファレンスDockerConで披露された。このイベントは今週、サンフランシスコで行われている。

SumoのCEO Ramin Sayerによると、コンテナの定着は、DockerとKubernetesがメインのツールとして使われるようになった12〜18か月前から始まった。その人気を見て、Sumoは自分たちもコンテナに対応したい、と考えた。“DockerとKubernetesは圧倒的にスタンダードなツールとして新旧大小あらゆるショップで、新しいアプリケーション開発や既存のオンプレミスアプリケーションのクラウドへの移行、あるいはワークロードをベンダーAからBへ容易に移行できるようにするために、利用されている”、と彼は語る。

もちろん彼は間違っていない。コンテナとKubernetesは1年半前ぐらいから大々的な離陸が始まり、デベロッパーもオペレーションもどちらも、それらの理解と採用に奮励努力してきた。

“しかしそれらの利用が標準化してきたために、その扱い方もわかりやすくなってきた。そしてコンテナの扱い方が分かってくると、コンテナ化アプリケーションのベンチマークも提供できるようになった”、とSayerは説明する。

同社はそれを、エージェントを使わずにやろうとする。アプリケーションがVMで動こうが、コンテナで動こうが、どこで動いても、Sumoはデータを捕捉して、ユーザー自身には困難だったフィードバックを届ける。

スクリーンショット提供: Sumo Logic(トリミングした)

同社はKubernetesとAmazonのElastic Container Service for Kubernetes(Amazon EKS)をネイティブでサポートする。Kubernetesのユーザーお気に入りのオープンソースのモニタリングツールPrometheusもサポートする。Sumoの目標は、顧客が問題を早く修復し、ダウンタイムを減らすことだ。

こういう新しいテクノロジーを揃える中で重要になってくるのが、顧客への周知と教育だ。“顧客にはガイドを提供し、ベストプラクティスや使い方のコツを教える。彼らがやってることだけでなく、Sumoのほかの顧客との比較も提供している”、と彼は語る。

Sumo Logicは2010年に創業され、これまでに2億3000万ドルを調達してきた(Crunchbaseによる)。最近のラウンドは、昨年6月にSapphire Venturesがリードした7000万ドルのシリーズFだ。

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

今年Kubernetesは急速に立ち上がり、活き活きとしたエコシステムを生み出した

普通の人はおそらく聞いたこともない技術だろうが、Kubernetesは今年2017年に、コンテナテクノロジーを使うITプロたちの間で、急速に人気を獲得した。Kubernetesは、運用スタッフがコンテナ群を大規模に展開および管理するための基盤を提供するオーケストレーションエンジンである。(コンテナの基礎については、 この記事を参照のこと )。

もっと分かりやすい言い方をするなら、コンテナの数が増加するにつれて、それらの起動や状態を管理するツールが必要になるということだ。コンテナというアイデア自身や、それが可能にするいわゆる「マイクロサービス」モデルが、複雑なモノリシックなアプリケーションを、はるかに小さく管理しやすいものに分解するので、必然的にコンテナの数は時間とともに増加する傾向がある。Kubernetesはこうした際の運用/管理用途に使われる事実上の標準ツールとなっている。

Kubernetesは、元々はGoogleで開発されたオープンソースプロジェクトで、現在はCloud Native Computing Foundation(CNCF)によって管理されている。昨年、AWS、オラクル、マイクロソフトなどを含むテクノロジー界の大企業たちがCNCFに名前を連ねた。もちろんKubernetesの開発に何らかの影響を与えたいという思いが、その動機の大半を占めている。

急速な成長

Kubernetesが勢いを増すにつれ、それはイノベーションとビジネスアイデアのプラットフォームになってきた(人気のあるオープンソースプロジェクトではよく見られることだ)。早期に採用を行った企業たちは、いまや新技術に移行したいものの内部に専門家がいない顧客たちを支援できるチャンスを得ている。支援企業は、このようなツールを使用することに伴う基本的な複雑さを隠すことによって、商業的な機会を創出することができる。

私たちは、Kubernetesでもこの大きな流れを見ることができている。支援企業たちはオープンソースに基づいたブロダクトの開発を始めており、それによってツールの細かな癖に精通せずとも、利用と実装が容易になるパッケージアプローチが可能になる。

利用実績がどれほど急速に伸びているかを知ってもらうために、451 Researchが行ったサーベイを紹介しよう。2015年に行われた調査では、回答企業の10%が何らかのコンテナオーケストレーションツールを使用していた(Kubernetesもしくは他の競合を含む)。ちょうど2年後に行われたフォローアップ調査では、451は、回答企業の71%がコンテナ管理のためにKubernetesを使用していることを報告している。

Googleのプロダクトマネジメント担当副社長であるSam Ramji(以前はCloud Foundry FoundationのCEOだった)は、こうしたことが一夜にして起きたような感じを受けているかもしれないが、他の多くのことと同様に、作成には長い時間を要したのだと語っている。Kubernetesの直接の前身はBorgと呼ばれるGoogleのプロジェクトである。Ramjiは、2014年にオープンソースプロジェクトとしてKubernetesをリリースする10年前から、Googleはコンテナを実運用していたのだと指摘する。

「10年近いコンテナの大規模運用の歴史をGoogleは持っていました。実験ではありません。Borgの上でGoogleのビジネスが大規模に運用されていたのです。Kubernetesはそれらのレッスンに基づいて、ゼロから構築されたものです」とRamjiは語った。

クラウドネイティブコンピューティング

Kubernetesやクラウドネイティブツールを使用する背景にある大きな要因の1つは、企業がリソースの一部をクラウドに置き、一部をオンプレミスのデータセンターに置くハイブリッド環境での運用が増えていることだ。Kubernetesのようなツールは、どこにデプロイされても一貫した方法でアプリケーションを管理できるフレームワークを提供する。

その一貫性が、人気の大きな理由の1つなのだ。IT部門が2つの異なるツール(またはツールセット)を使用して、2つの異なる場所でアプリケーションを管理することを余儀なくされた場合、やがてどのリソースが利用され、データがある瞬間にどこにあるかを把握することが難しくなるような混乱に陥る可能性がある(実際にそのようなことは起こっている)。

クラウドネイティブコンピューティングファウンデーション(CNCF)が、KubernetesファウンデーションではなくCNCFと呼ばれる理由は、Googleやその他の運営メンバーたちが、Kubernetedはクラウドネイティブストーリーの一部に過ぎないと考えているからだ。もちろんそれは「大きな一部」かもしれないが、彼らはより豊かなツールシステムを目指したいと考えている。より広範な名前を付けることで、オープンソースコミュニティ対して、クラウドネイティブのやりかたで、インフラストラクチャ管理機能を拡張するためのツールを構築するように奨励しているのだ。

採用に向かう大企業たち

このプロジェクトへの貢献者のトップ10を見ると、OpenStack、Linux、その他のオープンソースプロジェクトにまたがった、主要なテクノロジープレイヤーたちの名前を見ることができる。それらはGoogle、Red Hat、CoreOS、FathomDB、ZTE Corporation、Huawei、IBM、Microsoft、Fujitsu、そしてMirantisなどだ。

CNCFのエグゼクティブディレクター、Dan Kohnは、これらの企業は、基盤技術では協力を行いながら、高レベルのツールで競争することが、より効果的であると認識しているのだと言う。「Linuxに関するアナロジーを使うことができます。人びとはKubernetesを『クラウドのLinux』と表現しています。企業のすべてが手を携えたり、同じ顧客に対して競合しないことにしたというわけではありません。ただ、コンテナオーケストレーションそのもので競争することには、あまり価値がないと認識しているのです」。

そして、これらの企業の多くは、過去12-18ヶ月間の間に、Kubernetesや、コンテナ、そしてクラウドネイティブ関連企業を買収している。

会社名 買収企業 目的 買収日付 金額
Red Hat Codenvy コンテナ開発チームワークスペース

5/25/2017

非公開
Oracle Wercker 大規模クラウドネイティブアプリの運用と展開

4/17/2017

非公開
Microsoft Deis Kubernetes用ワークフローツール

4/10/2017

非公開
Mirantis TCP Cloud 連続更新

9/15/2016

3000万ドル
Centurylink ElasticBox マルチクラウドのアプリケーション管理

6/14/2016

2000万ドル
Apprenda Kismatic Kubernetesのサポートとツール

5/19/2016

非公開

これらのすべてが、2015年7月までにはバージョン1.0に達していなかったツールを中心に構築されたビジネスとなった(その前にもいくつかの 0.x リリースが行われている)。それ以降、採用は順調に増加している。

今年の初め、CNCFは、36社がKubernetes認定基準に合意したことを発表した。以前36社ものハイテク企業が何かに合意したのは一体何時だったろうか?彼らがこれを行った理由は、個々のメンバーは互換性がなかったり一貫していないバージョンを作成することを防ぐためだ。もしこれが満たされないならば、期待に反した振舞が起きたり、あるバージョンから他のバージョンへの移植ができなくなったりするだろう。これは一般的にはフォーク(枝分かれ)という名で知られている現象だ。組織はKubernetesの人気の高まりを認識し、可能な限り不都合が起きないようにしたいと考えている。

エコシステムの構築

Kubernetesを商用化している企業には、Google Kubernetes Engine(以前のGoogle Container Engine)を提供しているGoogle自身、Red Hat OpenShift、Pivotal Container System(正しくない略称のPKSとして知られている)、そしてCoreOS Tectonicが含まれている。AWSは、そのコンテナサービスにKubernetesサポートを追加して流れに飛び乗ったばかりだ。今年の初めには、コンテナのブームを生み出したDockerも同じ動きをみせた

写真:Googleより(クリックして拡大)

Kubernetesのコアなオープンソース版を商用化する方法を探る以外にも、ホスト管理から、セキュアなログ管理と監視に至るまで、少なくないツールが開発されている。

これらがすべて、生まれてわずか2歳のオープンソースプロジェクトの周りに、豊富なツール群を構成している。これがオープンシステムを作成したときに起きることだ。皆がそれを運用するツールアプリケーションを必要とするので、イノベーションが起こる傾向があるのだ。私たちはそれをLinuxで目撃した。同じようにHadoopとOpenStackでも目撃した。そして今やそれがKubernetesでも起きている。今年それは大きな飛躍を果たしたのだ。

[原文へ]
(翻訳:sako)

MicrosoftのAzure Container Serviceの頭字語がACSからAKSに変わった、そのココロは?

コンテナのオーケストレーションに関してはKubernetesが急速にデファクトスタンダードになりつつあり、Docker SwarmやデータセンターOS(DC/OS)を自称するMesos/Mesosphereなどは今や、なんとか自分なりのニッチを見つけようと努力している。そんな中でMicrosoftは長きにわたって、同社のマネージドAzure Container Service(ACS)のアドバンテージのひとつは複数のオーケストレーションツールをサポートすることだ、と主張してきた。しかし今日(米国時間10/24)からは、それがすこし変わるようだ。Azure Container Serviceの頭字語が、なんと、“AKS”になるのだ。

お察しのとおり、この唐突な“K”はKubernetesであり、Microsoftは明らかにそのサービスをこのオーケストレーションツールに向かわせようとしている。サービスの正式名は変わらないのに。

Azureに、マネージドなKubernetesが加わるこのAKSは、目下プレビューだ。

AKSでMicrosoftは、そのフォーカスの中心にKubernetesを置く。Azureのコンテナ対応主席PM Gabe Monroyによると、コンテナサービスは至近の6か月で300%成長し、そしてその顧客は、同社の現在のKubernetesサポートを“とても気に入っている”、という。他の類似サービスと同様にAzureも、Kubernetes環境の管理と運用をできるかぎり容易にしているのだ。

なお、AKSそのものは無料だが、コンテナを動かすためには当然、AzureのVMを有料で使わなければならない。これに対しGoogle Container Engineは、そのサービスの使用時間とクラスター数に応じて課金される。

Microsoftが強調するのは、今でもDocker EnterpriseやMesosphereのDC/OSへの関心が存続していることと、既存のACSデプロイメントエンジンのサポートは今後も続けることだ。Monroyは今日の発表声明でこう述べている: “Azureの顧客でもあるこれらの顧客のニーズに対応するために、DockerMesosphereのエンタープライズ製品の統合は弊社のAzure Marketplaceにおいて、さらに強化していく。Azure MarketplaceはACSと同様の容易なデプロイメントを提供し、またエンタープライズエディションへの容易なインプレースアップグレード(稼働時アップグレード)を提供していく。それはまた、付加価値としての商用機能と24×7のサポートを提供する”。

この春Microsoftは、KubernetesにフォーカスするコンテナプラットホームDeisを買収した。また同社は最近、オープンソースソフトウェアとしてのKubernetesの‘実家’Cloud Native Computing Foundationに加盟した。Kubernetesの共同制作者の一人Brendan Burnsは、今ではAzureのコンテナ関連サービスのトップだ。こういった最近の動きはすべて、同社がますます強力に、このオープンソースのプロジェクトを支持するようになったことの現れ、と見なさざるをえない。

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

DockerもついにKubernetesをネイティブでサポート、Swarmの併用も可能

コンテナのオーケストレーションといえば、Googleが開発したオープンソースのツールKubernetesが今や事実上のデフォルトスタンダードになってしまったようだ。だから今日Dockerが、コペンハーゲンで行われたDockerCon EuropeでKubernetesのネイティブサポートを発表したことには、誰も驚かないだろう。

同社独自のオーケストレーションツールDocker Swarmを完全に放棄したわけではないが、今回初めてKubernetesのネイティブサポートを提供したということは、今やそのユーザー数がとても多いから、コンテナ企業である以上、サポートせざるをえないのだ。ただしDockerの場合は、ユーザーがランタイムにオーケストレーションエンジンを選択できる。DockerのプロダクトマネージャーBanjot Chananaによると、毎回SwarmかKubernetesかどちらかを選べるが、コードを替える必要はない。

これまでも、DockerでKubernetesを使うことはできたが、それは必ずしも容易ではなかった。今回発表されたKubernetesのサポートにより、Docker Enterprise EditionとDocker Developer Editionのどちらのユーザーにとっても、それがずっと単純になったはずだ。

Chananaによると、Dockerのアーキテクチャのおかげで、KubernetesとDocker Swarmの併用はそれほど難しくなく、違和感もない。Dockerは顧客に、プログラムのコンテナを作るための標準的な方法を提供している。それはDevOpsモデルでは通常、デベロッパーの担当になる。

一方オペレーションの方は、コンテナのライフサイクルの間にそのデプロイとセキュリティと管理を担当し、そのためにコンテナオーケストレーションツールを使用する。最近の2年間でAWS, Oracle, Microsoft, VMwareとPivotalなどのビッグネームがこぞってKubernetesを採用し、彼らはオープンソースのKubernetesプロジェクトの拠点であるCloud Native Computing Foundationにも参加した。それによりデフォルトスタンダードとしてのKubernetesの地位が、いよいよ確定した。

これだけの企業がKubernetesバスに乗り込んでしまったからには、Dockerも顧客の要望に従わざるをえない。Dockerはこれまで、自社のオーケストレーションツールを使いながらKubernetesをサポートすることもできていたが、でも今後は、大多数のコンテナワークロードでKubernetesが選ばれることが、確実になってきた。

なお、今週のThe Informationの記事によると、GoogleはKubernetesを開発していた2014年に、Dockerをコラボレーションに誘(さそ)っている。でも当時DockerはSwarmを選び、そしてGoogleはCloud Native Computing Foundationへと向かった。今日の発表は、まさに円が閉じたようであり、これからはDockerも、(コードはホストしないけれど)Kubernetesをサポートしていくことになる。

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

インメモリデータベースのRedis Labsが$44Mを調達、データベースもスタートアップによる革新の波が

インメモリーデータベースを専業とするRedis Labsが今日(米国時間8/21)、Goldman Sachsが率いるラウンドにより4400万ドルを調達したことを発表した。

Redis Labsはそのほかのオープンソースのデータベース企業と同じく、技術そのものは無料、企業のお世話は有料、というビジネスモデルだ。つまり誰でもその技術を利用して何かを作れるが、企業のデータベースの管理は十分な能力を持つわれわれにお任せください、というタイプだ。

同社が提供するデータベースは、サーバーのメモリ上で操作されるので速い。しかし企業ユーザーがその速さを享受できるためには、NoSQLデータベースをはじめとして、それなりの知識技能が必要だ。Redis Labsの今回の資金調達や、この前のMongoDBの非公開IPOなどを見ると、データベースのスタートアップはこのところ追い風と言えそうだ。

Redis Labsのオープンソースバージョンは誰もがローカルにホストできるが、有料の企業ユーザーにはそれをクラウドに置くオプションがある。つまり企業は、自分のリソース(計算機資源)を使わずにその技術を利用できるのだ。

このモデルで成功している例としてDockerやClouderaが挙げられる。後者は好調なIPOを達成ししたが、最近は平凡だ。前者は、Bloombergによると、13億ドルの評価額で資金調達中と言われる。

Redis Labsのこれまでの調達総額は8600万ドルになる。

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

Red HatのコンテナプラットホームOpenShiftのアップデートに外部サービスへの接続インタフェイスを導入

Red Hatが今日(米国時間8/9)、OpenShiftプラットホームの今四半期のアップデートをリリースし、社内や社外のさまざまなサービスへの接続を作る機能、Service Catalogを新たに加えた。

OpenShiftは、KubernetesDockerをベースとするPaaSで、コンテナのスタンダードとしてOpen Container Initiativeを採用している。KubernetesはGoogleで開発されたコンテナ管理プラットホーム、Dockeは広く使われているコンテナ作成プラットホームだ。

企業が仮想マシンからコンテナへ移行していくに伴い、OpenShiftのようなコンテナデプロイプラットホームのニーズがますます高まっている。そして今やRed Hatの顧客の中には、Deutsche Bank, Volvo, United Healthのような有名大企業もいる。

Red HatでOpenShiftを担当するプロダクトマネージャーJoe Fernandesによると、コンテナへ移行しようとする企業は最近ますます多くなり、すべての企業が何らかの形でコンテナの採用を目指していると言っても過言ではない。今では“いちいち表に書ききれないほど多い”、と彼は言う。

同社の、コンテナを利用する顧客ベースの増大とともに、大企業のIT部門の現実的なニーズを満たす、コンテナ化アプリケーションの展開プラットホームが重要になっている。とくに最近よく聞くニーズは、コンテナ化したアプリケーションが社内や外部のサービスに容易に接続できるようにしてほしい、という要望だ。

Service Catalogは、アプリケーションストアみたいな機能で、デベロッパーがそこへ行って構成済みのコネクターを見つけ、それらをサービスへのインタフェイスとして利用する。それは会社のOracleデータベースへのコネクターのこともあれば、AWSやAzureのようなパブリッククラウド、すなわち社外的サービスへのコネクターのこともある。Fernandesによると、アプリケーションストアの比喩は適切だが、今のところ正規の調達の手順は組み込まれていない。それが今後の課題だ、という。

これまでも、顧客がサービスへの接続を自作できたが、それには大量の作業を要した。ユーザーの面倒な作業を要しない、パッケージ化されたやり方でないと、時間と労力を取られすぎる。

そのために登場したService Catalogは、今回のリリースではテクニカルプレビューだ。次のリリースは、今年の終わりになる。

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

AppDynamicsのアプリケーションパフォーマンス管理サービスがDockerのコンテナに対応

今年初めに37億ドルで買収されてCiscoの傘下になったAPM(application performance management/monitoring)プレーヤーAppDynamicsが、今日(米国時間6/29)のアップデートでついに、成長が今も続いているトレンド、コンテナに対応することになった。

コンテナの問題は、なにしろその数が多いことだ。コンテナを利用すると一枚岩的なアプリケーションを小さなマイクロサービスの集合に分割できるが、そうすると、パフォーマンスの劣化等の原因を、個々のコンテナのレベルで特定しなければならない。AppDynamicsのデベロッパー対応担当Matt Chotinは、そう語る。

その問題の原因が分かっても、アプリケーションがどのようなコンテナ構造(マイクロサービス構造)でデプロイされているのか、ユーザーに聞いても分からない場合が多い。ユーザーにとってアプリケーションは動けばいいのであって、最近のAppDynamicsの調査によると、アプリケーションのユーザーとは、辛抱強くない動物である。アプリケーションの調子が悪くなって、問題が簡単に解決しないと、別のアプリケーションへ移ってしまう。

コンテナでデプロイしている場合は、パフォーマンスの問題の原因を見つける作業が非常に困難になる。“同じコンテナの複数のインスタンスをデプロイしていて、どれも同じ状態のように見えても、実際にはどれかが問題を抱えている。そんなとき、問題のコンテナをどうやって特定するのか?”、とChotinは問う。

AppDynamicsのMicroservices iQはDockerのコンテナモニタリング機能を統合して、三つの領域の情報をユーザーに提供する: 1)ベースラインメトリックス、2)コンテナメトリックス、3)その下のホストサーバーメトリックス。これらによりオペレーションのチームに、不良なコンテナを見つけるために必要な情報を与える。

同社はまた、Tier Metrics Correlatorと呼ばれるヒートマッププロダクトをリリースした。分かりづらい名前だが、これはコンテナのデプロイ状態を視覚化するツールで、問題を抱えているコンテナがすぐ分かるように表示される。

これまでさまざまなデータソースを手作業で調べていたオペレーションチームも、情報がこのように視覚化されると、相当な時間節約を達成できる。この新しいツールは要するに、たくさんの点と点をつないで像を作り、問題領域を指摘する。

Chotinによると、コンテナは数が多いから、このことがとくに重要だ。“ひとつの仮想マシンではなくて、数十から数百というたくさんのコンテナが相手だ。それらをいちいち、人間が調べることはできない。良質な視覚化がどうしても必要なんだ”、と彼は説明する。

Chotinによると、同社の周辺でもコンテナを採用する企業が増えている。そして少なくとも今は、需要はDockerに集中している。“今のコンテナ・ブームの中でうちの顧客は、圧倒的多数がDockerを使っている。でも、今後そのほかのコンテナ技術にうちのツールを対応させることは、それほど難しくない”、と彼は言う。

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

Cloud Foundryの企業採用が進む

今や、最新のソフトウェアの開発、展開、管理の方法を主導していくために、オープンソースプロジェクトがこれまで以上に大きな役割を果たすようになっている。例えばコンテナのためにはKubernetesがあり、エンタープライズ規模のインフラ運用のためにはOpenStackがあるといった具合だ。しかしここ数年の間に、Cluod Foundryという名のまた別のプラットフォームが、企業が内外のサービスを開発する方法を変えてきた。

Cloud Foundryは「サービスとしてのプラットフォーム」(PaaS)に分類されるもので、OpenStackのような「サービスとしてのインフラストラクチャ」(IaaS)とは区別される。Cloud Foundryが目指しているのは、インフラストラクチャを運用するという厄介な作業やデータベースのようなより高度なサービスを抽象化して、開発者にアプリケーションを書くための単一のプラットフォームを提供することだ。

ここでの前提は、Cloud Foundryの下にあるものを、開発者が気にする必要はないということだ。たとえばそれはオンプレミスのOpenStackクラウドかもしれないし、AWS、Google Cloud Platform、IBM Bluemix、Azureなどのパブリッククラウドかもしれない。これは、企業がアプリケーションをあるクラウドから別のクラウドに移動させる(または複数のクラウドを同時に使用する)能力を得ることを意味する。もちろんその際に、それぞれのクラウド特質に合わせてコードを改変する必要はない。Cloud Foundry FoundationのCTOであるChip Childersによれば、プロジェクトの目標は開発者を幸せに(そして生産的に)することだ。

Cloud Foundryの歴史は、当初の開発者VMwareが最初のバージョンをリリースした2011年に始まるが、2015年以降はLinux Foundationの助けを借りてプロジェクトを推進している(CFとLFとの提携が行われたのは正確には2014年12月)。その提携以前にもプロジェクトは成功していたものの、以降は真に独自の成功を収めて来ている。Fortune 500社の半分が現在、何らかの形でCloud Foundryを利用している。

企業の変化はゆっくりで、しばしば沢山の古いソフトウェアを維持しなければならないために、完全に移行した例はまだ多くないが、現在多くの企業が新しいソフトウェアの全てをCloud Foundryの上に構築している最中だ。最大手のユーザーでも、Cloud Foundryで実行しているアプリケーションはおそらく10%程度に過ぎないが、将来はこのプラトッフォームに賭けられている。

「多くの人たちがその方向に集中しています」と、Cloud Foundry財団のエグゼクティブエディタであるAbby Kearnsは語った。「多くの企業にとって、デジタルトランスフォーメーションはまだ初期段階ですが、企業の変革には通常7〜8年かかると考えられていますし、その中には更に時間がかかるものもあるでしょう」。

会社の従業員たちによる切り替えを簡単にするために、Cloud Foundryでは従業員たち自らがが選択した言語で記述することが可能だ。「Cloud Foundryの目標は、開発者の手に多くの自由を戻し、自ら開発が可能になるようにすることです。そのためには邪魔になるものを減らして行きますが、同時に十分なガードレールも与えます」。

さらに、財団は現在、そのプラットフォームとクラウドネイティブ開発パターンの両方を、一般的に利用する開発者を養成する認定プログラムを提供している。

先週、Cloud Foundryは年次開発者会議を主催したが、その講演者の顔ぶれは、Allstate and Liberty Mutualから、Ford、Home Depot、Google、Microsoft、SAP、IBM、そして独自のサービスを現在これらの企業に提供している多くのスタートアップたちに及んだ。これらの企業はすべてCloud Foundry財団のメンバーであり、Google、Microsoft、IBM、SAP、VMware、Cisco、DellEMC、Pivo​​talといった顔ぶれがこのプロジェクトを構築するためにここに集まっているのは時代を象徴している。

MicrosoftとGoogleが参加するこのラインナップに、明らかに欠落しているのはAWSクラウドのAmazonだ。彼らがすぐに参加してくるとは思わない。しかしながら、ユーザーたちはすでにAWS上にCloud Foundryをデプロイしはじめているため、プラットフォームの進化に対して意見を言うことも大きな関心事になることだろう。

Childersが強調したように、このプロジェクトはオープンソースが主眼というよりも、共同の研究開発を狙ったものである。このことがプロジェクトの哲学を他のオープンソースプロジェクトとは少し異なるものとしている(ガバナンスモデルも他のLinux Foundationプロジェクトとは少し異なる)が、最終的な結果はとても似通ったものとなっている。

将来については、Childersは、財団は明らかに製品会社ではないため、そのロードマップはメンバーやさまざまなサブプロジェクトに非常に依存していると語る。全体の取り組みに関わる商用ベンダーたちはそれぞれのロードマップを持っているので、このプロジェクトが何処へ向かうのかを正確に予測することは困難だ。

例えば、現在エンタープライズ分野で囁かれる、多くの構想段階の概念の1つとして、サーバーレスコンピューティングがある。Cloud Foundry財団は、まだこの騒ぎには跳び乗っていない。Childersはその理由を、今年は企業たちが実際にそれに手をつけようとしていないためだと述べているが、やがてプロジェクトが実際に取り組むときが来るかもしれないことは認めている。「私たちは、エコシステムにイノベーションを導入したくなる、微妙な地点にいるのです」とChilders。「それを素直に押し出して『これには意味がある、世間には沢山の選択肢があるが、私たちはリリースするプラットフォームの全体の中にこれを取り込むことが正しいことだと考えている』と言える場合もあるでしょう。しかし私たちはそれが正しい答えだと言い切る準備はできていません。[…]私たちは目新しいものに飛びつくことはしません」。

プロジェクトが積極的に検討しているのはユニカーネルだ。これは特に、DockerがUnikernel Systemsを買収したことで、ゆっくりと再浮上してきたコンセプトだ。またグループは、Cloud Foundryが、ネットワークのエッジ部分にさらに多くのコンピューティングパワーをもたらすためにどのように役割を果たすことができるかも検討している(コンピューティングをクラウドへ何年も集中してきた動きを思えば、興味深い転換だ)。

「イノベーションは難しいことです。私たちは、コミュニティとして、こうした問題に取り組んでいきます」とChilders。「実を結ぶこともあれば、そうでないときもあるでしょう」。Cloud Foundryは安定したコアを手に入れたため、この先の数ヶ月から数年の間にこうした探求の結果をより多く目にすることになるだろう。特に企業たちはただクラウドを一般的に活用するだけでなく、複数のクラウドベンダーからの最高のサービスを同時に活用できるようにしたいと願っているからだ。

[ 原文へ ]
(翻訳:Sako)

 

FEATURED IMAGE: BRYCE DURBIN

レガシーアプリケーションをコンテナ化するDockerの新サービスModernize Traditional Applications

今日(米国時間4/19)オースチンで行われたDockerConカンファレンスでDockerが、Modernize Traditional Applications(MTA) Program(従来型のアプリケーションを現代化する事業)と呼ばれるサービスを発表した。それは、現役の古いアプリケーションをDockerのコンテナに収め、Docker Enterprise Editionの管理下に置き、それらに現代的なインフラストラクチャを使わせるようにするサービスだ。

同社はアプリケーションをそのように移行させる能力に自信を持っていて、アプリケーションが一定の基準を満たしていれば良い結果を‘保証する’とまで言っている。

Dockerがこのツールを作っていた最近の半年間で気づいたのは、顧客たちがコンテナ化をやりたくてうずうずしていることだ。彼らは必ずしも、マイクロサービスに全面的に移行できるほどのスキルや意志は持っていないが、コンテナ化がもたらす数々のメリット…ポータビリティ、効率、セキュリティなど…をいつまでも指をくわえて見ていたくはない。DockerのCOO Scott Johnstonはそう説明する。

“アプリケーションを本格的なマイクロサービスのプロジェクトに移行しなくても、弊社の技術で既存のアプリケーションをコンテナに入れられることに、彼らは喜んでいる”、と彼は語る。

これまでのアプリケーションは、全体が一つの一枚岩のようなものとして配布されていた。しかしコンテナ化のキモであるところのマイクロサービスアーキテクチャでは、アプリケーションを、マイクロサービスと呼ばれる個々の離散的なピース(小片)の集まりへとモジュール化し、それによってデプロイと管理を大幅に容易にする。そんな形の環境では、デベロッパーはプログラミングに集中し、アプリケーションのデプロイをオペレーションのチームが担当できる。これがいわゆる、DevOpsと呼ばれているやり方だ〔※1※2〕。今日発表された新しいサービスにより顧客は、マイクロサービスへの全面的な移行をしなくても、コンテナのメリットを享受できる。

そのためにDockerのチームは、Avenade, Cisco, Microsoft, HPEなどのパートナーの協力を仰ぎ、彼らのレガシーアプリケーションの一部をコンテナ環境へ移行させた。しかもこれらのベンダが抱える多くの企業顧客は、そうした方が良さそうなアプリケーションをたくさん動かしているから、Dockerの市場開拓という面からも都合がよろしい。

同社は、一定の基準を満たしているレガシーアプリケーションなら、そのコンテナ化の成功を期間限定一定料金で保証できる、と感じた。この一見大胆な約束は、このサービスのベータ期間に得た所見に基づいている。レガシーアプリケーションの中には、簡単にコンテナ化できるものもあれば、あまり良い候補とは言えないものもあった。そしてそのような体験から、保証は可能、と確信した。

“われわれとして言えるのは、エンタープライズのアプリケーションスイートは何千ものアプリケーションで構成されていて、その中には必ず、その基準を満たすものもある、ということだ。確実に、そう言えるね”、とJohnstonは語る。

彼によると、今の企業の中には、IT予算の80%近くをレガシーアプリケーションのサポートに費やしているところもある。Dockerなら、大げさなことをしなくても、それらを現代的なアーキテクチャへ移行して、サポート費用を軽減できる。しかも保証対象のアプリケーションなら、その工程は超簡単だ。

[原文へ]
(翻訳: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 App Engineは、お好みの言語で開発が可能

Googleは、完全にオーバーホールを施したApp Engineが本日(米国時間3月9日)から利用可能になったことを公表した。この発表は、サンフランシスコで今週開催されているGoogle Cloud Nextで行われた。

App Engineとは、複雑なインフラの保守の心配をすることなしに、アプリケーションのバックエンド構築を可能にする、GoogleのPaaS(platform-as-a-service)だ。

ビッグニュースは、App Engineが任意のプログラミング言語をサポートするようになったということだ。これにより開発者は、自身が快適に使いこなせる任意の言語を用いてアプリケーションを開発することができる。Googleはこれをゲームチェンジャー(流れを大幅に変えるもの)と見做している。企業ユーザーたちをGoogle Cloud Platformへと強く誘いたい同社にとって、プラットフォームをよりオープンなものにすることは重要なテーマだ。

Googleの製品管理担当副社長であるSam Ramjiは、当初のApp Engineが完全に閉じた環境であったことを指摘した。「私たちがこれからやろうとしているのは、オープン世代のApp Engineです」とRamjiは言う。

従来のバーションでは、ランタイムに使えるライブラリに制限があり、1度アプリケーションを構築してしまうと、Googleから取り出すことは極めて困難だった。今回同社は、そのオープンであることの哲学の一環として、移動することやロックインを避けることを容易にするという姿勢を示したということだ。たとえそれがGoogle Cloud Platformからの離脱を容易にするということを意味しているとしても。

新しいApp Engineを使えば、もしGoogle Cloud Platformを離れたくなった場合には、アプリケーションのDockerイメージを取得して、必要に応じてそれをどこにでも移動することができる、とRamjiは指摘した。

まず手始めに、Java 8、Ruby、Go、Python 2/3、C#、PHP 5/7、そしてNode.jsの7種の言語をサポートするが、それ以外にも、プログラマが独自のランタイム、フレームワーク、そしてサードパーティのライブラリを持ち込むことも可能にしている。そして開発者たちが使いたいと思うツールを、面倒な管理なしに使える柔軟性をApp Engineが与えてくれる。そもそもこれこそがクラウドサービスが提供できる最大の利点だ。

そして開発者はDockerイメージとして、(バイナリの)プログラミングパッケージをApp Engineに持ち込めるようにもなる。

App Engineは、クラウドツールとしては管理が簡単なことで知られているが、Googleは、それでも全ての制御をあきらめる必要はないと指摘している。開発者たちは、カスタムデバッギングやカスタムインテグレーションを行う必要がある際には、使い慣れたツールを用いて、必要なレベルまで内部に手を入れることができるのだ。

[ 原文へ ]
(翻訳:Sako)

コンテナのデプロイをマルチプラットホーム化するDockerのEnterprise Editionで企業ユーザーのコンテナ導入を単純化

docker_whale_dockerconeu

Dockerのコンテナプラットホームのようなシステムを実装しようとすると、そのためのかなり専門的なスキルが必要になる。Dockerは、ユーザーが同社のプロダクトを使おうとするときにぶつかる複雑性を緩和するために今日(米国時間3/2)、Docker Enterprise Editionをリリースした。

このエンタープライズエディションは、DockerがサポートしているLinuxやWindowsのフレーバー(ディストリビューションやバージョン)、およびAWSやMicrosoft Azureのようなクラウドプラットホームのすべてに亙ってシームレスに使用できる、準汎用的なツールのパッケージだ。これらのツールがあれば、コンテナアプリケーションの複数のプラットホーム間の移動が、コードを書き換えることなく可能だ、とDockerは主張している。

本当にそれほど簡単なターンキーシステムのようなものなら、デベロッパーとオペレーションスタッフの双方にとってコンテナのライフサイクル管理がずっと楽になるだろう。DockerはLinuxデベロッパーのためのコンテナプラットホームとして誕生したが、これからは多様なインフラプラットホームと、企業によって異なるやり方をサポートしていくことになる。無料のCommunity Editionは継続するが、それは有料のEnterprise Editionほど多様なプラットホームをサポートしない。

screenshot-2017-03-02-08-54-22

写真提供: Docker

もちろんDockerには、今回のリリースの前にもエンタープライズプロダクトのようなものはあったけれども、それも今度のEnterprise Editionに編入されている、と、Dockerのマーケティング担当SVP David Messinaは語る。前のエンタープライズプロダクトDocker Datacenterは、今ではエンタープライズエディションの中へモジュールとしてバンドルされている。“Docker Datacenterは、これまでの有料サポートつきコンテナエンジンの基盤だった。今パッケージされているのは、前に売っていたものの進化形だが、完全に新しいプロダクトの一部でもある”、とMessinaは説明する。

同社は新パッケージのリリースと並行して、新しいリリースの番号システムとリリースサイクル(release cadence, リリースケイデンス)を発表した。まず番号は、単純な順序数ではなく、1703のようにリリースの年月を表す。今年の6月のリリースは、1706になるだろう。

またリリースサイクルは、ユーザーがジョブのタイプに応じて指定できる。たとえばコードの最新のアップデートをいつも入手したいデベロッパーなら、各月のリリースを選ぶだろう。一方、安定性を重視するオペレーションスタッフなら、四半期リリースのチャネルを契約するかもしれない。なお、四半期リリースは1年契約となる。

Enterprise Editionの課金プランは、ベーシック、スタンダード、アドバンスドの3段階になる。Docker Datacenterはスタンダードに含まれ、アドバンスドではもっと多様なエンタープライズ機能が提供される。

なお、パートナー各社のサードパーティプロダクトを提供するDocker Storeが開店した。Messinaによると、“このストアの最大のメリットは、Dockerの証明つきであること。それにより、パートナーが商業的成功をシェアできるエコシステムになっていくことだ”、という。証明つきとは、Dockerが試用結果に基づいて品質を証明しているから、ユーザーは安心して買える、という意味だ。

エンタープライズエディションとストアの二つが組み合わさると、企業顧客にとって、Dockerのプロダクトやサードパーティ製のアドオンを自社の複雑な環境へ導入することが、よりスムースでシンプルな過程になるだろう。

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

Dockerはコンテナの機密情報の管理を同社エンタープライズ製品に内蔵化、デベロッパーの仕事を楽に

docker_whale_dockerconeu

数年前には、アプリケーションをコンテナで構成しようとすると、仮想マシンの場合と違って、セキュリティ関連のいろんなトレードオフに直面しなければならなかった。コンテナの利用が企業間で予想以上に急速に普及していくに伴い、次第にこの問題を放って置けなくなり、Dockerのようなコンテナ技術を提供する企業は、セキュリティをプライオリティの上の方に置かざるをえなくなった。そしてとくにDockerの場合は、このセキュリティ重視の姿勢を業績にも反映させようとしている。

今日同社は、Docker Datacenterのためのコンテナネイティブな機密管理ソリューション(container-native secrets management solution)を提供する、と発表した。このサービスの下でデベロッパーたちは、APIや暗号の鍵、そしてパスワードなどを安全に作成し、それらを、サードパーティのサービスを使うことなくアプリケーションから利用できるようになる。

Dockerのセキュリティ担当ディレクターNathan McCauleyによると、これらの機密情報の従来的な共有方法は、ホストへ直接コピーするとか、ソースコード中にそのまま置く、というやり方だった。“しかしそんなやり方は、コンテナの場合は破滅的だ。コードはあちこちへ任意に移動していくし、まったく別のインフラストラクチャへ行ってしまうこともある”、とMcCauleyは述べる。そこで現状は、デベロッパー各自がいろんな工夫を凝らしたり、あるいはHashiCorpのVaultに代表されるようなサードパーティのサービスを使っている。

937d1e2d-bf31-4875-a19c-3604d104dd89

コンテナのオーケストレーションサービスは今やDocker以外にもいろいろあるが、McCauleyによると、それらが独自に貼り付けているようなセキュリティのソリューションも、本質的に不備なものが多い。たとえばKubernetesも、セキュリティを管理するためのツールを内蔵している

Dockerのソリューションでは、セキュリティをクラスター(Docker用語では“swarm(群れ)”)に比較的容易に付加できる。そうすると機密の共有は同じ証明を共有するTLS接続の上でのみ可能になり、またマネージャーノードに保存される場合も、暗号化されていない状態でディスクに書き込まれることはない。これらの過程のいくつかの実例を、ここで見ることができる。そしてこれらの仕組みの中心的なねらいは、デベロッパーが容易にそれらを…アプリケーションのレベルで…実装できて、アプリケーションを支えているインフラストラクチャとはいっさい無関係であることだ。

Dockerのエンタープライズマーケティング担当VP David Messinaによると、今や同社は、セキュリティをメインのセールスポイントのひとつと考えている。彼の主張では、これからの企業があえてDockerを選ぶメインの理由が、他社製品に比べてセキュリティが優れているから、になるだろう。もちろん、いろんなレガシーのソリューションに比べても、だ。“Dockerはお買い得だよ。うちはこれまでも一貫して、アジリティとポータビリティという二本の柱を重視してきた。顧客企業が他社よりもうちに魅(ひ)かれるのも、そのためだ。そしてこれからは、三本目の柱として、セキュリティが加わるね”。

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

MicrosoftがAzure Container Service Engineをオープンソース化、Kubernetesのネイティブインテグレーションも発表

Cargo Port.

オープンソースのKubernetesコンテナ管理プロジェクトは、おそらく、今日利用可能なさまざまな競合するコンテナ管理サービスの中で最も人気があるものだ。Kubernetesのオープンソース側のホスト役を果たしているCloud Native Compute Foundationは、初めてのKubernetesカンファレンスを今週主催する。当然ながら、数日の内に私たちは相当な数のコンテナ関連ニュースを目にすることになるだろう。

その筆頭はMicrosoftである。同社はそのAzure Container Service(ACS)のコアエンジンのソースコードをオープンにするだけではなく、ACSに対するKubernetesのネイティブインテグレーションに関しても、そのプレビューを公開する。加えて、MicrosoftはMesosphere’s DC/OSへの対応も続けていて、DC/OSの最新版に対するサービスもアップデートする。

「コンテナが仮想化の次の進化です、組織をこれまでよりも更にアジャイルにしてくれるのです」と、MicrosoftのCompute for Azureの責任者のCorey Sandersは、本日のアナウンスの中に書いている。「私はこれを毎日のように顧客から教えられています!一度アプリを書けば、どこへでもデプロイすることができます。開発でも、テストでも、そして本番環境でも。コンテナはどのようなハードウェアでも、どのようなクラウドでも、そしてどのような環境でも変更せずに実行することができるのです。要するに、それらはアジャイルなDevOpsに対する真にオープンでポータブルなソリューションを提供してくれるのです」。

マイクロソフトは、ユーザーに対してコンテナのオーケストレーションプラットフォーム(Docker Swarm、DC/OS、Kubernetes)の選択肢を提供する戦略を続けている。Kubernetesに関しては、Microsoftはすでに最近の2年の間、そのインフラ上で、このGoogleがインキュベートしたコンテナ管理プラットフォームをサポートしていた。「今日は、私たちはこのサポートをさらに進め、Azure Container Service上のKubernetesのプレビューリリースをアナウンスします」とSandersは書いている。「この深くネイティブなKubernetesへのサポートは、Azure上におけるコンテナオーケストレーションエンジンに対する、また別の完全なオープンソースの選択肢を提供します」。

Microsoftはまた、コンテナイメージのためのプライベートリポジトリであるAzure Container Registryのプレビュー版を、11月14日にローンチすることも発表した。既にAzureの上に各自がプライベートなDocker Registryをセットアップすることはできていたが、それは手動プロセスで、開発者にリポジトリインフラストラクチャの管理を委ねるものだった。AmazonGoogleの両者が、既にこの機能を提供していることを考えると、Microsoftが今この競争に参加してくることは驚きではない。

これに加えて、Microsoftはまた、Visual Studio、Visual Studio Team Service、およびフリーでオープンなVisual Studio Code Editorのような開発ツールから、マルチコンテナLinuxアプリケーションをデプロイするための、より沢山のツールを11月14日に提供することもアナウンスした。

[ 原文へ ]
(翻訳:Sako)