KnativeがCNCFのプロジェクトになった

Cloud Native Computing Foundation(CNCF)は、今日の最も重要なオープンソースプロジェクトのホームであり、Kubernetesもその1つだ。米国時間3月2日、CNCFの技術監督委員会(Technical Oversight Committee)が、KnativeをCNCFのインキュベーションプロジェクトとして受け入れたことを発表した。

CNCFのCTOであるChris Aniszczyk(クリス・アニシュチェク)氏は「Knativeはクラウドネイティブのエコシステムに良質に統合された強力な技術であり、サーバーレスのコンテナを容易に動かせるようにしてくれる。このプロジェクトは当財団のオープンガバナンスモデルの下でさらに成長し、新たなコントリビューターやエンドユーザーに到達するだろう。Knativeのコミュニティと一緒に仕事をすることが楽しみであり、チームのコントリビューションを歓迎する」と述べている。

Knativeは「ケイネイティヴ」と読み、2018年にGoogleが開発したが、その後IBMやRed Hat、VMware、TriggerMesh、SAPなど業界の重鎮たちも貢献した。このプロジェクトの基本的な考え方は、Kubernetes上でサーバーレスおよびイベントドリブンのアプリケーションを容易に構築、デプロイ、そして管理できるようにすることだ。今は多くのエンタープライズがデジタルトランスフォーメーションの一環として新しいアプリケーションを開発したり、既存のアプリケーションをモダナイズするとき、まさにその方向に進んでいる。そしてKnativeは今なお極めて若いプロジェクトだが、すでにBloombergやAlibaba Cloud、IBM、VMwarenなどはプロダクションでそれを使っており、またGoogleはKnativeを使ってGoogle Cloudのサーバーレスコンピューティングプラットフォームを運用している。

関連記事
サーバーレスコンピューティングの使いどころ
サーバーレスとコンテナは両者を一緒に使うのがベストプラクティスだ

このプロジェクトは2021年11月にバージョン1.0の節目に達し、その直後にGoogleが、プロジェクトをCNCFに検討のために付託したと発表した。現在、その段階が完了したためGoogleはKnativeの商標とIPとコードをCNCFに寄贈することになる。

Knative推進委員会とDOCS-UXのリードであるCarlos Santana(カルロス・サンタナ)氏は次のように述べている。「Knative 1.0で安定に達したこのプロジェクトを、特定のベンダーに偏らないホームへ寄贈することは、プロジェクトの今後の成長とコミュニティの自己統治を可能にする次のステップです。私たちの信ずるところによれば、CNCFこそがそのベンダー不偏の団体であり、そこがKnativeを受け入れたことで今後多くの企業が採用する気になり、プロジェクトの寄与貢献や宣伝もしてくれるでしょう。また、Knativeのコミュニティが、自身が利用しているすべてのプロジェクトに限らず、このエコシステム内のその他のクラウドネイティブプロジェクトにも接近して、フィードバックと機能の善循環を確立するでしょう」。

画像クレジット:bugphai/Getty Images

原文へ

(文:Frederic Lardinois、翻訳:Hiroshi Iwatani)

楽天シンフォニーがKubernetesプラットフォーム「Robin.io」を買収

楽天通信事業プラットフォーム楽天シンフォニーは、米国時間2月28日、Robin.ioを買収したことを発表した。このスタートアップは、ストレージソリューションと複雑なネットワークアプリケーション向けに最適化されたKubernetesプラットフォームを提供している。同社の初期の顧客の1つが楽天モバイルで、楽天キャピタルがRobin.ioのシリーズCの投資ラウンドをリードした。楽天は、Robin.ioのマルチクラウドモビリティやオートメーションのためのツールを楽天シンフォニーのポートフォリオに統合することを計画している。

立ち上げ時のRobin.ioは主にストレージのソリューションがメインだったが、その後、拡張して完全な機能を持つKubernetesプラットフォームを提供するようになった。同社のマーケティングは対象が常に大手の通信事業者で、Kubernetes上の5Gサービスアプリケーションを自動化するソリューションと、またプライベートな5GとLTEのデプロイのオーケストレーションなどを提供してきた。一方、楽天シンフォニーは、まさにこれらのクラウドネイティブなオープンインフラストラクチャのデプロイとサービスが事業の主力だ。またRobin.ioが保有する70件の特許と世界中の多くのFortune 1000企業の顧客も魅力的だ。通信業界の、天国のような組み合わせだ。

Robin.ioのCEOであるPartha Seetala(パルタ・シータラ)氏は次のように述べている。「 Robin.ioが数年かけて築いてきたテクノロジーのイノベーションが今回もっと大きなキャンバスの上で、業界のクラウドネイティブへの転換のビジョンを率先していけることは、喜ばしいことです。シンプルで使いやすくハイパースケールなオートメーションを容易にデプロイできる弊社のビジョンは、その転換と非常に良好にマッチしている。Robin.ioの顧客は、Robin.ioのクラウドネイティブテクノロジーのイノベーションと、楽天シンフォニーのオープンで競合に強いインフラストラクチャのソリューションとグローバルなスケールの、両者から大きな利益を得るでしょう。これはまったくのところ私たちが迎えた極めてエキサイティングなタイミングとして、共にもっと大きなエコシステムを導入し、私どものグローバルな顧客により高い価値を提供していけるフェーズだといえます」。

買収額は双方から発表されていない。本日の前までにRobin.ioは、合計8600万ドル(約98億9000万円)のベンチャー資金を調達。楽天キャピタルの他にUSAA、Hasso Plattner Ventures、DN Capital、Clear Ventures、Raine Next-Gen Communications、そしてEmory University(エモリー大学)が投資している。

関連記事:Robin.ioがクラウドネイティブのKubernetesストレージソリューションに無料版を追加

画像クレジット:Tomohiro Ohsumi/Getty Images/Wikimedia Commons

原文へ

(文:Frederic Lardinois、翻訳:Hiroshi Iwatani)

Kubernetes利用システムのリソース支出を視覚化し管理とインサイトを与えるKubecost

ウェッブ・ブラウン氏とアジェイ・トリパシー氏(画像クレジット:Kubecost)

2021年はKubernetesの採用が爆発的に増え、このクラウドネイティブツールを今では560万ほどのデベロッパーが使っている。前年に比べ67%の増加だ。

Kubernetesはオープンソースのコンテナプロジェクトで、アプリケーションを自動化しモニターし実行するために2014年にGoogleが作ったシステムだ。

Kubernetesはクラウドネイティブのデベロッパーが最も多く使っているツールの1つで、企業が大きくなると扱いが難しくなることもあるが、しかしKubecostはそんな成長痛の一部を、Kubernetesの大きな支出をモニターし、管理し、最適化するオープンソースのツールで軽減しようとする。

同社は2019年に2人の元Google社員、Webb Brown(ウェッブ・ブラウン)氏とAjay Tripathy(アジェイ・トリパシー)氏が創業した。どちらもGoogleのインフラストラクチャーやGoogle Cloudのための、インフラストラクチャモニタリングの仕事をしていた。

「インフラモニターの分野には、コンテナへの本格的な移行に要する費用とパフォーマンスと信頼性をめぐって問題があった。それらのチームは優遇されていたが、支出の可視性は完全に犠牲にされていた。それを数百万人ぶんの給与に例えると、どれだけの額がどの部やどのチームに行くのか分からない、という状態だった」とブラウン氏はいう。

Brown氏の説明では、そういう可視性がなければ、ダウンストリームに起きることも往々にして無駄と見なされる。彼が実際に見た例では、チームが80%も過大支出をしていて、しかもプロダクトの正しいコストを誰も知らなかった。

チームに支出の安全ネットがあって、今後のショックを和らげられるために、Kubecostはリアルタイムの費用可視性と、Kubernetes関連の何百万ドル(何億円)ものクラウド費用を継続的にモニターして軽減するために必要な、インサイトを提供する。

同社のコアプロダクトはオープンソースで、チームが自由に使える。ブラウン氏がいうのだから真実だろう。またエンタープライズ向けの商用プロダクトもあり、その機能は数分でインストールできて、セールスに持ち込まなくても試用や現用ができる。

顧客は情報をKubecostと共有しなくてもよいが、その代わりにその技術はオープンソースの情報を使い、それを顧客の環境に持ち込み、それをクラウドやオンプレミスのデータセンターに統合する。

そこから、情報はリアルタイムで集められて、企業がリソースに支出しているすべての領域と、費用の高騰やその理由を示すインサイトが提供される。それからKubecostは、費用を削減する方法のインサイトを提供し、アラートを送ったり、今後の長期的管理を可能にするポリシーを設定する。

画像クレジット:Kubecost

Kubecostはすでに2000社以上と仕事をしており、そのうち、エンタープライズ級は100社ほどとなる。それは2021年の1年間で3倍になり、エンゲージメントの数は5倍になった。同社が現在管理しているKubernetesの支出は総額20億ドル(約2300億円)ほどに達する。同社の年間経常収益は、前年比で3倍だ。ブラウン氏はKubecostの評価額を明らかにしないが、2021年の5倍だという。

同社を採用する企業がこれまでのペースで増えていくという想定で、同社は2500万ドル(約28億7000万円)のシリーズAを調達した。これをリードしたのはCoatue Management、そしてシード投資家からの参加としてFirst Round CapitalとAfore Capitalの名がある。Coatueのパートナー、David Cahn(デビッド・カーン)氏がKubecostの取締役会に加わる。

この新たな資金は全社的な雇用増に充てられる。Kubecostのルーツはオープンソースだが、ブラウン氏の計画では、そのコミュニティへの相当な投資により、機能をもっと増やしたいという。また、そのエコシステムのその他のプロダクトの統合や、インサイトと最適化の開発も進めたいとのこと。

さらに、Kubecostの管理を他に任せたい顧客企業やチームのために、その付加価値バージョンである「Hosted Kubecost」も開始する。

「全体的にいえるのは、これまではクラウドからコンテナへの本質的で重要な変革の波があり、それはデータセンターからクラウドへの変化よりも大きな変化だと私は認識しています。だからそれは、これからも続くだろう」とブラウン氏はいう。「Kubernetesは今や、モダンなエンタープライズのテクノロジースタックの心臓部です。私たちの計画は、そこに深入りすることによって移行を興し、すべてのアプリケーションをそこから動かせるような高スケールのプロダクトに到達したい」。

原文へ

(文:Christine Hall、翻訳:Hiroshi Iwatani)

Mirantis、Docker Enterpriseの資産買収から2年間でランレート約115.6億円超えの大成功

2019年、DockerDocker Enterpriseを売却すると発表したときは誰もが驚いた。もっと大きな驚きは、買い手がMirantisだったことだろう。同社はそれまで、OpenStackプロジェクトの商用化で知られていた。

売却後のDockerは開発者を主対象とする企業へと方向性を変え、先週、5000万ドル(約57億8000万円)の年間経常収益を報告した。今週、MirantisのCEOであるAdrian Ionel(アドリアン・イオネル)氏がTechCrunchに、同社が前四半期に2800万ドル(約32億4000万円)の経常収益を得て、ランレートは1億ドル(約115億6000万円)をゆうに超えるだろうと語った。

イオネル氏によると、その売上はおよそ半分がDockerから得た資産、具体的にはDocker Enterprise Engine、Docker Trusted Registry、Docker Unified Control PlaneそしてDocker CLIなどとなる。そして残り半分が同社の買収前の本業だったKuberentes上のクラウドプラットフォームツールだ。なお、同社は2020年にKubernetes用のIDEであるLens買収しており、これも売上に貢献している。

しかし基本的にはDockerとMirantisはともに、買収の効果として年間経常収益5000万ドルのラインに達しており、Dockerの方はエンタープライズプロダクトを売却した後の経営努力として、そしてMirantisはDockerのエンタープライズアセットから、どちらも大きな売上を得ている。両者とも、買収から2年後にほぼ同額の取引効果を得ていることは極めて稀だが、しかしイオネル氏によると、当時はそれを知るすべもなかったという。

「信じられないほどすばらしい旅路でした。そのスタートは、2019年11月に契約に署名したことです。当時は、それが今後どうなるかを誰も知りませんでした」とイオネル氏はいう。何よりもまず、最初に作り出されたのは、この買収が同社の未来にとって何を意味するのかに関する顧客たちの混乱だ。しかしイオネル氏によると、同社のビジョンが複数のプロダクトの組み合わせとそれがもたらす効果にあることを、顧客はすぐに理解した。

「多くの人が、プロダクトのビジョンをとても早く、理解し共有してくれました。私たちがこれから新しい企業を作ろうとしていること、それが私の考える中心的なテーマであることをみんな理解しました。それは単に、MirantisがDocker Enterpriseを買収したという話ではありません。むしろ、両社のアセットを有効利用して新しい企業を作り、フレッシュでより強力な企業として立ち上がることでした」。

これらのアセットを買うメリットについては、取締役会も議論した。「買収前には取締役会で激しい議論がありました。ご想像どおり、うまくいかない買収の方が多いためです。しかしこれは、大成功でした。株主たちが持つ価値がものすごく増えました。私たちにとってはKubernetesとの旅路が加速され、未来につながったという意味で、すばらしい賭けでした」とイオネル氏はいう。

関連記事:Kubernetesの統合開発環境のLensをMirantisが買収

しかし買収が完了した後の航行は、楽なものではなかった。まず買収した企業の40%をレイオフしなければならなかった。イオネル氏は、当初は辛かったと認める。しかしエンジニアリングとビジネスファンクションを1つの傘の下にまとめることによって費用を節約し、その後の成功に導くことができた。

イオネル氏によると、Mirantisは過去2年間キャッシュフローがプラスで、その間に1900万ドル(約22億円)以上の現金を生み出しているという。Apple、Visa、Booking.comなど、合併時点で300の顧客との関係を拡大し、その過程で100の新規顧客を追加した。

イオネル氏自身も、Docker Enterpriseの買収がこれほどうまくいくとは考えなかった。「すばらしい旅路だったが、ときには難題もあった。それは主に、Docker Enterpriseの事業を再構築する過程だったが、決断力を重視して迅速にそれを行った。現状の好結果を見れば、成功だったといえるでしょう」。

画像クレジット:Suriyapong Thongsawang/Getty Images

原文へ

(文:Ron Miller、翻訳:Hiroshi Iwatani)

クラウドファウンドリーの今後

今月、Google在籍中に Kubernetes(クバネティス)プロジェクトを共同で立ち上げ、現在VMWare(自身のスタートアップ、Heptioを同社に売却した)のR&D(研究開発)担当副社長を務める Craig McLuckie(クレイグ・マクラッキー)氏が、非営利団体、Cloud Foundry Foundation(クラウド・ファウンドリー・ファウンデーション)の理事会会長に選出された。

同氏は2020年4月から理事長を務めていたVMWareのPaul Fazzone(ポール・ファゾーン)氏を引き継ぐ。2020年以来、Cloud Foundry Foundationではもう1つ幹部の変更があり、Chip Childers(チップ・チルダーズ)氏が8月に辞任し、同氏が務めていたエグゼクティブ・ディレクターの後任は指名されなかった。これで同団体は、新たに結成された技術検討委員会と理事会に重点を置くことになった。すなわち、現在マクラッキー氏は、かつてのエグゼクティブ・ディレクターの役割に最も近い立場
にいることになる。

マクラッキー氏はCNCF(クラウド・ネイティブ・コンピューティング・ファウンデーション)を設立し、そこにKubernetesを寄贈した中心人物であるにも関わらず、Cloud Foundryエコシステム内での活動は必ずしも積極的ではなかった。ただし、どちらのファウンデーションもLinux Foundation(リナックス・ファウンデーション)の傘下にあるため、両団体には重なる部分も少なくない。加えて、近年のCloud Foundryの動きは、中心基盤をKubernetesに移すことと密接に関連しており、Cloud Foundryエコシステムに由来するbuildpacks(ビルドパックス)の考え方がKubernetesエコシステムに影響を与え始めている。異なるコミュニティの間には多くの交流がある。そしてVMWareがPivotal(ピポタル)を買収したことで、グループ間に多くのつながりができた。

マクラッキー氏が私に話したところによると、約6ヶ月前、同氏はCloud Foundryエコシステムでの自身の役割について深く考えるようになり、行動を起こすきっかけになった。

「VMwareがPivotalを買収したとき、私はCloud Foundryエコシステムの中に作られてきたものをしっかりと見直す機会を得ました。そこには多くのクラウド・ネイティブのパターンを生み出すための重要な技術がありました」と同氏は語った。「たとえばKuberetes以前のテクノロジーがあり、アプリケーションの構築、編成、展開に関わる非常に具体的な考えがありました。そして、Pivotalの買収を通じて1つのコミュニティと密接に関われるようになったことが数多くのクラウド・ネイティブ・パターンを生み出す素晴らしい機会となり、一種のコンテナ・パッケージ配信のアイデアを採用したことで、デベロッパーが自身のIDE(統合開発環境)を非常によくコントロールされた生産環境へと変えることを可能にする抽象概念が生まれました」

関連記事:
How Kubernetes came to rule the world

現在重要なのは、この2つのテクノロジーを合体させることだと彼は言った。Cloud Foundryのデベロッパー体験を成功させたものは何か、Kubernetesがインフラストラクチャーの抽象概念として何を提供できるか、を見極めることだ。そう考えると、同財団から生まれる最初のプロジェクトの1つが、2022年第1四半期に公開されるKubernetes上の新たなCloud Foundry体験のベータ版であることは驚くに当たらないだろう。いくつかのメーカーがそれぞれの取組みをしてきたが、この新プロジェクトによってVMware、SAP(サップ)、IBM(アイ・ビー・エム)などいくつかの会社が新たな道に向かって集結した。

「つまるところ、毎晩Hacker Newsを熟読し、あらゆるテクノロジーに手を染めているデベロッパーばかりではない、ということです」とマクラッキー氏は言った。「家に帰ってビールを飲んでYouTubeを見たい、という人もたくさんいます。Cloud Foundryは、非常にシンプルですぐに使える体験をたくさん生み出し、アプリケーションを稼働させることに関わる頭痛の多くを緩和します。今回私たちは、彼らがその体験を維持しながら、マルチクラウド環境の標準になりつつある抽象モデルを提供できるようにしました」

しかし、こうした個々のプロジェクトよりも大切なのは、組織が劇的に変化しようとしていることだ。1年前メーカー主導のグループとして始まったものが、デベロッパー一人一人がエコシステムに貢献しやすく、かつてオープンソース・プロジェクトに参加するために必要だった儀式や式典を通過しなくてもよい組織になった。

「これまでは、Cloud Foundryのテクノロジー基盤に関連する特定のプロダクトを開発する組織の商業的関心を推進するための組織でした。そしてどこの財団でもそうであるように、メーカー間には一種の緊張関係が常にありました」と彼は説明した。しかし今後同財団は、3つのことに焦点を当てる。 貢献者のためのコミュニティーをつくる。メーカーのために働く人もそうでない人も対象だ。オープンソース・バージョンのCloud Foundryを利用しているエンドユーザーのサポートを強化する。そして、エコシステムと連携して、メーカーが団結し、協力してCloud Foundryエコシステムから生まれた数多くのクラウド・ネイティブ・テクノロジー(たとえばBuildpack)のコンセプト化や革新を行うことを支援する。

「この組織は、テクノロジーの進化に目を向け、それを消費する組織と、オープンでフェアな方法でそこに貢献している人々、両方に役立つ新しい時代を象徴しています」とマクラッキー氏は言った。

関連記事:
Kubernetes co-founder Craig McLuckie is as tired of talking about Kubernetes as you are

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

画像クレジット:anucha sirivisansuwan / Getty Images

原文へ
 
(文:Frederic Lardinois、翻訳:Nob Takahashi / facebook

AWSがKubernetesクラスタを自動的にスケーリングするオープンソースツール「Karpenter」を公開

米国時間11月30日、Amazonはラスベガスで開催されている同社の顧客向けカンファレンスAWS re:Inventで、オープンソースの新しいKubernetesクラスタスケーリングツールであるKarpenter(カーペンター)を発表した。

クラウドコンピューティングの利点の1つは、必要なリソース要求に合わせて自動的にスケーリングできること、と少なくとも理論的にはいわれている。しかし現実には、Kubernetesクラスタの管理担当者は、サービス停止を防ぐために適切な量のリソースがあるかどうを注意深く監視していなければならない。

Karpenterは、そのクラウドコンピューティングの理想を現実にするために開発された。その利点について、AWSのChanny Yun(チャニー・ユン、尹 錫璨)氏は、新機能を紹介するブログを書いている。

「Karpenterは、変化するアプリケーション負荷に応じて適切なサイズのコンピュートリソースを割り当てることで、お客様のアプリケーション利用率とクラスタ効率を改善します。Karpenterは、アプリケーションのニーズを満たすリソースをジャスト・イン・タイムで計算する機能を提供しており、近々クラスタのコンピュートリソースを自動的に最適化してコスト削減、性能改善ができるようになります」とユン氏は述べている。

Karpenterは、Kubernetesの負荷を分析し、リソース制限のために開始できないポッドが必要としているリソースを特定する。次に、クラウドプロバイダーに情報を送り、それに基づいてコンピュートを追加あるいは削除してもらう。

ここで重要なのは、オープンソースツールであるため、KarpenterはAWSクラウドリソースに特化して作られているのではなく、あらゆるクラウドプロバイダーに対して内在するKubernetesクラスタに関する情報を送るのに使えることだ。Karpenterは、Kubernetesの負荷を判定するために、KubernetesのパッケージマネージャーであるHelm(ヘルム)を利用している。Karpenterが対象のプロバイダーでコンピュートリソースを自動的に設定するための許可も必要になる。

Karpenterは、Apache 2.0ライセンスの下で提供されるオープンソースツールで、すでに利用可能だ。

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

原文へ

(文:Ron Miller、翻訳:Nob Takahashi / facebook

コンテナ化されたアプリをオンプレミスまたはクラウドで実行できるようにする新しいAWS Marketplaceオプション

コンテナが急増するにつれ、開発者はコンテナを使用してソフトウェアを配布するようになっている。だがオンプレミスかクラウドかの環境によって、ユーザーにはコンテナのインストールに関わる一連の課題が残される可能性がある。この問題を解決するために、AWSは米国時間11月30日、ラスベガスで開催中のAWS re:Inventで、AWS Marketplace for Containers Anywhere(AWSマーケットプレイス・フォー・コンテナズ・エニウェア)を発表した。

製品の名前はあまりクリエイティブではないかもしれないが、それは何をするものかを正確に説明している。開発側がコンテナをAWSのマーケットプレイスで提供すれば、ユーザーはそれをどこにでもデプロイできるのだ。ここでの狙いは、AWS Marketplace上で、コンテナ化されたアプリケーションを検索する手段を提供し、それらをサブスクライブして、任意の環境のKubernetes(クバネティス)クラスターに簡単にデプロイする方法を提供することだ。

AWSのChanny Yun(チャニー・ヤン)氏は、新機能を発表したブログ投稿で「このリリースによって、Amazon EKS Anywhereを使ったオンプレミス環境や、Amazon Elastic Compute Cloud (Amazon EC 2) やオンプレミス環境上でお客様ご自身で管理されているKubernetesクラスターに対して、サードパーティのKubernetesアプリケーションをデプロイできるようになりますので、最終的にどこにデプロイするかに関係なく、単一のカタログを使用してコンテナイメージを検索することができるようになります」と書いている。

ヤン氏が指摘するように、これにより、柔軟な請求オプション、アプリケーションのセキュリティスキャンが済んでいるという情報、管理の簡素化など、マーケットプレイスを使用する際のすべての利点がユーザーに提供される。なにより大きな利点の1つは、ライセンスを変更するだけでさまざまな環境に展開できる柔軟なライセンス方式だ。

またヤン氏は「この機能を使用してアプリケーションをサブスクライブすれば、独立系ソフトウェアベンダー(ISV)が提供するHelm(ヘルム)チャートを、AWS上のISVのKubernetesクラスタにデプロイすることで、ご自身のKubernetesアプリケーションをAWSに移行できます」とも書いている。

AWSは、AWS Marketplace for Containers Anywhereが、AWS Marketplaceをサポートしているすべてのリージョンで利用できるようになったと発表した。

画像クレジット:Jason Alden/Bloomberg/Getty Images

原文へ

(文: Ron Miller、翻訳:sako)

グーグルがハイブリッドクラウドに全力、エッジ・オンプレミスのマネージドソリューション新ポートフォリオを発表

米国時間10月12日、Google(グーグル)は、同社の年次カスタマーカンファレンス「Google Cloud Next」において、ハイブリッドクラウドサービスの幅広いポートフォリオを発表した。これらのサービスでは、Googleのデータセンターネットワークのエッジ、パートナー施設、または顧客のプライベートデータセンターでコンピューティングを提供し、すべてを同社のクラウドネイティブ管理コンソールであるAnthosで管理する。

今回の発表の背景には、パブリッククラウドには必ずしも適さない特殊なワークロードを持つ顧客を取り込むという戦略があると、GoogleのIaaS担当GM兼VPのSachin Gupta(サチン・グプタ)氏は述べている。このようなニーズは、潜在的な顧客から絶えず聞かれていたという。

そのためには、合理的な代替案を提供することが必要だ。「パブリッククラウドへの移行を妨げるさまざまな要因があることがわかりました」とグプタ氏はいう。例えば、低遅延の要求があったり、処理しなければならないデータが大量にあったりして、そのデータをパブリッククラウドに移したり戻したりすることが効率的でない場合がある。また、セキュリティ、プライバシー、データの残留、その他のコンプライアンス要件がある場合もある。

このような背景から、Googleは純粋なパブリッククラウドではないさまざまな状況で機能する一連のソリューションを設計した。ソリューションは、Googleの世界各地のデータセンター、通信事業者やEquinixのようなコロケーション施設のパートナーデータセンター、あるいは企業のデータセンター内の管理対象サーバーの一部として、エッジに設置することができる。

後者については、Dell(デル)やHPEなどのパートナー企業が提供するサーバーであり、Amazon(アマゾン)が提供するOutpostsのようにGoogleが製造・管理するサーバーではないことに注意が必要だ。また、これらのマシンはGoogleのクラウドに直接接続されるわけではないが、Googleがすべてのソフトウェアを管理し、IT部門がクラウドとオンプレミスのリソースを一元的に管理する方法を提供するというところも興味深い点だ。これについては後述する。

ホスティングソリューションの目的は、コンテナとKubernetes、または仮想マシンを使用した、一貫性のある最新のコンピューティングアプローチだ。Googleは安全なダウンロードサイトを通じてアップデートを提供しており、顧客は自分でチェックすることも、サードパーティベンダーにすべてを任せることもできる。

このアプローチを支えているのは、数年前に発表した制御ソフトウェアであるAnthosだ。Anthosを使用することで、顧客は、オンプレミス、データセンター、パブリッククラウドなど、それがMicrosoft(マイクロソフト)やAmazonのような競合他社のクラウドでも、ソフトウェアがある場所でコントロールし、管理することができる。

Google Cloudハイブリッド・ポートフォリオ・アーキテクチャ図(画像クレジット:Google Cloud)

このようなアプローチは、Googleがハイブリッドの市場機会を利用して、クラウドの中で独自のシェアを開拓しようとしていることを示している。この分野はMicrosoftやIBMも開拓しようとしているが、Anthosを使ってすべてをつなぎ合わせながら、このような包括的なプラットフォームアプローチをとることで、とりわけ特定のワークロードをクラウドに移行できないような固有の要件を持つ企業において、Googleが支持される可能性がある。

Googleは、8月に発表された最新の四半期報告書において、クラウドインフラストラクチャ市場のシェアが初めて10%に達し、54%という活発な成長率を示した。市場シェアが33%のAmazonや20%のMicrosoftにはまだ遠く及ばないものの、少しずつ勢いを増してきていることがうかがえる。

関連記事:クラウドインフラ市場は2021年第2四半期も成長を続け、売上高は約4.6兆円に到達

画像クレジット:Sean Gallup / Getty Images

原文へ

(文:Ron Miller、翻訳:Aya Nakazato)

Solo.ioがそのエンタープライズプラットフォームにクラウドネイティブAPIゲートウェイとサービスメッシュを統合

最新のクラウドネイティブエンタープライズアプリケーションが必要とする、すべてのサービスやマイクロサービスに接続するのは複雑な作業かもしれない。それこそが、スタートアップのSolo.io(ソロアイオー)がGloo Mesh Enterprise(グルーメッシュエンタープライズ)プラットフォームの新しいリリースで、破壊的に変革しようとしている分野だ。

マサチューセッツ州ケンブリッジに拠点を置くSoloは、創業以来、サービスメッシュと呼ばれるコンセプトに重点を置いてきた。サービスメッシュは、異なるコンポーネントを自動化された最適なアプローチで接続する。これはしばしばKubernetes(クバネテス)によるクラウドネイティブ環境の中で提供される。

Soloの創業者でCEOであるIdit Levine(イディット・レバイン)氏がTechCrunchに説明したところによれば、2017年に会社を立ち上げた当初から、サービスメッシュのコンセプトとその必要性が市場に理解されるまでには数年かかるかもしれないと考えていたという。そのため彼女の会社は、異なるデータソースやサービスであるAPIを開発者が接続できるようにするAPIゲートウェイ技術も構築してきたのだ。

これまでは、このAPIと、SoloGloo Mesh Enterpriseのサービスメッシュのコンポーネントは別の技術であり、構成や制御も異なっていた。それが今では、APIとサービスメッシュの両方の機能が統合された、統一されたサービスに変わりつつある。この統合された機能により、Kubernetes上で動作するクラウド上のあらゆるサービスのセットアップと設定が容易になるはずだ。

Gloo Meshという名で知られるSoloのサービスメッシュは、もともとGoogleが作成したオープンソースのIstio (イスティオ)プロジェクトをベースにしている。またAPI製品はGloo Edge(グルーエッジ)と呼ばれ、オープンソースの Envoy(エンボイ)プロジェクトを利用しているが、このプロジェクトはもともとライドシェア企業のLyft(リフト)が作成したものだ。レバイン氏は、現在彼女のチームがIstioのプラグインアーキテクチャを使用して、最適化されたアプローチでEnvoyと接続していると説明している。

関連記事:サービスメッシュIstioがバージョン1.0に到達、マイクロサービスアーキテクチャの成熟を推進

レバイン氏は、多くのユーザーがAPIゲートウェイから始めて、サービスメッシュの利用へと拡大していると指摘する。今回のGloo Mesh Enterpriseのアップデートにより、SoloはサービスメッシュとAPIマネジメントの両市場で、競合他社との差別化を図ることができるようになり、顧客の導入がさらに加速することを期待していいる。

サービスメッシュの分野はまだ始まったばかりだが、たとえばライバルTetrate(テトレート)はより成熟したAPIゲートウェイ技術を提供している。またAPI管理の分野には、7100万ドル(約78億円)の資金を調達した、Kong(コング)のようなライバルがいる。2016年にGoogleはAPI ベンダーの Apigee(アピジー)を6億2500万ドル(約687億2000万円)で買収し、それ以来数年をかけてその技術の拡張を続けてきた。その中には2021年2月に発表されたApigee X(アピジーエックス)プラットフォームも含まれている。

関連記事:Google Cloudが次世代API管理プラットフォーム「Apigee X」を発表

API管理のためのGloo EdgeをGloo Mesh Enterpriseに統合したことで、SoloがAPI技術のすべてのベースをカバーできたわけではない。Gloo Edgeは、現在最も一般的なRESTベースのAPIをサポートしているが、最近徐々に存在感を増しているGraphQL(グラフキューエル) API規格には対応していない。レバイン氏は、SoloプラットフォームのためのGraphQLの発表については、これからに「期待していてください」と語った。

Soloはこれまで2回のラウンドなどから合計3650万ドル(約40億1000万円)を調達している。2018年には1100万ドル(約12億円)のシリーズAを、2020年10月には2300万ドル(約25億3000万円)のシリーズBを発表している。RedpointやTrue Venturesなどが同社の投資家として名を連ねている。

画像クレジット:Laurence Mouton/Getty Images

原文へ

(文: Sean Michael Kerner、翻訳:sako)

【コラム】オープンソースの終焉が来ているのだろうか?

本稿の著者Shaun O’Meara(ショーン・オメーラ)氏は、MirantisのグローバルフィールドCTO。企業のITインフラストラクチャの設計と構築において20年間、顧客と仕事をしてきた。

ーーー

数週間前、ミネソタ大学の研究者らにより「偽善者のコミット」と彼らが呼ぶものをLinuxカーネルに投入するメソッドが展開されたという憂慮すべきニュースがLinuxコミュニティを揺るがした(ただし結果的には完全に実行されなかったことが明らかになっている)。その主意は、検知が困難な振る舞いを配布し、それ自体には意味はないが、後に攻撃者によって整合されることで脆弱性が顕在化し得るというものだった。

その後すぐに、ある意味同じように憂慮すべきことだが、大学が少なくとも一時的にカーネル開発へのコントリビューションを禁じられたことが発表された。続いて、研究者らが公式に謝罪した。

脆弱性の発見と開示は往々にして厄介なものだが、世界最大かつ最も重要なオープンソースプロジェクトに対して、技術的に複雑な「レッドチーム」プログラムを実行するのは、少々やりすぎだと感じる。こうした振る舞いが爆発的な広がりを持つ可能性があることを理解しないほど、研究者や研究機関が無知であるとか、怠慢であるなどとは考えにくい。

同様に確かなこととして、メンテナーとプロジェクトガバナンスは、ポリシーを強化し、時間の浪費を回避する義務があり、常識的観点では、脆弱性を含まないカーネルリリースの生成に努めることが推奨されている(そしてユーザーが要求している)。しかしメッセンジャーを排除することは、少なくともいくつかの要点を見落としているように思われる。つまり、これは単なる悪意によるものではなく研究に基づくものであり、技術的、体系的な緩和を必要とする、ある種のソフトウェア(および組織)の脆弱性を明らかにしようとするものだということだ。

「偽善者のコミット」に端を発した不慮の事象は、拡張されたオープンソースエコシステム全体とそのユーザーを脅かす、あらゆる面において関連性のあるトレンドの兆候だと思う。このエコシステムは長い間、規模や複雑性、そしてFOSS(フリーソフトウェアとオープンソースソフトウェア)が人間による各種の活動において重要性を増していることにまつわる、数々の問題と格闘してきた。この複雑に絡み合った諸問題を見ていこう。

  • 最大規模のオープンソースプロジェクトは現在、大きなターゲットを掲げている。
  • その複雑さとペースは、従来の「コモンズ」アプローチや、さらに進化したガバナンスモデルで対応できる規模を超えて拡大している。
  • 互いにコモディティ化する方向に進化している。例えば、分散アプリケーションのために「Linux」と「Kubernetes」のどちらを「オペレーティングシステム」として扱うべきかを明確にすることはますます難しくなっている。営利組織はこれに注目し「フルスタック」ポートフォリオとナラティヴを中心に再編成を始めている。
  • そうすることで、一部の営利組織は、FOSS参加という従来型パターンを歪め始めている。多くの新機軸が現在進行中である。一方で、資金調達や、FOSSへの人員コミットメントなどのメトリクスは減少傾向にあるようだ。
  • OSSプロジェクトとエコシステムはそれぞれ異なる方向性で順応しており、場合によっては、営利組織が居心地の良さを感じたり、参加から恩恵を受けることが難しくなっている。

一方で、脅威のランドスケープは進化し続けている。

  • 攻撃者は巨大化し、巧妙化し、高速化するとともに持続性を増しており、長期にわたるゲームやサプライチェーンの破壊などにつながっている。
  • 攻撃はこれまで以上に財務的、経済的、政治的に収益性を高めている。
  • ユーザーは以前にも増して脆弱になり、多くのベクターにさらされている。
  • パブリッククラウドの利用が増えるにつれて、技術的および組織的なモノカルチャーの新たな層が生まれ、攻撃を可能にし正当化する可能性がある。
  • オープンソースソフトウェアから部分的または全体的に組み立てられた複雑な商用オフザシェルフ(COTS)ソリューションは、そのコンポーネント(およびインタラクション)にアクセスできる、悪質な攻撃者によく理解された複雑な攻撃サーフェスを生成する。
  • ソフトウェアのコンポーネント化は、新たな種類のサプライチェーン攻撃を可能にする。
  • そして、組織が非戦略的な専門知識を排除し、設備投資を運用コストにシフトさせ、セキュリティのハードワークをクラウドベンダーやその他の事業体に依存するように進化する中で、これらすべてが起こりつつある。

結果として、Linuxカーネルの大規模かつ絶対的な重要性を持つプロジェクトの多くは、大きな変化をもたらす巨大な脅威モデルに立ち向かう準備が整っていない状況にあると言えるだろう。私たちがここで考察している特定のケースでは、研究者たちは比較的少ない労力で侵入候補サイトをターゲットにし(静的分析ツールを使い、コントリビュータの注意を必要としていることがすでに確認されているコードの単位を評価する)、メールで非公式に「修正」を提案し、信頼性が高く、高頻度のコントリビュータとして確立されている彼ら自身の評判を含む多くの要因を活用して、脆弱性コードをコミットされる寸前の状態にした。

これは、堅牢で安全なカーネルリリースを作成するためにこれまで非常にうまく機能してきた信頼システムの「内部者」による重大な裏切り行為だった。信頼を悪用すること自体が状況を変え、それに続く暗黙の要件、つまり体系的な緩和で相互の信頼を支えるということが大きく浮かび上がってくる。

しかし、このような脅威にどう対処すればいいのだろうか。ほとんどの場合、正式な検証は事実上不可能である。静的解析では巧妙に設計された侵入を明らかにできない場合がある。プロジェクトのペースを維持しなければならない(修正すべき既知のバグがある)。そして、こうした脅威は非対称的だ。典型的な言い方をすれば、ブルーチームはすべてに対して防御する必要があり、レッドチームは一回成功すれば良い。

改善の機会がいくつか存在する。

  • 単一培養の広がりを制限する。Alva LinuxやAWSのOpen Distribution of ElasticSearchなどは、広く使われているFOSSソリューションを無料でオープンソースにしていることもあるが、技術的な多様性を注入しているという点からも優れている。
  • 人的要因への完全な依存を緩和し、営利企業に専門知識やその他の資源を提供するインセンティブを与えることを目的として、プロジェクトのガバナンス、組織、資金調達を再評価する。ほとんどの営利企業はオープンソースへのコントリビューションを、そのオープン性ゆえに、またオープンソースにもかかわらずオープンではない場合でも歓迎するであろうが、多くのコミュニティにおいて、既存のコントリビュータの文化を変える必要があるかもしれない。
  • スタックを簡素化し、コンポーネントを検証することで、コモディティ化を促進する。適切なセキュリティ責任をアプリケーション層に押し上げる。

基本的に私がここで主張しているのは、Kubernetesのようなオーケストレータはあまり重要ではなく、Linuxはそれほどインパクトを持たない、ということだ。最後に、ユニカーネルのようなシステムの使用を形式化することに向けて、できる限り早く進むべきである。

いずれにしても、オープンソースの継続に必要なリソースを企業と個人の両方が提供することを確保する必要がある。

関連記事
セキュリティテストのCheckmarxがオープンソースサプライチェーンのセキュリティを確保するDusticoを買収
オープンソースのアプリケーションフレームワークServerless Stackが1.1億円調達
【コラム】オープンソースとオープン標準の統合を再評価しよう

カテゴリー:ネットサービス
タグ:オープンソースコラムLinuxKubernetes

画像クレジット:Alexandr Baranov / Getty Images

原文へ

(文:Shaun O’Meara、翻訳:Dragonfly)

Kubernetesベースの開発で面倒なDevOps部分をPaaSとして引き受けるPorter

Porter共同創業者アレクサンダー・ベレンジャー氏、トレバー・シム氏、およびジャスティン・リー氏(画像クレジット:Porter

Porterの共同創業者であるTrevor Shim(トレバー・シム)氏とAlexander Belanger(アレクサンダー・ベレンジャー)氏とJustin Rhee(ジャスティン・リー)氏がDevOpsに関する企業を作ろうと決心したとき、彼らはすでにKubernetesのリモート開発を良く知っていた。そして他のユーザーと同様に、彼らも頻繁にその技術で痛い思いをしていた。

リー氏によると、確かに技術というレベルではすばらしいが、ソリューションをホストするときの面倒さや大きなDevOpsチームを維持する費用の負担もユーザーの仕事になる。

そこで彼らは、ソリューションを外で作ることにしたが、2020年にY Combinatorの夏季に参加したとき、同じやり方をしているスタートアップがいくつもあることに気づいた。

米国時間7月30日、PorterはVenrockやTranslink Capital、Soma Capital、および数名のエンジェル投資家からの150万ドル(約1億6000万円)のシードラウンドを発表した。その目標は、どんなチームでもそれを使ってアプリケーションを自分のクラウドで管理でき、Herokuのような体験を通じてKubernetesの完全な柔軟性を提供できるような、PaaSを開発することだ。

なぜHerokuか? それはデベロッパーが使い慣れているホスティングプラットフォームであり、しかも小企業だけでなく、後期段階の企業も使っている。シム氏によると、Amazon Web ServicesやGoogle Cloud、DigitalOceanなどに移行したくなったら、Porterはそのための橋になるだろう。

しかし、Herokuは依然として広く使われてはいるものの、企業はそのプラットフォームがもう古い、昔から何も変わっていない、と感じている。リー氏によると、毎年のように、技術的限界と費用を理由としてこのプラットフォームから他へ移行する企業が絶えない。

彼によると、Porterで重要なのはホスティングに関しては課金しないことだ。その費用は純粋にSaaSプロダクトのそれだ。彼らはプラットフォームの再販を志向してはいないので、ユーザー企業は自分のクラウドを使えるが、しかしPorterはオートメーションを提供し、ユーザーはAWSやGCPのクレジットで払えるから、柔軟性がある。

最もよくあるパターンはKubernetesへ移行することだが、しかし「あえて皮肉を言えば」、もしもHerokuが2021年に作られていたら、Kubernetesを使っていただろう。シム氏はそう付け加えた。「自分たちはHerokuの後継者を自負している」。

シム氏はさらに、「そんな橋になるために今度の資金で技術の幅を広げて、『すべてのスタートアップのためのデファクトスタンダードになる』ことを目標にしたい」という。

VenrockのパートナーであるEthan Batraski(イーサン・バトラスキー)氏によると、Porterのプラットフォームが動き始めたのは2月で、それから6カ月後には6番目に速く成長しているオープンソースのプラットフォームとしてGitHubでダウンロードされている。彼はYCでPorterに会い、リー氏とシム氏のビジョンに感銘を受けたという。

バトラスキー氏はこ「Herokuには10万名のデベロッパーがいますが、今では停滞していると思います。Porterのプラットフォーム上にはすでに100社のスタートアップがいます。彼らが達成した4倍から5倍の成長は、現時点ではむしろ当然の現象です」という。

彼の会社は長年データのインフラストラクチャにフォーカスしてきたが、そのスタックは今や相当に複雑だ。そして「それなのに、1週間ほどでアプリを作ってそれを数百万人のユーザーにまでスケールしたい、と考えるデベロッパーがますます増えている。でもそのためには人がたくさん必要だ。しかしKubernetesを使えば、誰もが知らない間にエキスパートのデベロッパーになれる」。

カテゴリー:ソフトウェア
タグ:PorterDevOpsKubernetesPaaS資金調達

原文へ

(文:Christine Hall、翻訳:Hiroshi Iwatani)

Esriが地理情報システムプラットフォーム「ArcGIS」をKubernetesに搭載

地理情報システム(GIS)、マッピング、空間分析最大手のEsriは、米国時間4月6日に(バーチャル)デベロッパーサミットを開催した。予想どおり、イベントでは新たなデザインシステムとJavaScript APIの改訂からArcGIS EnterpriseをKubernetes(クバネティス)のコンテナで動作させるサポートまでさまざまな発表が行われた。

Kubernetesプロジェクトは同社にとって大きな事業だったと、とプロジェクトマネジャーのTrevor Seaton(トレバー・シートン)氏とPhilip Heede(フィリップ・ヒーデ)氏が私に話した。多くの類似製品と同じく、ArcGISは伝統的に物理的なコンピューターかバーチャルマシン、あるいはクラウドでホストされたVM上にインストールするように作られていた。そしてエンドユーザーにとってはソフトウェアがどこで動いているかは関係ないが、アプリケーションのコンテナ化は企業がシステム規模を必要に応じて拡大縮小するのがはるかに簡単になることを意味している。

Esri ArcGIS EnterprizeをKubernetesにデプロイ(画像クレジット:Esri)

「私たちの顧客の多く、特に大規模な顧客の中には、非常に複雑な問題を処理しているところがたくさんあります」とシートン氏は説明する。「そして、それが予測不可能なこともあります。季節性のイベントやビジネスイベントや経済イベントに対応することもあり、そのためには世界で何が起きているかを理解する必要があるだけではなく、ArcGISを設置したシステムに関する質問をする多くのユーザーに対応しなくてはなりません。そしてその予測不可能な需要は、Kubernetesの重要な利点の1つです」。

KubernetesへのEsri ArcGIS Enterpriseのデプロイ(画像クレジット:Esri)

開発チームは楽な道を選んで既存ツールをラッパーに入れてコンテナ化することもできたが、Esriはこの機会にツールを再構築してマイクロサービスに分解した、とシートン氏は説明した。

「しばらく時間がかかりました、なぜならArcGIS Enterprizeを構成している3つか4つの大規模アプリケーションを扱うからです」と彼は言った。「これらを数多くのマイクロサービスに分解します。そうすることで特定のサービスをコンテナ化することが可能になり、管理者にとって複雑にすることなくシステムの供給力と回復力を高めることができるようになりました。実際、複雑さを取り除いた結果、インストールは1つのデプロイスクリプトでできます」。

Kubernetesは多くの管理業務を簡易化するが、ArcGISを使っている多くの企業はまだKubernetesをよく知らない。そしてシートン氏とヒーデ氏が指摘するように、同社はこのプラットフォームの利用を誰にも強制していない。今後もWindowsとLinuxを今までどおりサポートする。またヒーデ氏は、ArcGISのように複雑な統合システムを、顧客が自社インフラで実行できるマイクロサービスと複数コンテナの形で提供していることは今も珍しいことであり、この業界では特にそうだと強調した。

画像クレジット:Esri

Kubernetesサポートに加えて、この日Esriは新しいJavaScript APIを発表した。デベロッパーはEsriのサーバーサイドテクノロジーとクライアントサイドで分析の大部分を行うスケーラビリティを組み合わせたアプリケーションを作れるようになる。かつてEsriは、Microsoft(マイクロソフト)のSilverlight(シルバーライト)やAdobe / Apache Flexなどのツールをサポートして、高度なウェブベースアプリケーションを作れるようにしていた。「今私たちは、単一のウェブ開発技術とその周辺のツール群に専念しています」とEsriのプロダクトマネージャーであるJulie Powell(ジュリー・パウエル)氏が私に言った。

2021年4月、Esriはデベロッパーが簡潔で一貫性のあるユーザーインターフェースを簡単迅速に作ることのできる新しいデザインシステムの公開を計画している。そのデザインシステムは4月22日に公開予定だが、同社は今日すでに部分的に紹介している。パウエル氏によると、Esriにとって困難だったのは、このデザインシステムは同社パートナーが、ArcGISエコシステムから作ったマップとデータの上に独自のスタイルとブランディングを載せられるようにする必要があることだった。

カテゴリー:ソフトウェア
タグ:EsriKubernetes

画像クレジット:Esri

原文へ

(文:Frederic Lardinois、翻訳:Nob Takahashi / facebook

マイクロソフトのマルチクラウドプラットフォームAzure Arcが機械学習のワークロードに対応

Microsoft(マイクロソフト)はコンテナのクラスターがどこでホストされているかに関わらずあらゆるKubernetes環境でAzureを実行できるサービスをAzure Arcで提供している。Arcは登場当初から幅広いユースケースに対応していたが、サービス開始時には残念ながら対応していない機能があった。それが機械学習だ。しかしArcのようなツールの利点の1つは企業がデータに関するワークロードを実行できることであり、それは現在ではそのデータを使って機械学習モデルをトレーニングするという意味であることが少なくない。

米国時間3月2日、Microsoft IgniteカンファレンスでMicrosoftは、Azure Machine LearningをArc対応のデータサービスに追加することでまさにこの機能をAzure Arcで利用できるようになると発表した。

AzureのGMであるArpan Shah(アルパン・シャー)氏は同日の発表で「機械学習の機能をハイブリッドやマルチクラウドの環境に拡大することにより、お客様は既存のインフラストラクチャへの投資を生かしつつ、データのある場所でトレーニングモデルを実行できます。データの移動やネットワークの遅延が減り、セキュリティやコンプライアンスの要件を満たすこともできます」と記した。

この新機能はArcの利用者にすでに公開されている。

Arcに機械学習機能が追加されたことに加え、MicrosoftはAzure Arc対応KubernetesがGAになったことも発表した。これによりユーザーは標準的なKubernetesの構成をあらゆる場所にあるクラスターにデプロイできる。

Azureのハイブリッドサービスの世界で新しい点としては、Azure Stack HCI上でのAzure Kubernetes Serviceのサポートがある。解説すると、Azure Stack HCIは顧客のデータセンター内にある標準化されたハイパーコンバージドなハードウェアセット上でAzureを実行するマイクロソフトのプラットフォームだ。このアイデア自体はAzure Arcより前からあるものだが、自社データセンター内でAzureを実行したい企業にとっては今でも妥当な代替策で、DellやLenovo、HPE、富士通、DataOnなどのベンダーがサポートを継続している。

Arcのオープンソースの面では、MicrosoftはArcがCNCF(Cloud Native Computing Foundation)の標準に適合するあらゆるKubernetesディストリビューションと連携して動作するように構築され、RedHat、Canonical、Rancherそして現在ではNutanixと連携してAzure Arc上でKubernetesの実装に関してテストと検証を実施していると強調した。

Microsoft Ignite 2021

カテゴリー:ネットサービス
タグ:MicrosoftMicrosoft Ignite 2021Microsoft AzureKubernetes機械学習

画像クレジット:Akio Kon/Bloomberg / Getty Images

原文へ

(文:Frederic Lardinois、翻訳:Kaori Koyama)

Google CloudにKubernetes Engineの「オートパイロイット」サービスが登場

Google Cloudは米国時間2月24日、Google Kubernetes Engine(GKE)の新しい運用モードを発表した。そのモードではコンテナのクラスターの日常的な運用の多くを、Googleの技術者と自動化ツールに任せることができる。Autopilotと呼ばれるモードでは、クラスターとそのノードを管理するデイツー(実稼働初日)のすべての操作をGoogleが管理し、そのためのベストプラクティスとセキュリティを実装している。

新しいモードは、既存のGKE体験を拡張する。そのエクスペリエンスはすでに、クラスターを立ち上げるインフラストラクチャの多くを管理していた。Google Cloudが「スタンダード」と呼ぶそのエクスペリエンスは今後も可利用であり、ユーザーが構成を心ゆくまでカスタマイズでき、ノードのインフラストラクチャを手作業で用意し管理できる。

GKEのプロダクトマネージャであるDrew Bradstock(ドリュー・ブラッドストック)氏によると、Autopilotの基本にある考え方は、GoogleがGKEのためにこれまで開発してきたすべてのツールをまとめて、本番環境でのクラスターの動かし方を知っているSREチームに渡すことだ。それは、Googleの社内では前からやっていたこととなる。

ブラッドストック氏は次のように説明する。「Autopilotは、オートスケーリングとオートアップグレードとメンテナンスとデイツーの運用を一体的に縫い合わせて、さらに全体の強化も行う。これによって新しい顧客は極めて迅速に、デベロッパーやテスト、それにプロダクションのためのより良い環境を手に入れることができる。なぜなら、デイゼロから始めた彼らも、クラスター作成に要する5分間が終わればデイツーが完了しているからだ」。

画像クレジット:Google

デベロッパーから見れば、何も変わっていない。しかしこの新しいモードはチームをKubernetesの管理から解放して実際のワークロードに専念させる。企業は依然としてKubernetesの利点を享受するが、ルーチン的な管理とメンテナンスの作業がなくなる。それは、Kubernetesのエコシステムの進化にともなって生じつつあったトレンドでもある。結局のところ、企業がKubernetesを有効に管理できる能力を身につけても、それが競争で優位に立てる差別化要因になることはまずない。

もちろん、Autopilotは有料のサービスだ。GKEの1時間0.10ドル(約10.6円)の定額料金に加えて、クラスターやポッドが消費するリソースが費目に加わる。なお、無料のGKEティアには74.70ドル(約7910円)のクレジットが付いている。GoogleはAutopilotクラスターのコントロールパネルには99.95%のSLAを提供し、マルチゾーンのAutopilotのポッドには99.9%のSLAを提供する。(公式ページ

画像クレジット:Google

GKEのAutopilotは一連のコンテナ中心型のプロダクトをGoogle Cloudのポートフォリオに収めているが、そこには顧客のマルチクラウドをサポートするAnthosや、サーバーレス環境のCloud Runなどもある。ブラッドストック氏は、次のように説明している。「実はAutopilotはGKEの自動化という側面を利用する便宜だが、それはGoogle Cloudを動かすために使われていたものだ。今回はそれらのすべてを使いやすいパッケージにまとめることで、Kubernetesの初心者でも、非常に大きなコンテナ群を動かしている者でも、大量の時間と操作、計算処理すら節約できるようにした」。

そしてGKEはAnthosの鍵となるものだが、そのサービスの実体はむしろ、Googleの構成管理とサービスメッシュとその他のツールを、エンタープライズ自身のデータセンターに持ち込むものだ。GKEのAutopilotは少なくとも現在のところ、Google Cloudでしか利用できない。

ブラッドストック氏はさらに「サーバーレスの世界では、Cloud Runが独自の開発哲学を持つデベロッパーの間で人気が高い。例えばアプリケーションのインスタンスが0から1000に増えてまたすぐにゼロになったとしても何も心配する必要はなく、すべてをGoogleが管理する。どんな開発にとっても、それはすばらしいことだ。Autopilotは複雑なサービスというよりもむしろ、プラットフォーム全体を単純化して、ユーザーをKubernetesの有効利用に専念させる。また、もっと多くのものを制御できるようにしたり、1つの環境で大量のアプリケーションを動かすこともできる」という。

関連記事:Rapid7がKubernetesセキュリティスタートアップのAlcideを52.5億円で買収

カテゴリー:ソフトウェア
タグ:GoogleGoogle CloudKubernetes

画像クレジット:Kittikorn Nimitpara/Getty Images

原文へ

(文:Frederic Lardinois、翻訳:Hiroshi Iwatani)

Rapid7がKubernetesセキュリティスタートアップのAlcideを52.5億円で買収

ボストンに拠点を置くセキュリティ運用会社のRapid 7はクラウドへの進出を行っており、米国時間2月1日の朝、ワークロードやサービスのコンテナ化を管理するプラットフォームであるKubernetes分野のセキュリティスタートアップAlcideを5000万ドル(約52億5000万円)で買収したと発表した。

世界がKubernetesを使ったクラウドネイティブに移行していく中で、コンテナを安全に保つために正しく設定しておくことが難しくなっている。Kubernetesはコンテナの管理を自動化するように設計されていることから、人力を作業ルーチンから除外し、自動化された方法でセキュリティプロトコルを適用することがさらに重要になっている。

Rapid7のクラウドセキュリティ担当SVPを務めるBrian Johnson(ブライアン・ジョンソン)氏は、その目的には特化した種類のセキュリティ製品が必要であり、それがAlcideを買収する理由だと述べている。「クラウドを運用している企業は、リアルタイムでリスクを特定して対応できる必要があり、クラウドインフラやコンテナを個別に見るだけでは、どこに脆弱性があるのかを真に理解するのに十分なコンテキストを提供できません」とジョンソン氏は説明している。

「Alcideを追加することで、企業はクラウドインフラストラクチャおよびクラウドネイティブアプリケーションの全体について、包括的で統一された可視性を得ることができます。これにより、企業は安全性を維持しながら迅速な革新を継続できるようになります。」

今回の買収は、2020年4月に1億4500万ドル(約150億円)でDivvyCloudを買収したことに関連している。2社の買収価格は合計でほぼ2億ドル(約210億円)に相当し、Rapid7がクラウドのワークロードの保護を幅広く広く支援することを可能にしている。

これはまた、大企業が人材やテクノロジーを買収してコンテナのセキュリティの強化を図る中で、2020年に数多くのKubernetesセキュリティスタートアップが誕生したという業界のトレンドの一部でもある。これにはVMWareによる2020年5月のOctarine買収Cisco(シスコ)による10月のPortShift買収したこと、RedHatの2021年1月のStackRox買収などが含まれる。

Alcideは2016年にテルアビブで設立され、イスラエルの活発なセキュリティスタートアップシーンの一部となっている。Crunchbaseのデータによると、同社はこれまでに約1200万ドル(約12億6000万円)を調達している。

関連記事:CiscoがイスラエルのPortShiftを買収、DevOpsとKubernetesのセキュリティを強化

カテゴリー:ネットサービス
タグ:Rapid7Alcide買収Kubernetes

画像クレジット:aydinmutlu / Getty Images

原文へ

(文:Ron Miller、翻訳:塚本直樹 / Twitter

GoogleがKubernetesのインフラ運営の資金としてCNCFにさらに3.1億円提供

2018年にGoogle(グーグル)は、Google Cloud Platformのクレジット900万ドル(約9億3000万円)の3年分割でCloud Native Computing Foundation(CNCF)に提供し、同団体によるKubernetesプロジェクトのためのインフラストラクチャの開発と配布を支援していくと発表した。それまでGoogleがそれらのリソースを保有し、コミュニティのために管理していた。米国時間12月17日、両組織はGoogleがCNCFへの2020年の提供を300万ドル(約3億1000万円)増額して、「Kubernetesとそのエコシステムの長期的な健在と質と安定性を支えていく」と発表している。

Googleによると、調達した資金はKubernetesプロジェクトのテストとインフラに充てられ、Kubernetesには現在、月間2300のプルリクエストがあり、約40万の統合テストが実行され、そのすべてがGCP上で約30万時間のコアタイムを消費している。

「投資を継続できることを嬉しく思っている。それがKubernetesとそのコミュニティの長期的な健全性と質と安定性にとって極めて重要であることを、我々も知っており、Cloud Native Computing Foundationとのパートナーシップがずっと続いていることも喜ばしい。結局のところ、究極の目標はデベロッパーが自由に開発できることと、いうまでもなく誰にとっても重要なKubernetesがそのための優れた、堅固な、安定したスタンダードであり続けることだ」とGoogleのプロダクト管理ディレクターで、CNCFの統轄委員会の議長を務めるAparna Sinha(アパルナ・シンハ)氏は語っている。

シンハ氏によると、Googleはこのプロジェクトに大量のコードも寄贈しており、それは過去12カ月だけでも12万8000行に達する。また、そういう技術的な貢献だけでなく、チームはコミュニティへのエンゲージメントとメンタリングを通じて現物的な貢献も行っている。12月17日に行ったような、財政的貢献だけがすべてではない。

CNCFのゼネラルマネージャーであるPriyanka Sharma(プリヤンカー・シャルマ)氏は、次のように語っている。「Kubernetesプロジェクトは急速に成長してきた。次から次とリリースがある。そして大きな変化もあり、それらがいろんなところで動いている。この300万ドルの寄贈も、そんな動きの1つだ。このようにKubernetesのプロジェクトはストレスと無縁であり、1年中いつでも使えるクレジットがある。またセキュリティも重要で、現状で未知の時間である来月に、どんな環境で動いてもよいようなコードでなければならない。プロジェクトのデベロッパーとコントリビューターは、確信をもって機能の集合にフォーカスし、絶えず進化を続けるKubernetesを開発していかなければならない」。

なお、GoogleとCNCFの協力関係はこのように歩調が揃っているが、サービスメッシュのプロジェクトであるIstioに関してはGoogleの管理に若干の疑問がある。それはGoogleとIBMが数年前に孵化したプロジェクトだが、2017年のある時点でCNCFの傘の下に入れるべきという提案があった。その提案は結局流れたが、2020年になってIstioは、Open Usage Commonsの創設プロジェクトの一員になった。しかしそのプロジェクトはもっぱら商標の問題に関心があり、プロジェクトの統轄を目指していない。そして、こういったことのすべてが内輪ネタにすぎないようであり、確かにそうなのだが、オープンソースのコミュニティの一部は、CNCFのような団体へのGoogleの深入りを疑問視している。

これについてシンハ氏「Googleは、たくさんのオープンソースプロジェクトに貢献している。しかもそれらの多くはLinux Foundation傘下のオープンソースのファンデーションであり、またそうでないものも多い。それは特に新しいことではなく、改めて報告すべきことでもない。今回の議論の主題であるCNCFへのGoogleのフォーカスは、あくまでもKubernetesが軸だ。それは私の考えでは、他のプロジェクトに比べて圧倒的に多くの貢献と時間とコミットメントを注入しているプロジェクトだ」と答えている。

カテゴリー:ソフトウェア
タグ:GoogleKubernetesCNCF

原文へ

(翻訳:iwatani、a.k.a. hiwa

AWSがECSとEKSサービスをデータセンターに提供、EKSはオープンソース化

米国時間12月1日に開催された「AWS re:Invent」2020カンファレンスで、Andy Jassy(アンディ・ジャシー)氏は企業がクラウドを強力に推進していることについて多くを語ったが、同日のコンテナに焦点を当てたイベントで、オンプレミスでもクラウドでも実行できるように設計されているECS AnywhereとEKS Anywhereの発表もデータセンターに大きな反響を与えた。

これら2つのサービス、つまり汎用コンテナオーケストレーションのECSとKubernetesに焦点を当てたEKSは、顧客がこれらの人気のAWSサービスをオンプレミスで利用できるようにする。ジャシー氏によると、一部の顧客はまだオンプレミスで使用しているのと同じツールを望んでおり、今回のサービスはそれを提供するために設計されている。

ECSについては「クラウドへの移行を進める中では、まだオンプレミスで実行しなければならないコンテナをたくさん持っているというものや、AWSでもオンプレミスやユーザから作業を依頼されているのと同じ管理とデプロイのメカニズムを持っていて欲しい、という要望もあります。そこで、2つの発表を皆さんにお知らせしたいと思います。1つ目はAmazon ECS Anywhereの発表で、これによりECSと独自のデータセンターを運用することができます」と、同氏はカンファレンスで語った。

画像クレジット:AWS

ジャシー氏によると、これにより同等のAWSのAPIとクラスタ構成管理機能が得られるという。これはEKSでも同じように動作し、サービスをどこで使用しているかに関わらず、単一での管理方法を可能にする。

同時にAmazon(アマゾン)は、自社運営のKubernetesサービスによるEKSをオープンソース化することも発表した。これらの動きの背景には顧客にできる限りの柔軟性を与え、Microsoft(マイクロソフト)やIBM、Google(グーグル)が主張してきたこと、つまり我々はマルチクラウドやハイブリッドの世界に生きており、人々はすべてをすぐにクラウドに移行するわけではないということを認識していることになる。

実際にジャシー氏は冒頭で、2020年現在の世界のIT支出のうちクラウドに費やされているのはわずか4%にすぎないと述べた。つまり、オンプレミスでサービスを販売することで収益を得ることができ、これらのサービスはそれを実現するということだ。

カテゴリー:ネットサービス
タグ:AWS re:InventAWSAmazonKubernetes

画像クレジット:AWS / Getty Images

原文へ

(翻訳:塚本直樹 / Twitter

MirantisがKubernetesのIDEであるLensに拡張API導入、新たなKubernetes配布系発表

この夏、Dockerのエンタープライズ事業のオーナーであるMirantisは、Kubernetesのクラスターを管理するためのIDEのようなデスクトップアプリケーションLensを買収した。その際、MirantisのCEOであるAdrian Ionel(アドリアン・イオネル)氏は、モダンなアプリケーションをすばやく作ることができるツールをエンタープライズに提供したい、と語っていた。米国時間11月12日、同社はその方向に新たな一歩を踏み出す、Lensの拡張APIを立ち上げた。これによりLensの能力が最初に比べて格段に向上する。

MirantisはLensのアップデートに加えて、k0sという新しいオープンソースプロジェクトも発表した。同社によると、それは「モダンで100%アップストリームの、特別な機能は何もないシンプルなKubernetesディストリビューションで、妥協のない設計とパッケージングが行われている」という。

k0sは、カーネル以外ではOSへの依存性もない最適化された単一のバイナリだ。アップストリームのKubernetesをベースとするk0sは、IntelとArmのアーキテクチャをサポートし、Linuxホストのすべて、またはWindows Server 2019のワーカーノードで動く。このような要求を元にチームは、k0sはローカルな開発クラスターやプライベートなデータセンター、通信事業者のクラスター、ハイブリッドクラウドのソリューションなど、 事実上どんなユースケースにも使うことができると主張している。

「Kubernetesが使われるさまざまなユースケースのための、モダンで堅牢で多芸なベースレイヤーを作りたかった。何も余計な部分のないアップストリームのKubernetesを利用して、典型的なクラウドベースのデプロイメントから多様なエッジやIoTのケースに至るまで、それらのさまざまなユースケースに十分対応できる多芸なシステムだ。私たちのこれまでの経験から、OSのディストリビューションが違うたびにメンテナンスとセットアップとパッケージングが違うというものにはしたくなかった。そこでパッケージングのモデルは単一のバイナリにして、debやrpmなどパッケージングのフレーバーの違いにわずらわされることなく、コアな問題に集中できるようにした」とMirantisの上級主席技術者でk0sを開発したJussi Nummelin(ユシ・ヌンメリン)氏は述べている。。

もちろんMirantisも、ディストリビューションのゲームにちょっと参戦したことがある。同社初期となる2013年には、初期のメジャーなOpenStackディストリビューションの1つを、結局開発してしまった。

画像クレジット:Mirantis

Lensといえば、その新しいAPIは来週、KubeConにタイミングを合わせたかのようにローンチし、開発者が自分のサービスを拡張して、Kubernetesを統合した他のコンポーネントやサービスをサポートできるようになる。

Lensのオープンソースプログラムを共同で創始し、いまではMirantisの技術長であるMiska Kaipiainen氏(ミスカ・カイピアイネン)は次のように語っている。「拡張APIはテクノロジーのベンダー間のコラボレーションを可能にし、Lensをクラウドネイティブな開発のための機能が完全に揃ったIDEにする。そしてそれをさらに、限りなく拡張強化できる。あなたがベンダーなら、Lensが何万人ものKubernetesデベロッパーに到達できる最良のチャンネルを提供し、製品のこれまで存在し得なかったような流通と配布が可能になる。それと同時にLensのユーザーは、高品質な機能と技術および統合を、前よりずっと容易に享受できる」。

同社はすでにCNCFの人気プロジェクトとクラウドネイティブのエコシステムの中のベンダーたちと協力して、それらとの統合を作っている。それにはKubernetesのセキュリティのベンダーAquaとCarbonetesや、APIのゲートウェイメーカーAmbassador LabsとAIOpsの企業Carbon Relayが含まれる。VenafiやnCipher、Tigera、Kong、そしてStackRoxなども、彼らの機能拡張に取り組んでいる。

「Lensへの拡張APIの導入はKubernetesのオペレーターとデベロッパーにとってゲームチェンジャーだ。なぜならそれは、クラウドネイティブツールのエコシステムを育て、ユーザーは超簡単にそれらを、Kubernetesのコントロールのフルパワーの中で使用できる。今後はKubeLinterをLensと統合して、よりシームレスなユーザー体験を実現したい」とStackRoxのソフトウェアエンジニアでKubeLinterを開発したViswajith Venugopal(ヴィスワジット・ヴェヌゴパール)氏はいう。

関連記事
Kubernetesの統合開発環境のLensをMirantisが買収
Kubernates利用のクラウドサービス、MirantisがDocker Enterpriseを買収

カテゴリー:ソフトウェア
タグ:MirantisKubernetes

画像クレジット:anucha sirivisansuwan / Getty Images

原文へ

(翻訳:iwatani、a.k.a. hiwa

Robin.ioがクラウドネイティブのKubernetesストレージソリューションに無料版を追加

Robin.ioはクラウドネイティブのアプリケーションとデータ管理ソリューション(Robin.ioサイト)で、USAAやSabre、SAP、Palo Alto Networks、楽天モバイルなどに利用されている。そのRobin.ioが米国時間10月20日、新しいフリー(フリーミアム)版のサービスをリリースしたことと、ツールのコアをメジャーアップデートしたことを発表した。

Robin.ioはクラウドネイティブのデータ管理機能をコンテナ化されたアプリケーションに取り入れ、バックアップと復元、スナップショット、ロールバックといった標準的な機能を提供する。ベアメタルのパフォーマンスを実現し、主要なクラウドに対応している。このサービスは基本的に使用されている実際のデータベースには関係なくPostgreSQL、MySQL、MongoDB、Redis、MariaDB、Cassandra、Elasticsearchなどに対応する。

画像クレジット:Robin.io

Robin.ioの創業者でCEOのPartha Seetala(パーサ・シータラ)氏は「Robin Cloud Native StorageはKubernetesベースのどのプラットフォームのどのワークロードでも、またどのクラウドでも動作します。保存、スナップショット作成、バックアップ、クローン、移行、セキュリティ保護の機能を備え、これらをきわめてシンプルなコマンドで利用できます。このRobin Cloud Native Storageを使えば、開発者やDevOpsチームはとてもシンプルでありながらパフォーマンスの高いツールでKubernetes上の企業のワークロードを迅速にデプロイし管理することができます」と語る。

新たに公開された無料版では、最大5ノード、5TBまでのストレージを管理できる。ずっと無料で提供されることになっており、Robin.ioとしては当然、企業が気軽にサービスを試し、その後有料のエンタープライズプランにアップグレードすることを期待している。

米国時間10月20日に同社はエンタープライズプランに関して、ノード時間あたり0.42ドル(約44円)からの従量制の価格に移行することも発表した(ただし年間サブスクリプションも提供する)。エンタープライズプランには365日24時間のサポートが含まれ、ノード数やストレージ容量の制限はない。

Robin.ioのコアストレージサービスの新機能には、Helm Chartsのデータ管理のサポート(HelmはKubernetesのパッケージマネージャ)、データをどこに置くかを正確に指定する機能(たいていはコンピューティングリソースの近くに置くように指定する)、分散データベースやデータプラットフォームに依存するステートフルアプリケーションのアベイラビリティを保証するアフィニティポリシーがある。

カテゴリー:ネットサービス
タグ:Robin.ioKubernetes

画像クレジット:Jacky Parker Photography / Getty Images

原文へ

(翻訳:Kaori Koyama)