ソフトウェア自動化プラットフォームのChefを開発ツールメーカーのProgressが買収

ボストンを拠点として各種の開発者向けツールを開発しているProgressが、ソフトウェアオートメーションプラットホームのChefを2億2000万ドル(約233億円)で買収することを発表し、そのプロダクトを大幅に拡大することになった。

Chefは昨年完全なオープンソース(未訳記事)になったが、その商用化努力により7000万ドル(約74億円)の年間経常収益を得ていた。しかしProgressはChefのその収益を手にするだけでなく、高度なスキルを持つ社員たちと、強力なデベロッパーコミュニティ、そして素晴らしい顧客リストを獲得する。

ProgressのCEOであるYogesh Gupta(ヨゲシュ・グプタ)氏によると、Chefは彼の企業の買収哲学によく合っている。「この買収は弊社の成長戦略に完璧にフィットし、これまで構想してきた要求にも合っている。それは、強力な経常収益モデルと、弊社の事業を補完する技術、忠実な顧客ベース、そして弊社の経営モデルとインフラストラクチャを利用してビジネスをより効率的に動かす能力だ」と同氏は声明で述べている。

ChefのCEOであるBarry Crist(バリー・クリスト)氏は、買収される企業によくあるタイプの主張を述べている。「Progressは今後の成長のためのより良い道筋を提供し、またオープンソースのコミュニティと顧客にProgressがChefのビジョンの良き支持者であるというメッセージを送る」と。

クリスト氏は声明で「Chefにとっては、この買収は次の章です。Progressは弊社の成長ポテンシャルの強化を助け、弊社のオープンソースのビジョンをサポートし、私たちの顧客とパートナーと従業員とコミュニティに、より幅広い機会を提供するでしょう」と述べている。

Chefの顧客リストは確かに素晴らしく、Facebook、IBM、SAPなどテクノロジーの大物と並んで、Nordstrom、Alaska Airlines、Capital Oneなどの一般企業も名を連ねる。

Crunchbaseのデータによると、同社は2008年の創業で、これまでに1億500万ドル(約111億円)を調達した。2015年にDFJ GrowthがリードするシリーズEで4000万ドル(約42億円)を調達してからは、大きな資金調達がない。同社を支えてきた投資家としてはほかに、Battery Ventures、Ignition Partners、およびScale Venture Partnersなどが挙げられる。

この買収は規制当局の承認を得て完了するのが来月と予想されている。

関連記事:Chef goes 100% open source(未訳記事)

画像クレジット:KrisCole / Getty Images
[原文へ]

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

DevOpsのためのモニタリングと試験プラットフォームのChecklyがシードで2.4億円相当を調達

DevOpsチームのためのモニタリングと試験のプラットホームを開発しているベルリンのChecklyが米国時間4月28日、Accelがリードしたシードラウンドで225万ドル(約2億4000万円)を調達したことを発表した。エンジェル投資家でInstanaのCEOであるMirko Novakovic(ミルコ・ノバコビッチ)氏やZeitのCEOであるGuillermo Rauch(ギジェルモ・ラウフ)氏、Twilioの元CTOであるOtt Kaukver(オット・カウクバー)氏らも、この投資に参加した。

同社のSaaSプラットホームを利用することでデベロッパーは、彼らのAPIエンドポイントとウェブアプリケーションをモニタし、異変の警告を受けることができる。そのトランザクションモニタリングツールを使えば、フロントエンドのウェブサイトの試験を定期的に繰り返し行うことが容易になり、コードは一行も書く必要がない。この試験ソフトウェアはGoogleのオープンソースのPuppeteerフレームワークを使っており、そしてその商用のプラットフォームを開発するためにChecklyはさらに、Puppeteer Recorderというものを開発して、エンドツーエンドの試験スクリプトをローコードツールの中に作り込んでいる。デベロッパーはそれに、Chromeのエクステンションからアクセスする。

モニタリングツールの市場は混み合っているが、Checklyのチームはエンドツーエンドの試験とアクティブモニタリングの組み合わせ、およびモダンなDevOpsチームへのフォーカスが自分たちの強みだと考えている。

創業者のTim Nolet(ティム・ノレット)氏は 「モニタリングの市場の1人の顧客として、それらのツールは90年代にずっと行き詰まりになっていて、チームをJavaScriptでサポートし、DevOpsのチームの中のいろんな役割で使えるツールが必要だと感じていた。自分で作り始めてみてすぐに気づいたのは、モニタリングと同様に試験も重要だということだ。Checklyで開発したのは、顧客が以前からずっと求めていたような新しいタイプのツールだ。評価は口コミですでに相当広がっている。DevOpsのチームに信頼されるプラットフォームというビジョンの今後の構築に向けて、Accelをパートナーにできたことは非常にうれしい」と語っている。

Noletの共同創業者は、TestObject(後にSauce Labsが買収)を創ったHannes Lenke(ハネス・レンケ)氏と、Saucd LabsのEMEA担当営業部長だったTimo Euteneuer(ティモ・オイチューニア)氏だ。

同社によると現在の顧客は約125社で、同社のプラットフォーム上で1日に100万回のチェックを行なっているとのこと。料金は個人デベロッパーなら月額7ドル(約750円)から、小さなチームのためのプランは月額29ドル(約3090円)となっている。

[原文へ]

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

Atlassianがデータセンターアプリケーションをコンテナに入れて管理を容易に

5月20日〜23日、Linux Foundation主催で行われたKubeCon + CloudNativeConカンファレンスの大量の発表の中で、特に目立ったのがAtlassianだ。

同社はデベロッパーの効率的な仕事を支える開発ツールでよく知られている企業だが、最近ではクラウドインフラストラクチャのプロバイダーとしても台頭してきた。でも、このコンテナ化の時代においては、AtlassianといえどもKubernetesの栄光の輝きをその肩に浴びざるをえない。そこで同社はカンファレンス初日の5月20日に、チャネルパートナーのPraqmaがAtlassian Software in Kubernetes(ASK)をローンチしたことを発表した。それは、エンタープライズがJira Data Centerなどのオンプレミスアプリケーションを、Kubernetesを利用してコンテナとして動かし管理できる、という新しいソリューションだ。

Praqmaは現在、ASKをオープンソースで提供している。

同社は今日の発表の中で言っているが、データセンターアプリケーションを動かして高い可用性を確保することは、今日までの方法では膨大な作業になる。AKSを使ってアプリケーションをコンテナ化すれば、スケーリングと管理は容易になるはずだ。ダウンタイムも避けやすくなる。

Praqmaのチームはこう説明する。「ASKでは可用性が鍵だ。自動化によって、ミッションクリティカルなアプリケーションは何が起きても動き続けるようになる。もしもJiraサーバーが落ちたら、Data Centerアプリケーションは自動的にトラフィックを健康なサーバーへリダイレクトする。アプリケーションやサーバーがクラッシュしたら、Kubernetesが新しいアプリケーションを起動して自動的に解決する。Jiraのゼロダウンタイムアップグレード、というものもある(正常稼働を続けながらのアップグレード)」。

AKSはスケーリングと多くのアドミンタスクを担当し、オープンソースのGrafanaとPrometheusをベースとするモニタリングも提供する。

さまざまなベンダーが、今ではコンテナを最良のディストリビューションメデイアとして使っている。エンタープライズが既存のアプリケーションをコンテナに移行させていくと、同じシステムにある、サードパーティベンダーからの既存のオンプレミスアプリケーションも同様に管理できると思うようになる。一部のベンダーにとっては、これによってサーバーごとのライセンスからユーザーの人数割りのライセンスへの移行を意味するかもしれない。その意味ではこれはビジネス上の含意もあるけど、でも一般的には、多くのベンダーにとって論理的な動きだ。

[原文へ]

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

自動化ソフトウェアデリバリのためのパッケージマネージャーOrbsをCircleCIがローンチ

DevOpsプラットホームCircleCIが今日(米国時間11/7)、新しいパートナー事業を発表した。それによりこのプラットホームがオープンになり、サードパーティのツールを統合できるようになる。加えて同社は、パッケージマネージャーOrbsをローンチする。同社によるとそれは、“世界で初めての、ソフトウェアデリバリ自動化の構成のため専用のパッケージマネージャだ”。

今年初めに3100万ドルを調達したばかりのCircleCIは、競争の激しい継続的インテグレーションとデリバリの世界に、しっかりと根を下ろしつつある。今日発表されたローンチパートナーは、Cypress, JFrog, Pulumi, Sauce Labs, Sonatype, WhiteSourceなどだ。

そのパートナー事業はしかし、主にOrbsのためのステージになる。Orbsの考え方は、同社のユーザーに、彼らが好むCI/CDの構成を複数のチームやプロジェクトにわたって共有させ、彼らがそのコマンドやエグゼキュータ、ジョブなどを数行のコードで指定できるようにする。それは基本的には、チームがそのビルド/テスト/デプロイのワークフローをさらに自動化して、彼らのソフトウェアパイプラインを構成するためのベストプラクティスを共有する方法だ。新規ユーザーにとってOrbsは、大量の決まりきったコードを書かなくても容易に利用を開始できる。

CircleCIは、同社自身の証明されたOrbsと、パートナーが書いたそれらを提供する。現在あるOrbsは、Heroku用、Amazon S3用、CodeDeploy用など、また、お決まりのSlack通知Orbもある。全部で今日CircleCIがローンチするパッケージは、25ある。

“CircleCIのOrbsはCIの世界で、Dockerのコンテナ以後もっともエキサイティングなシステムだ”、こう語るCypressのエンジニアリング担当VP Gleb Bahmutovは、Orbsのアーリーアクセスカスタマーでコントリビューターでもある。“デベロッパーにとってOrbsは、これまでの‘ドキュメンテーションを読んでサンプルコードをコピペして30分いろいろやってやっとCIが終わる’というやり方に代わる、待望の工程改良だ”、と彼は言っている。

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

使い慣れたプログラミング言語を使ってクラウドのインフラストラクチャを管理できるPulumiが商用バージョンを開始

シアトルのPulumiを使ってデベロッパーは、自分が知っているプログラミング言語を使ってクラウドインフラストラクチャを指定しそれを管理できる。同社は今日(米国時間10/22)、Madrona Venture GroupがリードするシリーズAのラウンドで1500万ドルを調達したことを発表した。Tola Capitalがこのラウンドに参加し、同社のマネージングディレクターSheila GulatiがPulumiの取締役会に加わる。Madronaからはすでに、元Microsoftの役員でMadronaのマネージングディレクターS. SomasegarがPulumiの取締役会に加わっている。

資金調達の発表に加えてPulumiは今日、その商用プラットホームをローンチした。それは、同社のオープンソース製品をベースとするものだ。

Pulumiの協同ファウンダーでCEOのEric Rudderはこう語る: “これまでは企業とコミュニティの両方からの関心がどちらも大きくて、彼らから大量のオープンソースのコントリビューションが寄せられている。たとえばVMwareとOpenStackのサポートは、コミュニティの尽力によるものだ。だからうちでは、オープンソースのコミュニティの活力が大きいが、それと同時に、商用化への関心も大きかった。つまり企業のチームはPulumiの運用面の充実を求めており、それを彼らのプロダクションに入れることと、プロダクトとして購入できることを要望していた”。

そこで、その機会に応えるべく同社は、チームとプロダクトの両方に底入れするために、新たな資金調達を決意した。そして今では、そのプロダクトには商用バージョンの‘team edition.’(チームエディション)が含まれ、この新しいエンタープライスバージョンには、ユーザー数を限定しないサポートと、サードパーティツール(GitHub、Slackなど)の統合、ロールベース(役割に基づく)のアクセスコントロールとオンボーディング(研修など)、そして12×5のサポート(月-金、昼間のみ)が含まれる。無料でシングルユーザーのコミュニティエディションと同様、このチームエディションもSaaSプロダクトとして提供され、すべてのメジャーなパブリックおよびプライベートクラウドプラットホームへのデプロイをサポートする。

Pulumiへの投資の動機を聞くとTolaのGulatiはこう答えた: “クラウドは今や規定の結論だ。でもエンタープライズがクラウドへ行こうとすると、厄介な問題を多く抱える。しかも、今のエンタープライズは、仮想マシンとコンテナとサーバーレスのすべてを理解し使いこなせねばならない。しかもそれを、1)単一のツールセットで、2)実際のプログラミング言語を使って、3)今日的な最新のスキルを使い、そして4)企業にとってもっとも有効にクラウドを利用しなければならない。率直に言ってPulumiは、このような複雑な課題と、それらをめぐるデベロッパーとITの現実によく応えている。デベロッパーとITは、ランタイムとデプロイの両側面から良好な関係を築かなければならない。それを助けるプラットホームとしては、私の知る限りPulumiがベストだ”。

オープンソースのツールは、今後も開発を続ける。また、コミュニティの構築にも厚く投資していく。同社によると、Pulumiにはすでにこれまでも相当な勢いがついていたが、新たな資金によりその努力を従来の倍にできる。

新たな資金により、オンボーディングのプロセスを容易にし、それを完全なセルフサービス型にしたい。でもそれをすべて企業任せにすることはできないから、Pulumiとしては売る前と売った後のお世話も充実させる必要がある。今現在は、この段階のスタートアップの多くがそうであるように、同社の社員はほぼ全員がエンジニアだ。だから営業の充実が、当面の優先課題になる。

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

Chefの標準ツールと最新ツールがMicrosoft Azureへ深く統合、安心のマイグレーションを担保

DevOpsオートメーションサービスChefが今日(米国時間9/25)、Microsoft Azureとの新しい統合をいくつか発表した。その発表は、フロリダ州オーランドで行われているMicrosoft Igniteカンファレンスで行われ、企業がレガシーアプリケーションをAzureへ移行する際の支援に焦点が絞られた。それに伴い、Chef Automate Managed Service for Azureのパブリックプレビューや、ChefのコンプライアンスプロダクトInSpecをMicrosoftのクラウドプラットホームに統合する例などが提示された。

Azure上のマネージドサービスとなるChef Automateは、コンプライアンスとインフラの構成の、管理とモニタリングを単一のツールでできる能力をopsのチームに与え、またデベロッパーは、Chef AutomateとChef ServerをAzure Portalから容易にデプロイし管理できる。それは完全なマネージドサービスであり、初めてのユーザー企業でも30分で使えるようになる、と同社は主張している。この数字には、やや宣伝臭があるかもしれないが。

構成を変えるときにはAzure上のChefユーザーは、AzureのコマンドラインインタフェイスであるAzure Cloud ShellでChef Workstationを使える。WorkstationはChefの最新の製品のひとつで、構成の変更を即席でできる。また、Chefが管理していないノードでも、対応できる。

コンプライアンス堅持のために、ChefはセキュリティとコンプライアンスツールInSpecのAzureとの統合をローンチした。InSpecは、MicrosoftのAzure Policy Guest Configuration(誰だ?こんな名前をつけたやつは!)と協働し、それによりユーザーはAzure上のすべてのアプリケーションを自動的に監査できる。

Chefのプロダクト担当SVP Corey Scobieはこう語る: “Chefは企業に、彼らが確信を持ってMicrosoft Azureに移行できるためのツールを提供する。ユーザーは単純に自分たちの問題をクラウドへそっくり移すのではなく、状態や状況をよく理解したうえで移行を行なう。事前に構成やセキュリティの問題を検出できるから、移行後の成功が確実になり、正しい、そして着実なペースで、移行できる実力を企業に与える”。

more Microsoft Ignite 2018 coverage

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

Atlassianがopsチームのためのインシデント管理ツールJira Opsをベータでローンチ

Atlassianが今日(米国時間9/3)、同社の旗艦製品であるJiraの新しいエディションの最初のベータと、opsのチームがインシデントを迅速効率的に処理できるための問題追跡ツールを発表した。

そのツールJira Opsは、OpsGenie, PagerDuty, xMatters, Statuspage, Slackなど他のツールをいろいろ統合している。多くのチームがすでに、自分たちのサービスがダウンするとこれらのツールを使っているが、Atlassianによると、現状では、その場しのぎ的な使われ方が多い。Jira Opsは、同じページ上の全員をまとめる糊になり、現在進行中のインシデントを可視化することをねらっている。

AtlassianがJiraを使って、その中核的なオーディエンスであるデベロッパーから逸れた方向へ脇道するのは、これが初めてではない。たとえばJira Service DeskとJira Coreは、もっと広いオーディエンスを対象としている。しかしOpsは、きわめて限定された層が対象だ。

Atlassianでソフトウェアのチームを率いるJens Schumacherはこう述べる: “Service Deskが、最初の一歩だった。そして、Jiraで対応できるそのほかの特定層を、探していた”。Schumacherによると、同社は社内のopsチームのためにこれまでたくさんのツールを作ってきたが、それらは主に、インシデントを追跡し管理するために必要な、いろんなピースを糊のようにまとめることが目的だった。Jira Opsはそんな糊的ツールを、正規のプロダクトにしたものだ。

しかし、Jira Opsを使うことはある意味で、パズルのピースがまた一つ増えることだ。でもSchumacherの主張では、プロセスを管理する単一の場所を作ることがねらいだった。“インシデントが起きたら、そのインシデントに関係のあるものをすべて見つけられる、センター的な場所へ行けばよい、…それがねらいだ”、と彼は語る。“そのページに誰がいて、誰がアラートされているかが分かる。必要と思えば、さらにもっと多くの人にアラートできる。Slackのどのチャネルでそのインシデントが議論されているか、も分かる”。

Atlassianの他のプロダクトと違うのは、Jira Opsのセルフホスティングバージョンを出す計画は今のところないことだ。その理由は、単純明快だ: ユーザーのインフラがダウンしたら、Jira Opsもダウンするかもしれない。…そうなると、そのダウンタイムを管理するツールがない。

Jira Opsは今、アーリーアクセスのベータとして無料で利用できる。バージョン1.0の立ち上げは、2019年の初期の予定だ。もちろんそのときには、料金体系も明確になっているだろう。

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

JenkinsによるCI/CDの自動化サービスを提供するCloudBeesが$62Mを調達、ますます買収志向に

最近Codeshipを買収したCloudBeesは、主にJenkinsを使用するDevOpsプラットホームだ。同社はこのほど、6200万ドルの新たな資金を調達したことを発表した。そのラウンドは3700万ドルがDelta-v Capitalがリードする通常のエクィティラウンドで、2500万ドルがGolub Capitalのレイトステージレンディング(Late Stage Lending)による成長融資だ。既存の投資家Matrix Partners, Lightspeed Ventures, Unusual Ventures, Verizon Venturesもラウンドに参加した。

このラウンドで、2010年に創業されたCloudBeesの調達総額は1億ドルあまりになる。DevOps分野は急成長している競争も激しいビジネスだから、小さなプレーヤーを買い集めて拡大を早くし、大手と有利に競争できるほどのマーケットシェアを獲得するためには、これぐらいの資金が必要なのだ。

CloudBeesのCFO Matt Parsonは、次のように語る: “今日では、ほとんどの企業がソフトウェアを使って、製品と事業の継続的な改良に努めている。継続的経済のそのようなグローバル化により、DevOpsの市場も爆発的に拡大している。弊社も最近の数年間で、自分たちのビジネスの大きな成長を見てきたが、しかし今では、ソフトウェアの継続的デリバリがすべての企業にとって喫緊の戦略的課題になり、それに伴って弊社の目の前にもさらに大きな機会が出現している”。

CloudBeesの現在の顧客には、Fortune100社が46社、Fortune10社が3社いる。

オープンソースのJenkinsを動かすオートメーションサーバーが、CloudBeesのプロダクトの中核だ。Jenkinsの教育訓練や資格試験/証明も、提供している。オープンソースのツールを使って有料の商用サービスを提供する企業の例に漏れず、CloudBeesも主力ツールであるJenkinsをエンタープライズ向けにいろいろ拡張して、多種類のサービスを構築している。また、最近Codeshipを買収したことによって、Jenkinsにあまり縛られない継続的インテグレーションとデリバリのプラットホームをサービスとしてホストできている。

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

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

GitLabがライバルのGitHubをサポート、CI/CDで顧客を取り込みたい

おもしろい展開だ。チームがコードを共有するための共有リポジトリを提供するサービス、という点では多くの点でGitHubと競合するGitLabで、その継続的インテグレーションとデリバリ(continuous integration and delivery(CI/CD))の機能がGitHubをサポートすることになった

今日(米国時間3/22)ローンチするその新しいサービスは、GitLabがホストするサービスの一環だ。2019年の3月22日までは無料で利用できるが、その後は、GitLab.comの有料のSilverティアへ行く。

GitHubもやはり、そのコアツールの上の層としてベーシックなプロジェクト管理やタスク管理のサービスを提供しているが、しかしDevOpsのライフサイクルのほとんどの部分はパートナーたちにまかせている。GitLabは、複数のコードリポジトリを統合するなど、もっと完全なCI/CDソリューションを提供しているが、GitLabの人気もけっして低くはないけど、GitHubはデベロッパーや企業による知名度ではGitLabを大きく引き離している。というわけで今回GitLabは、コードをGitHubに保存しているけどより完全なCI/CDソリューションも使いたい、という新しいユーザー、とりわけエンタープライズユーザーを獲得したいのだ。

今度の新たなGitHubの統合により、デベロッパーは自分のプロジェクトをGitLabでセットアップし、それらをGitHubのリポジトリに接続できる。するとデベロッパーがコードをそのGitHubのリポジトリへプッシュするたびに、GitLabがそのプロジェクトのCI/CDパイプラインを動かし、ビルドとテストとデプロイを自動化する。

GitLabのCEOで協同ファウンダーのSid Sijbrandijはこう述べる: “継続的インテグレーションとデプロイメントは現代的なDevOpsの根幹だ。今回の新しいサービスにより、GitHubをコードリポジトリとして使っている企業やオープンソースのプロジェクトは、GitLabの、業界のトップを走る高度なCI/CDサービスを利用できる”。

なおGitLabは、AtlassianのBitBucketの、今回とよく似た統合も提供している。

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

CoreOSの商用化KubernetesツールTectonicがv.1.8にアップデート、外部サービスの利用が容易に

CoreOSが、ポピュラーなコンテナオーケストレーションツールKubernetesを企業向けに使いやすく商用化して提供するTectonicのマイナーアップデート、v.1.8をリリースする。その新しい機能Open Cloud Services Catalogにより、ユーザー企業のDevOpsは、外部サービスを容易にKuberneesにプラグインできる。

CoreOSでTectonicのプロダクトマネージャーをやっているRob Szumskiが、ニューバージョンを発表する同社のブログ記事で言ってるように、パブリッククラウドは使いやすくて便利ではあるけれども、そこにロックインされてしまって、プロプライエタリなツールしか使えないこともある。

CoreOSのOpen Cloud Services Catalogは、その問題を解決する。‘カタログ’の名のとおりここには、特定のプロプライエタリなツールに代わる多様な選択肢があり、クラウドやハイブリッド環境など、複数の実行環境間の移動や行き来が容易にできる。

“Tectonic 1.8では、CoreOSのOpen Cloud Servicesで、マネージドクラウド(管理サービスを伴うクラウド)が提供すると期待されている苦労のないオペレーションに、さらに一味加えたものを体験できる。通常のプロプライエタリなクラウドサービスと違ってOpen Cloud Servicesは、CoreOSのTectonicプラットホームの上で走る第一級の、完全に自動化された、Kubernetesリソースの集合だ”、とSzumskiはそのブログ記事で述べている。

CoreOSは、提供物のすべてをできるかぎりオープンでポータブルにして、顧客のあらゆる特殊条件や要求にも柔軟に対応したい、と考えている。それだけでなく今度のOpen Cloud Services CatalogはTectonicsのコンソール本体上にあるので、外部サービスの導入も、またその無効化も、きわめて簡単容易である。

Open Cloud Servicesの初期のリソースとしては、etcd, Prometheus, Vaultなどが挙げられる。

Open Cloud Service CatalogはあくまでもTectonic 1.8のリリースの一部であり、基本的には9月の終わりにリリースしたオープンソースバージョンの路線は維持されている。とくにCoreOSが強調するのは、それがあくまでもKubernetesのオリジナルバージョンであり、フォークではないことだ。Kubernetesの管理団体であるCloud Native Computing Foundationも、それがピュアなオープンソースバージョンとして維持されることを期待し奨励している

なお、このバージョンにより、コンテナエンジンDockerも自動的にアップデートされる。デベロッパー(Dev)は、このエンジンを使って、コンテナに収めたアプリケーションを作る。そしてオペレーション(Ops)はKubernetesを使ってコンテナの管理とデプロイを行う。というわけでこのツールは、コンテナのDevOpsの両サイドの面倒を見てくれる。

この最新バージョンは年内にダウンロード可能になるが、既存のTectonic 1.7からのアップデートは自動的に行われる。

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

GitLabがGVのリードするシリーズCで$20Mを調達、ソフトウェア開発〜リリースの総合ソリューションを目指す

デベロッパーのためのコラボレーションとDevOpsのプラットホームGitLabは現在、10万あまりの企業が利用している。同社は今日(米国時間10/9)、GV(元Google Ventures)がリードするシリーズCのラウンドにより2000万ドルを調達したことを発表した。これでGitLabの総調達額は4550万ドルあまりとなる。

新たな資金調達に加えて同社は今日、WordPressの協同ファウンダーMatt Mullenwegが同社の取締役会に加わったことを発表した。

GitLabは、その名が示すように、gitをベースとし、デベロッパーがコードのリポジトリーをセルフホスティングしていくためのオープンソースのツールだ。しかし2014年のローンチ以来同社は、そのほかのDevOps向けサービスをいくつも新設してきた。それらの中にはワークフローツールがいくつかあり、またコードのレビューやリリースを容易にできるためや、アプリケーションのモニタリングのための機能すらある。

そこで同社は、自己のミッションを次のように定義している: “現代のソフトウェアデベロッパーのためのシームレスで総合的なプロダクトを開発し、またKubernetesによるソフトウェア開発のためのアプリケーションになること”

そう。今やGitLabですら、Kubernetesというゲームに深く関わりたいのだ。

GVのゼネラルパートナーDave Munichielloは、今日の声明文の中で次のように述べている: “Fortune 500社は今、互いに競ってワールドクラスのソフトウェア開発組織を作ろうとしており、またそれらに、世界最大のテクノロジー企業なみのスピードと生産性とクォリティを持たせようとしている。これらの組織は高品質で大規模なコードを作るべく努力しているので、最高クラスのツールとプラットホームを必要とする。GitLabのプラットホームは、コラボレーションとオートメーションを強調することにより開発プロセスを加速する。GitLabのハイブリッドでマルチクラウドのソリューションはデベロッパーに好まれており、その分野で巨大なファン層を形成している”。

GitLabの現在のユーザーには、Ticketmaster, ING, NASDAQ, Sony, Intelなどもいる。

新たな資金の使途について同社は、“ソフトウェアのパッケージングとリリース方式と構成とモニタリングに関して新たな機能性を加えたい”、と言っている。

同社の競合サービスはGitHubやAtlassianのBitBucketなどだが、GitLabによると、セルフホスティング型のgit市場では同社が2/3のシェアを占めるそうだ。

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

Atlassianが全デベロッパーツールをワンセットにしたAtlassian Stackを年会費制でローンチ

Atlassianが今日(米国時間6/13)、Atlassian Stackという、新しい会員制のサービスを立ち上げた。それは、同社がホストしているデベロッパーツールをすべてまとめたサービスで、会費は1000ライセンスにつき年額18万6875ドルだ。これにより企業の調達担当は仕事が楽になり、費用削減にもなる(一見、高いけど!)。個々のプロダクトの会員ユーザーになるよりも、Atlassian Stackの会員になるとデベロッパーツールのすべてを手早く利用できて簡単なのだ。

Stackにはこんなものがある:

  • データセンターバージョン: JIRA Software, Bitbucket, JIRA Service Desk, Confluence
  • サーバーバージョン: JIRA Core, HipChat, Bamboo, FishEye, Crucible, Crowd
  • アドオン: JIRAのPortfolio, JIRAのCapture, ConfluenceのQuestions, ConfluenceのTeam Calendars
  • 有料サポート

デベロッパーがAtlassianの上で仕事をするには、これで十分だろうが、ただしファイヤーウォールの内側で使えるもののみだ。Atlassianのツールのホストバージョンはないが、このようなバンドルに関心のある企業は、自社独自のデプロイをするところがほとんどだろう。

1000ライセンスの料金は一人あたりの月額で15ドル57セントになる。1万ユーザー以上もいる超大企業は、一人あたり月額が6ドル74セントになる。

Atlassian Stackに加えて今日同社はDevOps Marketplaceをローンチした。この新しいストアはAtlassianのユーザーに、200以上のアドオンとインテグレーションへのアクセスを提供する。現在のパートナーはAppDynamics, Splunk, そしてSauce Labsだ。Atlassianにはすでにマーケットプレースはあるが、この新作はDevOpsツールが中心だ。

[原文へ]
(翻訳: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)

WalmartLabsがWalmart.comのアップグレードに使ったReactベースのアプリケーションプラットホームをオープンソース化

SPRINGER, NM -  MAY 15:  A Wal-Mart truck sits on the side of the highway May 15, 2005 near Springer, New Mexico.  Wal-Marts are now nearly ubiquitous on the American landscape, with over 3,000 stores coast-to-coast.  With growth, Wal-Mart continues to weather criticism of low wages, anti-union policies as well as accusations that it has homogenized America's retail economy and driven traditional stores and shops out of business. (Photo by Chris Hondros/Getty Images)

オープンソースソフトウェアという言葉と、あの大手スーパーマーケットWalmartが頭の中で結びつく人はあまりいないと思うが、同社のイノベーション意欲旺盛な技術開発部門WalmartLabsはこれまでにも、さまざまなオープンソースプロジェクトを一般公開している。その中でいちばんおもしろいと思えるのがDevOpsプラットホームOneOpsだが、今日(米国時間10/3)はそれと同等に意欲的なプロジェクトを立ち上げた。

Walmartのeコマース部門Walmart.comは、今や月間ビジター数が8000万、販売品目1500万に達する。そこが昨年1年間をかけて、React(react.js)とNode.jsに移行した。その移行過程でWalmartLabsのチームがWalmart.comのために作ったReactベースのアプリケーションプラットホームElectrodeがこのほど、オープンソースになった

デベロッパーは、Electrodeが提供しているいくつかの定型句的なReactコードに自分なりに手を加えて必要なモジュールを作り、それらの機能をNodeで作るアプリケーションに加えていく。たとえばそれは、Node.jsアプリケーションの構成を管理するツールや、アバブ・ザ・フォールド(above-the-fold)を素早く表示するReactコンポーネントなどだ。〔above-the-fold, アバブ・ザ・フォールド, ページの最上部、スクロールしないで見れる部分。 〕

1-5_vpgxrjriefylzxbmdj-a

チームによると、このプロジェクトにはいくつかの特定の目標があり、それらはほかの企業の問題解決にも役立つはずだ、という。Electrodeは社内のデベロッパーがアプリケーションを早く作れることが目的であり、彼ら自身がこれまでの経験の中で開発してきたベストプラクティスに従った、堅実な構造をそのまま利用できる。

WalmartLabsの技術部長Alex Grigoryanはこう語る: “Electrodeはとりわけ、われわれが作るアプリケーションのパフォーマンスとデベロッパーの生産性を上げた。オープンソースにすることによって、コミュニティがそれをさらに良くしていくことを期待したい。もちろんそれは、うちだけではなく、これを使うデベロッパー全員にとってね”。

このプラットホームは、できるかぎりモジュール的な構造にするよう努めた。その結果それは、コア、モジュール群、ツール類、という三つの部分から成り、それぞれを単独で利用することもできる。

1-rzjgp3sxadbt2v1yabnsiw

Electrode今、WalmartでWalmart.comを動かしているが、今後はSamsClub.comなど、Walmart社のそのほかのWeb資産にも適用していく意向だ。Electrodeは昨年の12月に発足したプロジェクトだが、Grigoryanによると、プロジェクト自身は若くても内部で大量のオープンソースプロジェクトを利用している。オープンソースコミュニティの助けがなければ、これだけのものは到底作れなかっただろう、と彼は言う。

Electrodeに移行する前Walmartは主に、Thorax(Backbone.jsとHandlebars.jsによるフレームワーク)と、Javaを使っていた。

WalmartLabsがこれまでに発表したオープンソースプロジェクトはおよそ140あり、Electrodeもその仲間に加わる。まさしく、「今やすべての企業がソフトウェア企業だ」と言われる由縁である。Walmartのような一見保守的な企業でさえ、オープンソースの意義と効用に目覚めるのだから。

Grigoryanは述べる: “うちはいつも、大量のオープンソースを利用しているから、そのお返しをすることをつねに念頭に置かなければならない。Electrodeはアプリケーションのパフォーマンスとデベロッパーの生産性の両方を上げるから、オープンソース化する意義が十分にある。そしてまた、オープンソースのコミュニティによって、うちばかりでなく、それを使うほかのデベロッパーの役に立つ改良改善が為されることも、働きかけていきたい”。

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

ソフトウェアの開発(dev)からオペレーション(ops)まで、DevOpsの全過程をツールセットで支えるHashiCorpが$24Mを調達

BIERE, GERMANY - JULY 01: Close-up of cables and LED lights in the new data center of T-Systems, a subsidiary of Deutsche Telekom AG on July 01, 2014, in Biere, Germany. T-Systems is the largest German and one of the largest European IT services companies. (Photo by Thomas Trutschel/Photothek via Getty Images)

ポータブルな開発環境をセットアップする便利なオープンソースのツールVagrantなどで知られる、デベロッパー支援ツール専門のHashiCorpが今日、シリーズBによる2400万ドルの調達を発表した。このラウンドはGGV Capitalがリードし、Mayfield, True Ventures, それに新たな投資家としてRedpointが参加した。同社の累計資金調達額は、3400万ドルになる。

今回の資金調達の目的について同社の協同ファウンダーでCTOのArmon Dagarはこう語る: “HashiCorpはアプリケーションの開発から運用までのすべての過程を支援しているが、とくに力を入れているのが開発、オペレーション、そしてセキュリティだ。今後も弊社の7つの主力製品に注力していくことは変わらないが、同時に、オープンソースのツールを使う場合のワークフローの問題を解決するための、エンタープライズアプリケーションも作っていく。弊社はアプリケーションの最終デリバリまでの過程を、必要にして十分なステップだけに純化し、それらの問題を解決するためのツールを作る。弊社は今後も継続してそれらの問題領域に注力し、オープンソースとエンタープライズの両方のプロダクトに新たな機能を加えていく”。

Dagarによると同社は、特定分野の大企業が成長の主な源泉になっている。それらは、金融、メディア、リテール、そしてWeb上の巨大なインターネット企業だ。具体的な顧客企業名としてはConde Nast, Cisco, Mozillaなどが挙げられる。またStripe, Uber, Twitch, OpenAI, Pinterest, Capital Oneなどの企業も、Vagrant, packer, Terraform, Serf, Nomadなど同社のオープンソースツールを利用している。

中核的なツールをオープンソースのライセンスで提供している企業によくある例として、HashiCorpも主な収益源はエンタープライズサービスだ。同社のそういうサービスの一例がHashiCorp Atlas、これは同社の主要ツールのエンタープライズバージョンを収めたスイートだ。その中には、リソースプロビジョニングツールのTerraformや、ベータを終えたばかりのセキュリティ強制設定ツールVaultなどが収められている。

結局のところ同社のキモは、企業が自分たちのDevOpsのワークフローを、その下のインフラストラクチャに左右されずに管理できるための、一連のツールを提供することだ。そのため同社のサービスは仮想マシンやコンテナのレベルを対象とし、Azure, AWS, Google Cloud Platformなど多くのパブリッククラウドや、OpenStackのようなプライベートクラウドのプラットホームをサポートしている。

GGV Capitalのパートナー役員でHashiCorpの取締役でもあるGlenn Solomonは述べる: “HashiCorpは、開発(dev)とオペレーション(op)とセキュリティを担当するチームが分散アプリケーションとそのインフラストラクチャを管理するための、世界クラスのツールを作っている。グローバルなエンタープライズにおけるこれらのツールの採用率は、きわめて高い。彼らとのパートナーシップを継続できることは大きな喜びであり、ソフトウェアアプリケーションのデリバリを加速するという彼らのミッションの継続を、これからも見守り支援していきたい”。

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

AWSの新しいロードバランサーはユーザーによるきめ細かいコントロールが可能

aws-alb

ニューヨークで行われたAmazonの顧客向けイベントで今朝(米国時間8/11)、AWSのCTO Werner Vogelsが新しいロードバランサーを発表した。それはコンテンツを複数のサーバーに分散する場合、もっときめの細かい分散の仕方をデベロッパーや管理者が指示できる、という負荷分散ツールだ。

それはAWS Application Load Balancerと呼ばれ、これまでの(2009年からある)Elastic Load Balancingツールのように、何をどこに置くかということをロードバランサーが自分のアルゴリズムで勝手に決めるのではなく、人間管理者が決められる。

この新たに加わった制御方式は、これまでのアプリケーションを動かしているだけのユーザーにはあまり関係ないかもしれないが、複数のコンテナに収めた現代的なタイプのアプリケーションを使っているユーザーには、プロセスに対するより強力なコントロール能力を与えるだろう。コンテナ化したアプリケーションは複数のマイクロサービスで構成されることが多いので、個々のマイクロサービスごとにトラフィックを制御できた方がありがたいのだ。

Vogelsはこう言う: “これにより、ユーザーのシステムの個々の部位ごとに、トラフィックの送り方を完全に制御できる”。

たとえば、APIコンテンツ(のリクエスト)はすべてそれ専用のサーバーへ行かせ、モバイルコンテンツは別の専用サーバーが担当する。この新しいツールを発表しているブログ記事は、こう述べている: “こうやってリクエストをルーティングしてやれば、複数のマイクロサービスから成るアプリケーションをそれぞれ個別に、独立的に動かし、またスケールできる”。

ユーザー(デベロッパーや管理者)にはElastic Load Balancing Consoleというコンソールが提供されるので、その上で新しいロードバランサーを使うのか、従来ので十分か、を決めて指示できる。

技術的には、新旧の違いは大きい。前のツールは“Layer 4”のロードバランサーといって、ネットワークプロトコルのレベルで動作し、ネットワークのパケットの内部で起きていることを表す詳細な情報にはアクセスできない。そこでこのツールは今後、Classic Load Balancerと呼ばれることになる。

そして新顔のApplication Load Balancerツールは“Layer 7”のロードバランサーと呼ばれる。それはパケットの内部を覗くことができ、より詳しい情報へのアクセスにより、より高度な仕事ができる。たとえば、パケットの性質に基づいて行き先を仕分けする、といったことも可能だ。

また新しい情報に伴う測度も、CloudWatchメトリクスをはじめ、新しいより詳しい測度だ。たとえばトラフィックはGBで表され、現在のアクティブコネクションの数や、毎時のコネクションレート(1時間あたりの接続数)なども分かる。

この新しいロードバランシングツールは、WebSocketとHTTP/2をサポートしている。これらはどちらも、ネットワークトラフィックを扱うためのより現代的な方法を提供しているから、一部のユーザーにとっては、ありがたいだろう。

Application Load Balancerは今すでに可利用であり、機能が増えているにも関わらず料金は従来品より10%安い。課金の単位は、使用した時間プラス、Load Balancer Capacity Unitsと呼ばれるややこしい測度で、それは毎秒の新しい接続の数や、アクティブコネクションの数、ユーザーが送信するデータの量、などをベースとする単位だ。

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

ChefのHabitatは多様なインフラストラクチャへの対応雑務からアプリケーションデベロッパーを解放する

Chefが今日(米国時間6/14)、Habitatをローンチした。それはアプリケーションを、いろんなインフラストラクチャの上でそのまま動けるようにパッケージする、オープンソースのプロジェクトだ。

Habitatは基本的に、アプリケーションを独自の軽量ランタイム環境で包み、それらをどんな環境でも動けるようにする。ベアメタルのサーバー、仮想マシン、Dockerコンテナ(+そのコンテナ管理サービス)、Cloud FoundryのようなPaaSシステム、などなど。

2016-06-14_1038

“アプリケーションをインフラストラクチャへの依存性から解放して、DevOpsが本来の仕事をできるようにすべきである”、とChefの協同ファウンダーでCTOのAdam Jacobが今日の声明で述べている。“オープンソースソフトウェアは世界中でこれからもどんどん作られていく。そんな中へHabitatを送り出すことは、たいへんすばらしい。アプリケーション中心の自動化が、現代の開発チームに彼らが本当に望むものを与える。それは、新しいアプリケーションを作ったら、ややこしいインフラの工事をいっさいしなくても、それをすぐに動かせることだ”。

Chefのチームによると、最近のソリューションはどれも、あまりにもエンタープライズへ視野狭窄していて、どの企業の環境も独自に深くサイロ化しているので、“われわれはソフトウェアを個々のサイロに合わせていちいち再設計しなければならない”、という。一方GoogleやFacebookのようなWebスケールの企業は独自のプラットホームをスクラッチから作り、それを作ることが彼らのビジネスになっているが、それはどんな企業にもできるやり方ではない。

そこでHabitatは、アプリケーションの見地から見て、アプリケーションを作り、デプロイし、管理するためのベストの方法は何か?、という問に答えようとする。それは、インフラストラクチャを定義するのではなく、アプリケーションが動くために何を必要とするか、を定義し、そこから出発する。そして、一種の“スーパーバイザー”であるHabitatがデプロイを担当し、またあなたがそこにデプロイしたいと考えている環境の、アップグレードやセキュリティポリシーの面倒も見る。

Chefのチームによると、レガシーのアプリケーションをHabitatに移植するのは、かなり簡単だそうだ。

Habitatのそんな約束は、そもそも、かねてからコンテナについて言われていたことと似ている。でもChefによると、Habitatはコンテナ体験を改良し、コンテナ管理の複雑性を大幅に減らした。そこで、ある意味ではこのプロジェクトは、コンテナに対するChefの反応のようでもある。コンテナは、少なくとも部分的には、同社のコアビジネスを脅(おびや)かしているのだ。そして当然ながらHabitatは、Chefの既存のDevOpsツールと問題なく併用できる。

Habitatを試してみたい人のために、Chefはチュートリアル集対話的なデモを提供している。

2016-06-14_0844_001

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

コンテナ管理のWeaveworksにGV(元Google Ventures)がシリーズBで$15Mを投資、オープンソースと商用サービスの併立へ

shutterstock_127403000

コンテナ管理ツールのWeaveworksが今日(米国時間5/11)、GV(元Google Ventures)がリードするシリーズBのラウンドで1500万ドルを調達したことを発表した。同社へのシリーズAで500万ドルを投資したAccelが、このラウンドにも参加した。同社の調達総額は、これで2000万ドルになる。

Weaveworksは、デベロッパー(dev)とエンタープライズのオペレーション(ops)の両方にとって最新のホットな技術であるコンテナを、管理しモニタしセキュリティを図るための一連のオープンソースのツールを作っている。しかし今回得られた資金は、オープンソースのプロダクトよりも構造性の明確なシステムを求める企業のために、商用製品を作っていくことに充てられる。

CEOのAlexis Richardsonは、今回の資金調達を発表するブログ記事で、“次のステップは統合化された商用製品の提供だ”、と述べている。同社にはクラウドサービスを提供していく計画もあり、それはまだベータの段階だ。

データセンターの進化史における最初の原生動物は、モノリシックな(一枚岩的な)アプリケーションだ。単一の巨大なアプリケーションを作り、それをセットアップしていく。アップグレードは大作業になるので、本当に必要になってからでないと、できなかった。

しかし今日では、デベロッパーはもっと迅速にアップデートしたいし、ユーザーは、変化の激しい市場の中でもっとも最新のツールを使って企業競争に勝ちたい。コンテナはアプリケーションを、複数のマイクロサービスの集まりへと分割する方法を提供する。それらは迅速にデリバリでき、自分の仕事が終わったらメモリから消えていく。

今の企業は、何百何千という大量のコンテナをデリバリし、そのそれぞれが、特定の時間にローンチしてディスクリートなタスクを実行しなければならない。大量のコンテナに関して、それらがすべて正しく行われるためには、ソフトウェアのコーディネーション努力がたいへんな仕事になるが、でも今日までは、デベロッパーとオペレーション(合わせてDevOps)たちは、自作のツールを適当に寄せ集めてそのプロセスを管理していた。

まだコンテナがアーリーアダプターのものだった時代には、そんな大変な仕事を誰もがやっていたが、でも技術がメインストリームに乗って市場の大きな部分を捕まえていくためには、企業が簡単に買えて簡単に使える出来合いのツールセットがあって、それらを既存のシステム管理体制に容易に組み込めないといけない。

そういう仕事をやってくれるのが、Weaveworksだ。同社はコンテナとそのまわりに存在する大量の可動部品のすべてを管理する方法を提供し、ユーザーが作ったコンテナのエコシステムを視覚化する。そしてそのエコシステムのライフサイクルに付き合いながら、複雑な仕事を単純化するためのお手伝いを提供する。

Weaveworks以外にもコンテナ管理を代行するサービスはあるが、同社はその業界のリーダーになれる、とGVは賭けている。今回の投資は、そのための賭け金である。

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

Kubernetes/Docker Swarm両方をサポートするコンテナ管理プラットホームRancher LabsがシリーズBで$20Mを調達

rancher_labs

KubernetesとDocker Swarmの両方をサポートするコンテナ管理プラットホームRancher Labsが今日(米国時間5/9)、シリーズBで2000万ドルを調達したことを発表した。このラウンドをリードした同社の新しい投資家は、中国の投資企業GRC SinoGreenで、既存の投資家MayfieldとNexus Venture Partnersも参加した。これで同社の資金調達総額は3000万ドルになる

新たな資金は、営業とマーケティングの強化および、ユーザーの要望に合わせての製品の改良に充てられる、という。

Rancher LabsのCEO Sheng Liangは今日の発表声明の中でこう述べている: “コンテナ化によって企業は、アプリケーションのパフォーマンスと可利用性とコストを改良するための、すばらしいことがいろいろできるようになった。このパズルの次のピースはコンテナ技術の完成に貢献するものであり、それはコンテナの管理に関連するツールだ。ユーザーがコンテナ技術をフルに利用して、コンテナが約束する財務的および組織的な利益を得ていけるための、正しいツールを提供していくことが、弊社の目標である。弊社が今後もこの目標追求のための努力を継続できることは、きわめて喜ばしい”。

コンテナプラットホームの市場はやや混み合ってきたが、Rancher Labsによれば、KubernetesとDocker Swarmの両方をサポートしているために、Rancherはエンタープライズのコンテナ展開のための正しいツールになっている。しかしおそらくさらに重要なのは、 それが、使用するクラウドを特定しないこと、およびエンタープライズがパブリックとプライベート両方のクラウドと、さらに従来からのデータセンターで、コンテナを使えることだ。

なお、Rancherはマルチテナントプラットホームなので、各チームが自分たちのニーズに即したやり方で自分のクラスタを管理できる。この方式では、たとえば、Kubernetesのクラスタのセットアップがわずか5分でできる。(ただしクラスタのデプロイを初めてやる方は、もっとかかるかもしれない。)

コンテナのデプロイを容易にするために同社は、アプリケーションカタログを提供している。それを利用すると、かなり複雑なアプリケーションのデプロイでも、わずか数クリックで簡単に構成できる。

投資をリードしたGRC SinoGreenのパートナーDr. James Zhangは発表声明の中でこう語る: “コンテナはソフトウェアの開発とITのオペレーションを急速にディスラプトしつつある。Rancher Labsはそのすばらしいオープンソース技術によって、ソフトウェア開発の加速化のためにはコンテナ管理が重要であることを企業に示し、同じく適正なコンテナ管理によってアプリケーションをプロダクション(本番稼働)における高い信頼性と効率で動かせることを、示してきた”。

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