MesosphereがデータセンターOS、DC/OSをオープンソース化、パートナーシップとコミュニティの基盤強化がねらいか

logo-horizontal-styled-800x600

MesosphereのData Center Operating System(DC/OS)は、デベロッパーやアドミンがデータセンターをまるで一台のコンピュータのように扱えて、その上でソフトウェアによるコンテナに収めたアプリケーションを運用する、という単純化に徹した抽象化システムだ。それは、クラスタ管理システムのApache Mesosや、スケジューラーChronos、コンテナオーケストレーションプラットホームMarathonなど、多くのオープンソースプロジェクトを利用している。

このほどMesosphereは、DC/OSの完全なオープンソースバージョンローンチして、同社のオープンソース戦略をさらに一歩前進させた。またこれを機に、名前にスラッシュ文字のあるDC/OSを、プロダクトの正式名にした。今やDC/OSを軸とする同社のパートナーは60社以上にのぼり、その中にはMicrosoft, Hewlett-Packard Enterprise(この2社は同社に投資),NGINX, Puppet, EMC, Autodesk, Cisco, Accentureなどがいる。Microsoftはすでに、このオープンソースバージョンを同社のAzure Container Serviceに取り入れている。

Mesosphereは曰く、“DC/OSのすべてのパートナーがコードに初期からアクセスし、各社なりのやり方でプロジェクトの成長と形成を本格的に支援した”、と。

dcos1_7_services_marathon_open

しかしそもそも、DC/OSの主要構成部位は最初からオープンソースだったでなないか? たしかにそうだが、今回同社がオープンソースにするのは、そのGUIやロードバランサーなど、プロプライエタリなツールだった部分だ。DC/OSを独自にハックしたいデベロッパーは、これからは自分が有料のエンタープライズ顧客でなくてもさまざまな機能にアクセスできる。

ある意味でMesosphereは、ソフトウェアのほとんどすべてをオープンにして、その上の特殊なツールやサービスを売るという、オープンソースビジネスの標準形をビジネスモデルにしている。

深夜に突然行われた今回の発表の真のねらいは、オープンソース化そのものよりも、パートナーシップのより強固な育成にあると思われる。GoogleはKubernetesのコアな部分をオープンソース化して、同社自身のデータセンターでプロダクション・レベルのコンテナをどのように管理運用しているかを明らかにすることによって、それを軸とするエコシステムを急成長させた。その中には、Docker, Box, Intel, Red Hat, Twitterなどが支えるCloud Native Computing Foundationもいる。

Dockerにも同社独自の、データセンター向けコンテナ管理システムがあり、その知名度も高く、大きなエコシステムが形成されている。

dcos1_7_universe_selected_packages-400x321@2x

これら3社のプロジェクトは、それぞれ異なるワークロードをターゲットにしているが、しかし長期的には、全社のビジョンが(“実装が”ではなく)ひとつに収斂し、各社はサービスと、提供するデベロッパー体験で差別化を図ることになるだろう。

当然ながらDC/OSのエンタープライズバージョンには、モニタリングツールやエンタープライズのセキュリティとコンプライアンスツール、高度なネットワーキングとロードバランスなど、オープンソース化されていない機能がいくつかある。Mesosphere InfinityMesosphere Velocityも、前からエンタープライズバージョンで提供されているツールの一環だ。

MicrosoftやHPEなどが投資家となり、彼らとのフォーマルな関係を築いたことにより、同社のコアツールの開発はより迅速になるかもしれない。同社の今日の声明は、こう述べている: “Mesosphereでは、全員がオープンソースの熱心な信者だ。オープンソースのソフトウェアは、作者のビジョンの限界を克服することに役に立ち、ユーザーやパートナーやコントリビューターの活発なコミュニティを育てるから、弊社のDC/OSも新しい要求やユースケースを知る機会が増え、より高度に成長していくことができる”。

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

MicrosoftのAzure Container Serviceが一般供用へ…オーケストレーションは主要二社の製品から選べる

shutterstock_145340113

MicrosoftのクラウドコンピューティングサービスAzure用のコンテナスケジューリングおよびオーケストレーションサービスAzure Container Serviceが、一般的に可利用になった。

このサービスではユーザーが、自分たちのコンテナをデプロイおよびオーケストレートするためにMesosphereのData Center Operating System(DC/OS)、またはDockerのSwarmとComposeを選ぶ。サービスが発表されたのは2015年9月で、公開プレビューは今年の2月に行われた。

MicrosoftのAzure担当CTO(でときどき小説家の)Mark Russinovichによると、DockerのSwarm/Composeと、DC/OSのオープンソース部位…どちらもオープンソースプロジェクトがベース…の両方を使えることが、Azure Container Serviceの、コンペティターにはない利点だそうだ。

acs-cluster

Russinovichによると、同社は顧客に、二つのうちのどっちを使え、ということは言わない。“うちのクラウド上で顧客に、どちらか、または両方を使って、グレートな体験をしていただくことが、われわれの仕事”、だそうだ。

MicrosoftとMesosphereの関係は、もうかなり長い。最初同社は、AzureのユーザーがAzure上でMesosphereのDC/OSを使えるという方式を選び、Mesosphereとのパートナーシップにより、WindowsとHyper-VコンテナでもDC/OSを使えるようにした。さらにMicrosoftはMesosphereに戦略的投資を行い、昨年はMicrosoftがMesosphereをその年に買収するという噂もあった。Russinovichはもちろん、買収についてはコメントしないが。

Inbox_–_frederic_techcrunch_com

Microsoftの考えでは、オープンソースのソリューションを使うことによってユーザーは、自分たちのワークロードを、必要に応じてオンプレミスに移すことも容易にできる。また、既存のオンプレミスのソリューションをAzureに移すこともできる。

しかしMicrosoftのこの陣容には、GoogleのKubernetesの姿がない。こちらもやはり、オープンソースのプロジェクトだが。この点についてRussinovichは、あくまでも顧客の要望の多いオープンソース技術を選んだのだ、と言う。Kubernetesはこれまでの要望になかった、ということだが、彼は、Azureが今後それをサポートする可能性がないわけではない、と言った。

Russinovich曰く、今Microsoftは、多くの企業がそのワークロードをコンテナに移しつつある状況を目撃している。“数年前にはdevの連中がテストしているだけだったが、今では全社的にそのプロダクションに採用している”、と。

しかしユーザーは、自分のデプロイに対するサポートを、直接、MesosphereやDockerから得なければならない。今MicrosoftがRed Hatとの契約でやってるような、‘Azureからのサポート’という形には、当面ならないようだ。

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

MicrosoftのマイクロサービスプラットホームAzure Service Fabricが一般公開へ

o92a3327

Microsoftが今日(米国時間3/31)、Azure Service Fabricから“プレビュー”のラベルを外した。それは、ステートフルとステートレスの両方のDockerベースのマイクロサービスを、クラウドとオンプレミスで動かすサービスだ。

Service Fabricは、Microsoft自身もAzureの中核的インフラストラクチャの多くを駆動するために使っており、一般のデベロッパーはこれをMicrosoftの次世代PaaS技術の上で利用することにより、高度にスケーラブルなサービスを構築できる。

このサービスの基本的な考え方は、デベロッパーをアプリケーションのコードに集中させ、オーケストレーションやスケーリングはすべてMicrosoftが面倒見る、というものだ。デベロッパーはService Fabricを使って、自分のコードをパッケージし、デプロイするが、その際、それらを支えるサーバーのアーキテクチャをまったく気にする必要がない。今日のキーノートでMicrosoftは、リアルタイムマルチプレーヤーゲームのAge of Ascentのデベロッパーたちが、Service Fabricを利用してそのマイクロサービスを、必要に応じてスケールアップ/ダウンできるところを見せた。

O92A3314

そのService Fabricが今日から一般公開されるので、MicrosoftはそれをLinuxとWindowsの両方のサーバーでサポートする、と約束どおりの発表をした。どちらの実装も今はまだプレビューだが、それによりデベロッパーはツールをハイブリッドなデプロイ環境でも利用でき、AWSなどほかのクラウド上のランタイムも使えるようになる。

さらにMicrosoftは、Service FabricのプログラミングフレームワークをLinux上でオープンソースにする。

O92A3303

MicrosoftはAzure Service Fabricを、この前のBuildデベロッパーカンファレンスで初めて発表した。ということは、それをSkypeやCortanaなどで、すでに内部的には使っているにもかかわらず、一般供用までには相当の時間をかけたことになる。

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

MesosphereがシリーズCで$73.5Mを調達、HPとMicrosoftの共同投資のような形になる

periodic-table-721x411-ea2b3e75968fbb5dd814f2a2cdc926ec

DockerコンテナとApache Mesosをベースとするクラスター管理サービスMesosphereは、企業のデータセンターに同社の主要プロダクトData Center Operating System(DCOS)を提供して、リソースの管理を単純に一元化し、その有効利用を導く。その同社が今日、シリーズCで7350万ドルを調達したことを発表した。

このラウンドをリードしたのはHewlett Packard Enterprise(HPE)で、既存の投資家Andreessen Horowitz, Khosla Ventures, および新たな投資家としてA CapitalとTriangle Peakのパートナーたちも参加した。これだけでも強力な面子(めんつ)だが、もっとおもしろいのは、Microsoftが戦略的投資家としてラウンドに参加したことだ。

MicrosoftとHPEは共に、Mesosphereを買収してもおかしくない企業だし、実際に昨年は、Microsoftが買収するという噂があった。しかしこれまでのところMesosphereは、そんな話に抵抗してきた。HPEとMicrosoftが同じ企業に投資するのはおかしい、と思えるかもしれないが、実際には両社は昨年の12月に公式のパートナーシップを発表している

本誌の前の記事では、このラウンド…Microsoftの戦略的投資を含む…におけるMesosphereの評価額を6億ドルと書いた。同社の調達総額は、これで1億2600万ドルになる。

MesosphereのCEOで協同ファウンダーのFlorian Leibertによると、同社は今後も継続的にエンジニアリングに重点投資をしていきたい、という。“というのも、従来型の企業は今、‘古いスタック’から‘新しいスタック’へ、われわれの予測よりも急速に、移行しつつある。おたく(TechCrunch/AOL)の親会社であるVerizonも、今ではデータセンターのオーケストレーションのためのプラットホームとしてDCOSを使っている。しかもそういうGlobal 2000社の企業は、エンタープライズ級の営業とサポートを(われわれベンダに)求める。今回のシリーズCも大半はエンジニアリングへの深い投資…データセンターのすべての側面を自動化すること…に充てられるが、同時に、営業やサポートチームへの投資も行っていく”。

HPEを投資ラウンドのリーダーに選んだことについてLeibertは、“MesosphereのDCOSとHPEのハードウェアの組み合わせは最強の提案だから、顧客企業における、データセンターの“旧”から“新”への変容を加速する”、と述べた。Microsoftの参加については、“Microsoftは誰が見ても、世界中のほとんどすべての大企業との、強力な商業的関係があり、また同社はAzureを彼らに提供することによって、大企業顧客をハイブリッド展開のクラウドへ移行させようとしている”、というのがLeibertの見方だ。

今日は、新たな投資ラウンドの発表とともに、新しいプロダクトVelocityのローンチも行われた。Velocityは継続的インテグレーション/継続的デプロイメントのためのツールで、オープンソースのJenkins オートメーションサーバーを利用している。Velocityは基本的にはJenkinsに、MesosphereのコンテナオーケストレーションプラットホームMarathonを組み合わせて、スケーラビリティに優れた継続的インテグレーションのプラットホームに仕立てたプロダクトだ。同社によれば、今すでに多くの企業が、この、Mesos, Docker, Jenkinsの組み合わせをベースとする独自のプラットホームを展開している。Velocityはそれを、“どんなタイプの企業でも”利用できる形にまとめたものだ。

〔参考記事: Apple SiriとMesosとMesosphere

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

CoreOSのコンテナセキュリティスキャナーClairがベータを脱してv.1.0へ

shutterstock_145340113

CoreOSが昨年11月に最初のプレビューを発表した、DockerコンテナのセキュリティチェックツールClairが今日、ベータを終了してClair 1.0のローンチに到達した。

デベロッパーは既製のコンテナに依存することが多く、同じものを再利用することもよくあるから、その中のソフトウェアを安全に保つことはきわめて重要だ。しかも問題はマルウェアばかりではなく、セキュリティの弱点があると分かっている旧版のパッケージが、そのまま使われていることもありえる。

clair-1.0-embed

CoreOSが同社のコンテナレジストリQuayにあるコンテナを調べたところ、検出された脆弱性の約70%は、コンテナの中にあるパッケージをアップグレードするだけで解消するものだった。

“インストールされているソフトウェアを最新バージョンにアップデートすれば、インフラストラクチャの全体的なセキュリティも向上する。したがってコンテナイメージのセキュリティ脆弱性を分析することと並んで、Clairが見つけたそれらの問題を解決するアップデートのための、明確な手順や方式を確立しておくことが重要である”、と同社は主張している。“コンテナイメージは頻繁にアップデートされないことが多いが、しかしClairのセキュリティスキャンニングにより、ユーザーは問題のあるイメージをより容易に見つけてアップデートできる”。

CoreOSによると、最初の発表から今日のv.1.0までに、多くの変更をClairに加えている。それらは、サービス全体をより拡張しやすくすることや、REST APIの改良などだが、Clair 1.0でいちばん重要なのは、検出された脆弱性の詳細説明が提供されることだろう。

coreos_clair_schema

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

次世代SQLデータベースのCrateが$4Mのシード資金を調達、コンテナ環境との相性が売り

3991309955_059841f3d5_o

2014年のTechCrunch Disrupt Europe startup Battlefieldで優勝したCrateが今日(米国時間3/14)、そのオープンソースのSQLデータベース技術に対する400万ドルのシード資金を獲得したことを発表した。

このラウンドをリードしたのはロンドンのDawn Capitalで、これに既存の投資家Sunstone Capital, DFJ Esprit, およびSpeedinvestが参加した。さらにまた、Dockerコンテナの原作者でDocker, Inc.のファウンダー&CTOのSolomon Hykesも投資に加わった。

Hykesは今日の発表声明で、次のように述べている: “Crateの、マスターのないシンプルなアーキテクチャはコンテナ環境に完全にマッチする。マイクロサービスパラダイムを採用するデベロッパーが今後増えるに伴い、広くデプロイされることを期待している”。

CrateのCEOで協同ファウンダーのChristian Lutzによると、同社は今回の追加資金を同社のシリコンバレーにおけるプレゼンスを拡大するために使いたい、という。Crateの中核的な技術者グループはヨーロッパに残るが、合衆国にはプレセールスのエンジニアなどを置き、顧客の増大に備えたい、と。

Lutzによると今年の後半にはシリーズAのラウンドを行いたいが、今回のラウンドがそのためのベースになる。

Lutzは語る、“若いデータベース企業の最大の課題は、信頼と信用の獲得だ”。昨年Crateはシリコンバレーで、有名企業数社を顧客にできた。それらの社名は明かさないが、Lutzによるとセキュリティ企業のSkyhigh Networksが最近Crateに乗り換えたので、今同社はSkyhighのデータベースクラスタを動かしている。それは、数十億件のセキュリティイベントを保存するデータベースだ。

今後の予定としては同社は近く、初のエンタープライズプロダクトをローンチする。それには、データセンターのレプリケーションなども含まれ、Crateのオープンソースコアとは別途のコードになる。

 

〔参考記事: docs, Wikipedia, cloudpack

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

DockerがAuroraによるオーケストレーションサービスのConductantを買収、「運用経験は良質な開発のベース」

conductant

Dockerが今日、オーケストレーションを専門とする小さなスタートアップConductantを買収した、と発表した

Conductantを知らなかった人がほとんどだと思うし、そもそもWebサイトも外部資金の導入経験もまだない企業のようだが、この買収でDockerは相当数の人材を獲得することになる。

Conductantは、Bill FarnerとDavid Chungがファウンダーだ。TwitterにいたときFarnerのチームは、のちにApache Auroraとなるプロジェクトを作った。AuroraはMesosをベースとするスケジューリングシステムで、後者は個々のサーバーを抽象化することによって、デベロッパーやアドミンがクラスターの集合を単一のマシンのように扱えるようにする。Auroraは現在、Twitterなど多くの企業で、そのマシン群のオーケストレーションを担当している。

FarnerとChungとJohn SiroisがDockerに加わる。このチームは、GoogleやTwitterやZyngaで、大規模なミッションクリティカルシステムの構築と運用を長年経験している。

image00-1024x576

Dockerによると、チームはAuroraの商用ディストリビューションを作る仕事を担当する(それはMesosphereなどと競合することになるだろう)。また、AuroraをDocker Swarmに統合する。さらに今後は、AuroraをDockerスタックのコンポーネントとして統合することを目指す。

本誌がもらった内部メモによると、Farnerのチームはほかにも、Dockerの内部的なシステムをいろいろ手がけるようだ。その中には、Dockerの社員一人一人にDockerベースのサンドボックスを与え、個別にAWSのアカウントを持たなくてもよいようにするプロジェクトもある。これをやることを通じてチームは、上述したメインのプロジェクトの一部をドッグフード(dogfood, 毒味)していく。買収が公式に完了するまでの数週間、彼らはすでにそういうことを、やっていたようだ。

“このプロジェクトによって弊社は、Docker DNAの基本的な部分を強化していく。弊社はつねに、自分たちのソフトウェアの運用のプロでもなければならない”、と内部メモには書かれている。“Dockerの誕生も、まさにそのようにして行われた: Dotcloudにおける運用の経験からDockerは生まれたのだ。このように、開発(dev)と運用(ops)のあいだには善循環があり、そのことは、弊社がインフラストラクチャソフトウェアのベンダとして信頼されるための、不可欠の条件だ”。

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

コンテナ化したアプリケーションの総合的一元的管理コンソールDocker DatacenterをDockerが提供

shutterstock_119411227

Dockerが今日(米国時間2/23)、Docker Datacenter(DDC)と名付けた新しいコンテナコントロールセンター(管理者用総合コンソール)を発表した。ユーザー企業は、規模の大小を問わず、このアドミンツールを使ってコンテナの作成や管理、それに配布をコントロールできる。

DDCは、同じく今日発表されたDocker Universal Control PlaneやDocker Trusted Registryなど、さまざまな商用製品で構成されている。また、一部には、Docker Engineのようなオープンソース製品も使われている。DDCのねらいは、Docker化されたアプリケーションの全ライフサイクルを一箇所の中心的なアドミンインタフェイスから管理できることだ。

この新しいツールは、顧客からの強力な要望に押されてできあがった。企業ユーザーはDockerのコンテナから得られるアジリティーを好感しているが、同時にまた、自分たちが作って配布するコンテナのアドミニストレーションやセキュリティ、それにガバナンスを総合的に管理しコントロールしたいと願っている。Dockerのプロマネ担当SVP Scott Johnstonが、本誌にそう語った。

同社はこれを、Containers as a Service(CaaS)と呼んでいる。Johnstonによると、顧客が同社にこのようなアドミン的コントロール機能を求めるとき、そういう言葉を使うことが多かったのだそうだ。

Docker Data Center architecture lets companies, build, ship and run containers.

画像提供: Docker

 

多くのオープンソースプロジェクトがそうであるように、Dockerも最初はデベロッパーたちのあいだで人気者になり、その後彼らが仕事をする企業にも浸透し、そして企業は、使いやすい管理ツールを求めるようになった。

DDCはまさに、そういう要望に応えたプロダクトだ。それはデベロッパーに、コンテナ化されたアプリケーションを作るため必要なアジリティーを与えると同時に、オペレーションに対しては、彼らの仕事に秩序をもたらすツールを提供する。

その典型的な過程は、まずデベロッパーが一連のコンテナ化されたコンポーネントを作り、それらのデプロイをオペレーションが承認し、次いで、完全に証明されたイメージのライブラリにアクセスする。これによってデベロッパーは、車輪を毎回再発明することなく、多様なアプリケーションから必要なピースを取り出すことができる。そしてそれにより、アプリケーションの開発とデプロイがスピードアップされる(コンテナが何よりもまず提供するはずのアジリティが、さらに一層強靭になる)。

DDCのベータのときには、この点がとくにADPにアピールした。この給与管理サービスの大手は、デベロッパーにとって可利用なイメージの集中管理的なリポジトリを企業が持てる点を、とくに気に入った。

ADPのCTO Keith Fultonはこう語る: “わが社の、企業にとってとても重要なアプリケーションを、マイクロサービス化して現代化するイニシアチブの一環として、デベロッパーたちが、IT部門が十分検査してセキュリティを確認したコアサービスの、一元管理されるライブラリを利用できるようにしたい、と考えた。それによって、デベロッパーたちの仕事もスピードアップされるはずだ”。

Dockerは、2010年にファウンダーのSolomon Hykesが最初、dotCloudという名前で作った。そして2013年に、Dockerに改名しコンテナ専門企業に変身した。dotCloudは2014年の8月に売却し、Dockerに専念することになった。

CrunchBaseによると、同社は2年前に、相次ぐ5回ものラウンドで計1億8000万ドルを調達し(うち1億6800万ドルがDockerになってから)、投資ブームに湧いた。投資家たちがそこまでDockerに注目したのは、同社が提供するコンテナ技術がアプリケーション開発を現代化する、と確信したからだ。それは、分散アプリケーションの構築と管理と配布を効率化する、新しい方法だった。

デベロッパーはコンテナ化によってこれらの分散アプリケーションを小さな離散的なピースの集まりとして構成でき、しかもそのアプリケーションは複数のサーバーにまたがって稼働する。それまでの、巨大な一枚岩のような、単一のサーバーの上で動く、アプリケーションではもはやないのだ。

Docker Datacenterの使用料は1ノード1か月あたり150ドルからだ。

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

ひとつのソフトウェアのクラウドバージョンとオンプレミスバージョンを単一のコードベースから開発できるGravitationalのデベロッパサービス

shutterstock_80206504

Y Combinatorを2015年に卒業した Gravitationalは、ソフトウェアのクラウドバージョンとオンプレミスバージョンを一つのコードベースで作る、という難しい問題に挑戦している。

今Gravaitionalが提供しているようなソリューションがなければ、当然ながらコードが二セット必要になり、開発費用が高騰する。顧客が提示する予算額によっては、それはできません、ということすらあるだろう。

GravitationalのファウンダーEv Kontsevoyは、実は2011年のYCのクラスで、自分の最初の企業(起業)Mailgunを立ち上げたことがある。それは120万ドルの資金を調達したが、その後2012年にRackspaceが買収した

買収に伴い、彼自身もRackspaceで数年間仕事をしたが、そのとき彼は、クラウドからSaaSを提供しているソフトウェア企業が抱えている難しい問題に気づいた。そしてそのことが、Gravitationalの起業へと導いた。

まず第一にSaaSの顧客は、そのデリバリ形式の単純さが気に入っている。顧客企業のIT部門に管理コストがあまり発生しない。しかし同時に、データのコントロールは自分でやりたい、と願う顧客企業もある。データを合衆国の外に保存することが法で禁止、または非推奨になっている業種では、なおさらそうだ。

企業のそういう実情を見ながらKontsevoyは同時に、クラウド市場におけるAmazon Web Servicesの隆盛にも気づかざるをえなかった。そして彼が知るオンプレミスソフトウェアのベンダたちの一部は、このパブリッククラウドの巨大な怪物との競合に悩んでいた。

Kontsevoyがこれらのトレンドに着目し始めたとき、それとほぼ同時に、 DockerやGoogle Kubernetesといった、ソフトウェア開発の新しいやり方を可能にする技術が登場してきた。

それを好機と見定めたKontsevoyは、Rackspaceを去りGravitationalを作った。彼はDockerとKubernetesを利用して、複数のコードベースをメンテしなくても好きなやり方でソフトウェアをデプロイできるための、ソリューションを作った。Gravitationalが提供する方法では、コードベースを単一の管理コンソールで管理しながら、クラウドとオンプレムなど、複数のやり方でソフトウェアを配布できる。しかも開発に要する費用や労力は、大きく増えない。

彼は最初の起業の成功経験から、Y Combinatorに参加することの意義を十分に理解していたが、でも、この高名なインキュベータが、彼が最初に参加した2011年に比べて、大きく進化したことも感じていた。

まず、2011年当時に比べるとネットワークのサイズが巨大になり、今ではたくさんのエンタープライズ企業も抱えている。2011年当時は消費者向け企業が圧倒的に多くて、エンタープライズ企業は適切なヘルプを得にくかった。

彼は曰く、“2015年には、YCの卒業生の多くがエンタープライズ企業を作って成功していたから、彼らの経験やコネから得るものが大きかった”。

Gravitationalはすでにある程度の資金を獲得し、初期のベータ顧客も数社抱えている。ただしその数は、公表されない。Kontsevoyによると、年内には10数社のエンタープライズ顧客を確保したい、という。そして、Gravitationalを使うようになって、売上などの業績が上がった、というサクセスストーリーも欲しい、と。

Gravitationalが究極的に目指すものは、ソフトウェア企業が顧客にとっていちばん理にかなったやり方で開発とデリバリとデプロイを行い、それによって、従来以上に売上を伸ばすことだ。それが、オンプレミスであれ、クラウドであれ、何であれ。

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

CoreOSのコンテナエンジンrktがバージョン1.0に到達…プロダクション利用可に

rkt-1-0-banner

CoreOSのコンテナランタイム競合製品rkt今日(米国時間2/4)バージョン1.0に達し、同社によるとプロダクションユースに十分使えるレベルになった。

バージョン1.0ではセキュリティ機能が新たに増え、今後は、CLI(コマンドラインインタフェイス)とオン・ディスクフォーマットのいかなる変更も後方互換性が保証される。

rktは現在、CoreOS App ContinerのイメージおよびDockerのイメージフォーマットでパッケージされたアプリケーションをサポートする。したがって、コンテナをDockerで作って、それをrtkで動かすことが可能だ。

CoreOSがrktプロジェクトを発表したのは2014年の晩(おそ)くで、Dockerランタイムのオルターナティブを提供することがその意図とされた。当時CoreOSのCEO Alex Polviはこう述べた: “Dockerはわれわれみんなが同意できるシンプルなユニットになる、と考えていた。しかし残念ながら、シンプルで再利用できるコンポーネント、という方向には進まなかった。今のDockerは、クラウドサーバーやクラスタリングシステムをローンチするための構築ツールであり、イメージの構築やその実行、アップロード、ダウンロード、さらにオーバレイネットワーキングなど、多様な機能がすべて、一つの一枚岩的なバイナリへコンパイルされ、ユーザーのサーバーの上でもっぱらrootで動いている”。

2016-02-04_1048

rktのローンチとほぼ同時期にCoreOSは、App Container(appc)プロジェクトもローンチした。それは、Dockerコンテナのスペックとイメージフォーマットに代わるものだ。

昨年Dockerは、そのコンテナのスペックをOpen Container Initiative寄贈した。そこは、コンテナ関連の主要選手が全員参加している、オープンソースの連合団体だ。

一見すると、Dockerのこの動きによって傍系のプロジェクト、rktやappcやCoreOSのイメージフォーマットなどは、割りを食うことになりそうだ。でもPolviは今日、“OCIの主な目的はコンテナのランタイム環境のスタンダードを作ることであり、コンテナのイメージの〜〜ではない”、と主張している。

でも、DockerとCoreOSというこの分野の二大勢力が、とても目立つ競争をしていることは、コンテナにとって強力な追い風になるはずだ。標準化プロセスはまだ始まったばかりだから、元気な論争や競争があることは、とても良いことだ。

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

コンテナ指向の開発自動化プラットホームWerckerが$4.5Mを調達、CLIをオープンソース化

オランダのWerckerが今日(米国時間1/28)、450万ドルのシリーズA資金の調達を発表した。

Werckerは、マイクロサービスやアプリケーションの開発を自動化するための、コンテナ指向の開発プラットホームだ。デベロッパーはこのサービスのコマンドラインインタフェイスを使ってDockerのコンテナをデスクトップ上で作り、それらのビルドとデプロイの工程を自動化し、そしてそれらをHeroku、AWS、Rackspaceなどさまざまなクラウドプラットホームへデプロイする。

Werckerは今日、そのコマンドラインインタフェイスをオープンソース化して、“開発とプロダクションとの落差のないワークフローを作り、それによりアプリケーションの改良サイクルを迅速化して、デベロッパーコミュニティの力を強めることに奉仕していく”、とした。

WerckerのシリーズAラウンドをリードしたのはInkef Capitalで、これまでの投資家Notion Capitalも参加した。これにより同社の調達総額は750万ドルになる。

約2億ユーロを抱えるオランダ最大のVCファンドInkef Capitalにとって、デベロッパーツールへの投資は今回が初めてである。

WerckerのファウンダーでCEOのMicha Hernández van Leuffenは今日の発表声明の中で、“Inkef Capitalのポートフォリオの一員になれたことと、今後も引き続いて、アムステルダムの革新的なコミュニティとシリコンバレーのギャップを橋渡ししていけることは、喜ばしい。我が社が情熱的なデベロッパーコミュニティに支えられていることは、幸運である。弊社のオープンソースのCLI技術により、コミュニティはさらに成長を継続できるものと信ずる”、と述べている。

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

コンテナを超えてマイクロサービス技術の広い世界を目指すDockerがUnikernel Systemsを買収

docker_whale_dockerconeu

Dockerが今日(米国時間1/21)、Unikernel Systemsの買収を発表した。この、イギリスのケンブリッジのスタートアップは、unikernel(ユニカーネル)の普及を目指している(少なくとも、デベロッパに対する普及を)。

Dockerは、同社のツールやサービスにユニカーネルのサポートを統合する計画だ。最近の同社は、デベロッパがさらに効率的なマイクロサービスアーキテクチャを構築できるための、コンテナ以外の技術にも着目し始めている。買収の価額は公表されていない。

ユニカーネルとは、オペレーティングシステムを最小限ぎりぎりまでそぎ落として、特定のアプリケーションだけを動かす、というものだ。それ以上のものでも、それ以下のものでもない。アプリケーションが必要とするライブラリも、コンパイルしてオペレーティングシステムのカーネルに置く。

[ユニカーネルによる隔離と専門化]
specialisation

アプリケーションがその上で動くマシン(仮想マシン)は極端に小さく、かつ、高速になり、通常のオペレーティングシステムのようなセキュリティの問題が少ない(攻撃を受け入れるインタフェイス〜入り口がほとんどない)。

そのため、ユニカーネルはセキュリティと効率が重視されるアプリケーションに向いている(セキュアであるべき政府のシステム、リアルタイムのトレーディングプラットホーム、IoTのアプリケーションなど)。

Dockerはなぜ、ユニカーネルに関心を持ったのか? DockerのファウンダでCTOのSolomon Hykesによると、確かにこれは、Dockerが行った買収の中では“いちばん分かりにくい”ものかもしれないが、しかし同時に、彼らにとっては、これまででもっともエキサイティングな買収なのだ。

Unikernel Systemsの13名のチームは、その多くが、Xenハイパーバイザーを手がけたデベロッパだ。Unikernel Systemsはユニカーネルのエコシステムと、そのオープンソース部分に対する、主要な貢献者だ。Hykesによると、Dockerもそのコミュニティへの貢献は積極的に継続していく。

この買収により、Docker自身も大量の深い技術的知識をユニカーネルの世界に持ち込むことになる。“Dockerプラットホームがスタックのずっと下の方〔カーネルレベル〕でも問題解決に向けてきわめてアグレッシブであることを、お分かりいただけるだろう”、とHykesは述べる。“今回の買収はわれわれに、これらの問題を解決するための、さらに多くの能力を与える”。

でもそれは、この買収のひとつの側面にすぎない。Dockerといえば誰もが“コンテナ”を連想するが、しかし同社自身はDockerをコンテナに限定されないエコシステムと考えているようだ。その見方に立てばDockerは、マイクロサービスを推進する中心的な力であり、したがってユニカーネルの採用も、きわめて論理的な次のステップだ。

コンテナによってデベロッパは、“小さいことの味を知った”、とHykesは語る。彼のこの見方では、ユニカーネルは、ペイロードをVMからコンテナへ、コンテナからユニカーネルへと縮小していく路線の上にある。

しかし彼は、それが必ずしも、後者が前者を置換する過程であるとは考えていない。ユニカーネルの利用には、トレードオフが伴う…主に互換性やツールの部分で。Dockerは近い将来、同社独自のツールにユニカーネルのサポートを統合する計画だ。“誰も求めていないのは、三つの完全にばらばらなツール集合だ”、と彼は指摘する。“これはVM用、これはコンテナ用、そしてこれはユニカーネル用、なんてね”。

実は、昨年のDockerCon Europeで気づいた方もおられるかもしれないが、そのときからユニカーネルはすでにDockerの予定表に載っていた。Dockerはある短いデモで、同社のツールを使ってユニカーネルのデプロイメントを管理する例を見せたが、そのデモをステージ上で行ったのは、Unikernel SystemsのCTOで、MirageOSのプロジェクトリードAnil Madhavapeddyだった。MirageOSは、ユニカーネルを構築するための、オープンソースのライブラリオペレーティングシステムだ。

 

参考記事。〕

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

OracleがDocker運用管理サービスのStackEngineを買収、経営の軸足はますますクラウドへ

2500129881_55a8fb5f90_b

長年クラウドを馬鹿にしていたOracleが最近は逆にそれを、ものすごく重視している。先週ひそかにStackEngineを買収したのも、同社のPaaSの提供物をさらに一層充実させるためだ。

テキサス州オースチンのStackEngineは、同社のWebサイト上の短い声明で、Oracle.comへの合体を説明している。それによると、データベース大手のOracleが同社を買収し、その条件の一環として社員は全員Oracleに加わる。

StackEngineは昨年、二人のベテラン技術者たちが創業し、Dockerの運用管理を提供するサービスとして2014年10月にステルスを脱した。オープンソースのコンテナシステムであるDockerは、最近の数年間で、猫も杓子も使う日用品のような、普遍的人気者になっているが、それ自体は、ITのプロたちがアドミニストレータとしてコンテナを管理するための機構を欠いていた。StackEngineは、そのことに着目した。

ChefやPuppetとスクリプトを使えばそんな管理層を作ることは可能だが、StackEngineは、もっと最初からDockerに特化された適正な管理コンソールを提供したい、と考えた。今回の買収までに同社は、二度のラウンドで計450万ドルの資金を獲得している。

単独で見ればこの買収は、Oracleの買い物としては奇妙に見えるかもしれないが、むしろこれは、もっと大きな同社のクラウド計画の一環だ。同社は今年、クラウドに向かう大きな数歩を踏み出したが、今回の買収はDockerコンテナに直接関連していて、Oracleのコンテナ市場への参入と、その市場の将来性に賭ける姿勢を表している。

この買収はDockerにとって有意義だったかもしれないが、Dockerはこの前、競合製品Tutumを買収しており、そのほかのコンテナ管理スタートアップにとっては状況が不利になったかもしれない。Docker自身が選んだ管理レイヤが、Tutumなのだ。

Oracleは別の声明で、StackEngineの本拠地オースチンに新たにクラウド専用事業所を作ると言っている。その近くに、クラウド担当社員のための住宅も買うらしいから、今後の人材獲得策も含め、このプロジェクトへのOracleの“本気度”が伺える。

今月初めに発表された決算報告(.pdf)でOracleは、クラウドの売上が26%伸びて6億4900万ドルである、と言っている。その内、PaaSの売上は4億8400万ドルで34%伸びている。対して、オンプレミスの売上は7%ダウンだ。同社の、未来に向けての伸びしろはクラウドにしかない、ということか。

StackEngineにとっては嬉しいイグジットパス、そしてOracleにとってはPaaSの持ち駒のさらなる充実だった。今建設中のオースチンキャンパスは、2016年のOracleの新しい動き(新たな買収、プロダクト開発など)のメインの舞台になるだろう。

〔訳注: ここにグラフが表示されない場合は、原文を見てください(Oracle企業プロファイル)。〕
[graphiq id=”5kqMqbO7qrH” title=”Oracle Corporation (ORCL)” width=”700″ height=”461″ url=”https://w.graphiq.com/w/5kqMqbO7qrH” link=”http://listings.findthecompany.com/l/12055771/Oracle-Corporation-in-Redwood-City-CA” link_text=”Oracle Corporation (ORCL) | FindTheCompany”]

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

CoreOSのコンテナ管理サービスTectonicが完全な暗号化保証によりコンテナ採用システムのセキュリティを強化

shutterstock_174080105

ソフトウェアを開発しデプロイする方法としてコンテナの人気がますます大きくなりつつあるが、しかしそれとともに、コンテナのデプロイのセキュリティという問題も、ますますクローズアップされてきた。コンテナのセキュリティに関しては、これまでにもDockerCoreOSなどの取り組みが見られるが、CoreOSは今日、それをさらに一歩進めて、同社のKubernetesベースのコンテナ管理サービスTectonicのために、”Distributed Trusted Computing“と呼ばれるセキュリティサービスをローンチした。

このサービスは企業のシステム環境の全体、ハードウェアからアプリケーションに至るまでのすべての層に、暗号化によるセキュリティの保証を与える。ハードウェアのレベルでは顧客の暗号キーがハードウェアのファームウェアに組み込まれ、一方オペレーティングシステムのCoreOSはブート時に、いじられていないことを確認する。またコンテナは、信頼できる鍵で署名されているものしか、動かせない。

CoreOSのCEO Alex Polviが、今日の発表声明で述べている: “セキュリティは弊社CoreOSの中心的なミッションである。まったく新しい種類のコンピューティングを市場に導入することは容易ではないが、その大きな阻害要素であるセキュリティは、Distributed Trusted Computingで担保できる。これは企業のセキュリティ能力を一挙に高めるものであり、初めての、完全に暗号化が保証されたエンドツーエンドのデータとコンピューティングおよび環境の、制御能力を提供する”。

しかし、これらの新しい機能がユーザをTectonicプラットホームに縛り付けることはない。

コンテナを使ったソリューションのデプロイが、今後の企業現場で増加するに伴い、CoreOSが提供しているようなセキュリティ機能が必須のスタンダードになるだろう。Dockerも暗号による署名を新しいコンテナのデフォルトにしようと努めている。でも現状では、コンテナのセキュリティ機能・サービスがいちばん進んでいるのはCoreOSだろう。

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

Dockerアプリケーションの有料の総合デプロイ&管理サービスをDocker自身が制作し発表

docker_control_plane

Dockerが今日(米国時間11/16)バルセロナで行われた同社のデベロッパカンファレンスで、商用のDockerデプロイ総合サービスDocker Universal Control Plane(UCP)を発表した。Dockerの有料サービスUCPは、opsチームによるクラスタのセットアップを容易化し、またそのクラスタに載るアプリケーションのデプロイを、デベロッパ向けに支援する。

Dockerのプロダクト担当VP Scott Johnstonによると、これまではつねに、Dockerなどの新しい技術を採用したいデベロッパと、会社のインフラストラクチャの安全性と信頼性を優先しなければならないITのオペレーションチームとのあいだに、対立があった。しかしスピードとセキュリティの両立は難しいので、何らかのトレードオフに落ち着くのが常だった。

今回の新しいツールを使うと、デベロッパはグラフィカルなユーザインタフェイスとDockerの標準のコマンドラインを使ってセルフサービス的に仕事ができ、一方ITはITでインフラストラクチャのデプロイと管理ができる。

docker_control_plane_schematics

Johnstonの説明によると、このプロダクトは基本的にはDockerの既存のツール(DockerネイティブのクラスタリングマネージャDocer Swarm、Docker Engine、Docker Compose、などなど)をラップするものだが、それだけでなく、エンタプライズが必要とするコントロール機能が大量に盛り込まれている。たとえばUCPは、既存のLDAPやActive Directoryのインストールを統合し、アドミンが個々のクラスタやアプリケーション、コンテナ、それにイメージなどをコントロールできるようにしている。

またユーザオーディットのログをとれるし、最初からTLS(標準化SSL)をサポートしている。アドミンとユーザには、クラスタをモニタリングするためのグラフィカルなツール集が提供される。

エンタプライズはUCPを使って、ローカルなクラスタと、パブリッククラウドに置いたクラスタの両方をコントロールできる。このサービス自身がDockerの標準APIを全面的に使っているので、Dockerに慣れているデベロッパにとってはきわめて使いやすいはずだ。

しかも、ということはこのサービスは、Docerのエコシステム中の既存のいろんなサービスでもって、容易に拡張できることを意味する。たとえば、もっと高度なモニタリング機能が欲しければ、そんな既存のサービスを見つけてプラグインすればよい。

tutum_ucp

Dockerは先月、Dockerアプリケーションをクラウドからデプロイし管理するクラウドベースのサービスTutum買収したが、いろんな点でUCPは、それのエンタプライズ向けオンプレミスバージョンと言える。

UCPは今非公開ベータだが、ここで登録できる。料金の発表はなく、また、いつ一般公開されるのかも、現時点では不明だ。

control_plane_2

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

Hewlett Packard Enterpriseは今後何もかもコンテナが主軸…ハイブリッドクラウドをメインにしつつ

hpe_container

Hewlett Packard Enterprise(HPE)が今日(米国時間11/16)、バルセロナで行われたDockerのデベロッパカンファレンスで、同社のデベロッパ関連製品のアップデートをたくさん発表した。HPEのコンテナにかける意欲には、並々ならぬものがあるようだ。

HPEのインキュベータパートナー担当VP Tana Rosenblattは次のように語る: “コンテナは確かに画期的な技術だが、それは単に新しい技術であるだけでなく、ハイブリッドな環境を求める企業にとっても意味がある。今後のDockerとの、きわめて有意義なパートナーシップにより、その優れたやり方とプロダクトの恩恵に与れると期待している。その際のわが社の戦略は、受容して拡張せよ、だ。弊社には、devとopsおよび両者を結びつけることに関連した知財がたくさんある。それらをDockerと組み合わせれば、弊社のエンタプライズ顧客にさらに高い価値を提供していけると信ずる”。

HPEには今日ローンチしたハイブリッドクラウドのためのPaaS Helion Development Platform 2.0があり、それが最初からデフォルトでDockerをサポートする。したがってデベロッパとITオペレータはたとえば、このサービスを使って、Dockerコンテナとしてパックされたマイクロサービスをデプロイできる。

HPEにはさらに、クラウドの負荷とパフォーマンスをテストするStormRunnerと、モバイルのパフォーマンスモニタツールAppPulseがあり、これらもDocker化されたアプリケーションのデプロイとモニタリングをサポートする。

HPEのクラウドモニタリングツールSitescopeも、これからはDockerのSwarmクラスタをサポートする。それによりアドミンは、Dockerのクラスタのすべての層…Swarmからコンテナの個々のワークロードを実際に動かすDockerのデーモンに至るまで…をマップしモニタできる。

さらにまた、リリース管理サービスHPE CodarもDockerをサポートし、ストレージ配列3PAR StoreServとソフトウェア定義ストレージStoreVirtualもDockerイメージをサポートする。

以上すべてをひっくるめて、HPEは近いうちに24×7のエンタプライズコンテナサポートを開始し、Dockerのリファレンスアーキテクチャとデベロッパ向けの新たなリファレンスガイドが、ハイブリッド環境にコンテナをデプロイしたいユーザに提供される。

Rosenblattによると、HPE(当時のHP)が、コンテナに全(まる)がけすることを意思決定したのは1年半前だ。HPはこれまでさまざまなアーキテクチャのコンテナ技術をトライしてきたが、コンテナへのフルコミットメントの契機になったのはDockerだ。“今というタイミングを決めたのがDockrだ”、と彼女は述べている。“それへ向かって全社が動き始めたのが1月であり、これからのHPEは、フィジカルからクラウドまでのすべてのソリューションにおいて、顧客にはコンテナによるソリューションを提供していきたい”、というのだ。

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

コンテナのセキュリティをモニタするオープンソースツールClairをCoreOSがローンチ

Container

データセンターのための軽量Linuxディストリビューションとして人気のCoreOSは、コンテナにも熱心だ。今日(米国時間11/13)同社は、コンテナのセキュリティをモニタするオープンソースのツールClairをローンチした。そしてその、まだベータのClairを、同社の有料のコンテナレジストリサービスQuayに統合する。その統合は、今後予定されているQuay Enterpriseでサポートされる。

コンテナはデベロッパの仕事を楽にしてくれるが、Linuxディストリビューションが脆弱性対策のためにたえずアップデートしているのと同じく、コンテナに収めたソフトウェアにも更新が必要な場合がある。たとえばCoreOSによると、同社のQuayサービスに保存されているDockerイメージの80%以上は、悪名高いHeartbleedバグへの対策をしていない。

coreos_clair_schema

Clairは、コンテナをスキャンして既知の脆弱性を探し、問題をデベロッパにアラートする。そのためにCoreOSは、Red HatやUbuntu、Debianなどの脆弱性データベースを参照する。

Clairのチームはこう書いている: “ソフトウェアには脆弱性がつきものだ。したがって、良質なセキュリティの実践によって事故に備えなければならない。とくに、セキュアでないパッケージを見つけ、それらをなるべく早くアップデートすることが重要だ。Clairは、コンテナの中にあるかもしれない、セキュアでないパッケージの発見を助ける”。

チームによれば、このツールの現状はまだまだ幼稚だ。Heartbleedは、このバグのあるOpenSLLのパッケージを使っているときにのみ、起きる問題だ。現状のClairは、コンテナにパッケージがあることは見つけるが、それが実際に使われているかいないかの判断はしない。“Clairにはそこまでの分析はできないので、その後のより深い分析が必要だ”、とClairのチームは言っている。

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

Googleが主力のコンテナサービスContainer RegistryとContainer Engineをアップデート…Kubernetesを統合など

docker-google

今年GoogleはContainer RegistryContainer Engineなどにより、同社のCloud Platform(IaaS)のコンテナ対応化にますます力を入れてきた。そして今日(米国時間11/10)は、この二つのサービス(ないしツール)のアップデートが発表された。

Container Engineは、クラスタの管理を自動化しコンテナの展開をオーケストレーションするGoogleのサービスだが、今回のアップデートでKubernetesの最新バージョン(version 1.1)をサポートすることになった。ニューバージョンでは随所にパフォーマンスの改良が行われ、そしてそれがContainer Engineのユーザにも可利用になった。

これによりContainer Engineでは、ポッド(pod, ノードの集合)の水平的スケーリング(クラスタへのサービスの追加)を自動的に行えるようになり、またHTTPのロードバランサも可能になる。後者では、トラフィックがその量に応じて別のKubernetesサービスへルートされる。

また、ネットワークのスピードも向上した。それにはContainer EngineにネイティブIPテーブルを導入し、CPUのオーバヘッドをほとんどなくし、信頼性を向上させたことなどが含まれる。

Container Registry(Dockerイメージのストレージ)の方も、今日同様のアップデートが行われた。それらはAPIのv2、パフォーマンスを40%アップ、高度な認証のサポートなどだ。高度な認証により、CodeshipやCircleCI、Drone、Jenkins、Shippable、Werckerなどの継続的なデリバリシステムを容易に統合できるので、デベロッパの仕事が相当楽になるはずだ。

Googleはまた、TwistLockとパートナーして、コンテナのためのセキュリティサービスを導入した。たとえばContainer Registryのユーザは、その上のコンテナへのアクセスポリシーを、設定できる。

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

CoreOSのKubernetesベースのコンテナプラットホームTectonicが今日から一般供用へ

Container

数か月前にCoreOSは、Tectonicのプレビューをローンチした。それはGoogleのコンテナ管理/オーケストレーションツール、Kubernetesを使用するコンテナプラットホームだ。今日からそのTectonicが、ベータを脱する。

CoreOSのCEOで協同ファウンダのAlex Polviによると、チームはベータ期間中に数百の顧客と協働してバグなどを見つけ、それらを修復した。そして、一般公開OKと判断した。

まだ料金体系は未定だが、クラスタのメモリ使用量に応じて課金されるだろう、とPolviは言っている。つまり、メモリの使用量が増えれば料金も上がる。“コンテナの最大のメリットの一つが、クラウドと自前のデータセンターの両方に透明に跨(また)がれることだ。そんな環境ではノード数による公平な課金はできない”、とPolviは述べる。

Polviによると、Tectonicの現在の顧客はきわめて多様だが、とくに多いのは、これから基本業務をWebサービスとしても提供しよう、というところ、たとえば銀行や通信企業などだ。どちらもこれまでは、物理店舗におけるカウンター接客が主だった。

今日CoreOSはTectonicの一般供用開始の発表と並行して、ベルリンにエンジニアリングのオフィスを開設したことを発表した。また、同じく今日からは、Google Compute Engineを立ち上げ、Kubernetesプロジェクトにも貢献したJoe Bedaが、CoreOSの顧問団に加わる。

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

コンテナ化したアプリケーションがベアメタル級の速さで動くクラウドホスティングサービスCarinaをRackspaceが立ち上げ

carina_photo

Rackspaceが最近ますます、コンテナに深入りしてきた。その同社が今日(米国時間10/27)、コンテナサービスCarinaのベータローンチを発表した。Carinaは完全な管理サービスを伴うコンテナ環境で、ベアメタルのパフォーマンスを提供するとともに、デベロッパがローカルに使い慣れていたDockerツールをすべて提供する。

Carina_by_Rackspace

Rackspaceのプロダクト/ストラテジ担当SVP Scott Crenshawと上級ソフトウェア設計技士Adrian Ottoによると、チームはとくに、高速で使いやすくて、コンテナ環境を使うときの複雑性をすべて隠した開発/運用環境の提供を目指した。OttoはOpenStackによるコンテナプロジェクトMagnumをリードし、Carinaはその上で動く。

このベータは長期に及ぶと想定されるが、その期間中はサービスを無料で利用できる。最初はDocker中心だが、長期的にはMagnumとOpenStackの柔軟性を生かして、KubernetesやMesosなどそのほかのコンテナオーケストレーションエンジンも使えるようにしていく。

Carinaによる、マルチテナント環境とベアメタルに近いパフォーマンスの組み合わせは、高性能なシステムをローコストで提供できる、とチームは信じている。Ottoによると、高度なセキュリティを目指した場合、マルチテナントのシステムは必ずしも最適の選択ではないかもしれないが、ユーザにはRackspaceのプライベートクラウドサービスを利用する選択肢もある。

carina-demo-simple-f7cdab95adada0da1d9436d6f65de0d6befd5c3042990696b0f6760f8dff17f4

同社のこれまでの経験に基づいて選ばれたデフォルトの集合があり、ユーザは通常、それらのデフォルトの上でサービスを利用する。ただしもちろん、細部の変更は自由だ。Ottoはによると、多くのユーザがコンテナオーケストレーションエンジンとしてデフォルトのDocker Swarmをそのまま使い続けるだろう、という。癖の強いKubernetesに比べれば、Swarmの方が(重要な項目における)デベロッパの自由度が高いそうだ。

このサービスは従来的なハイパーバイザを使わない設計(代わりにlibvirt/LXCを使用)なので、従来からの仮想マシンを使うサービスに比べてコンテナの始動が相当に速い。しかしセキュリティなどの面で仮想マシンにこだわるユーザもいるので、今後は仮想マシンもサポートしていく予定だ。

大手のパブリッククラウドのベンダたち(Google, AWS, Microsoft)は今こぞって、独自にコンテナサービスを提供している。しかしRackspaceのサービス(Carina)は、それらよりも速いだけではなく、コンテナを抽象化して(物理的細部を隠して)デベロッパに提供している。それに、Rackspaceとしては当然ながら、競合他社よりも一段レベルの高いサービスを提供できる、とチームは信じている。

Rackspaceはこれまで、多くのパートナーと組んで非公開ベータを行ってきた。たとえばO’Reilly Media社は、オンラインの学習ツールをコンテナを使って動かしている。DrupalやWordPressのホスティングサービスPantheonは、かなり前から、プラットホームのコアにコンテナを利用している。

本番供用になった場合の料金体系を同社はまだ発表していないが、Ottoは、同じワークロードをほかのパブリッククラウドサービスで動かした場合よりも相当安くなる、と約束している。

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