Google CloudがCloud NAT、Firewall Rules Loggingなどネットワーキング機能を充実

今日(米国時間10/10)は、ロンドンでNextイベントを開催しているGoogle Cloudからのニュースで、忙しい日だった。このイベントで同社は、いくつかの新しいネットワーキング機能をローンチした。それらの中でも今日の主役はCloud NAT、これによりデベロッパーは、一般的に公開されるIPアドレスがなくて、企業の仮想プライベートクラウドの中にあるアプリケーションからのみアクセスできる、クラウドベースのサービスを容易に構築できる。

Googleも言うように、このようなセットアップは前から可能だったが、しかし容易ではなかった。でも、よくあるユースケースなのでGoogleは、Cloud NATにより、ネットワークアドレス翻訳(network address translation, NAT)のすべてを取り扱う完全に管理されたサービスを提供することになった。そしてCloud NATのゲートウェイの背後にあるプライベートなインスタンスへのアクセスを、デベロッパーに提供する。

Cloud NATはGoogle Compute Engineの仮想マシンと、Google Kubernetes Engineのコンテナをサポートし、デベロッパーが手作業でIPを指定できるマニュアルモードと、IPが自動的に割り当てられるオートマチックモードの両方を提供する。

今日は新たに、Firewall Rules Loggingがベータでリリースされた。アドミンはこの機能を利用してファイヤーウォールのルールの効果を監査し確認できる。たとえば、ファイヤーウォールがブロックする接続の試みが何度も繰り返されるときには、それらを分析して、誰かが良からぬことをしようとしているのか、それともファイヤーウォールの構成ミスかを判断できる。データの遅れは5秒程度なので、ほとんどリアルタイムに近い点検が可能だ。また、これをほかのサービス、Stackdriver Logging, Cloud Pub/Sub, BigQueryなどと統合してアラートやデータ分析もできる。

さらに今日の発表の中には、HTTPSロードバランサー用に証明を提供するマネージドTLSがある。これは、ロードバランサーを使っているときのTLS証明の管理に伴う煩雑さを解消することが目的で、これによりエンドユーザーのブラウザーがデベロッパーのアプリケーションに安全に接続できるようになる。この機能も、現在はベータだ。

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

Cloud FoundryがKubernetesへのサポートを拡大

比較的最近まで、Cloud Foundry財団はCloud Foundryが全てだった。Cloud Foundryとは、今ではFortune 500企業の大部分で利用されているオープンソースのPaaS(サービスとしてのプラットフォーム)プロジェクトである。このプロジェクトは、Cloud Foundry Application Runtimeという名のものだ。1年前、財団はCloud Foundry Container Runtimeというものも発表した。これは企業たちが、Application Platformと自分たちのコンテナベースのアプリケーションを同時に運用することを助けるための仕掛けだ。さらに、Cloud Foundryはクラウドアプリケーションの構築、展開、および管理のためのツールであるBOSHを支えてきた長い歴史を持っている。

1年前のContainer Runtimeの追加は、組織のミッションを少々混乱させるもののように見えたが、そうした混乱も今は落ち着いて、その意図はより明確になり始めている。Cloud FoundryのCTOであるChip Childnerが語ったように、企業がContainer Runtimeを利用する最大の目的は、それぞれのベンダーから調達したパッケージ済のアプリケーションを実行するためだ。「Container RuntimeやあらゆるKubernetesによるデプロイメントを、App Runtimeと並列に、あるいは組合せて利用することが、独立ソフトウェアベンダーからパッケージソフトウェアを導入する際に多く行われていることです」と彼は私に言った。「コンテナは新しいCD-ROMなのです、利用者はそれを優れたオーケストレーションプラットフォームに載せたいだけです」。

Application RuntimeはKubernetesが登場するよりも前に始まっていたものなので、Cloud FoundryプロジェクトはDiegoという独自のコンテナサービスを構築していた。

本日(米国時間10月9日)、Cloud Foundry財団は、両者の統合を新しいレベルに進めるために、2つの新しいKubernetes関連プロジェクトを立ち上げた。1つ目はProject Eiriniである。これはIBMによって立ち上げられ、現在はSuseとSAPによっても作業が行われている。このプロジェクトは開発に長い時間を費やしているが、コミュニティが期待を続けているものである。これは基本的に、開発者たちがApplication Runtimeのために書かれたアプリケーションをデプロイする際に、既存のDiegoオーケストレイターとKubernetesの間で選択ができるようにするものだ。それはCloud Foundryにとって大きな変化だ。

「Eiriniが行うことは、Cloud Foundry Application Runtime(Cloud Foundryブランドが緊密に結びついているコアPaaS体験)に対して、それを支えるDiegoスケジューラーを、代替可能な場合にはKubernetesで置き換えるというオプションを与えることなのです」とChildersは説明する。彼は、Diegoコンテナ管理システムの方がKubernetesよりも適しているユースケースがまだあると付け加えた。そのうちの1つは、Windowsに対するサポートが優れていることだ。Cloud Foundryを使用する企業にとってはかなり重要な点だ。Childersはまた、Kubernetesのマルチテナントへの保証は、Diegoのものよりも若干厳密さが足りないとも指摘した。

2番目の新しいプロジェクトは、最初Suseによって開発されたContainerizedCFである。その名前が示唆するように、ContainerizedCFは基本的に、Cloud Foundry Application Runtimeのコアをパッケージ化し、BOSHデプロイメントツールの助けを借りてKubernetesクラスターにデプロイすることを可能にする。これは、Suseが既にCloud Foundryディストリビューションを出荷するために使用しているものとほとんど同じものだ。

明らかに近い将来、Kubernetesは、Cloud Foundry PaaSサービスがその上に載り、開発者たちがそのために書いたアプリケーションをデプロイするために使うものの、一部を占めるようになる。一見しただけでは、このKubernetesへの集中は、Cloud Foundry自身を無駄なものにしてしまうように思えるかもしれない。しかしそのコア体験としてのCloud Foundry Application Runtimeは、インフラストラクチャだけではなく、アプリケーション開発の全ライフサイクルを管理することを目指した開発者体験と方法論であることは覚えておく価値があるだろう。Kubernetesを使用してインフラストラクチャの管理を支援することができれば、Cloud Foundryプロジェクトは最も得意とする部分に集中することができるのだ。

[原文へ]
(翻訳:sako)

写真: Kittikorn / Getty Images

Bloombergの中国スパイチップのスクープはどこまで信頼できるか――ハイテク・エスピオナージュの闇を探る

昨日(米国時間10/4)、Bloombergが報じたスクープはインターネットに鋭い亀裂をもたらした。一方の陣営はこの記事は正確であり、Bloombergの記者はかつてない規模の外国のハイテク・スパイがアメリカのハイテク産業に浸透し、途方もない損害をもたらしていることを暴露したというものだ。他の陣営は、そうではない、多くの人々がデタラメの騙されているのだという。

中国のスパイがアメリカのデータセンターで用いられているサプライチェーンに浸透し、Supermicroのマザーボードに鉛筆の芯の先端ほどの微小なチップを仕込んで情報を盗み出しているというのがBloombergの記事だ。SupermicroのボードはAppleからAmazonまでアメリカ中のデータセンターで用いられているという。

Apple、Amazon、Supermicro、それに中国政府はそろってこの報道を強く否定した。AppleとSupermicroはその後独自の否定声明を出している。これはめったにないことで、各社とも「なにも隠していない」と強調したいのだろう。声明は公開されており、一読することをお勧めする。

では国家機密の報道という闇の世界へようこそ。

私は過去5年間(最近はCBSで)主にサイバーセキュリティーに関する報道を担当してきた。CBSではサイバーセキュリティー関していくつかのスクープを発表している。これにはアメリカ政府が監視活動に役立てるため脆弱性を調査できるようプロダクトのソースコードを明かすようテクノロジー企業に秘密に圧力をかけていた件も含まれる。昨年私はNSAが5年間に5回もデータ漏えいを起こしていたことを突き止めた。発見した秘密情報は政府のアメリカ市民に対する情報収集活動は当初予想されたよりはるかに広汎であることを示していた。

私はBloombergのスクープに対して態度を決めかねている。

どんな分野であろうと事実を求めようとするジャーナリストが諜報コミュニティーから確実な情報を得るのは不可能に近い。スパイや外交官にとって機密情報を資格のない相手に明かすのは刑務所で長い時間を過ごすリスクを冒すことになる。事実、あるものは今も服役している

セキュリティー担当記者がスクープできるのはトップクラスの情報源を握っているか、途方もないツキに恵まれているかどちらかだ――たいていの場合は後者だが。

当然読者は「スパイからのリーク」には用心深くなる。しかし一方、Bloombergは1990年以来、報道機関として高い評価を得てきた。調査は綿密で、重大なスクープなら10以上のソースから情報を得るのが普通だ。情報源は政府の内外にあり、証拠によって十分に裏付けのある記事を発表してきた。

とはいえ、こうしたスクープのソースは匿名であるのが普通だ。そもそも知る資格がなかったり、公開が禁じられている秘密情報であるなどの理由で情報源が法律的責任を追求される可能性があるからだ。しかしこれはアカウンタビリティーを難しいものにする。「事情に詳しい筋によれば」といった表現を好む記者はいない。記事が弱くなるからだ。記事に情報提供者の氏名が明記するのは記事が事実であるとことに責任を持つためだ。

一方で記事の対象となった企業からの否定声明は(これ自体Bloombergが正確に全文報道している)記事の内容が事実でないという証明にはならない。こうした声明は法務部を通して発表され、法律や諸規則に従っていることを主張している。証拠に基づいた報道を「言った、言わない」の水掛け論に持ち込もうという意図の場合もある。

そこでBloombergの記事に対して判断を下すのは読者に委ねられる。ジャーナリストはいかほどでも事実を報じることができるが、それを信じるか否かは結局読者だ。

Bloombergの記事に対するAppleの異議は、「指摘の内容があいまいだ」という点にある。しかし公平に言って、これほど重大なニュースであれば、最初から手の内をすべて見せることはあり得ない。しかしソースが他のニュースメディアに情報を流すのを防ぎながらさらに詳しい情報を得ようとする。情報源がライバルのメディアにも情報を流すというのは、スクープの価値を下げて報道の過熱を防ごうという意図で政府機関もときおり使うテクニックだ。

しかし記事で名指しされた企業、Apple、Amazon等も事情を知らず、闇の中にいる可能性がある。 外国政府による企業に対するスパイ行為に対するカウンターインテリジェンス活動が進行している場合、企業内でその事実をかすかにでも知ることになるのは一握りの人間だけなのは間違いない。アメリカの監視活動および対敵情報を所管する法律はこのような活動について「知る資格がある」人間を厳しく制限している。これは通常、企業の最高法務責任者に限られる。CEOや社長などその上司にはこの情報は知らされない。これは会社の経営陣が株主や市場に対して虚をつくことになるのを防止するためだ。

この点については2013年にエドワード・スノーデンが秘密文書多数を公開したときのことを考えてみるのがよい。

Apple他(この際はAmazonは含まれていなかった)のテクノロジー企業が関連したNSAのデータ収集プロジェクト、PRISMの存在が暴露された後、名指しされた企業はいっせいに強い言葉で関与を否定した。トップは知らなかったのだろうか? 半分は, イェスだ。しかしこうした場合、企業はチェリーピッキング、つまり自分たちに都合のいい部分だけに議論を限定することで、嘘をつかずに記事に反論することができる。 たとえば「アメリカ政府はPRISMでテクノロジー企業のサーバーから直接情報を入手している」という部分について、対象企業は「事実ではない」と否定した。しかし間接的アクセスまで否定したわけではなかった。そう主張すれば嘘になっただろう。

Bloombergの記事の批判者はチップのデザイン、スペック、機能などの技術的詳細を始めもっと情報が必要だと要求しいるがこれは正しい。元NSAの専門家、でRendition Infosecのファウンダーに転じたJake Williamsは、私の取材に答えて、問題の記事は「信頼できると思う。しかしもし事実でないと判明しても、(サプライチェーンを通じてサーバーに侵入する)能力は存在している。ネットワークが侵入されていないかどうかチェックできるようにする体制が必要なことは変わりない」と述べた。

私は当初この問題をカバーするのをためらった。問題があまりに複雑であり、、記事が衝撃的な事実を主張しているのに私には実否を確認できる手段がなかったからだ。Bloombergのチームがこの1年近くかけて探り出した問題について数時間で判断を下すのは難しい。Bloombergが記事発表の常道を踏んでいたすれば、こうしたカバーストーリーの場合、公表以前に数しれないほどの編集、推敲、ファクトチェックを受けていたはずだ。記者はいわば壁に頭をぶつけ、もうこれ以上何も報告するものがない状態になる。それから出版される。

もちろんBloombergももっとうまくやることはできただろう。たとえばNew York Timesが最近トランプ大統領のビジネスの税金問題でその取材過程をオープンにしたのがよい例だ。 Bloombergは結論を導き出すにあたって取材プロセスの透明性をさらに高めるべきだろう。ジャーナリズムは独占であってはならない。誰もが検証可能なオープンなものでなければならない。取材過程のオープンさを欠けばそれだけ読者の信用を失うことになる。

そこがこのような問題の報道で困難な部分だ。Bloombergの記事は、公平に言って、きわめて綿密に取材されており情報源も質が高いと思われる。しかし私が(他の読者もそうだと思うが)記事の内容を信用するかどうかはBloombergと取材チームを信用するかどうかにかかってくる。

フェイクニュースが溢れている現在、ジャーナリズムの未来のためにも、Bloombergの記事が決定的に間違っていたといった結果に終わらないよう私は望んでいる。

原文へ

滑川海彦@Facebook Google+

企業のコールセンター支援をクラウド上のサービスとして提供するTalkdeskが$1Bの評価額で$100Mを調達

企業のコールセンターのための顧客情報サービスをクラウド上のSaaSとして提供するTalkdeskが、コネチカットのヘッジファンドViking Global Investorsとこれまでの投資家DFJから新たに1億ドルを調達した。

このラウンドでは同社の評価額が10億ドルを超えたことを、協同ファウンダーでCEOのTiago Paivaが認めたが、正確な額は明かさなかった。

同社は、機械学習をはじめとする人工知能の技術を利用して、中企業から上のエンタープライズに良質なカスタマーサービスのための支援を提供している。顧客の中にはIBM, Dropbox, Stitch Fix, Farfetchなどがいる。

Paivaは次のように語る: “企業に100万の顧客がいて、彼らがサポートを求めているとしよう。Talkdeskはそんなときに、企業と顧客を可能なかぎり最良の形で結びつける。たとえばFarfetchはTalkdeskを利用することによって、各顧客が何を買ったか、彼らの好みは何か、これまでどんな苦情を言ってきたか、などが即座に分かる。われわれは企業にあらゆるものの履歴を提供して、迅速な問題解決ができるようにする”。

2011年にポルトガルで創業したTalkdeskは、サンフランシスコとリスボンにオフィスがある。今度の資金でイギリスへの進出と、AIへのより厚い投資を計画している。同社はこれまで、2015年の1500万ドルのラウンドも含め、約2400万ドルの増資を行っている。2012年のTechCrunch Disrupt NY Startup Battlefieldにも出場した

DFJのパートナーJosh Steinは、声明文の中でこう言っている: “今日のデジタル慣れしている顧客は迅速で個人化された答を求めているが、未だに大多数の企業が、そのようなアジリティとサービスを可能にする、柔軟性に富むクラウドネイティブなプラットホームを採用していない。しかし2019年には、クラウドを利用するコンタクトセンターが、例外ではなく標準になるだろう”。

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

Blissfullyが全てをサーバーレスで行うと決めた理由

サーバーレスは最近の大きな流行語だが、そうなったのには正当な理由がある。開発者がコ​​ードを書く方法を、完全に変えてしまう可能性があるのだ。その世界では、開発者たちは単に連続するイベントトリガーを書き、後はクラウドベンダーたちに、その仕事を終わらせるために必要な計算リソースの確保の心配を、任せてしまうことができるのだ。このことによって、プログラムが開発される方法は大きく変化するが、このやり方はまだ極めて新しいものであるために、完全にこの方法を採用する会社を見出すのは難しい。

顧客たちがそれぞれの企業内で使うSaaS利用の管理を助けるスタートアップであるBlissfullyは、そうした構築方法を採用すると決心した企業の1つだ。共同創業者でCTOでもあるAaron Whiteは、Blissfullyの初期バージョンを構築する際に、ある組織が利用しているすべてのSaaSプロダクトのリストを提供するためには、計算パワーを一時的に、迅速かつ大量に調達する必要があることに気が付いた。

必要に応じてその爆発的な計算機パワーを提供するためには、沢山のサーバーを予備として確保しておけば良いことはわかったが、そうするためには管理対象となる膨大なオーバヘッドが必要になってしまう。彼はサーバーレスと従来の仮想マシンの長所と短所を見比べて、サーバーレスが実現可能なアプローチとみなし始めた。しかしこの時点では、彼自身のSaaS管理アイデアが実現可能であることを証明しようとしているのは、彼1人しかいなかった。

彼がその過程で学んだことは、Blissfullyのような、必要に応じてスケールアップとダウンが繰り返される瞬発的なアプローチをとる企業に対しては、サーバーレスは多くの利点を提供できるということだった。しかし、それは完璧ではなく、管理や設定、そしてスケーリング能力に関する長所と短所の取扱に関わる課題があり、彼はそれを実践しながら学んで行かなければならなかった。特にこのアプローチを取り始めた初期のころには問題が山積していた。

サーバーレスは合理的だ

Blissfullyは、サーバレスを利用することが大変理に適ったサービスだ。利用していないサーバーに対して、管理をしたり支払いを行ったりする必要はない。また、基礎となるインフラストラクチャについても全く心配する必要がない。そうしたことはクラウドプロバイダーに任され、発生したバースト(瞬発的な利用増加分)に対して支払いを行うのだ。

サーバレスという名称は実は正確ではない。サーバーが実際にないということを意味してはいないからだ。実際に意味していることは、プログラムを実行するためにサーバーをセットアップする必要がないということである。そしてこれは驚くべき変化なのだ。従来のプログラミングでは、データセンターであろうがクラウドであろうが、事前にコードを書き、基礎となるすべてのハードウェアをセットアップしておく必要があった。サーバーレスでは、開発者はコードを書くだけで良く、残りの全てをクラウドプロバイダーが処理してくれるのだ。

実際には、プログラマたちが一連のイベントトリガを設定する。するとクラウドプロバイダーはそのイベントトリガーの発生に合わせて、必要なリソースをその場で提供するのだ。今ではクラウドベンダーのほとんどがこの種のサービスを提供している。例えばAWS Lambda、Azure Functions、そしてGoogle Functionsなどがその例だ。

ある時点から、Whiteはサーバーレスを、インフラストラクチャの管理と維持について考えることから彼を自由にしてくれるものと考え始めるようになったのだ:「この先、何処までいけるか見てやろうと考え始めたのです。全てをサーバーレスで本当に行うことが可能なのか?そしてそうしたときに、実際に行うべき、膨大な従来型DevOpsスタイルの作業を減らすことができるのか?(訳注:DevOpsとは開発と運用を意味する)。まだまだ多くのことがありますが、ともあれまずそれが最初に考えたことだったのです」と彼は語る。

問題を克服する

しかし、それにも問題があった。特に彼がサーバーレスに取り組み始めた当初の問題が大きかった。まずなにはともあれ、Whiteはこのようなやり方で作業できる開発者を見つける必要があった。しかし2016年に始めたときには、サーバーレススキルを持つ人の数はまだ多くなかった。Whiteは、Blissfullyをどのよう実装するかに関わらず、学習に意欲的で新しい技術に柔軟に取り組む人間を重用し、直接的な経験をあまり重視はしなかったと語る。

一度基礎を理解した後は、これがどのように構造的に機能するかを考える必要があった。「チャレンジの一部は、異なるサーバーレス機能間の境界を、どこに置けば良いかを決定することです。1つの機能の能力を他の機能に比べて、どれくらい重いものにするかをどのように決定すれば良いでしょう?そして、それをどのように分割すれば良いでしょう?非常に細かい機能に分割することもできれば、もちろん非常に大きな機能にすることも可能です。このようにして動作するコードベースを、どのように分割したいのかという点で、多くの判断が必要となります」と彼は語る。

サーバーレスのアプローチの中で、彼がまず直面したまた別の課題は、それを取り巻くツールの欠如だった。Whiteは、Serverless、Inc.と出会うことができ、同社は彼を開発の基礎的フレームワーク部分で手助けしてくれたが、優れたログツールには欠けていて、現在でも彼の会社は、その問題には苦労しているのだと語る。「DevOpsはなくなりません。それは、いまでもどこかのサーバ上で実行されていて(たとえ自分でそれをコントロールしていないとしても)、問題は発生するのです」。そのような問題の1つが、彼が言うところの「コールドスタート問題」である。

リソースを正しく確保する

BlissfullyはAWS Lambdaを利用している。そして彼らの顧客がリソースを要求したときに、Amazomはそのイベントを待つための専用のリソースを確保していてくれるわけではない。もしサーバーをコールドスタート(実行が全く行われていない状態から起動を始めること)する必要がある場合には、結果的にこれは遅延の発生に繋がる可能性がある。この問題を回避するために、BlissfullyはLambdaを刺激し続けるジョブを走らせている。このことによって実際のアプリケーションを実行する準備が常に整っていることになり、ゼロから開始することで起き得る遅延時間がなくなる。

もう一つの問題は、これとは逆の問題かもしれない。対処可能な規模を超えて容易にスケールアップしてしまうことができるため、小規模のチームにとっては問題になってしまう可能性があるのだ。彼は、そのような場合には、呼び出し速度にリミッターをかけることになるという。そうすれば支払い可能な上限を超えることはないし、チームが管理可能な上限を超えて規模が大きくなることもない。「ある意味、このことによって、通常はもっと大きな規模になってから真剣に考えることになる問題に、より簡単に遭遇してしまうことになると思います」とWhiteは言う。

また別の問題は、Lambdaですべての処理を行うようになると、外部APIが扱うことのできる能力以上の速度でデータを動かしてしまう可能性があるということである。このため実際の実行を遅くするためのリミッターが必要となることがあるのだ。「Googleの場合は、多くの計算材料を与えることで速すぎると文句をいってくる様なことに遭遇したことは、ありませんでした。Googleの場合は速すぎると言われるためには、多大な努力が必要ですが、Lambdaの場合はあまり努力せずともすぐに速すぎると言われるようになります。どんなリソースであっても使うことを決定したときには、他のAPIに対して重大な出力ダメージを与える可能性があるのです」。それが意味することは、彼と彼のチームは本当に初期段階で、洗練された速度制限スキームについて本当に考える必要があったということだ。

コストに関しては、Whiteはサービスを構築し配置した今、コストはずっと安くなったと考えている。「当社のコストは現在非常に低いものになっています。サーバーベースのインフラストラクチャを使用している場合よりもはるかに低いものです。私たちの計算パターンは非常に瞬発的なものなのです」。この理由は。SaaSデータベースの再解析を行うのは、1日に1度か、最初に顧客がサインアップしたときであるからだ。その間のデータのやり取りは非常に少ないものなのである。

「ということで、サーバーレスは私たちとっては完璧な選択でした。なぜなら純粋に無駄になってしまうかもしれないリソースを維持し続ける必要はないからです」。

[原文へ]
(翻訳:sako)

写真:Vladimir_Timofeev / Getty Images

各クラウド企業がペンタゴンの100億ドルJEDIクラウド契約に持ち込もうとしているもの

ペンタゴンは100億ドル規模のエンタープライズクラウドプロジェクトである JEDI(Joint Enterprise Defense Infrastructure:ジェダイ)の勝者を選ぶことで、該当クラウドベンダー1社だけを極めてハッピーにしようとしている。この契約は、Internet of Things(IoT)、人工知能およびビッグデータのような、現在の動向の利用を始めながら、今後10年の軍用クラウド技術戦略を確立するようにデザインされている。

10年以上にわたって使われる100億ドルという金額は、もうすぐ年額1000億ドルを超えることが期待されている市場を完全に変えてしまうことはないだろう。しかし、このプロジェクトはより小さなベンダーに対してもより大きなプレゼンスを与え、他の政府機関や民間部門へ深く入り込むことを可能にするだろう。クラウド企業たちはもちろんそれを認識している

写真:Glowimages/Getty Images

このことが、ベンダーたちが徒党を組んで、契約の流れを変えさせようとしていることを説明してくれる。おそらく正しい主張だが、彼らはマルチベンダーアプローチの方が合理的だと主張している。

提案依頼書(RFP)を眺めてみると、セキュリティからトレーニングに至るまでの様々な仕様を、勝者である1社に要求する、沢山のドキュメントがあることがわかる。このことからこの提案が如何に複雑なものであるかが理解できる。その中心は、機密扱いならびにそれ以外の、インフラストラクチャ、プラットフォームおよびサポートサービスのパッケージである。この記事で取り上げる主なクラウドベンダーはいずれも、これらのサービスを提供している。彼らはみな特異な存在ではないが、それぞれはこうしたプロジェクトに関係した、異なるスキルセットと経験を持っている。

ここでは技術的な先進性だけが問われているわけではないことに注意することが大切だ。DOD(国防総省)はまた、価格も注意深く見ており、各コンポーネントに適用可能な特定の割引を明示的に求めている。RFPの受付は10月12日に終了し、勝者は来年4月に選択される予定である。

Amazon

Amazonについて何を語れば良いだろう?彼らは、圧倒的に支配的なクラウドインフラベンダーだ。彼らは2013年にCIAのプライベートクラウドを構築していて、過去に大規模な政府契約を獲得したという意味で有利な立場である。そのときにはその労力の対価として6億ドルを受け取っている。Amazonが提供するのは、機密データをホストするために設計されたこのプロジェクトの成果から生まれたGovCloudという製品だ。

Amazon.comの会長兼創業者、Jeff Bezos写真:Drew Angerer/Getty Images

他のベンダーの多くは、このことがこの取引で、Amazonを有利にしているのではないかと心配している。5年は特に技術面では長い期間だが、それにも増して、Amazonはその間に市場の支配を強化した。 なんと言っても、他のプレイヤーのほとんどは2013年の段階ではクラウドビジネスに確立に向けて動き始めたばかりだったのだ。2006年にクラウドを開始したAmazonは、他のベンダーたちが欠いていて、いまだに開発途上である成熟度を持っている。また毎年のように沢山の機能を投入している。このことによって、Amazonはますます競争するのが難しい相手となるだけでなく、正しいゲームを行うことのできる最大のプレーヤーにもなっている。

Microsoft

も誰かがAmazonに追いつけるとすれば、それはMicrosoftである。彼らはクラウドに対して遅れをとっていたが、過去数年の間にそれを補って余りあるものを成し遂げた。彼らは急速に成長しているが、純粋な市場シェアの点という点では、まだAmazonよりも遥かに遅れている。それでも彼らはペンタゴンに対して、彼らのクラウドプラットフォームであるAzureと、Word、PowerPoint、Excel、Outlookの電子メールを含む人気のあるビジネススイートであるOffice 365の組み合わせを、多数提供している。さらにDODとの間に、Windowsおよび関連ハードウェアのために、2016年には9億ドルもの大きな契約を締結している。

Microsoft CEO, Satya Nadella。 写真;David Paul Morris/Bloomberg via Getty Images

Azure Stackは、軍事シナリオに特に適している。それはAzureパブリッククラウドの、ミニプライベートバージョンを提供するプライベートクラウドなのだ。これはAzureのパブリッククラウドと、APIやツールの点で完全に互換性がある。さらに同社は、DODレベル5を含み、米国政府の各部署の多​​くで利用が認定されているAzure Government Cloudも所有している。Microsoftは、長年に渡って大企業や政府のクライアントの中で多くの経験を積んでいるため、このような大規模な契約をどのように管理すれば良いかを知っている。

Google

クラウドについて語る時には、私たちはビッグスリーについて考える傾向がある。グループの3番目のメンバーはGoogleである。彼らは、2015年にDiane Greeneを雇用して、クラウドユニットを組織化し企業からの信用を得ることを通して、エンタープライズクラウドビジネスを確立するために熱心に取り組んできた。市場における彼らのシェアは比較的小さいが、広げるべき市場がまだ広大に残されていることを睨みつつ、彼らは長期的な視野を語っている。

Google Cloudの責任者であるDiane Greene 写真:TechCrunch

彼らは社内で使用していた多くのツールをオープンソース化するアプローチを採用し、同じサービスのクラウドバージョンを提供した上で、彼ら以上に大規模なサービス運用をうまく行う会社はいないと主張している。彼らの主張には理があり、それはこの契約に対して有利に働くかもしれないが、一方彼らは、従業員グループの反対によって、Project Mavenと呼ばれるDODとの人工知能契約から離れたという経緯もある。それがここでの入札プロセスで、彼らに不利に働くか否かは明らかではない。

IBM

IBM は2013年にSoftlayerを買収して以来、広範なクラウドサービスのプラットフォームを構築し、インフラサービスを提供してきた。一方、何年もかけてソフトウェアと開発ツールを加えている。そしてAI、ビッグデータ、セキュリティ、ブロックチェーンその他のサービスに注力してきた。その間にも、人工知能エンジンであるWatsonを最大限に活用しようとしてきた。

IBMの会長、社長、そしてCEOであるGinni Romett 写真:Ethan Miller/Getty Images

20世紀における主要技術ブランドの1つとして、同社はこの範囲の契約や大規模な企業の顧客や政府と協力してきた、膨大な経験を持っている。その経験が最近開発されたクラウドサービスに転換されるのか、それとも他のもの、特にMicrosoftとAmazonなどと同様の、成熟したクラウドを持っているのかは明らかではない。そのような意味でも、このような契約を獲得するために、IBMはその仕事を適宜整えてくることだろう。

Oracle

Oracleは、昨年の春以来誰彼お構いなしに不満を述べ続けている。一説では大統領に対してもそれを訴えたと言われている。すなわちJEDIのRPFはAmazonを有利にするために不公平に書かれているという不満だ。もちろんDODはそれを断固として否定している。彼らはプロセス自体に対して正式な抗議を提出したことさえある。

これは同社がクラウドに乗り遅れているための、煙幕である可能性がある。コンセプトに真剣に取り組むまでに何年もかかり、現在では市場シェアという意味では、かろうじて端っこに居るという状態なのだ。同社がテーブルに持ち出すのは、数十年以上にわたるエンタープライズにおける経験と、過去40年間最も有名なエンタープライズデータベースの1つであったという事実だ。

Larry Ellison, chairman of Oracle Corp.

Oracle会長のLarry Ellison写真:David Paul Morris/Bloomberg via Getty Images

最近Oracleは、DODにとって魅力的であるかもしれないクライド内での自己修復データベースの提供を開始した。しかしそれ以外のものがこの契約を獲得できるほど魅力的か否かは、まだ分からない。

[原文へ]
(翻訳:sako)

画像:Hoxton/Tom Merton / Getty Images

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

Office 2019が出たけど今やMicrosoft Offeceの最良の機能はOffice 365にある

Microsoftが今週、WindowsとmacOS用のOffice 2019をリリースした。それは、この生産性スイートの、サブスクリプション型(有料会費制)ではないタイプの、定例の最新アップデートだ。言い換えるとそれは、あなたが10年前にOffice Depotで買ったシュリンクラップ(収縮包装)のOfficeと同じ種類のOfficeだ。でも今やそれは、Microsoftがあなたに買ってほしいと思っているOfficeではない。あなた自身も、買いたくないかもしれない。なぜなら現時点では、Office 2019は一種の限定バージョンであり、それは、サブスクリプション(有料会員制)のOffice 365にあるおもしろい最新機能を欠いているからだ。

Microsoftの企業向けOfficeとWindows担当VP Jared Spataroはこう語る: “私たちはOfficeの全フレーバーの中で、Office 365の…とくに商用ユーザーのためのOffice 365 ProPlusの…位置づけにたいへん苦労してきた。それを、名前の中に年数のあるOfficeとはまったく違うものにしたかった。Office 2019には、これまでのOffice 365にあった機能がすべてある。だからクラウドバージョンのOffice 365には、インターネットに接続しているからこそ得られる新しい命がある、と言いたい”。

Spataroによると、Microsoftはユーザーに、Office 365はクラウドに接続されているから生産性が高く、セキュリティも優れていることを知ってほしい、と思っている。彼によると、TCO(total cost of ownership, 総保有コスト)も、自分のパソコンにインストールするバージョンより安いそうだ。

Office 2016のころには、それらの一般市販バージョンは、たえずアップデートされているOffice 365のスナップショット、言い換えればコピーだった。365は毎月アップデートされ、新しい機能も増えていた。しかし今回は初めて、オンプレミスバージョンのOffice、すなわちOffice 2019には、Office 365の機能の多くが欠けている。つまり、機械学習による人工知能機能など、もっともおもしろい機能は、Office 365にあってOffice 2019にはない。

Spataro曰く: “混乱するユーザーもいると思うが、名前に年数がついていることは、それが‘現時点でベストバージョンである’という意味ではない、ということを時間をかけて分かってもらう努力をしなければならない”。

しかし、機能の差は当然でもある。Office 365だけにある新しい機能は、その多くが、クラウドだからこそ得られる機能だからだ。たとえばアプリケーションの中から行なう検索も、機械学習のモデルを動かしてそこからデータを取り出すことも、クラウド、すなわちインターネットへの接続がなければできない。そしてそれを有料化する最良の方法は、サブスクリプション(subscription, 有料会員制)しかない。

Microsoftのやり方は、たとえばAdobeのサブスクリプションサービスCreative Cloudなどと同じだ。こちらも従来の主要アプリケーションをシュリンクラップからクラウドへ移して、サブスクリプションで課金している。Adobeのこのやり方は大成功しているが、Microsoftは同じことをOffice 365やMicrosoft 365でやろうとしている。

[AIでOfficeが賢くなった…Microsoft Ignite 2018カンファレンス開幕]

more Microsoft Ignite 2018 coverage

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

センサーデータのリアルタイムデータベースを提供するModeが$3Mを調達(上田学氏談話あり)

企業が、センサーのデータに瞬時にアクセスできるためのリアルタイムデータベースを提供しているModeが、True Venturesの率いるラウンドにより300万ドルを調達した。GigaOm(テクノロジーブログの老舗)のファウンダーでTrue VenturesのパートナーOm Malikが、このラウンドの一環としてModeの取締役会に加わった。

今では多くの企業で、車や携帯電話、各種器具・機器、医療器具、そのほかの機械類などからのセンサーデータがたくさん集まってくる。しかしこれらのセンサーをデプロイしている企業に、データの意味を〔時系列や統計分析などで〕理解するためのバックエンドデータベースがない場合が多い。

サンマテオに拠を置くModeは、企業が大量のデータをクラウドに置いて、彼らのデバイスをもっとよく理解し、次にやるべきことが分かるようにする。今Modeの顧客は、ソーラー、医療、製造業などの業種が多い。

Modeの協同ファウンダーでTwitterの技術部長だったGaku Uedaは語る: “データの収集にフォーカスするのは、共通的なインフラの問題をわれわれが担当して、顧客企業はデータの有効利用に専念してもらうためだ”。

Uedaと、同じく協同ファウンダーでゲーム企業50Cubesの技術部長だったEthan Kanは、長年の友だちだ。True VenturesのMalikによると、彼が投資家として同社に惹かれた理由の一つが、それだった。

そのMalikは言う: “企業は直線ではない。上がり下がりがある。でも、良い協同ファウンダーに恵まれていたら、何でも切り抜けられる”。

今回の資金調達でModeの調達総額は500万ドルになる。Kleiner Perkins, Compound.vc, Fujitsuなども同社に投資している。今回のシリーズAの資金は、クラウドにつなぐセンサーをもっと増やし、チームを拡張するために使われる。

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

GoogleのCI/CDプラットホームCloud Buildがコンテナイメージの脆弱性をスキャンする

Googleが今日(米国時間9/19)、同社のCD/CIプラットホームCloud Buildの重要なアップデートを発表した。それにより、このサービスを利用して構築されるすべてのコンテナイメージに対し脆弱性スキャンが行われる。Container Registryに対するその脆弱性スキャンはまだベータだが、現代的なDevOpsの実践手法を採用した企業に対し、彼らがデプロイするコンテナに確実に、既知の脆弱性がないようにすることがそのねらいだ。

Googleがいみじくも言うように、セキュリティプロトコルがつねに確実に実践されているようにするための唯一の方法は、その工程を自動化することだ。今回の場合では、Cloud Buildの新しいイメージはすべて、Cloud Buildがそのイメージを作ってそれをContainer Rgistryに保存するそのときに、自動的にスキャンされる。

このサービスは、セキュリティ関連の標準的ないくつかのデータベースを利用して脆弱性を見つける。現在、脆弱性を見つけることのできるのは、Ubuntu、Debian、そしてAlpineのパッケージだ。CentOSとRHELにも、近く対応する。

問題を見つけたらユーザーに通知するが、ユーザー企業が自動化のルールを決めて、自動的にアクションをさせることもできる。アクションへのメッセージングとアクションの実行にはそれぞれ、Google CloudのPub/Sub通知と、サーバーレスのCloud Functionsを用いる。ユーザーは、脆弱性の重度やCVSSのスコア、どのパッケージが危ないか、有効な対策の有無、などに関する詳細レポートを受け取る。

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

GoogleのGitHub競合製品Cloud Source Repositoriesが検索機能を大きく改良

Googleが今日(米国時間9/19)、最近再び立ち上げたGitベースのソースコードリポジトリ Cloud Source Repositoriesのアップデートを発表し、とくに検索機能が大幅に改良された。この新しい検索機能はGoogleの技術者たちが毎日使っているツールをベースとし、今日からCloud Source Repositoriesのベータリリースで提供される。

かなり前からインターネットを使っている人なら、Google Code Searchをご存知だろう。これを使ってインターネット上のオープンソースのコードなら何でも検索できたが、残念ながら2012年に閉鎖された。今度の新しい機能はそれの復活ではなくて、自分の(もしくは会社の同僚の)コードしか検索できない。でもそれはGoogle自身の検索に劣らず高速で、正規表現などの高度な検索機能もある。

またJava, JavaScript, Go, C++, Python, TypeScript, Protoで書かれたコードに対しては、検索で見つかったものがクラスか、メソッドか、列挙型か、フィールドか、というタイプ情報も返す。

Googleは、コードの検索をローカルにやるのは、古いコードも検索されてしまうので良くない、と主張している。

さらにGoogleによると、GitHubや(Atlassianの)BitbucketにあるコードをCloud Source Repositoriesにミラーできる。検索だけのために、そんなことをするデベロッパーがたくさんいるとは思えないが、でもGoogleにとってはユーザー獲得の手段になるだろう。この世界はGitHubの独壇場だから、何もしなければ単なる負け犬になってしまう。

Cloud Source RepositoriesのプロダクトマネージャーRussell Wolfが、今日の発表声明で書いている: “重要な利点は、ユーザーのすべてのリポジトリをCloud Source Repositoriesにミラーないし加えておくと、一回のクエリーでそれらすべてを検索できることだ。それは、小さなウィークエンドプロジェクトでもよいし、Googleのような巨大なコードベースでもよい。しかもそれは速い。一瞬で答が得られ、前の検索機能に比べると大違いだ。そのため、検索でコーディングが中断しない。インデクシングも、超速い。新しいコードを加えたらすぐにそれが検索対象になり、つねに最新の検索ができる”。

画像クレジット: TechCrunch

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

Googleが日本で複数のAI関連事業を立ち上げ、UNIQLOとパートナーシップ

Googleが今日(米国時間9/18)東京で行われたCloud Next 2018イベントの場を利用して、日本市場にフォーカスした二つのイニシアチブを発表したのは、当然のことだ。このイベントはメインのカンファレンスがサンフランシスコで行われ、複数の国際的イベントが東京など各地で行われる。

発表には、ベーシックなアップデートとしていくつかの日本語ローカライゼーションも含まれ、その中には、CourseraのコースMachine Learning with TensorFlow on Google Cloud Platformの日本語化や、クラウド技術者の資格検定Associate Cloud Engineerの日本語化、50種のクラウド実践演習(各30分)Qwiklabsの日本語化などがある〔日本語化の例はここで〕。

さらにGoogleは、東京にAdvanced Solutions Labを立ち上げる。同様のラボは、アイルランドのダブリンとカリフォルニアのサニーベール、そしてニューヨークにもある。それらはGoogleのエキスパートたちによる4週間の機械学習教育訓練コースを軸として、機械学習のさまざまな学習オプションとコラボレーションによる演習経験を提供する。

(写真: Hitoshi Yamada/NurPhoto via Getty Images)

Googleは今日、新しいテクノロジーの採用をめぐって、ユニクロの親会社Fast Retailingとのパートナーシップを発表した。社名が示すように同社は小売業の高速化に関心があり、成長の加速化のためにGoogleのG Suiteや機械学習ツールを利用していきたいようだ。このパートナーシップ事業の名前は、’Ariake’である。

Fast RetailingのCEO Tadashi Yanaiはこう言っている: “全社員が情報にアクセスできるようにすることが、Ariakeプロジェクトの基盤のひとつだ。それによって社員たちは、論理や判断、共感といった人間の特性を生かした意思決定ができるようになる。毎シーズン、事業計画を書いているが、G Suiteのような共同作業ツールを使えば、それらを全社員が共有できる。Google Cloudとのパートナーシップは、需要予測のようなものをとっくに超えて、全社員の協働的な仕事のやり方を抜本的に変えた”。

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

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

G Suiteによる企業のデジタルトランスフォーメーションの進捗を測るツールWork Insights

東京で行われたイベントでGoogleが今日(米国時間9/18)、社員たちのG Suite生産性ツールの使用状況や、それらのツールをコラボレーションに利用している状況を知るためのツールWork Insightsのローンチを発表した。

さらにGoogleは、G Suiteのデータのセキュリティを向上させるための調査ツールを一般公開した。

G SuiteのグループプロダクトマネージャーReena Nadkarniはこう説明する: “Work Insightsは、G Suiteの利用で企業のデジタルトランスフォーメーションがどれぐらいうまくいっているかを測るツールだ”。…そのデータは10名以上のチームごとに集められ、それぞれのチームのG Suiteアプリケーションの利用状況が分かる。

企業がいろいろなベンダーの製品を使っているときは、デジタルトランスフォーメーションの進捗にもチームごとの格差が生じやすい。でもそれらのツールの多くは、全社一斉採用でないと目に見える効果の得られないものが多い。このことは、Slack, Hangouts Chat/Meet, Microsoft Teamsなどのコミュニケーションツールにおいてとくに顕著だが、G Suiteのような生産性ツールにも言える。

もっとおもしろいユースケースとして、Work Insightsでは複数のチーム間の対話の状況を知ることができる(マーケティングと営業、とか)。たとえば複数のチームがドキュメントを一緒に作っているなら、その協働関係はうまくいくだろう。そうでないと、営業がマーケティングのプレゼンテーションを酷評するだけで終わったりするかもしれない。

“これらの結果を見て役員たちは、企業内の、コラボレーションを強化しサイロ化(孤立・閉所化)の危険性を防ぐべき部分を同定できる”、とNadkarniは書いている。コラボレーションの活発化よりもサイロ化の蔓延を好む役員はたぶんいないから、このツールを利用する企業は今後結構多いのではないか。

画像クレジット: TOSHIFUMI KITAMURA/AFP / Getty Images

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

ペンタゴンの100億ドル規模のプロジェクトJEDI(ジェダイ)が、クラウド企業たちを悩ます理由

おそらくこれまでに、国防総省による「勝者総取り」の100億ドル規模の大規模なクラウド契約について耳にしたことがあるだろう。これは別名Joint Enterprise Defense Infrastructure(略称JEDI:ジェダイ)と呼ばれている。

スター・ウォーズを連想させる名前はともかく、この契約は政府の基準に照らしてみても巨大なものだ。ペンタゴンは、単一クラウドベンダーがその組織クラウドを構築することを望んでいる。事の是非はさておき、彼らはそれこそがクラウド戦略に集中しコントロールをするための最適なアプローチであると信じているからだ。

国防総省(DOD)のスポークスマンHeather Babbは、TechCrunchに対して、同省はこのやり方をとることに多くの利点を見ているのだと語った。「単一契約は有利です。なにしろ何よりもセキュリティを改善し、データアクセス性を改善し、そして国防総省がクラウドサービスに対して適応し利用する過程を単純化してくれるからです」と彼女は言う。

この契約のために国防総省がどの企業を選択しようとも、これはコンピューティング基盤とその戦闘組織を、旧来の基盤もある程度取り込みつつ、IoT、人工知能、そしてビッグデータ解析の世界に向けて近代化することなのだ。「このDODクラウド・イニシアチブは、国防総省の情報技術体制の近代化に関わる遥かに大きな動きの一部なのです。この試みの基礎は、現在国防総省内にあるネットワーク、データセンター、そしてクラウドの数を合理化することです」とBabbは語る。

その後の動向を決める

このDODの契約を勝ち取るものは誰でも、政府内での類似のプロジェクトに対して有利な立場をとることが可能になるだろう。結局のところ、軍に対してセキュリティと信頼性で合格することは容易なことではない。そしてもし1つの会社がそれを遂行する能力があると証明できたなら、この先の取引を、安泰なものとすることができるだろう。

しかしBabbが説明するように、それはクラウドを長期的に理解するという行為なのだ。「JEDI Cloudは、DODがエンタープライズクラウドソリューションをどのように取り込むべきかを学ぶ手助けになる、草分け的な取り組みとなるでしょう。そしてデータ駆動型意思決定を可能にし、DODがアプリケーションとデータリソースを最大限に使うことを可能にする重要な最初の1歩となるのです」と彼女は言う。

写真: Mischa Keijser for Getty Images

だが、この単一ベンダー方針は、応札している様々なクラウドベンダーたちが少々取り乱している理由を説明するものだ。ただしAmazonを除いてだが ―― 同社はほとんど何も語らず、一見事態の推移を落ち着いて眺めている。

その他のプレイヤーたちが信じているのは、Amazon がこの入札の主導権を握っているということだ、なぜならAmazonは2013年に政府に対して6億ドル分のクラウド契約を提供し、CIAのためにプライベートクラウドを立ち上げているからだ。当時それは様々な意味で大きな取引だった。何よりもまず、それは情報機関がパブリッククラウドプロバイダーを使った、最初の大規模例だった。そして当然のことながら、当時の金額は印象的で、100億ドルという規模ではなかったものの、良い契約だった。

こんなことを言っても慰めになるかどうかはわからないが、Babbはそのような意見を一蹴する。入札プロセスはオープンで、有利に扱われるベンダーはないと言うのだ。「JEDI Cloudの最終RFP(提案依頼書)はDODのユニークで重要な要求を反映したものです。競争力のある価格設定とセキュリティのベストプラクティスが考慮されます。どのベンダーも事前に選択されてはいません」と彼女は言う。

大声で不満を言う者

ペンタゴンが今後10年間に向けての主要なクラウドベンダーを選ぶ方向に向かう中で、特にOracleは、耳を傾ける者たちに対して、Amazonはこの取引に対して不公平に有利な立場に立っていると不満を言い続けている。そして先月には正式な訴状を提出している。これは入札がまだ始まってもおらず、ペンタゴンが決定を行う遥か前のタイミングだ。

写真: mrdoomits / Getty Images (一部編集)

皮肉なことに、自身の過去のビジネスモデルにもかかわらず、Oracle は何よりもこの取引が、国防総省を長期間にわたって1つのプラットホームにロックインしてしまうことに不満を述べているのだ。またワシントン・ポストのレポートによれば、Oracleは入札プロセスが、この手の取引の調達規則を遵守しているかどうかに対して疑問を呈している。またBloombergによれば、4月には共同CEOのSafra Catzが直接大統領に対して、この取引はAmazonのためにあつらえられていると不満を訴えたと言う。

Microsoftも単一ベンダーのアイデアに満足していない。単一ベンダーに制限してしまうことで、様々な変化が起きるクラウドマーケットの世界の中のその他の企業からのイノベーションを、ペンタゴンは取り入れ損なう可能性があると指摘する。特にそれほどまでに長期にわたる契約について語っているときは尚更だ。

4月にMicrosoftのLeigh Maddenは、同社は競争する準備は整っているが、単一ベンダーアプローチが必ずしも最善の道とは思わないと、TechCrunchに対して語った。「もしDODが単一ベンダーだけを採用する道を行くのなら、私たちは勝つために参加します。しかしそうは言いいながらも、それは私たちが世界で見ているような、80パーセントのお客様がマルチクラウドソリューションを採用している動きとは、対照的なものなのです」と彼は同時に語った。

彼の指摘は妥当だが、90年代のような独自システム(OracleやMicrosoftがその代表だ)に比べて、クラウドは遥かに大きな相互運用性を提供するのにかかかわらず、ペンタゴンは単一ベンダーのアイデアを推し進める決意をしているように見える。

Microsoftもそれ自身の大規模な契約をDODと結んでいるが、その規模はほぼ10億ドルに達する。2016年から続くこの取引はDODの職員のためのWindows10と関連するハードウェアの関するものだが、AmazonがCIAと結んだような純粋なクラウド契約ではない。

また同社は最近、政府向けのAzure Stackをリリースした。これは政府の顧客に対してプライベート版のAzureを、パブリック版と全く同じツールと技術と共にインストールするもので、JEDI入札の際には魅力的なものとなるだろう。

クラウド市場の動向

またAmazonがクラウドインフラストラクチャ市場の最大のシェアを占めているという事実が、ある程度効果を発揮する可能性もある。Synergy Researchの2017年第4四半期データが明らかに示すように、Microsoftは急速に成長してはいるものの、それでも市場規模という意味では、Amazonのまだ3分の1に過ぎない。

このデータが出されて以来、市場は劇的には変化していない。市場シェアだけが決定要因ではないものの、Amazonはこの市場に最初に参入した企業であり、市場での規模という意味では後続の4社を合計したものよりも(Synergyのデータによれば)遥かに大きいのだ。これは、なぜ他のプレイヤーが非常に激しいロビー活動をしており、Amazonを最大の脅威であると考えている理由を説明できるだろう。なにしろ、その凄まじい大きさゆえに、おそらくあらゆる取引で向かい合うことになる最大の脅威だからだ。

最大の不満の声をあげるOracleがが、何年もの間クラウドを無視していたために、乗り遅れていることも考慮しよう。彼らはJEDIプロジェクトを、プライベート版のクラウドビジネスを構築するために使うことのできる、政府の中の足場を確立するチャンスだと考えているのだろう。

10年は10年ではないかもしれない

実際の取引には、複雑な部分と、スポーツ選手のように最初の2年だけが保証された、オプトアウト条項が含まれていることは指摘しておく価値はあるだろう。その後2回の3年のオプションが続き、最後の2年のオプションで契約はクローズする。これが意味することは、もしこれが良くないアイデアだと判明したならば、ペンタゴンは様々な地点で契約を終了できるということだ。

写真:Henrik Sorensen / Getty Images (編集済)

JEDIの「勝者総取り」アプローチにもかかわらず、何が起きようともDODは複数のクラウドベンダーと作業を続けるとBabbは述べている。「DODは複数のクラウドを所有していますし、その運用も続けるつもりです。そしてJEDI Cloudは、DODのクラウド全体戦略の重要なコンポーネントとなるでしょう。私たちの任務の規模は、DODが複数のベンダーから複数のクラウドを調達することを要請するのです」と彼女は言う。

国防総省は8月に最終入札を受け入れ、RFPへの最終締切を10月9日(米国時間)へと延長した。締め切りが再び延長されない限り、この先数週間のうちに、私たちは幸運な会社の名前を耳にすることになるだろう。そしておそらく決定のあかつきには、多くの泣き言が聞こえ、敗者たちからの様々な策が巡らされることになるだろう。

[原文へ]
(翻訳:sako)

画像: Glowimages / Getty Images (編集済)

Boxがデジタルハブを構築し、コンテンツの断片化に対抗する

クラウドの相互接続性によって、組織内外の人びとの間で様々なアプリケーションをまたがって、コンテンツを広く共有することが可能になった。しかしそうした可能性は新たな問題を引き起こしている。一種のデジタル断片化だ。1つのコンテンツが、広がるクラウドサービスの中でどのように使われているかを、どのように追跡すれば良いのだろうか?それこそが、そBoxが最新の機能、Activity StreamとRecommended Appsで解決したい問題なのだ。

同社は、今週サンフランシスコで開催されている年1回の顧客会議であるBoxWorksで、それらの発表を行った。

Activity Streamは組織内で回覧されるコンテンツをリアルタイムに追跡する手段を提供する。そこで追跡されるのは誰がそのコンテンツにアクセスしたのか、どのアプリケーションが使われたのかといったもので、一種のデジタル監査証跡のように機能する。クラウド時代のコンテンツに関わる大きな問題の1つは、コンテンツ作成後に何が起こったのかを知ることだ。例えばそれは、SalesforceやServiceNowやSlackで使用されただろうか?今やコンテンツのパスをたどって、人々がそれをどのように共有したのかを知ることができるのだ。そしてこれは人びとがデジタル世界に感じている断絶をある程度取り除くことができる。

BoxチーフプロダクトならびにチーフストラテジーオフィサーであるJeetu Patelは、平均的な大企業は千個以上のアプリケーションを持っていて、構造化されていないコンテンツの追跡やデジタル証跡の統一的なビューを得るという観点からは、それらをうまく統合する良い手段を持っていないのだと指摘する。

「私たちは1400を超えるアプリケーションを統合しました。そしてそうしたアプリケーションを統合しながら、もしそれらの各種イベントを可視化することができたなら、それはユーザーにとってとてつもなく便利なものとなるだろうと考えたのです」と彼は語る。Patelはこれを、重要な概念の始まりだと見ている。それはコンテンツひとつひとつに関連するトランザクションレコード全体を見ることができる、コンテンツハブという概念だ。

Box内のActivity Streamサイドバー。写真提供:Box

しかしBoxは、それを単なる関係の長々としたリストで終わらせたくはなかった。それは使われているアプリケーションへのディープリンクも生成する。これによってユーザーはリンクをクリックしてアプリケーションを開き、そのアプリケーションのコンテキストでコンテンツを眺めることができるようになる(かつては「ディープリンク」という用語は、ウェブのリンクをトップページ以外の要素に対してリンクすることを指していたが、最近はアプリケーションの特定のページを開くことができるリンクのこともディープリンクと呼ぶ)。「Boxが、コンテンツがどのように利用されているかを俯瞰するための、理に適った場所のように見えます」とPatelは語り、この機能を生み出すBoxの考えを説明した。

これに関連した機能が、Recommended Appsリストである。ユーザーとコンテンツの関係を示すBox Graphや、Boxがユーザーや彼らが使っているコンテンツについて知っていること、そしてそれが他のクラウドアプリケーションとどのようにつながっているかといった知識に基いて、Boxインターフェイスの中に推奨アプリ(Recommended Apps)の一覧も表示される。これにより、ユーザは仕事のコンテキストの中でそれらのアプリケーションにアクセスすることができる。よってたとえば、ドキュメントから直接Slackにコンテンツを共有することができる。

Boxの中のRecommended Appsバー。写真提供:Box

まず手始めに、G Suiteアプリ、Slack、Salesforce、DocuSign、そしてNetsuiteがRecommended Appsインテグレーションとして含まれる。だがPatelによれば、APIを介してウェブアプリと統合されるものなら何でも、Activity Streamに表示されるということだ。

製品は今日(米国時間8月29日)発表されたが、Boxは動作上の問題点について、まだ作業を続けている。彼らはこの機能を、来年早々にリリースしたいと思っている。もし彼らがうまくやり通すことができたなら、デジタル断片化問題を解決し、Boxを組織のコンテンツセンターにするために大いに役立つことだろう。

[原文へ]
(翻訳:sako)

GoogleがKubernetesの開発インフラの自社負担から降りてすべてをCNCFに委ねる

Googleが今日(米国時間8/29)、同社がCloud Native Computing Foundation(CNCF)に、Google Cloudのクレジット900万ドルを提供して、Kubernetesコンテナオーケストレータの同団体による今後の開発を支援し、プロジェクトの運用に関わるコントロールを同団体に委ねる、と発表した。このクレジットは3年分割で提供され、Kubernetesソフトウェアの構築や試験、配布などに要する費用に充当される。

これまではGoogleが、このプロジェクトを支えるクラウドリソースのほとんどすべてをホストしていた。その中にはたとえばCI/CDによるテストのためのインフラストラクチャや、コンテナのダウンロード、同社クラウド上のDNSサービスなども含まれている。しかしGoogleは今回、一歩後退することになった。Kubernetesコミュニティの成熟に伴い、GoogleはKubernetesのすべてのサポートワークをコミュニティに移そうとしている。

テストのためのインフラストラクチャからコンテナダウンロードのホスティングまで、すべてを合わせるとKubernetesプロジェクトは常時、15万あまりのコンテナを5000基の仮想マシン上で動かしている。その費用は、相当に大きい。Kubernetesのコンテナレジストリはこれまで、1億3000万回近いダウンロードに応じてきた。

それにまた現在のCNCFは、互いに競合する多様なメンバーを抱えている。Alibaba Cloud, AWS, Microsoft Azure, Google Cloud, IBM Cloud, Oracle, SAP, VMwareなどがその例だ。全員がCNCFの仕事やKubernetesのコミュニティから利益を得ている。Googleはこれまで黙っていたが、そろそろKubernetesのインフラストラクチャを動かす重荷を、それにふさわしい者に担わせるべきだろう。それにコミュニティのメンバーの一部は、KubernetesがGoogleのインフラストラクチャにあまりにも密接に結びついていることを、嫌っていた。

GoogleのKubernetes EngineのプロダクトマネージャーWilliam Denissが、今日の発表声明でこう書いている: “Kubernetesの運用責任をプロジェクトのコントリビューターが共有することによって、彼ら全員が持ち寄る新しいアイデアや効率性を生かせるようになるだろう。それが楽しみである”。彼によると今後も、Kubernetesのインフラストラクチャの運用には、Googleの意思が適宜反映されていく、という。

CNCFの事務局長Dan Kohnはこう述べる: “KubernetesのコミュニティにGoogleの大きな財政支援があることによって、このプロジェクトのイノベーションと採用の安定的なペースが今後も減衰することなく維持されるだろう。Google CloudがKubernetesのテストとインフラストラクチャに関わるプロジェクトをコントリビューターの手に渡したことによって、プロジェクトはオープンソースであるだけでなく、オープンなコミュニティによってオープンに管理されるものになる”。

今後長期的には、インフラストラクチャがGoogleのクラウドから離れることになるのか、そのへんはまだ分からないが、3年後に他のクラウドプロバイダーが同様のクレジットを提供することは、大いにありえるだろう。

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

Microsoft、ビデオの自動文字起こし提供へ――Office 365にAIベースのアップデート

今日(米国時間2/28)、MicrosoftはOffice 365契約者のOneDriveとSharePoint向けにAI利用のアップデートを発表した。これによりMicrosoftのクラウド・ストレージに機械学習を利用した強力な能力が備わることになる。

新機能が実装されるのは今年中の見込みだ。MicrosoftのIgniteカンファレンスは来月フロリダ州オーランドで開催される。ここで今日のアップデートのいくつかのデモが見られると予想してもよさそうだ。

OneDrive、SharePoint向けアップデートのハイライトのひとつはビデオとオーディオのファイルからの自動文字起こしだ。ビデオ記録はたしかに素晴らしいが意味のある情報を取り出そうと思うとひどく時間を食う。まずどれが自分の求めている情報を含むファイルなのか決めるのに手間がかかる。ファイルを見つけてもさらに文字起こしをしなければならない。Microsoftによれば、新しいサービスはユーザーがビデオを視聴するとき、リアルタイムで音声を自動的に文字起こしして表示するという。320種類のファイルをサポートするのでユーザーがどんなファイルをアップロードしても対応できるだろう。

今日発表された他のアップデートには、 OneDriveとOffice.com向けの新しいファイルビューがある。これはOffice 365でユーザーがファイルを探す場合、最近利用されたファイルに基づいてシステムが必要なファイルを推測して候補として表示するというものだ。Microsoftでは近くこのアルゴリズムを他のアプリにも拡張する。たとえばPowerPointでファイルを作成してプレゼンしたとすると、システムはそのファイルを同僚と共有するよう提案する。

また知識のあるユーザーは、OneDriveないしSharePointのどのファイルについても利用状況をチェックすることができるようになる。

原文へ

滑川海彦@Facebook Google+

VMwareがその顧客元実装上にAWSのRelational Database Serviceを導入

ちょっと意外なニュースだ。Amazonのクラウドコンピューティング部門であるAWSが、今日(米国時間8/27)の発表によると、同社のRelational Database Service(RDS)をVMwareに持ち込む。それはAWS上のVMware Cloudと、企業が自分のデータセンターでプライベートに動かすVMwareの両方だ。

AWSのコンペティターの一部は、かなり前から、こういうハイブリッドなクラウドのデプロイにも力を入れてきたが、AWSはそれほどでもなかった。でも今や、それが変わろうとしている。それはたぶん、Microsoftなどの競合他社がこの分野で好調だからだろう。

AWSのCEO Andy Jassyはこう述べている: “データベースは、その管理にも運用にも、泥沼のように面倒で厄介な側面がある。だからこそ何十万もの顧客がAmazon RDSを信頼して、大規模なデータベースの管理を任せているのだ。この、オペレーションの現場で鍛えられた同じサービスを、オンプレミスやハイブリッド環境の顧客にご提供していけるのは、とてもすばらしいことだ。それによって、エンタープライズのデータベース管理が容易になるだけでなく、データベースをクラウドに移行する作業も、より単純になる”。

Amazon RDSがVMwareに来たことによって、エンタープライズは、AWSの技術を利用してMicrosoft SQL ServerやOracle, PostgreSQL, MySQL, MariaDBなどのデータベースを利用できる。たとえば、どこでデータをホストするにしてもデータベースのセットアップと管理が楽になる。…そして将来的には、AWSへの移行も容易になるだろう。

この新しいサービスは目下非公開プレビューなので、その詳細や料金などはまだ分からないが、ユーザー体験はクラウドの場合とほぼ同じだろうし、VMware上のRDSもアップデートやパッチを自動的に行なうことになるのだろう。

今日の発表は、AWS上のVMware Cloudのローンチから約2年後になる。それは今日の発表の真逆で、VMwareがAWSに来る、というものだった。VMwareのデプロイを動かしているエンタープライズは、それをそのまま、AWSへ移せるのだ。

関連記事: VMwareがついにクラウドサービスを提供、しかもAWSとのパートナーシップのもとで

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

VMwareがマルチクラウド管理のCloudHealth Technologiesを買収

VMwareは今週ラスベガスで、顧客のためのカンファレンスVMworldを開催しており、その席で同社は、ボストンのCloudHealth Technologiesを買収したことを発表した。買収の条件は公表されていないが、ロイターの報道では買収価額は5億ドルとされている。

CloudHealthはVMwareに、重要なマルチクラウド管理プラットホームを提供する。そのツールはAWS, Microsoft Azure, Google Cloud Platformなどをサポートし、ユーザーは、クラウドのコストや利用、セキュリティ、パフォーマンスなどを一つのインタフェイスから管理できる。

クラウド市場はAWSが大きくリードしているが、それは広大で急成長中の市場であり、多くの企業が複数のプラットホームを使い分けている。それぞれの目的にもっとも合ったクラウドサービスを使いたいからだ。

このマルチクラウドのアプローチには単一のプロバイダーに縛られないという利点はあるが、一方、その管理がたいへんになる。そこでCloudHealthはマルチクラウドのユーザーに、単一のツールでそれらの環境を管理する方法を提供する。

CloudHealthのマルチクラウド管理。写真提供: CloudHealth Technologies

VMwareでプロダクト管理とクラウドサービスを統括しているCOOのRaghu Raghuramによると、CloudHealthはマルチクラウドのオペレーションに伴うジレンマを解決する。彼曰く、“CloudHealth Technologiesが加わったことによって、複数のクラウドにまたがるコストとリソースや、アプリケーションのセキュリティとパフォーマンスを一元管理し、問題に迅速に対応できるようになった”。

つい先月、CloudHealthがサポートするクラウドプラットホームにGoogle Cloud Platformが加わった。CTOのJoe Kinsellaは、GCPのサポートを加えたことについて、こう述べている: “GCPでは、2015年にDiane Greeneが来て以来、いろんな企画が動き出し、エンタープライズへの適性が強化されている。その結果、われわれの顧客の間にも、急激に関心が高まっている”。

これによりCloudHealthの顧客も、大手プラットホーム三社のクラウドを安心して併用できるようになる。そして、かねてから顧客のハイブリッド環境や、マルチクラウド環境の管理を目指してきたVMwareにとっても、CloudHealthがいわば“買い時”になってきた。

これまで同社は、パブリッククラウドだけでなくプライベートクラウドやデータセンターも含めたすべての環境の一元管理を目指していた。それに対しVMwareもまた、さまざまなVMを使っている企業の、ハイブリッド環境の支援を、近年は志向してきた。

CloudHealthは、マルチクラウド管理のソリューションだけでなく、Yelp, Dow Jones, Zendesk, Pinterestなど、3000社の顧客をVMwareに連れてくる。

CloudHealthは2012年に創業され、これまで8700万ドルを調達している。最近では2017年6月のシリーズDで、Kleiner Perkins率いるラウンドにより4600万ドルを調達した。それよりも前のリード投資家は、Sapphire Ventures, Scale Venture Partners, そして.406 Venturesだ。

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

CI/CDを末端企業にも普及させたいArmoryはY Combinator出身で$10Mを調達

オープンソースのSpinnakerプロジェクトをベースとするCI/CDプラットホームArmoryが今日(米国時間8/22)、シリーズAのラウンドにより1000万ドルの資金を調達したことを発表した。このラウンドはCrosslink Capitalがリードし、Bain Capital Ventures, Javelin Venture Partners, Y Combinator, そしてRobin Vasanらが参加した。

ソフトウェア開発は、ここ数年で確かに変わった。間隔の長いアップデート・サイクルに代わり、継続的デリバリが主流になってきた。このコンセプトは今では、継続的インテグレーション/継続的デリバリ(continuous integration/continuous delivery)を表すCI/CDと呼ばれている。Armoryのプロダクトは、このタイプのソリューションをデプロイするときに伴う複雑性を、軽減しようとする。

同社を創業したときファウンダーたちは、CI/CD技術のバックエンドのベースとしてSpinnakerを使う、と決めた。それは、GoogleやNetflixなど業界の大物たちが支持しているプロジェクトだからだ。ArmoryのCEOで協同ファウンダーのDaniel R. Odioが、今回の資金調達を発表するブログ記事でこう述べている: “Spinnakerは大規模で本格的なマルチクラウドのデプロイを支えるスタンダードになるだろう。自分たちで新たに継続的デリバリのプラットホームを内製で構築する、そんな車輪の再発明を避けて、SpinnakerをArmoryプラットホームのコアにするという、大きな賭をした”。

同社によると、その賭は報われ、Spinnakerの同社バージョンはエンタープライズのソリューションで広くデプロイされている。同社の目標は、Fortune 2000社がソフトウェアのデプロイを今よりずっと速くできるようになることだ。そしてそのためには、CI/CDのアクセスと理解が欠かせない。

今企業は、どんな企業でもソフトウェア企業になりつつあるから、どの企業もこれまでとは異質な部分を抱え込むことになる。GoogleやNetflixのような超大物は、最先端の方法により、ソフトウェアを驚異的なスピードでデプロイする方法を経験から学び構築しているが、製品の製造技術=ソフトウェア開発技術ではない、そこらのふつうの企業は、ソフトウェア技術者もそんなに多くないから、Googleなどに追随することは難しい。

その空隙を補ってくれるのが、Armoryのような企業だ。同社は、オープンソースの技術を核として、その複雑性を包み隠すパッケージにより、高度なソフトウェアデプロイ技術を持たない普通の企業でもCI/CDを導入できるようにする。

中でもとくに同社が強調するマルチクラウドでクラウドネイティブなソフトウェア開発方式は、ユーザーのアプリケーションやインフラストラクチャを、オンプレミスも含む複数のクラウドに分散可能にする。そのようなデプロイ技術の重要な部分が、継続的デプロイを管理する技術だ。

Armoryは2016年にローンチし、ベイエリアに拠を構える。これまで1400万ドルを調達したが、そのうちの400万ドルのシードラウンドは昨年行った。同社はY Combinator 2017冬季の卒業生であり、Y Combinatorは今回の投資に参加している。

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