タグ: developer

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

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

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

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

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

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

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

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

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

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

AWSのグラフデータベースNeptuneが一般公開、既存の主要なグラフAPIもサポート

AWSが昨年のre:Inventカンファレンスで紹介したグラフデータベースNeptuneが、今日（米国時間5/30）から一般公開された。それはあのとき発表された数十ものプロジェクトのひとつだから、思い出せない人がいても不思議ではない。

NeptuneはTinkerPop GremlinとSPARQLのグラフAPIをサポートしているので、いろいろなアプリケーションと互換性がある。AWSによるとこのサービスはエラーから30秒以内に復旧し、99.99%の可利用性を約束する。

AWSでデータベースとアナリティクスと機械学習を担当しているVP Raju Gulabaniは次のように語る: “世界がますます接続された世界になるに伴い、互いに接続された大きなデータセットをナビゲートするアプリケーションが顧客にとってますます重要になる。そういう時期に、スタンダードなAPIを使って何十億もの関係性を数ミリ秒でクェリできる高性能なグラフデータベースサービスを提供できることは、たいへん喜ばしい。これにより多くのデベロッパーが、高度に接続されたデータセットを扱うアプリケーションを容易に作って動かせるようになるだろう”。

Neptuneに好適なアプリケーションといえば、ソーシャルネットワーク、リコメンデーションエンジン、不正行為検出ツール、エンタープライズのインフラストラクチャの複雑なトポロジーを表現しなければならないネットワーキングアプリケーションなどだ。

Neptuneにはすでに、有名企業のユーザーがいる。それらは、Samsung, AstraZeneca, Intuit, Siemens, Person, Thomson Reuters, そしてAmazon自身のAlexaチームなどだ。AlexaのディレクターDavid Hardcastleが、Neptuneの発表声明の中でこう述べている: “Amazon Neptuneは、Alexaの数千万の顧客のためにAlexaの知識グラフを継続的に拡張していくための欠かせないツールキットだ。今日はその正式スタートの日だが、これからもAWSのチームと協力してさらに良いユーザー体験を顧客に提供していきたい”。

今このサービスは、AWSのU.S. East(N. Virginia), U.S. East(Ohio), U.S. West(Oregon), EU(Ireland)の各リージョンで利用できる。そのほかのリージョンでも、今後随時提供されていく予定だ。

・関連記事: Amazon、re:inventカンファレンスでグラフDB、Neptune発表

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

ベアメタルでプライベートクラウドを提供するPacketがPlatform 9やDateraとパートナーして構成を充実

ベアメタルのクラウドプロバイダーPacketが今日（米国時間5/22）、オープンソースのハイブリッドクラウドスペシャリストPlatform9およびストレージとデータ管理サービスDateraとパートナーして、新しいプライベートクラウドソリューションをローンチした。それは、自分のプラットホームをもっと強力かつ広範にコントロールしたいと願う企業をターゲットとする。しかもPacketによると、この新しいソリューションはパブリッククラウドのソリューションを使う場合に比べて50%の費用節約を実現する。

PacketのCEO Zac Smithはこう述べる: “パブリッククラウドのような洗練されたユーザー体験を提供するとともに、それらよりもずっと多い選択肢と大きなパフォーマンスを提供したい。Packetのマネージドベアメタルに、DateraやPlatform9のような強力なマーケットリーダーが組み合わされば、これまでのパブリックやプライベートのクラウドソリューションの数分の一のコストでサービスを提供できる”。

Packetがとくに注目してほしいと言うのは、Platform9自身が最近AWSからマイグレートしたことだ。同社によると、パブリッククラウドというモデルには制約が多く、またその課金とデリバリのモデルも複雑なため、Platform9はもっと緑の多い草原を求めたのだ、という。

ここ数か月で二件の例があったが、小さなクラウドプロバイダーたちがチームを組んで独自のソリューションを提供し、AWSやAzure、Google Cloudなどと互角に競合しようとしている。先月PacketはBackblazeおよびServer Centralとパートナーして、BackblazeのクラウドストレージサービスB2〔低コストなバックアップストレージが売り〕をそのメニューに加えた。

Packetによると、この新しいソリューションは全世界18箇所で可利用となる。同社のOpenStackおよびKubernetesプロダクトも、同様である。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

コンテナを軽量VMで隔離するKata Containersがついにv1.0をリリース

OpenStack Foundationがホストする初めてのOpenStack以外のプロジェクトKata Containersの、バージョン1.0が今日（米国時間5/22）ローンチされた。それはコンテナのワークロードを隔離して動かすためのシステムで、元々IntelとHyperにそれぞれあった類似のプロジェクトをマージしたプロダクトだ。デベロッパーはKata Containersを使って、DockerやKubernetesをベースとするコンテナに、従来の仮想マシンのようなセキュリティと隔離機能を持たせることができる。

そのためにKata Containersは、各コンテナにきわめて軽量な仮想マシン(VM)を実装し、ハードウェアレベルの隔離を与えるが、ただしそれによる大きなオーバヘッドは生じない。そしてコンテナの標準的な定義に合わないように見えるKata Containersは、実はOpen Container Initiativeの仕様やKubernetesのコンテナランタイムインタフェイスと互換性がある。これをサービスとしてホストするのはOpenStack Foundationだが、Kata Containersは使用するプラットホームやアーキテクチャを特定しない。

IntelとCanonicalとRed Hatが、このプロジェクトの財政的サポートを表明しており、また99cloud, Google, Huawei, Mirantis, NetApp, SUSEなど多くのクラウドベンダーたちも支援を発表している。

このたびv1.0がリリースされたことにより、Kataのコミュニティは、このIntelとHyperの合作技術がついにプロダクション用途にまで成熟したことをシグナルしている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

OpenStackがオープンソースのCI/CDプラットホームZuulを切り離して独立化

OpenStackほど複雑なオープンソースプロジェクトはほかにないと思われるが、これは要するに、AmazonのAWSのような総合的なクラウドコンピューティング環境を、企業が自分のデータセンターの（主としてプライベートな）インフラストラクチャとして装備するためのシステムだ。それを構成するさまざまなサブシステムを作るためにチームは、独自のDevOpsツールを作らざるをえなかった。2012年には、その一環として、オープンソースの継続的インテグレーションとデリバリ(CI/CD)プラットホームZuulを作った。そしてこのほど、Zulu v3のリリースを契機に、ZuluをOpenStackから切り離して独立のプロジェクトにした。でもOpenStackのエコシステムを去るわけではなく、依然としてそれは、OpenStack Foundationがホストするツールだ。

構造をざっと展望すると、OpenStack Foundationは一種の母体的組織であり、その傘下のメインプロジェクトとしてOpenStack本体のほかに、昨年おそく登場したKata Containersと、今回のZuulがある、という構造になる。すなわちOSFは近年、本体OpenStackのほかに、関連のインフラストラクチャプロジェクトも揃えよう、としているのだ。

Zuulはデベロッパーたちに、プロジェクトに新たな変更を加えようとするときの、コードのマージ、ビルド、そしてテストの工程を自動化するシステムを提供する。サポートする開発プラットホームはかなり幅広くて、GitHubや、コードレビューとプロジェクト管理のツールGerritなどもサポートしている。

Zuulの現在のコントリビューターは、BMW, GitHub, GoDaddy, Huawei, Red Hat, そしてSUSEだ。BMWのソフトウェアエンジニアTobias Henkelは語る: “ソフトウェアプロジェクトがCD/CIを幅広く採用することは、高品質なソフトウェアをタイムリーにデリバリするための基盤だ。それにより、個々のコミットチェックからフルリリースに至るまでの、開発サイクルの重要な部分を、すべて自動化できる。弊社BMWのCI/CDチームは、Zuulコミュニティの一員であることを誇りとし、オープンソースのZuulプロジェクトの積極的なコントリビューターであり続けたい”。

Zuulがスピンオフして独立した今の時期は、CI/CDに関して選択肢がとても多くなっている。GoogleとNetflixはオープンソースのSpinnakerで、Zuulと同様の機能を提供しようとしているし、またJenkinsとその類似プロジェクトたちも依然として強い。これらに対してZuulは、大規模で複雑な開発プロジェクトをうまく扱えるmulti-repo gating（マルチリポジトリ・ゲーティング）機能の有利性を強調している。

今カナダのバンクーバーで、これらのオープンソースプロジェクトの代表者たちによるOpenDevカンファレンスが行われており、そこでOpenStack Summitも併催されているので、数日〜数週間後にはこれらのプロジェクトすべてに関するより詳しい情報が出てくることだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

AWSの仮想マシンサービスEC2にローカルなNVMeストレージが付随するインスタンスが登場

AWSの仮想サーバーEC2は、そのオプションが日に日に増えている。今日（米国時間5/18）加わった新しい仮想マシンは、ローカルなNVMeストレージによって、標準的なSSDよりも相当速いスループットを提供する。

このC5dと呼ばれる新しいインスタンスは、このサービスがすでに提供している、コンピュート（処理能力）優先で最適化されているC5インスタンス群の仲間に加わる。AWSはC5について、ハイパフォーマンスコンピューティングのワークロードやリアルタイムのアナリティクス、マルチプレーヤーゲーム、ビデオエンコーディングなどのユースケースに適する、としているが、今回高速ストレージのオプションが加わったことによって、さらなるパフォーマンスの向上が望めるだろう。

そのローカルストレージは仮想マシンに付随するので、インスタンスが停止したらそれも終了する。だから長期的なストレージではなくて、一時的なファイルの保存に向いている。

C5とC5dのインスタンスは共に、同じプラットホーム、3.0GHz Intel Xeon Platinum 8000プロセッサーを共有する。

この新しいインスタンスは今、アメリカとカナダのリージョンで利用できる。料金は通常のC5インスタンスよりやや高くて、オレゴン州のリージョンではもっともベーシックなRAM 4GBのマシンで1時間$0.096からだ。通常のC5マシンは、1時間$0.085からだ。

なお、FPGAを使用できるF1インスタンスも、NVMeストレージを提供している。それらは非常に高度な専用マシンで、C5のような一般的なデベロッパー向けではない。

AWSは今日のNVMeインスタンスの発表と並行してEC2のベアメタルインスタンスの一般公開についても言及した。これらの仮想マシンはその下の物理マシンへのダイレクトアクセスを提供し、仮想マシンだけでは要求を満たせないアプリケーションに理想的な運用環境を提供する〔関連記事〕。またコンテナのクラスターの安全な稼働にも適している。これらベアメタルインスタンスも、NVMeストレージをサポートしている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

AWSがIoTデバイスのワンクリックでLambdaファンクションを実行するアプリを発表

Amazonが2015年にAWS Lambdaを導入したときには、サーバーレスコンピューティングという概念がまだよく知られていなかった。デベロッパーはそれによってソフトウェアを、それを実行するサーバーの管理等をせずに配布できる。サーバーはAmazonが管理し、そのインフラストラクチャは何かのイベントが要求をトリガしたときだけ動く。今日同社は、AWS IoT 1-Clickと呼ばれるアプリをiOS App Storeにリリースして、サーバーレスコンピューティングの概念をさらにまた一歩、前進させた。

その名前の“1-Click”の部分はちょっと大げさだが、とにかくこのアプリは、ラムダのイベントトリガーへのさらに素早いアクセスをデベロッパーに提供する。それらは、バッジを読むとか、ボタンを押すといった単純な目的のデバイスに向いている。たとえばそのボタンを押したらカスタマサービスやメンテナンスにつながるなど、そういった単純なシナリオだ。

そもそもAmazonにその好例といえるダッシュボタンがある。それは（Wi-Fiなどインターネットのある環境で）、ワンプッシュで特定のもの（洗剤、トイレットペーパーなど）を一定量注文できるボタンで、AWS IoT 1-Clickでデベロッパーは、自分のデバイス*にそんなシンプルな機能を持たせることができる。〔*: ローンチ直後の現状でサポートされているデバイスはボタン2種のみ、今後増える予定。〕

この機能を利用するためには、最初に自分のアカウント情報を入力する。利用するWi-Fiを指定し、デバイスとそのデバイスのLambdaファンクションを選ぶ。今サポートされているデバイスは、汎用ダッシュボタンとも言えるAWS IoT Enterprise Buttonと、AT&T LTE-M Buttonだ。

デバイスを選んだら、Lambdaファンクションをトリガーするプロジェクトを定義する。単純に、メールやSMSを送らせてもよい。イベントをトリガーするLambdaファンクションを選びNextをタッチすると、構成画面になるのでトリガーアクションを構成する。たとえば、会議室にいるときそのボタンを押したらIT部門を呼び出し、IT部門は送られてきたページから、どの会議室からヘルプの要請があったか分かる、など。

そして、適切なLambdaファンクションを選ぶ。それは、あなたの構成情報どおりに動くはずだ。

これらの指定、選択、構成などのプロセスはもちろんワンクリックでは済まないし、テストや構成変えも必要になるだろう。でも、シンプルなLambdaファンクションを作るアプリ、というものがあれば、プログラミングのできない人でもボタンを単純なファンクションで構成できるだろう。ちょっとした学習は必要だが。

このサービスはまだプレビューなので、アプリは今日ダウンロードできても、現時点では参加を申し込む必要がある。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

AWSのデータベースサービスAuroraにアンドゥ機能が誕生、72時間の遡及可能

AWSの‘マネージドMySQL/PostgreSQL’データベースサービスに、アンドゥ機能がつく。今日の同社の発表によると、そのAurora Backtrack機能により、ユーザーは“時間を逆行できる”。今それはMySQLのみだが、この機能を有効にするとそれ以降新たに作られるデータベースクラスターとバックアップからリストアされたクラスターに対し、アンドゥができるようになる。それまであったデータベースは、ノーだ。

この機能を有効にすると、AWSは最大72時間ぶんのトランザクションのログを取る。本番のデータベースに不正なテーブルを入れた、などの間違いに気づいたら、アプリケーションをポーズして、どこまで戻りたいか、時間（時刻）を指定する。するとAuroraはデータベースもポーズして、開いているすべての接続を閉じ、まだコミットしてないものをすべて落としてから、指定された時点までロールバックする。

もちろん、トランザクションの逆行はAWSが初めてではない。MySQLも含め、多くのデータベースシステムが、すでに何らかの形で実装している。ただしそれらの多くは、今日AWSが発表したものに比べると範囲が狭い。

AWSのチーフエヴァンジェリスト(Chief Evangelist) Jeff Barrが今日の発表で言っているが、それは災害復旧だけが目的ではない。彼はこう書いている: “あなたも、このクールな新しい機能の、クリエイティブで奇抜な使い方を、きっと思いつくだろう。たとえば、本番データベースでいろんなテストをして、そのテストの痕跡をすべて掃除することもできる。復旧の指示は、APIまたはCLI（コマンドライン）からできるから、この機能を既存のテストフレームワークに統合するのも容易だ”。

Aurora Backtrackは今、すべてのデベロッパーが使える。料金は、アメリカリージョンではレコードの書き換え100万文字につき約0.012ドルだ。ヨーロッパとアジアでは、やや高くなる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

これからはchrootツールを使わなくてもChrome OSの上で正規にLinuxを動かせる

かなり前からデベロッパーたちは、Croutonなどのツールを使ってChrome OSマシンをLinuxベースのデベロッパーマシンとして使っていた。それはちょっと面倒なやり方だが、とりあえず使えた。でも今度からは、それがもっと簡単になる。Chrome OSマシンの上でLinuxアプリケーションを動かしたい人は、Settingsメニューにあるスイッチを切り替えだけでそれができるようになる。それは、今後Googleが、Chrome OSにLinuxの現在の安定バージョンの載ったDebian Stretchが動く、仮想マシンを同梱するからだ。

それは、シェルを使えるだけでなく、グラフィクスも完全にサポートされる。だからたとえば、Visual Studio CodeのMicrosoftによるLinuxバージョンを、Chrome OSマシンで動かせる。あるいはAndroid StudioでAndroidアプリを作り、そのラップトップ上でテストできる。Chrome OSのAndroidアプリのサポートは、昨年実現したから。

Linux on Chrome OSの最初のプレビューはすでにGoogleのPixelbookで試せるが、そのほかのデバイスのサポートは“もうすぐ”ということだ。

GoogleのChrome OS担当プロマネ・ディレクターKan Liuによると、デベロッパーがCroutonを使っていることはもちろん知っていたが、でもそうすると、Googleが提供しているセキュリティ機能がいっさい及ばなくなってしまう。最近ではChrome OSマシンもかなり強力になっているので、そのままLinuxを使いたいという要望も増えている、という。

グラフィクスに関しては、Waylandディスプレイサーバーを使用している。ウィンドウのルックスは、Androidや、Chrome OS上のWebアプリケーションと同じだ。

一般ユーザーにはLinuxの内蔵サポートから得られる利益はあまりないと思われるが、デベロッパーにとってはこれでChrome OSマシンがより魅力的になる。Pixelbookのようなハイエンドマシンでは、とくにそうだろう。Liuは、自分たちのチームが相当な労力を費やしてその仮想マシンを最適化した、と強調している。だから、Linuxアプリケーションを動かすことに伴うオーバヘッドは小さい、と見てよいだろう。あまり強力でないマシンでも、コードエディターを不満なく使えるのではないか。

そのうち誰かがWineエミュレータを持ち込んで、Chrome OS機の上でWindowsアプリケーションを動かし始めるのも、時間の問題だろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Visual Studioの協業機能、Live Shareが一般公開。デバッグセッションも共有可能

今日（米国時間5/7）Microsoftは、同社主催のデベロッパー・カンファレンスBuildで、以前発表したVisual StudioおよびVisual Studio codeの協業開発機能、Live Shareを全デベロッパーに公開すると発表した。これまではプライベート・プレビューのみだった、今後は無料版Visual Studio codeエディターのユーザーを含め誰でも利用できる

Live Shareは、ある意味でGoogle Docsの協業機能と似ている。デベロッパーは全員のカーソル位置や、同僚がタイプしているところをプラットフォームによらず見ることができる。Live Shareセッションに参加しているデベロッパーは、自分の気に入った（カスタマイズされた）環境をそのまま利用できるため、従来の画面共有と比べて柔軟性がずっと高い。

MicrosoftがBuildで特に強調していたのが、デバッグセッションも共有できる機能だ。これは全員がブレークポイント設定してログを見ることができることを意味している。コードを書くことは重要だが、デバッグセッションを共有できることは、多くのデベロッパーにとってそれ以上に重要かもしれない。

Live Shareは、C#、Python、Java、Go、C++を含む主要プログラミング言語で利用できる。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

Kubernetesのための機械学習ツールKubeflowが発表から4か月で最初のバージョンをリリース

Googleが作ったオープンソースのコンテナオーケストレーションツールKubernetesは、おそらく同社が想像しなかったほど華々しく成長した。そしてその人気が増すとともに、多くの関連プログラムが生まれてきた。今日（米国時間5/4）はGoogleが、オープンソースのツールKubeflowのバージョン0.1のリリースを発表した。これは、Kubernetesのコンテナに機械学習をさせるためのツールだ。

Googleはかなり前にKubernetesをCloud Native Computing Foundationへ移したが、積極的な関与は継続し、今回のKubeflowもそのひとつだ。このプロジェクトは昨年末オースチンで行われたKubeconで発表されたばかりだが、早くもかなりの勢いがついている。

GoogleでKubeflowを運用しているDavid Aronchickは、その前の2年半、Kubernetesのチームを率いた。その彼の言うKubeflowの基本的な考え方とは、データサイエンティストたちが、Kubernetesのクラスターの上で機械学習のジョブを動かせるアドバンテージを享受できることだ。Kubeflowを使って機械学習のチームは、既存のジョブを簡単にクラスターに付けられる。

今日の発表でプロジェクトは前進を開始し、その節目を報告するブログ記事は、安定性のアップと、コミュニティの要望に応じて実装した多くの新機能を強調している。新機能には、機械学習のジョブをコラボレーションと対話により訓練するJupyter Hubや、Tensorflowの訓練とホスティングなどが含まれる。

Aronchickが強調するのは、このプロジェクトがオープンソースなので、いろんなツールを使えるということ。最初のバージョンがGoogleの機械学習ツールばかりサポートしていても、 Tensorflowに縛られることはない。今後のバージョンでは、そのほかのツールのサポートも期待できる。

最初の発表からわずか4か月あまりでコミュニティは急速に成長し、70名を超えるコントリビューターと20社あまりのコントリビューター企業がいて、15のレポジトリーに700以上のコミットが行われた。次のバージョン0.2は、夏になる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Alexaのスキルにスキル内購入を書ける、デベロッパーに収入の道ひらける

【抄訳】
Amazonが今日（米国時間5/3）、Alexaのスキルを作っているデベロッパーが、そのスキルの中にスキル内購入を実装できるようにした。またそのために、スキルのためのAmazon Pay、Amazon Pay for Skillsを立ち上げた。これからはデベロッパーが、AmazonのEchoスピーカーのようなAlexa対応デバイスの音声アプリケーションから、収入を得ることができる。たとえばそれがゲームなら新しい武器を売ることができるし、無料の音声アプリの中に有料コンテンツのお買い上げお誘いを置くことができる。

この機能は2017年11月に発表されたが、これまではJeopardy!など、一部のアプリやゲームのデベロッパーだけが利用できていた。

音声アプリケーション（Amazon語で“スキル”）にスキル内購入が加わったら、お客はそこで売られているものを購入し、音声で支払うことができる。金額などの決済情報は、すでにそのユーザーのAmazonアカウントに結びついている。

有料にするコンテンツやその価格はデベロッパーが決められるが、購入の実際の処理はAmazonが扱う。またセルフサービスツールを使ってデベロッパーはスキル内購入を管理し、その売り方を最適化できる。ただしAmazonは、Prime会員向けには何らかの特典（値引き、特別コンテンツなど）を提供するよう、デベロッパーに要請している。なお売上に対するAmazonとデベロッパーの取り分は、30:70である。

【中略】

デベロッパーが売上を得る方法は、スキル内購入だけではない。

たとえばブランドやお店などは、イベントのチケットや花の配達など、さまざまな商品やサービスを、Amazon Pay for Alexa Skillsを利用して売ることができる。Amazon Payは既存のCRMと注文管理機能を統合しているので、お店は物やサービスを売るプロセスの中で販売管理ができる。その機能も、今日から一般公開される。

また、スキル内で何かを売るのではなく、人気の高いデベロッパーへの直接の報酬提供方式としてDeveloper Rewards（デベロッパー報酬）というプログラムもある。これは、スキルのデベロッパーのエコシステムを育てることが目的だ。

スキルのエコシステムと言えば、今日の発表ではAlexaのスキルの総数は40000、12月の25000から大きく増えている。

しかしこのエコシステムはロングテールがとても長くて、ユーザーのいない、またはほとんどいないスキルも多い。音声アプリの開発を体験してみるためにだけ作った、というものもある。音声デバイスの使われ方に関する調査によると、音声アシスタントでいちばん多く使われているのは、ニュースと情報、スマートホームのコントロール、タイマーのセット、リマインダーなどだ。多くは、音声アプリでなくてもよいものだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

DatadogのコンテナマップはKubernetesアプリケーションの内部〜各コンテナの可視性を提供

コンテナへ移行する企業が増えている中で、個々のコンテナと、それがアプリケーションに与えているインパクトをモニタすることが、課題になっている。それがとくに難しいのは、コンテナがきわめて短時間だけ存在する短命な実体だからだ。モニタリングとアナリティクスの専門企業Datadogは今日（米国時間5/3）、この問題を解決するための視覚化ツール、コンテナマップを発表した。

Datadogのプロマネ担当VP Ilan Rabinovitchはこう語る: “コンテナマップはユーザーのシステムにあるすべてのコンテナを見せる。顧客はすべてのコンテナを、どんなときでも見られて、それらをタグに基づいてグループ化し、その中で起きていることを詳しく知ることができる”。

同社はタグとメタデータを利用してコンテナの各部とそれらのお互いの関係、そしてそれらを支えるインフラストラクチャを識別する。そのツールはコンテナを、Datadogのそのほかのエンティティとまったく同じようにモニタする。

同社のブログ記事は、こう書いている:

“ホストマップが個々のインスタンスに対してするように、コンテナマップはメタデータを使ってコンテナを容易にグループ化し、フィルタし、点検できる。メタデータは、サービス、可利用性ゾーン、ロール、パーティション、そのほかのユーザーが望む特質など、何でもよい”。

問題が見つかったとき、Datadog自身が顧客企業のシステムにライト(write)アクセスして問題を修復することはしないが、その企業はWebhookや、あるいはAmazon Lambdaのファンクションのようなサーバーレスのトリガを使って、何らかのアクションを呼び出すことができる。

  1. container-inspect

  2. container-list

  3. dashboard

 View Slideshow
Exit

同社は、すべてのコンテナが正常に動作していることを監視するサードパーティにすぎない。“コンテナに対してやるべきことは、もっぱらKubernetesを信用している。でも異状が起きたら、何が起きたのかを知らなければならないが、それはKubernetesにできることではない”、とRabinovitchは語る。この新しいマップの機能は、コンテナシステムの内部に対する、その欠けていた可視性を提供し、ユーザーは個々のコンテナの内部を詳細に調べて、問題の原因を特定できる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

クラウドホスティングのDigitalOceanもついにコンテナプラットホームを提供

誰もが気軽に使えるクラウドホスティングサービスDigitalOceanが、そのメニューにコンテナサービスを載せた。同社は今でも、安価な仮想プライベートサーバーのホスティングサービスとしていちばんよく知られているが、同社自身はそのうち、クラウドコンピューティングの世界でメジャーになるつもりだ。ホスティングは、そのプランの最初の部分にすぎない。たとえば同社のストレージサービスSpacesは、同社の夢が本気であることを示す一例だ。

しかし今や、コンテナを避けて通れない世の中になっているので、同社が今日（米国時間5/2）、Kubernetesベースのコンテナサービスを立ち上げたのも、もはや意外ではないだろう。

このサービスはまだ初期のプレビュー段階で、ここからサインアップできるが、一般公開は今年の終わりごろだ。

DigitalOceanのプロダクト担当VP Shiven Ramjiはこう述べている: “私たちはいつも、デベロッパーのためのシンプルなソリューションに専心してきた。その最初のプロダクトが、クラウドサーバーDropletsだった。今度のプロダクトも、その例外ではない。デベロッパーは自分のアプリケーションを完成させることに専念でき、複数のアプリケーションにまたがるスケーラビリティの高い安全なクラスターを作って動かすことに伴う、複雑な作業は免除されるのだ”。

そのサービスはDigitalOcean Kubernetesと名付けられ、それによりデベロッパーは、自分のコンテナワークロードをDigitalOceanのプラットホームでデプロイし管理できる。大手のクラウドコンピューティングプロバイダーのほとんどすべてが提供している競合製品と同様に、DigitalOceanのプロダクトも、Kubernetesを動かすことに伴う複雑性の大部分を、抽象化してデベロッパーからは見えなくする。しかし必要ならユーザーは、KubernetesのAPIにフルアクセスして、独自の隔離されたKubernetesクラスターを作れる。

このサービスは同社の既存のサービス、ストレージやファイヤーウォールツールなどを統合している。デベロッパーは自分のコンテナを、DigitalOceanの標準のノードで動かすか、あるいはより強力で計算能力の高いノードで動かすかを、選択できる。また“teams”という機能で、アクセスコントロールができる。さらに、こういうサービスの通例として、通常のパフォーマンスアナリティクスやロギングの機能もある。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Google MapsがそのAPIの構成と課金方式を抜本的に変えて単純化、月200ドルぶんまで無料

GoogleがGoogle Maps APIを大きくアップデートし、それに伴い名称をGoogle Maps Platformに変えた。

これはこのAPIプラットホームの近年で最大の変化のひとつで、Google Mapsのデベロッパーからの利用を大幅に単純化するとともに、APIの課金方法も変わった。そして6月11日からは、デベロッパーは有効なAPIキーと、Google Cloud Platformの有料ユーザーとしてのアカウントが必要になる。

まず、これまで18に分かれていたMaps APIが三つのプロダクト、Maps, Routes, およびPlacesに統一される。ただし、既存のコードはそのまま無変更で動く。

また課金体系は、これまでのStandardとPremiumという二つのプランに代わり、単一の料金プランになる。サポートはこれまでPremiumプランのみだったが、これからは全域的に無料で提供される。無料プランはないが、月額200ドル相当ぶん*までの利用は無料となる。また、企業顧客向けには特注プランがある。〔*: 上のリンク先に200ドルでどれだけのことができるか、例がいくつか示されている。〕

特定業界向けのMapsソリューションも、既存のものを継続し、今後新たなものをローンチしていく。たとえば今年初めには、Mapsのデータを利用して現実世界を舞台とするゲームを作るゲームデベロッパーのためのプログラムを立ち上げた。そして今日は、アセットトラッキング*とライドシェアリングのための同様のソリューションを発表した。Lyftのアプリは昨年から、このライドシェアリングプロダクトを使っている。〔*: アセットトラッキングサービスの例。〕

今日の発表声明は、こう書いている: “われわれのアセットトラッキング提供物は、車両などの資産（アセット, assets）の位置をリアルタイムで追跡し、車両を複雑な行路へルートすることによって企業の効率を改善する。今後はわれわれがインサイトと専門的能力を提供できるようなほかの分野にも、新たなソリューションを導入していきたい”。すなわちGoogle Mapsは今後、そのビジネス利用〜企業利用の本格化多様化に力を入れるようだ。

しかしGoogle Mapsとしてはこれは、正しい方向性だろう。Google Maps APIのアクセスは往々にして、問題を生じてきた。とくに無料利用のレベルを変えたときには、騒動が起きた。今日の変化により、これからはデベロッパーコミュニティからそのようなリアクションが起きることもないだろう。デベロッパーの仕事を、今後長期にわたって楽にしてくれる、と思われるからだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

RedHatのCoreOSがKubernetesアプリケーションを管理するツールキットを発表

Red Hatが今年初めに2億5000万ドルで買収したLinuxディストリビューションとコンテナ管理のスタートアップCoreOSが今日（米国時間4/30）、Kubernetesのクラスターを管理するオープンソースのツールキットOperator Frameworkを発表した。

CoreOSがソフトウェア概念としてのOperatorについて最初に言及したのは、2016年だった。その考え方は、コンテナベースのアプリケーションをデプロイし管理するためのベストプラクティスをコードとして実装することだった。“まあOperatorとは、最良のオペレーター社員を絵に描いたようなものだ”、とRedHatのOpenShiftのプロダクトマネージャーRob Szumskiは語る。理想としては、Operator Frameworkはオペレーションのチームをあらゆる雑用や単純労働から解放して、高いレベルのタスクに集中させる。そして同時に、Operatorがつねに会社のルールブックに従うことによって、その過程からエラーしがちな人間を取り除く。

CoreOSのCTO Brandon Philipsは、今日の発表声明でこう説明している: “Kubernetesを最大限に有効利用するためには、Kubernetesの上で動くアプリケーションをサービスし管理するための一連の統一的なAPIを広げる必要がある。われわれはOperatorを、Kubernetes上のそういうアプリケーションを管理するランタイムだ、と見なしている”。

Szumskiによれば、CoreOSのチームは、同社独自のTechtonicコンテナプラットホームを作って管理するときに（そのユーザーコミュニティからのものも含めて）、これらのベストプラクティスを開発した。それらがコードとしてのOperatorとして動くようになると、Kubernetesのクラスターを監視し、アップデートを処理し、たとえば何かがおかしくなったら、数ミリ秒以内にその不具合に反応する。

全体としてのOperator Frameworkは、三つの部分から成る。1)実際のOperatorを作ってテストしてパッケージするためのSDK、2)OperatorをKubernetesのクラスターにデプロイしてそれらを管理するためのOperator Lifecycle Manager、そして、3)チャージバックや顧客への課金を必要とする企業のためにKubernetesのユーザーを（リソース使用量などを）計量することだ。

軽量ツールは全体の絵の中ではつけたり的だが、Szumskiによると多くの企業がそれを求めるのであり、CoreOSもKubernetesでそれをやるのはうちが初めて、と主張している。

今日のCoreOS/Red Hatによる発表は、今後各方面から、さまざまなKubernetes関連の発表が行われそうな週の、始まりにすぎない。数日後にはCloud Native Computing FoundationのデベロッパーカンファレンスKubeConが始まるし、そこではコンテナのエコシステムに帰属する企業のほとんどが、何かを発表すると思われるからだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

KubernetesをCloud Foundryが本格採用して両社の仲がより密接に

コンテナがソフトウェアの世界を食べている。そしてKubernetesがコンテナの王様だ。そこで、大きなソフトウェアプロジェクトに、とくに企業で関わる人は、いずれこの王様とお近づきになる。今ボストンで、半年に一度のデベロッパーカンファレンスをやっているCloud Foundryも、その興味深い例のひとつだ。

エンタープライズデベロッパーの世界の外にいる人にとっては、Cloud Foundryは馴染みのない名前だが、今ではFortune 500社の約半数がユーザーだ（スタートアップのユーザーはあまりいない）。Cloud Foundryをよく知らない人は、Herokuに似ている、と思ってもよい。ただしそれは商用ユーザーの大きなエコシステムのあるオープンソースのプロジェクトで、そのどんなクラウドやオンプレミス上のインストールでも、そしてどんなに大きなスケールでも、動かすことができる。デベロッパーは自分のコードを（Twelve-Factorの方法論–日本語–に従って）書き、実行に必要なものを定義すると、それが動くためのインフラや、必要なスケーリングについては、すべてCloud Foundryが面倒見てくれる。デベロッパーは自分のアプリケーションをどこで動かすか、どうやってもっと効率的に動かすかなどを、考えなくてよい。

それだけのことを可能にするためにCloud Foundryは、Dockerなどがまだ存在しない、きわめて初期のころからコンテナを導入した。そのころKubernetesはまだなかったので、Cloud Foundryに関わっているさまざまな企業が一緒になって、独自のコンテナオーケストレーションシステムを作った。それは今日のサービスでも利用されている。しかし、コンテナベースの開発が普及するに伴い、Cloud Foundryのエコシステムでも、Kubernetesをサポートせよ、という声が高くなった。昨年Foundationはその方向への第一歩を踏み出し、コンテナを管理するための、KubernetesベースのContainer Runtimeをローンチした。それが、これまでのApplication Runtimeの隣に座る。これによってデベロッパーは、Cloud Foundryを使って、彼らが開発する新しいサービスと並列に、彼らの新旧の一枚岩的なアプリケーションを動かし管理することもできる。

でも、Cloud FoundryではApplication Runtimeのための同団体独自のコンテナサービスをなぜ使い続けるのだろうか？　今ではKubernetesやそのほかの各種プロジェクトが出揃ってきて、それらがコンテナを扱うためのデフォルトになっているから、そんなことをする理由はないはずだ。そこで、当然とはいえ、今では、古いコンテナ管理システムをなくして、それらをKubernetesで置き換えていくCloud Foundryのプロジェクトがある。今やコンテナ管理の部分は、Cloud Foundryの差別化要因ではない。むしろ、Cloud Foundryの最大の差別化要因はデベロッパー体験であり、Cloud Foundryのそもそも中心的メリットは、デベロッパーがインフラストラクチャの内部構造をまったく気にする必要がない、という点にある。

Cloud FoundryのエコシステムがKubernetesに傾くことには、もうひとつの側面がある。Cloud Foundryも同じくソフトウェアだから、それをKubernetesの上で動かして悪い理由はない。だから、SUSEやIBMなど、Cloud Foundryの最大のベンダーたちの一部も、まさにそうしている。

Cloud Foundryの公認ディストリビューションであるSUSE Cloud Application Platformは、どのパブリッククラウドのKubernetesインフラストラクチャの上でも動く。それにはMicrosoftのAzure Container Serviceも含まれる。SUSEのチームによると、その方がデプロイが容易であるだけでなく、リソースの節約にもなる（アプリケーションがより少ないリソースで動く）。

同じくIBMも、今では顧客にKubernetesの上でCloud Foundryを提供している。ただしそれはまだ、実験段階だそうだ。IBMのCloud Developer ServicesのゼネラルマネージャーDon Bouliaが強調するのは、IBMの顧客の多くは自分たちのワークロードを、IBMのそのほかの顧客に共有されない隔離された環境で動かしたがることだ。

Bouliaによれば、多くの顧客に、KubernetesかCloud Foundryか、という視点はない。彼の顧客の多くにとっては、Kubernetesを使うことが即、自分たちの既存のアプリケーションをクラウドへ移すことだ。そして新しいアプリケーションに関しては、Cloud Foundryを動かすことを選ぶ。

SUSEのチームも、同じことを強調している。SUSEの顧客のひとつのパターンとして、彼らはコンテナ環境をセットアップしたくてSUSEにやってくるが、しかしその商談の過程で、Cloud Foundryを実装することを決心するのだ。

というわけで、今週のイベントのメッセージはまさに、KubernetesとCloud Foundryが互いに補完的な技術だ、ということだ。そのイベントのパネルディスカッションで、GoogleのContainer EngineとKubernetes担当技術部長Chen Goldbergも、その点を強調した。

Cloud Foundry Foundationと、KubernetesのホームCloud Native Computing Foundation(CNCF)は共に、Linux Foundationの傘下にある。しかしCloud FoundryはCNCFに比べて圧倒的にエンタープライズユーザーの比重が大きい。そこには何らかの政治が絡んでいるのかもしれないが、でも両団体は互いに十分に友好的で、メンバーも相当重複している。PivotalのCEO Rob Meeは、本誌のRon Millerの取材に対してこう述べた: “うちは半分CNCFで半分Cloud Foundryだ。二つのコミュニティはますますいろんな技術を共有し合っているし、共に進化している。完全に独立でもないし、競争関係もない。関係はもっといろいろ複雑で微妙だ。CNCFとCloud Foundryはどちらも、大きなエコシステムの部分であり、互いに補完し、収束している”。

つまりCNCFとCloud Foundryの技術共有と、もしかしてコラボレーションは、今後も増えるということだろう。CNCFはクラウドネイティブなアプリケーションを作るための、とてもおもしろいいろんなプロジェクトのホームであり、そしてそれらのユースケースの多くはCloud Foundryにもある。

関連記事: Cloud Foundry財団、Alibabaがゴールド会員に――中国のクラウドのオープンソース化加速へ

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

サイトに潜むトラッカーが、「Facebookでログイン」のデータを狙っている

Facebook がTechCrunchに伝えたところによると、現在同社は、「Facebookでログイン」機能を利用しているウェブサイトに埋め込まれたサードパーティー製Javascriptトラッカーが、Facebookのユーザーデータを取得できることを指摘したセキュリティー調査報告書を精査している。このバグを悪用すると、ユーザーが登録していれば、名前、メールアドレス、年齢層、性別、地域、プロフィール写真などを収集できてしまう。トラッカーがこのデータを何に使っているのかは不明だが、こうしたトラッカーを売っているTealium、AudienceStream、Lytics、ProPSといった会社は、集めたユーザーデータを使った収益化サービスをサイト管理者向けに販売している。

ウェブサイト上位100万件のうち悪意のあるスクリプトが見つかったサイトが434件あった、フリーランサーサイトのFiverr.com、カメラ販売のB&P Photo And Video、およびクライドデータベース・プロバイダーのMongoDBらの名前もあった。Steven EnglehardtがPrinstonのCenter For Information Technology PolicyがホストしているFreedom To Tinkerのチームと協力して調べた。

一方、コンサート発見サイトのBandsInTownは、同社のAmplifiedという広告アプリをインストールしているサイトの埋め込みスクリプトに、「Facebookでログイン」のユーザーデータを送り込んでいたことがわかった。サイトにロードされたBandsInTownの透明iFrameがユーザーデータを取り出し、埋め込みスクリプトがアクセスできるようにする。その結果BandsInTownを使っている悪質サイトは訪問者の個人情報を知ることができる。BandIn Townのこの脆弱性はすでに修正されている。

TechCrunchは、今もFacebookから「調査して後に連絡する」という以上の正式声明を待っている。今日（米国時間4/18）の午前にこの問題をMongoDBに伝えたところ、同社は調査した結果として次の声明を送ってきた。「サードパーティー製ツールがトラッキングスクリプトを利用してFacebookのユーザーデータの一部を収集していたことを、当社は認識していなかった。われわれはスクリプトの出所を突き止め、すでに停止した」

BandsInTownは私に、「BandsInTownは許可されていないデータをサードパーティーに提供することはない。当社の広告フラットフォームで動作していたスクリプトに脆弱性がある可能性を示す調査会社からのメールを見て、直ちに適切な作業をおこない、問題は全面的に解決している」。Fiverrからは本稿執筆時点で回答がない。

一連のデータセキュリティー欠陥の発覚は、Facebookが痛手を受けている時期に重なった。 Cambridge Analyticaスキャンダルから立ち直ろうとしている CEO Mark Zuckerbergは、つい最近議会で証言し、Facebookは、欧州のGDPR法に準拠するべくプライバシーの仕様を変更した。しかしFacebookが最近実施したユーザーデータを保護するためのAPI変更は、上記の脆弱性を防止できなかった。そして現在は、Facebookユーザーがサイトにいる間だけでなく、インターネットのどこにいても追跡される方法があるという、ほとんど知られていなかった事実に注目が集まりつつある。

「ユーザーがウェブサイトに自分のソーシャルメディアのプロファイルを渡すと、その人はそのウェブサイトを信用しただけでなく、サイトに埋め込まれているサードパーティーも信用したことになる」とEnglehardtは書いている。下の表は、トラッカーがユーザーから何を引き出しているかを示している。最近Freedom To Tinkerは、OnAudienceに対して別のセキュリティー問題について警告し、その結果同サービスはユーザー情報の収集を中止した。

FacebookがAPIを十分に監視していれば、こうしたトラッカーを見つけ出し悪用を未然に防いでいたかもしれない。現在同社はAPI監査を強化して、Cambridge Analyticaにユーザーデータを渡した手口を真似るデベロッパーを探し出そうとしている。さらにFacebookは、デベロッパーがアプリ固有のユーザーIDを使ってその人物のFacebookユーザーIDを突き止めることを阻止するために、システムを変更することができるはずだ。

この種の暴露はユーザーの大規模な反発につながることが多い。ここ数年、世間はウェブ周辺で自分のデータが無許可で利用されている状況に甘んじてきた。矢面に立たされているのはFacebookだが、Googleのような他のIT巨人たちも、ユーザーデータに依存し、容易には監視できないデベロッパープラットフォームを運用してる。そして、なんとか広告で稼いで生き残ろうとするニュース発信者たちは、怪しげな広告ネットワークやトラッカーに走りがちだ。

Zuckerbergが標的になりやすいのは、Facebookのファウンダーである彼が今もCEOを務めているからだ。評論家や規制当局は、Facebookの失敗をZuckerbergの責任にできる。しかし、ユーザーデータの扱いが大雑把な企業はどこも覚悟しておいたほうがいい。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

アプリケーションにチャット（会話）機能をつけるAPI、Dialogflow Enterprise EditionをGoogle Cloudが一般公開

会話ができるための入出力インタフェイスを作ることは、デベロッパーにとって新しい挑戦分野だ。チャットボットはWebサイトやアプリにおけるトラブルを減らし、会話ができるという構造の中では、企業はよく聞かれる質問に簡単迅速に答えることができる。そこで今日（米国時間4/17)Googleは、これまでベータだったDialogflow Enterprise Editionを一般公開した。

この技術は、2016年におけるAPI.AIの買収の成果だ。Googleは賢明にもツールの名前を変え、それが実際にすることにマッチした名前にした。同社によると、現在すでに、数十万のデベロッパーがこのツールを使って会話のためのインタフェイスを構築している。

これは必ずしもGoogleオンリーのツールではなく、Google AssistantやAmazon Alexa、Facebook Messengerなどの音声インタフェイスでも使えるから、デベロッパーが一度チャットアプリを作ったら、それらを、コードを大幅に変えなくてもさまざまなデバイスで使えるようになる。

さらに今日のリリースでは、機能を増やすとともに、エンタープライズエディションへの移行を容易にした。

GoogleのCloud AIのプロダクトマネージャーDan Aharonが、このツールを発表するブログ記事で、こう述べている: “今日からは、一つのAPI呼び出しで複数のAPI呼び出しが必要になるような、バッチ的な処理ができるようになり、コードの行数を減らして開発時間を短縮できる。Dialogflow API V2は今や、すべての新しいエージェントのデフォルトであり、Google Cloud Speech-to-Textを統合、APIからのエージェントの管理が可能になり、gRPCをサポート、そしてコードのマイグレーション不要でEnterprise Editionに容易に移行できる”。

同社は、Dialogflowを使って顧客のためのチャットインタフェイスを構築した企業の例として、KLM Royal Dutch AirlinesやDomino’s、Ticketmasterなどを挙げた。

この新しいツールは今日（米国時間4/17）から可利用になり、30以上の言語をサポートする。一般公開されたエンタープライズプロダクトには、サポートパッケージとサービスレベルアグリーメント（SLA）がつく。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

コードレビューサービスの繁盛でPullRequestはシードから数か月後に$8MのシリーズAを調達

オンデマンドのコードレビューをクラウドサービスとして提供しているPullRequestは最近忙しい。でもそれは、どんなスタートアップでも大歓迎するような忙しさだ。昨年8月にY Combinatorを卒業したばかりの同社はまだ、スタートアップの流儀を学んでいる最中だ。12月には230万ドルのシードラウンド を勝ち取り、資金面では安泰なはずだが、今日同社は同社のシードをリードしたシード投資家Google Gradient Venturesが率いるシリーズAによる、さらに800万ドルの資金調達を発表した。

今日発表された投資には、Y Combinator, Fika Ventures, Lynett Capital, Defy Partnersなど、そのほかのシード投資家も参加した。同社はわずか数か月で合計1030万ドルを調達したことになる。

なぜどうして、花の蜜にたかる蝶のように投資家は同社に殺到するのか？　PullRequestは、デベロッパーの大きな痛点を治療する。開発サイクルがはやくなると、真っ先に犠牲になるのが、コードの品質管理だ。同社のファウンダーでCEOのLyal Averyが昨年8月に本誌に語ったところによると、同社はオンデマンド方式でこの問題を解決している。彼は、こう語る:

“われわれは、コードレビューをSaaSとして提供している。デベロッパーがコードをプッシュすると、うちが抱えるオンデマンドのエキスパートたちがそれをレビューする。これによってデベロッパーたちは、負担増となる重いリソースを自分のところで抱えなくても、快調に前進できる。

12月のシードラウンドのときは、Averyはそのプラットホームにオートメーションとインテリジェンス(AI)を導入したい、と言ったが、最近では、今もその方向に向かって進んでいる、という。そこで早期の800万ドルの導入、となる。

今は、大規模なデータリークがあちこちで発生している。Averyも、今後のコードレビューではバグや問題を見つけるだけでなく、フィットネスのUnder Armourなどがやられたようなデータリークの防止にも力を入れなければならない、と言っている（Under Armourの名はたまたまごく最近の例だから挙げたにすぎない）。彼は自明の理由によりクライアントの名は明かさなかったが、最近同社は、コード中に脆弱性を見つけて、リークを未然に防ぐことができた、という。

投資をリードしたGradient Venturesの専務取締役Anna Pattersonは、オンデマンドとコードレビューは強力な組み合わせだ、と見ている。“PullRequestは、良質なコードと仕事の未来が交わるところにいる。AIを使ってコードレビューのアクセス性を良くし、大小を問わずあらゆる企業がコードレビューを気軽に発注できるようにしている”、と彼女は声明文の中で言っている。

コードレビューとバグ追跡は、スタートアップのホットな分野であり続ける。開発サイクルがどんどんはやくなっているから、企業もコードレビューを外注に頼らざるをえない。タイムフレームが長かった昔は、開発のワークフローの中でコードの品質管理をやる余裕があった。しかしタイムフレームはだんだん圧縮され、余裕がなくなり、PullRequestのようなところに頼まざるをえなくなっている。投資家たちは、そこに着目する。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）