タグ: Cloud

AWSのストレージサービスS3にゾーンを一つしか使えない低料金バージョンが登場

AWSのストレージサービスS3が今日（米国時間4/4）、データをクラウドに保存するための、低料金なオプションを導入した。デベロッパーは、それほど頻繁にストレージにアクセスしないアプリケーションのために、高い可用性を求めないことにより、最大でS3の標準料金の20%引きで利用できる。S3のこの新しいティアの名前は、S3 One Zone-Infrequent Access（ゾーンがひとつの非頻繁アクセス）だ。

S3は、AWSが最初から提供していたサービスのひとつだ。これまで、ティアの種類が少しずつ増えてきた。S3 Standardティアは、99.999999999%の永続性と99.99%の可用性を約束しているが、S3 Standard-Infrequent Accessは、同じ永続性と99.9%の可用性を約束している。またGlacierは、コールドストレージだ。

StandardとStandard-Infrequentに保存されるデータは、三つ以上のアベイラビリティゾーンへ複製される。しかし低料金のOne Zone-Infrequent Accessティアは、名前が示すように、一つのアベイラビリティゾーンにしか保存されない。複数のマシンへ複製することはできるが、しかしそのゾーンがダウンしたり破壊されると、データにアクセスできない。

そのため、この新しい低料金ティアは可用性が99.5%で99%のSLA（アップタイム率）しか提供しない。しかしその機能や永続性は、S3のほかのティアと違いはない。

今日（米国時間4/5）サンフランシスコで行われたAWS SummitのキーノートでCTOのWerner Vogelsが言ったように、ストレージのコストは複製を行うアベイラビリティゾーンの数で決まる。彼の見解では、この新しいサービスは、頻繁にアクセスされないけど複製はできる、というデータに利用すべきだ。

99.5%の可用性は、1年に1日か2日の、データにアクセスできない日がある、という意味だ。一部のアプリケーションにとっては、それで十分だが、Vogelsの説では、顧客はこのストレージを二次的なバックアップコピーや、複製可能なメディアファイルの保存に使うだろう、と言う。

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

サーバーレスコンピューティングのモニタリングサービスStackeryが$5.5Mを調達

StackeryのファウンダーたちがまだNew Relicにいた2014年に彼らは、今後伸びてくるサーバーレス技術の市場にツールを提供していく機会がある、と考えていた。New RelicのIPOを契機に同社を去った彼らは、サーバーレスのアーキテクチャに統括と管理の層を提供する、を目標としてStackeryを創業した。

今日（米国時間4/3）同社は二つの大きな発表を行い、その最初の550万ドルの資金調達を彼らは“シード＋”（プラス）と呼んでいる。第二の発表は、Health Metrics Dashboardと呼ばれるサーバーレスのパフォーマンスモニタツールだ。

まず、資金調達の話から。なぜ、シードプラスと呼ぶのか？　同社の協同ファウンダーでCEOのNathan Taggartによると、シリーズAでも良かったけど、でもまだ彼らの市場がそれほど成熟していないので、控えめな呼び方にした。“シリーズAへの欲求はあったけど、シードプラスの方が市場の現状に合っている”、と彼は述べる。今はまだ、各社がやっとサーバーレス方式の利点を理解し始めた段階だから、明らかに成長途上の市場だ。

HWVPがこのラウンドをリードし、Voyager Capital, Pipeline Capital Partners, そしてFounders’ Co-opが参加した。これにより、2016年に創業した同社の調達総額は730万ドルになった。

AWS LambdaやAzure Functionsなどのサーバーレスコンピューティングという呼び名は、やや誤称だ。プログラムはサーバーが動かすのだけれども、アプリケーションのための専用のサーバーは要らない。トリガーイベントがあってそれに呼応するコードをサーバーが実行するときだけ、料金が発生する。これに先駆けてやってきたクラウドコンピューティングと同じく、デベロッパーがこれを好むのは、アプリケーションの構成やリソースの確保に大量の時間を取られずに済むからだ。

しかし、従来のクラウドコンピューティングと同じく、サーバーレスも実はクラウドサービスだ。だからこそ、デベロッパーは容易にアクセスできる。2011年に始まった“ITの消費者化”現象を思い出せば、それはクラウドサービスを容易に調達できる能力と引き換えに、組織内部のコントロールを失うことを意味していた。

クラウド初期の当時と同じく、今企業はサーバーレス技術のアドバンテージを求めるが、それと同時に、その費用や、他企業の利用状況、セキュリティ、企業のルールとのコンプライアンスなどが気になる。そこで、Stackeryのようなサービスの出番となる。

Health Metrics Dashboardと名付けられた新しいダッシュボードは、このビジョンの延長であり、モニタリングにルーツを持つファウンダーたちらしいプロダクトだ。サーバーレスはコンテナを扱うことが多く、多くのファンクションがそこにはある。何かがおかしくなったとき、その根因を見つけるのが難しい。

StackeryのHealth Metricsダッシュボード。写真提供: Stackery

そのダッシュボードは、ひとつのアーキテクチャ全域のスループットと各リソースのパフォーマンスを見せるから、デベロッパーは、どこにボトルネックがあり、パフォーマンスの問題や失敗があるか分かる。

同社は2016年に創業し、オレゴン州ポートランドに本社がある。社員は今9名で、内5名がエンジニアだ。年内には3名の増員を計画している。

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

Googleが三月の狂気(march madness)でリアルタイムの試合展開予想をCMで提供

Googleは、同社のデータサイエンスの技術をリアルタイムで試してみたいようだ。今週末（米国時間3/30〜）同社は、サンアントニオで行われるファイナルフォー(Final Four, 全米男子大学バスケ選手権)で、データ分析と機械学習の技術を駆使して、試合中にさまざまな予測を行う。そしてハーフタイムに放映されるテレビコマーシャルでは、そのゲームの後半戦について予言する。

その詳しい計画は同社の今朝（米国時間3/30）のブログ記事に載っていて、そこでは、Googleのクラウド技術を使ったスポーツデータの統計分析などで同社とNCAA（全米大学体育協会）はすでに関係があり、今回の企画もそのご縁から生まれた、と言っている。そしてGoogleはこの機会を、NCAAのデータのより高度な活用の機会と捉えている。

チームはデータサイエンティストと技術者とバスケットボールのファンたちで構成され、GoogleはGoogle Cloud PlatformとBigQuery、Cloud Datalabなどの技術を利用するデータ処理のワークフローを構築した。データは非常に細かくて、各人の毎分のショットブロック数、動物をマスコットにしているチームの逆転負け率、などもある。Googleはそれらのデータを総動員して、今行われているゲームの経過や結果を予想する。そのためには、ゲームの前半から得られたデータをリアルタイムで分析し、それに基づく予想を数分後にコマーシャルで発表する。

Google Cloudのチームが試合中の会場にいて、前半のデータをワークフローに放り込み、NCAAの過去のデータも利用して分析する。ハーフタイムになったら、データをさらに分析して予想を作りだす。その技術的な詳しい説明は、Google Cloud Big Data and Machine Learningのブログで共有されている。

ハーフタイムが終わる前にGoogleは、出来立てほやほやのテレビコマーシャルをCBSとTurnerに渡し、後半が始まる直前にそれが放映される。

“スポーツイベントの実況中に自社のリアルタイム予測分析技術を利用してコマーシャルを作る企業は、うちが世界で初めてだろう”、とGoogleは言っている。

この実験はGoogle Cloudなどの技術を宣伝する方法としても巧妙だが、ファイナルフォーの予想をするテクノロジー企業はGoogleだけではない。

すべてのバーチャルアシスタント（スマートアシスタント、音声アシスタント）が、独自の予想をしている。GoogleのGoogle Assistantだけでなく、AmazonのAlexaも、MicrosoftのCortanaも、AppleのSiriも。でもそれらの一部は、本物のデータサイエンスを利用した予測というより、人が書いた意見のようだ。

このGoogleとNCAAのデータサイエンス/機械学習の実験には、そのためのWebサイトもある。

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

Microsoft Azureのアベイラビリティゾーンがやっとアベイラブルになった

どのクラウドを使う場合でも、あなたのアプリケーションの可利用性を高く維持するためには、そのアプリケーションとデータを物理的に異なる複数のリージョンに置きたいだろう。そうしないと、ひとつのリージョンがダウンするとアプリケーションもダウンする。しかし大手のクラウドプラットホームはすべて、ひとつのリージョン内に‘アベイラビリティーゾーン(availability zone)’という概念を設けて、アプリケーションを同じリージョン内の二つのデータセンターでホストするオプションを提供している。すべて、と言ったが、Azureのアベイラビリティゾーンは昨年9月にベータでローンチし、今日（米国時間3/30）から一般供用される。

今日のローンチに先駆けてMicrosoftのAzure担当VP Julia Whiteは、データセンターのネットワークに関する同社の設計哲学はつねに、商用利用の顧客にできるかぎり広い圏域のリージョンを提供して、彼らの顧客との至近性を確保し、またローカルデータの独立性とプライバシーに関する法律を守ることにある、と述べた。たしかにAzureは競合他社に比べてリージョンの数が多く、今可利用なものが38、発表されているものが12ある。

“Microsoftのインフラストラクチャのアプローチはエンタープライズの組織を念頭に置いており、そのために多数のリージョンを設けている”、とWhiteは言っている。“このようなリージョンの設定は、容易でシンプルだからしているのではない。顧客が本当に望むものはこれだ、と信じているからだ”。

それぞれのアベイラビリティゾーンに独自のネットワーク接続と電力のバックアップがあり、リージョン内のひとつのゾーンがダウンしてもほかは無事だ。しかしリージョン全体に及ぶ災害はすべてのゾーンを遮断するだろうから多くの企業は、データを少なくともあとひとつの別のリージョンに保存したいだろう。

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

Google Cloudがアプリケーションパフォーマンスモニタリングのツール集を提供

Googleのクラウドプラットホームでは、社内用に作ったツールやサービスがGoogleのプロダクトとして顧客に公開提供されることが多い。今日（米国時間3/28）同社は、その一環として、Google Cloud Platformの上でアプリケーションを構築するデベロッパーにとって重要な、アプリケーションのパフォーマンス管理(application performance management)ツール集Stackdriver APMを発表した。

APMの考え方はやや変わっていて、問題の責任をオペレーションに渡すのではなく、デベロッパーがアプリケーションを調べる。つまりアプリケーションを作ったデベロッパーがコードにいちばん近いところにいるので、そこから出てくる信号もいちばんよく理解できるはずだ、とする。

StackDriver APMは、三つのツールで構成される: プロファイラーとトレース（トレーサー）とデバッガだ。トレースとデバッガはすでに利用できるが、しかしプロファイラーと併用することによって、三つのツールが協働してコードの問題を特定し、調べ、そして修復できるようになる。

Stackdriver APMを発表するブログ記事でGoogleのプロダクトマネージャーMorgan McLeanはこう書いている: “これらのツールのすべてが、どんなクラウドの上で動くコードやアプリケーションでも扱えるし、オンプレミスのインフラでも使える。つまり、アプリケーションがどこで動いていても、一貫性がありアクセス性の良いAPMのツールキットを使って、アプリケーションのパフォーマンスをモニタし、管理できる”。

ほかにStackDriverにはモニタリングとロギングのツールもあり、これら完全なAPMのスイートが、SplunkやDatadog、New Relic、AppDynamics（Ciscoが買収）などのベンダと競合することになる。しかしGoogleのプロダクト管理担当VP Sam Ramjiによると、これらのベンダは競合他社であるだけでなくパートナーでもあり、お互いのツールが協働して問題解決に取り組むことを、Googleも十分に理解している。

“しかし、コアシステムがみんなによく見えるようにする点では、うちが一番だ。人びとはこれまで使ってきたお気に入りのツールをこれからも使って、彼らの企業の事業目的という見地からプロダクションシステムを検査したり、適切なタイミングでアラートしていくだろう”、と彼は述べる。

まず最初は、プロファイラーの出番だ。これによりデベロッパーは、軽量級の（全量ではなく）サンプリングベースのツールで、アプリケーションのすべてのインスタンスからデータを収集する。

Stackdriver Profiler. 画像提供: Google

プロファイラーが集めたデータから問題を判定したプログラマーは、次にトレースを動かす。Ramjiによると、コードの問題はほとんどつねにクリティカルパスの後（あと）にあるから、このツールを使えば、問題が分散システムの全域にわたって伝搬していく様子を理解できる。トレースの画面（下図）は視覚化されたアナリティクスのような形をしていて、これらにより問題の性質と、計算資源に対するそのインパクトが分かる。

Stackdriver Traceツール。 画像提供: Google

そして最後がデバッガだ。Ramjiがこれをとくに好きなのは、若き日の90年代のツールを思い出させるからだ。当時はデバッガでアプリケーションを止めたり動かしたりしながら、問題の所在を突き止めていた。このAMPのデバッガもやはり、指定した箇所でコードを止めて、問題の核心を見つける。

ただしこの現代的なデバッガには、Ramjiが“マジック”と呼ぶものがある。デベロッパーによるコードの停止や再開が、顧客に影響を及ぼさないのだ。McLeanもこう書いている: “プログラマーにおなじみのブレークポイント方式のデバッグ処理を提供するが、それによって顧客へのネガティブなインパクトはない”。

Stackdriver APMは今日（米国時間3/28）から可利用になり、完全なサービスから成る完全なモニタリングスイートが提供される。これでGoogleは、モニタリング〜デバッグという分野でも、既存の選手たちと競争するつもりのようだ。

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

Google CloudはGoogle自身が使っているテキスト音声変換エンジンをデベロッパーに公開

テキストから音声への合成技術は近年大きく進歩し、最近のシステムは本物の人間がテキストを読んでるように聞こえるものが多い。その進歩を引っ張った企業のひとつであるGoogleは今日（米国時間3/27）、同社がAssistantやGoogle Mapsなどで今使っているのと同じ、DeepMindが開発したテキスト音声変換エンジンをデベロッパー向けに一般公開した。

そのCloud Text-to-Speechと呼ばれるサービスは、32種の声が12の言語とその変種を喋る。このサービスが生成するMP3またはWAVファイルは、ピッチや読む速度、音量などをデベロッパーがカスタマイズできる。

しかし、声の質にはむらがある。それはたとえば、英語には6種類の声があるからで、それらはすべて、テキストから生のオーディオを作るためのDeepMindのモデルWaveNetで作られている。

WaveNetはそれまでの技術と違って、短い発話の集まりから音声を合成しない。それをやると、私たちにはおなじみの、ロボットふうの話し方になってしまう。それに対してWaveNetは機械学習のモデルを使って生のオーディオのモデルを作り、より自然に聞こえる音声を合成する。Googleが行ったテストでは、WaveNetの声の方がふつうの（人間の）声よりも20%良い、という評価になった。

Googleが初めてWaveNetに言及したのは約1年前だが、その後同社は、同社自身のTensor Processing Unitsをベースとする新しいインフラストラクチャへこれらのツールを移し、オーディオ波形の生成をそれまでの1000倍速くした。だから今では1秒のオーディオの生成に50ミリ秒しかかからない。

この新しいサービスは、すべてのデベロッパーが利用できる。料金表はここにある。

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

NvidiaのGPUによる高速化技術がついにKubernetesをサポート

やっと、という感じだが、NvidiaのCEO Jensen Huangが今日（米国時間3/27）、彼のGTC(GPU Technology Conference)キーノートで、Googleで生まれ育ったコンテナオーケストレーションシステムKubernetesをNvidiaのGPUでサポートする、と発表した。

その意味は、何百何千ものGPUが機械学習処理の高速化などのために使われているような、いわゆるハイパースケールなデータセンターでGPUの使用を最適化し、デベロッパーがコンテナをなんの変更も加えずに複数のクラウドへデプロイできるようにする、ということだ。

Jensenはこう言った: “今やフレームワークは高速化し、コードも高速化した。では、それをデータセンターの世界へデプロイするにはどうするのか？　そうだ、そこにはうまい具合に、Kubernetesというものがある。良かった！すごく良かった！”。

NvidiaはKubernetesのGPUによる高速化技術とそのコードを、オープンソースのコミュニティに寄贈する。機械学習のワークロードは、計算とデータの両方で巨大なものになりがちだ。Kubernetesはそんなワークロードのオーケストレーションを助け、そして今や、その仕事にGPUを使える。

Huangは次のように述べて、会場からの笑いを誘った: “Kubernetesは今やGPU対応だ。DockerのコンテナはGPUが加速する。そして私がこれまで名を挙げたようなフレームワークはすべて、GPUで加速される。そしてまた、みなさんが抱え込んでいる推論のワークロードもGPUが加速する。そしてこれらのクラウドのすべてでNvidiaのGPUが動く。そしてさらに、すばらしいオーケストレーションのレイヤとしてKubernetesがある。完全に満たされた人生だね”。

KubernetesのGPUによる高速化は、今日の発表以前にもある程度サポートされていた。たとえばGoogleは、そのKubernetes EngineですでにGPUをサポートしている。

 

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

Googleのクラウドプラットホームではハイパフォーマンスなワークロードを容易に動かせる

AmazonやMicrosoft、Googleなどが提供している非常に大きなクラウドプラットホームは、大学や企業の科学者たちがシミュレーションや分析のために必要とするハイパフォーマンスコンピューティング(high-performance computing, HPC)のプロジェクトを十分に動かせる。なにしろ彼らに課せられる大きなワークロードも、何百何千というマシンで並列処理されるから楽勝だ。しかし、往々にしてチャレンジは、それだけ大量のクラスターをどうやって作り、それらを動かすワークロードをどうやって管理するかだ。

HPCのコミュニティがこのチャレンジを比較的楽にこなせるために、Googleは今日（米国時間3/23）、同社のクラウドプラットホームでオープンソースのHPCワークロードマネージャーSlurmをサポートする、と発表した（このSlurmではない）。それは、上位500のリストに載ってるようなスーパーコンピューターのユーザーの多くが使ってるのと同じようなソフトウェアだ。ちなみに現在最大最速のクラスターは、1000万あまりのコンピューターコアから成るSunway TaihuLightだ。

GoogleはSlurmを作っているSchedMDとチームを組んで、SlurmをGoogleのCompute Engineで簡単に動かせるようにした。この統合努力によりデベロッパーは、自分たちの仕様に基づいて動くCompute Engineで、スケーリングを自動的に行うSlurmを容易にローンチできる。ここでの興味深い機能のひとつは、もうちょっと計算力が欲しいようなときに、ユーザーがオンプレミスのクラスターのジョブをクラウドと連合できることだ。

GoogleのCompute Engineは現在、最大96コア、メモリ624GBまでのマシンを提供しているので、GCP(Google Cloud Platform)の上で必要に応じて大規模な計算力クラスターを構築することも、十分に可能だ。

なお、Microsoft Azureもその上にSlurmをデプロイするためのテンプレートを提供しており、またこのツールはかなり前からAWSをサポートしている。

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

AIをクラウドにデプロイする過程を単純化するためにPaperspaceはサーバーレスを選ぶ

GPUベースのインフラストラクチャをサービスとして提供することは、スタートアップにとって容易なことではないが、機械学習やVFXを多用するモダンなソフトウェアの開発とデプロイを目指すクラウドインフラストラクチャサービスPaperspaceは、あえてそれに挑んでいる。そして同社は今日（米国時間3/21）、さらに次の一歩として、AIや機械学習のプロジェクトでサーバーのデプロイを不要にするサービスプラットホームGradientを発表した。

どんなサーバーレスのアーキテクチャでも、サーバーがいなくなるわけではないが、ユーザー（デベロッパー）が手作業でそれらをデプロイする必要はなくなる。Gradientはコードをデプロイする手段を提供し、アロケーションやマネージメントはすべてPaperspaceが面倒見る。それにより、機械学習のモデルの構築に伴う複雑性の、大きな塊（かたまり）を取り除く。

同社の協同ファウンダーでCEOのDillon Erbによると、数年前に同社を立ち上げたときはGPUは今日のクラウドサービスのように一般化していなかった。最初は仮想マシンのGPUインスタンスを立ち上げるやり方が主流で、今でもそうだが、問題はツールの不備だった。

Erbの説明では、大企業はツールセットを内製することが多い。しかし実際には、それだけのリソースを持たない企業がほとんどだ。“GPUなどで十分な計算パワーがあっても、それだけではだめで、ソフトウェアスタックが必要なんだ”、と彼は言う。

同社が昨年1年間を費やして作ったGradientは、デベロッパーにそのための構造を提供し、それにより彼らは、もっぱらモデルやコードの構築と、プロジェクトを軸とするコラボレーションに集中できるようになる。そしてマネージメントは、Paperspaceにまかせる。DevOpsのチームが、チームとコードとその下のインフラストラクチャの間の対話を管理する必要も、なくなる。

“コードとDockerのコンテナだけをいただければ、VMのスケジューリングなどはわれわれがいたします。ご自分でマシンを立ち上げる必要はありません”、とErbは語る。

Paperspaceは、Y Combinatorの2015年冬季クラスを卒業して以来、クラウドにGPUをデプロイするという難題に取り組んできた。2014年にローンチしてから今日までに1100万ドルあまりを調達してきたが、シードラウンドの400万ドルがやっと2016年だった。

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

AWS Lambdaのイベントトリガを使いやすくしてWebサイトの開発方法を改革するNetlify

Webプロジェクトの継続的なデプロイメントを支援するサービスNetlifyのビジョンは、Webサイトの作り方を変えることだ。とくに、フロントエンドのデザインとバックエンドで実行されるサービスとの結合を、もっとシンプルにしたい。今日同社は、そのビジョンの実現に向かう次の一歩として、NetlifyのサービスにAWS Lambdaのファンクションを導入した。

同社のねらいは、Web開発に伴う多くの複雑性を、できるだけ減らすことだ。たとえば、ユーザーがHTMLとJavaScriptでフロントエンドをデザインすると、Netlifyはそれをさまざまなサービスに結びつける。決済ならStripe、メールによるニューズレターの管理ならMailChimp、というように。このやり方でNetlifyは、Webサーバーという概念を抽象化（実体のないものに）してしまう。デプロイが遅くてセキュリティもスケーリングも困難なあのあれが、消えてなくなる。そして、一枚岩的なWebサイトから、スタティックなフロントエンドとバックエンドのマイクロサービスという組み合わせへ移行し、それによりセキュリティとスケーリングの問題を解決、そしてサイトを従来よりも相当早くユーザーに渡せるようになる（デリバリが早い）、と同社は信じている。

ユーザーは、サイトの構築に何を使ってもよい。ユーザーが作った設計/デザインを渡されたNetlifyは、バックエンドのコーディングのすべてをエッジに置き、コードはエッジで実行される。その意味で同社のサービスは、半分はContent Delivery Network(CDN)、残る半分はデベロッパーの自動化エンジンだ。

この、より動的なWebサイトをより早く作るというNetlifyの能力がAndreessen HorowitzのパートナーPeter Levineの目に留まり、昨年8月に同社の1200万ドルのシリーズを彼がリードした。Levineは曰く、“彼らの、マイクロサービスとAPIsを活用して柔軟性に富む動的な（ダイナミックな）Webサイトを作る、という考え方はすばらしいアイデアだ。しかも、エッジへデプロイすることによって、さらにハイパフォーマンスなユーザー体験を作れるし、GitHubを統合することによってアプリケーションを容易に作成し管理できる”。

今日の発表は、同社のサービスのそんなアプローチをさらに一歩前進させる。Lambdは、AWSのいわゆるサーバーレス・ツールだ。デベロッパーはファンクションを作り、それが特定のイベントにトリガされて実行される。デベロッパー側には、サーバーを24/7動かし管理しメンテナンスする苦労がない。これは、NetlifyのWeb開発アプローチとぴったり相性が良い。つまりそれは、AWS Lambdaと同じく、WebのパブリシングプロセスからWebサーバーを取り除くから。

そしてNetlifyは、Lambdaのファンクションを、もっと容易に実行できるようにした。同社によると、Webデベロッパーは確かにイベントトリガーという考え方を気に入っているけど、AWSのワークフローは複雑すぎる。イベントトリガーをデベロッパーのアイデンティティで容易に作れるようになれば、Lambdaをもっと気軽に利用できるだろう。

同社の協同ファウンダーChristian Bachは、こう説明する: “Lambdaが良いことは自明だが、それを軸とするワークフローがないために、使いづらい。われわれにはフロントエンドをパブリシングするワークフローがあるので、サーバーレスもそれと同じようにしたい、と考えた”。

“Lambdaのトリガのひとつひとつが小さなマイクロサービスになり、ブラウザーからそれらにアクセスできる”、と彼は述べる。たとえばStripeを使って決済をする場合なら、Stripeの秘密の認証情報のコードで決済のゲートウェイに入る。“従来なら、この小さな呼び出しのために、どこかでサーバーを動かす必要がある。この小さな機能だけのために、Railsのアプリケーションを作るだろう”、Bachはそう述べる。

しかしNetlifyのやり方では、認証情報を数行のコードでタイプし、それからLambdaのトリガとNetlifyの糊的なコードを少々使うだけだ。これにより、そのコードをどこに置くか、それをどうやって管理するか、という問題が解決する、とBachは言う。

かねてからエッジコンピューティングをテクノロジーの大きな駆動因として見ているLevineがNetlifyのシリーズAをリードし、同社の取締役会に加わったたのは、たぶん偶然ではない。

Levineは曰く、“かなり前からエッジコンピューティングには注目しているし、Netlifyは、エッジにおけるサービスという大きなトレンドの一部だ。同社は、現代的なWebサイトを構築しデプロイする方法を開発した”。

同社は、2015年に創業され、これまでに1410万ドルを調達している。

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

IBMがセキュリティやDDoS防御でCloudflareとパートナー、サービスの内製を選ばず

最近の数年間でCloudflareは、データセンターの立地とパートナーシップでグローバルなネットワークを築き、同社のDDoS防御やセキュリティツール、Webサイトの加速、などのサービスを拡大してきた。これだけの専門的能力は簡単に得られるものではないので、IBMのような巨大グローバル企業でさえ今日（米国時間3/13）、内製よりもむしろCloudflareとのパートナーシップにより、これらのサービスを顧客に提供していく、と発表したのも、不思議ではないかもしれない。

IBMが新たに始めたCloud Internet Servicesは今日発表され、サイトの保護と高速化のためのCloudflareのサービスをすべて提供する。IBMはこの発表を、来週行われるTHINKカンファレンスの前、というタイミングで行っているのだ。

IBMのWatsonとクラウドを担当するCTO Bryson Koehlerによると、IBM Cloudのユーザーは、一回のクリックでこれらの機能をonにできる。“Cloudflareは、ワールドクラスのツールセットを作るすごい仕事をしている。それらは使いやすいだけでなく、うちのチームが使っているのと同じスタンダードに従っている”、と彼は語る。“今日のように、変化が早くてサービスがつねに進化しているときには、いつも内製かパートナーかという決定を迫られる。そしてキャッシングやロードバランシングでは、彼らがうちとのパートナーシップにふさわしい仕事を成し遂げている”。

このパートナーシップに加えてIBMは今日、二つの新しいセキュリティ機能を発表した: それはIBM Cloud Security Advisorと、IBM Cloud App IDの新しい機能だ。Cloud Security Advisorは、デベロッパーとオペレーションの両チームに、彼らのセキュリティ態勢への、これまでよりも多くて深いインサイトを提供する。その中には、Webサーバーのセキュリティ証明がそろそろ期限切れだというベーシックなアラートがあったり、あるいはアプリケーションとデータに影響を与えるIBMのグローバルネットワーク上に兆候のある脅威に関する警報だったりする。このツールは十分高度に作りこまれているので、たとえば特定の規制に従ってデータを管理しなければならないデベロッパーが、うかつにPCIやHIPAA準拠のサービスからデータをロードし、それを非準拠のサービスに書き出す、といった事故を未然に防ぐことができる。

Cloud Security Advisorはまだ実験段階のプロダクトだが、必要なすべてのデータを単一のダッシュボード上に表示する。

App IDの方は、正しい認証を経たユーザーだけが、アプリケーションやデータにアクセスできるようにする。とくに新しい機能ではないが、IBMはこのサービスを今後、コンテナやIBM Cloud Container Serviceにも適用する。

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

GoogleがUbisoftと協働でオープンソースのゲームサーバーホスティングシステムAgonesをローンチ

クラウドコンピューティングといえば、ドキュメントをクラウドで編集したり、CRMシステムをアップデートしたりするための大規模なサーバーファームを連想する人が多いだろう。でも嬉しいことにクラウドには、遊びの側面もある。マルチプレーヤーゲームも、すべてどこかのクラウドで動いている。ゲーム企業は、これらのサーバーを動かすためのシステムを自分で作ることが多いが、しかしGoogleとUbisoftは今日（米国時間3/13）、マルチプレーヤーゲームのサーバーを管理しホスティングするためのオープンソースのシステムを提供する新しいプロジェクトを発表した。

そのプロジェクトの名前Agonesは、ギリシア語で“コンテスト”という意味だ。それはGoogleが育てたコンテナプロジェクトKubernetesを、マルチプレーヤーゲームサーバーの艦隊をオーケストレーションしスケーリングするための中核的なツールとして使用する。ユーザーが自分が好きなマルチプレーヤーゲームをプレイするときには、そんな大軍のゲームサーバーがあるおかげで、島にいる自分以外の99名のマニア的プレーヤーと互いに相手を見つけたり対戦したりできる。サーバーはゲームだけでなく、いかさまを見抜くためのソフトウェアを動かすこともある。コンテナがこの種のシナリオにとって理想的なのは、ゲームの個々のセッションは短時間で終わるものが多く、ひとつのコンテナでひとつのセッションを表せば、デプロイもシャットダウンも迅速にできるからだ。

Ubisoftの開発部長Carl Dionneは、こう書いている: “プレーヤーがゲームに集中できるためには、クォリティの高い、最高にシームレスなサービスを提供しなければならないし、そのための方法をたえず改良していく必要がある。Agonesが備えている柔軟性により、専用のゲームサーバー群を最適なデータセンターで動かすことができ、われわれのチームに、彼らが必要とするリソースのより強力かつ詳細なコントロールを与える。両社のコラボレーションによって、Kubernetesの大規模デプロイに関するGoogleの専門的能力と、われわれのゲーム開発パイプラインと技術に関する深い知識を、結びつけることができる”。

Agonesは要するに、ゲームサーバーを動かすために必要なツールでKubernetesを拡張したものだ。そのツールには、ゲームサーバーのためにカスタム化されたKubernetes Controllerと、同じくカスタムのリソース定義が含まれる。Agonesのチームによると、デベロッパーは、ペアのゲーマーを互いに引き合わせるデベロッパー独自のマッチメイキングサービスと標準のKubernetes APIsを容易に統合して、ゲームサーバーを始動できる。

Googleとしてはデベロッパーが自分のゲームをGoogle Kubernetes Engineでホストしてくれると嬉しいところだが、しかしAgones自身はクラウドを特定せず、どんなクラウドでも、あるいはオンプレミスでも、使用できる。

今日のリリースは、あくまでも初期的な形だ。しかしv2に向けてのロードマップはすでに作成中であり、チームによると、そこではゲームサーバーの集合体(Fleets)のような新しい機能や、ゲームサーバーのパフォーマンス分析、ノードの自動スケーリングなどが導入される予定だ。

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

Cloudflareが自分のグローバルネットワークへのアクセスを提供して真のエッジコンピューティングを可能に

ますます多くのコンピューティングがエッジへ移行して行くに伴い、プログラマーはレイテンシーを減らしパフォーマンスを上げるために、ユーザーになるべく近いコンピューティングパワーにアクセスしたい、と願っている。今日（米国時間3/13）Cloudflareが発表したCloudflare Workersは、そんなデベロッパーたちがCloudflareのネットワークのエッジで直接実行されるコードを、書けるようにする。

同社の協同ファウンダーでCEOのMatthew Princeによると、これまでそんなアクセスができるのはCloudflareの社員だけだった。“今日からはそれを、自分のアプリケーションをエッジで動かしたい人なら誰でも使える。これによってCloudflareの可能性も広がり、アプリケーションのこれまではできなかったような構成やプログラミングが可能になる”、と彼は説明する。

今の、IoTやゲーム、ビデオなどのアプリケーションは大量の帯域を使用するから、処理をなるべくエッジに持ってこれればパフォーマンスも改善され、またコードの実行に対する細かい粒度のコントロールも可能になる。

Princeによると、プログラマーは、ユーザーがそのアプリケーションにアクセスする場であるフロントエンドをいじったり、あるいはバックエンドではデータベースをいじくってパフォーマンスをアップしようとする場合が多い。しかしこれまでの彼らは、Cloudflareのネットワーク上のどこで自分のコードが実行されるかを、コントロールできなかった。

“本質的にローカルなプロダクトを開発する場合は、大多数のユーザーが至近距離にいるわけだから、コードがエッジで実行されるようプログラミングすればよい”、と彼は語る。至近距離という言い方は、誇張でなない。Cloudflareはデータセンターが世界中127箇所にあり、しかもその数はコンスタントに増え続けている。

この新しいサービスによりプログラマーは、コードが実行される場所をJavaScriptのコードで指定できる。しかも、そのコードをアップデートすると、エンドユーザーのところでアプリケーションのアップデートをする必要なく、ほとんどすぐに実装される。変更を、今使っているクラウドプロバイダーへアップロードする必要もない。

Cloudflareは、企業のWebサイトのパフォーマンスとセキュリティを向上することがメインの仕事だが、今回は自分のネットワークのパワーを顧客に利用させようとしている。コードの実行場所をプログラミングできることによって、ユーザーは自分のアプリケーションを動かすために必要なさまざまなレベルのリソースにアクセスでき、そしてロードバランシングやリソースアロケーションなどの面倒な仕事はCloudflare自身がやってくれる。AWsなどの、クラウドインフラストラクチャプロバイダーが、まさにそうやっているように。

2009年に創業された同社は、これまでに1億8200万ドルを調達し、これからの数か月ないし数年で同社のネットワークへのアクセスを拡大したい、という大きなビジョンを持っている。Princeによると、同社は昨年売上1億ドルのラインを超え、社員は600名を抱えている。今回のCloudflare Workersのようなサービスが加わると、売上はさらに拡大し、同社が作った全世界的なネットワークを、さらに有利に利用していけるだろう。

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

DropboxがIPOを前にしてSalesforceの深い統合を発表、エンタープライズの評価アップをねらう

Dropboxはこのところ忙しい。2週間前にはIPOを発表した。ついこないだの先週には、Googleとの大型パートナーシップを発表し、そして今日（米国時間3/9）は、Salesforceとのより深い統合のニュースが飛び込んできた。

DropboxとSalesforceは共にクラウド企業だから、過去に多少の関わりはあったが、しかし今日の発表はもっと大きい。たとえば、DropboxのフォルダがSalesforce Commerce CloudとMarketing Cloudに埋め込まれて、それらがあたかも、軽量版のデジタルアセット管理ソリューションのような様相になる。

たとえば、企業を顧客とするクリエイティブエージェンシーなら、写真などマーケティングキャンペーン用の素材を作り、それらの一部をSalesforceのマーケティングクラウドに保存するだろう。しかしそのフォルダは完全に統合化されているから、マーケティングとは無縁な現場のクリエイターがそれらのアセットの一部を自分たちのDropboxのフォルダでアップデートしても、マーケティングのための素材が入っているSalesforceのフォルダも自動的にアップデートされる。両者は物理的には同一のフォルダだから。

このような統合化によって、ユーザーの、あれをしたらこれをして、というステップが省略できる。Dropboxをオープンしてそのフォルダへ行き、アップデートされているアセットを見つけたらそれらを手作業でSalesforceにも持っていく、…こんな手間が、一発で済むようになる。

Salesforce本体だけでなく、同社が2016年に7億5000万ドルで買収したコラボレーション型ワードプロセッサQuipとも、同様に統合化される。それは、先週発表されたGoogleのG Suiteの統合の場合と同じく、エンドユーザーが自分のコンテンツに、どこで仕事をしていてもアクセスできるようにするためだ。

しかしQuipの場合は、双方向の統合になる。DropboxのフォルダがQuipに埋め込まれるのは、MarketingやCommerceのCloudの場合と同じだが、逆にQuipのドキュメントにDropboxの中でアクセスして仕事ができるようにもなる。これもまたユーザーが、そのとき使いたいツールや、アクセスしたい場所を自由に選べるためだ。

このようなパートナーシップは一見わかりにくいが、DropboxのSVP Quentin Clarkが先週、G Suiteの統合のとき言ったように、すべてはユーザーを楽にし、自由にするためだ。

“仕事の性質や都合などで、そのときどきの、ベストのツールは変わってくる。でもそんなとき、今の仕事のコンテンツに、そのときのベストのツールでアクセスできると便利だ。ツールや場所を変えても、そこに仕事がついて来る。それが、いちばん気楽だ”、と彼は語る。

今後はこのパートナーシップをさらに進めて、SalesforceはクラウドストレージにDropboxを使い、Dropboxは社内でSalesforceを活用する、という状態にしていく。Salesforcは前にも、G Suiteの統合やOffice 365ツールの統合に際して、同様の発表をしている。

Dropboxは、パートナーシップの発表はIPOと何の関係もない、と言うだろう。でも今や、同社のあらゆることがIPOと関係している。IPO申請のS-1ファイルで、売上の大半が消費者サイドからと言っている同社は、エンタープライズからの信任をできるかぎり厚くしてからIPOに臨みたい。今回のパートナーシップもそのことに寄与するはずだが、まだまだ実際の数字は薄い。

先週のG Suiteの統合パートナーシップと同じく、今回のSalesforceの統合も、まだ発表だけであり、ローンチはない。ローンチはたぶん、今年の後半だろう。

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

IBMのPAIRS Geoscopeは地理空間的/時間的データの大規模データサービス、デベロッパーはクェリするだけ

IBMが今日、PAIRS Geoscopeを発表した。それは、さまざまなソースからの大量の地理空間的データをデベロッパーが容易に扱えるようにする、実験的なクラウドサービスだ。このサービス自身がデータの取り入れや統合化、そして管理を担当し、デベロッパーはもっぱらクェリに集中できる。

というより、このサービスのデータの取り入れとインデクシングの部分が、PAIRS Geoscopeをそのほかのビッグデータ分析サービスとはひと味違うものにしている。取り入れるデータとしては、センサーからの、地理情報タグのついた(geotagged)IoTデータもあれば、天気予報データや国勢調査データ、航空写真、それにTwitterのツイートやGoogleが支援するGDELT Projectからのデータもある。

この膨大なデータサービスの仕組みに関心のある方は、彼らが最近発表したペーパーを読んでみよう。そこには、統合化エンジンについても詳しく書かれている。しかしデベロッパーの視点から見てもっとも重要と思われる機能は、PAIRSがすべてのデータを共通の形式と単位に変換して、すべての空間的データを自動的に整列することだ。

IBMによると、同社はこのサービスを、“スケーラビリティの高い”クラウド上のリポジトリに構築した、それは複雑な地理空間的-時間的情報のために特製したリポジトリだ”、という。デベロッパーはこのサービスにREST APIでアクセスできるが、ほかにWebによるインタフェイスもあり、それを使えばさまざまな層の選択や操作、結合により新しいクェリを作ることも容易にできる。

PAIRS Geoscopeを自分で試してみたい人は、このプロジェクトのホームページへ行ってみよう。現在は、このサービスのリポジトリにある公開データセットのどれでも無料で利用でき、そのやり方もガイドしてくれるから、この種のデータで遊んでみるためには、いちばん容易なツールであるようだ。

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

オープンソースのライブラリのセキュリティチェックと脆弱性フィックスを代行するSnykが$7Mを調達

オープンソースのライブラリはデベロッパーにとってとても重要なリソースだが、今日の慌ただしいアプリケーション開発環境では、それらが安全なコードであるという確信を持つことが容易ではない。そこでSnykは、デベロッパーがオープンソースのコードに脆弱性を見つけて直す作業を支援し、確実に安全なコードがプロダクションのその後の工程で使われるようにする。同社は今日（米国時間3/6）、Boldstart VenturesとCanaan PartnersがリードするシリーズAのラウンドで、700万ドルを調達したことを発表した。

このラウンドには、Heavybit, FundFire, VeeamのPeter McKay、およびそのほか数名の投資家が参加した。同社は2016年に、同じくBoldstartがリードするラウンドにより、300万ドルのシード資金を獲得している。

この種のバグフィックスは、アプリケーションが完成して世に出てからではなく、開発チーム自身がやった方がよい、とSnykのCEOで協同ファウンダーのGuy Podjarnyは信じている。今は開発工程にセキュリティチームがいないやり方が一般的になりつつあるが、そうでない方がよい、と彼は言う。ソフトウェアが何か月も何年もかかって構築されるときはそれでも良いが、しかし今日のような開発スピードでは、デベロッパーチームとは別のセキュリティチームがソフトウェアをチェックするやり方は、合理的でも効率的でもない、とPodjarnyは主張する。

“われわれは開発工程の中へエレガントに統合し、オープンソースの部分に既知の脆弱性を見つけ、それらをフィックスする”、とPodjarnyは説明する。同社はユーザーのGitHubリポジトリの中のコードをモニタするが、サードパーティの企業とソースコードを共有している場合も、どのファイルを使っているのかという“マニフェストファイルにアクセスできれば、われわれの仕事にとってとくに問題はない”、と彼は言う。

同社はインターネットのあちこちから情報を集めて、彼らがモニタしているオープンソースプロジェクトの既知の脆弱性とその特徴を知る。ユーザーが使っているライブラリと、使用している言語（JavaScript, Java, .netなど）が分かれば、今使っているコードが古いバージョンである（かもしれない）ことも分かる。

そしてそれらの脆弱性が見つかったら、そのコードに依存しているものを壊さずに早く効率的にフィックスする方法のアドバイスと共に、プルリクエストを送る。

  1. deep-integrations-into-a-large-and-growing-list-of-platforms.png

  2. detailed-advisories-for-vulnerabilities-in-the-snyk-vulnerability-db.png

  3. detailed-test-reports-with-a-single-click-fix-button.png

 View Slideshow
Exit

PodjarnyはBlaze.ioの協同ファウンダーだったが、同社は2012年にAkamaiに買収された。彼は買収後に、その企業のWeb体験ビジネスのCTOになり、2015年のSnykの立ち上げまでそこに在籍した。

そのときのスタートアップ体験が、ニューヨークのアーリーステージVC Boldstart VenturesのファウンダーでマネージングパートナーEd Simの目にとまった。“彼がAkamaiに売ったスタートアップにもうちは投資したが、彼と彼の協同ファウンダーたちには深いセキュリティ経験があった。また同社(Snyk)は、企業の大きな満たされざるニーズ、すなわちコードを継続的にデプロイしていくときの、オープンソースコードのセキュリティの確保というニーズを、満たすことができた”、とSimは語る。

SnykはまだシリーズAの企業だが、しかし今では月間ダウンロード数が35万もあり、大手の有料ユーザー企業が130社いる。同社は今後、対象とするオープンソースプロジェクトをもっと多くしていきたい、と考えている。また、現在30名の社員を、その倍にしたい。今同社は、テルアビブとロンドンにオフィスがあり、ボストンに小さな営業とサポートのオフィスがある。

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

Dropbox、Googleと提携してG Suiteを正式サポートへ

Drpoboxにとって盛りだくさんな一週間だった。金曜日（米国時間2/23）に同社はついに上場することを発表した。しかし、それだけではなかった。今日（米国時間3/1）同社はGoogleとの提携によって、G SuiteをDropboxに統合すると発表した。

Dropboxユーザーの半数以上がG Suiteアカウントをもっている、という事実がある —— Gmail、Google Drive、Docs、Sheets、Slidesなどだ。これまでG Suiteのファイルを直接Dropboxに保存する方法はなかった。DrpoboxとGoogleという不思議な組み合わせの協業が生まれたのは顧客がそれを望んでいたからだ、とDropboxの技術、製品、デザイン担当SVPのQuentin Clarkは言う。

「Dropboxは顧客が使いたいと思うプラットフォームはなんでも使えるように協業を進めてきた。この提携はその目標に向けたステップのひとつ」とClarkがTechCrunchに話した

Clarkは、過去数年間Dropboxが、Microsoft、Autodesk、Adobeらと提携してきたことを説明した。Googleとの提携で、これまで（目立って）欠けていたコンテンツタイプがサポートされることになる。

両社は現在統合の方法について作業を進めているところだが、今年中には完了する予定だ。完成した暁には、Dropboxの中でG Suiteドキュメントを直接開けるようになる。「統合の結果がどんなルックアンドフィールになるかを両社で検討している」とClarkは言った。

ClarkはかつてMicrosoftとSAPで働いていたことがあり、企業のニーズよりユーザーのニーズに集中することがDropboxのようなメーカーの責任であることを学んだという。オンラインストレージサービスを売る両社が協力する理由はそこにある。「これは最善の組み合わせであり、人はある仕事のためにひとつのプロダクトを使い、別の仕事のためには別のプロダクトをつかうことを結果だ。そのためには平和的な関係を築く必要がある」と彼は言った。

このタイミングはIPOの発表にかなり近いと感じるが、実際には提携にむけた作業はかなり前から進められていた。Dropboxとしては大企業からの評価を高めるためにIPO前に発表したかったところだが、法的に決められた上場前の沈黙期間中は公表できなかった。

なお、これはGoogleがサードパーティーのストレージと提携する初めてのケースではない。Google Cloudの責任者、Dian Greeneは、2016年のBoxworksカンファレンスで、BoxをGoogleコンテンツのストレージパートナーにすると発表した。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

AppleはiCloudのデータをGoogle CloudとAmazon S3に保存している

AppleがiCloudのためにサードパーティーのクラウドサービスを利用していることはよく知られている。そしてCNBCは、Apple自身の文書に興味深い情報があることを発見した。現在Appleは、iCloudデータの保存にAmazon S3およびGoogle Cloudのストレージサービスを使っている。

去る2016年、CRNはAppleがクラウドストレージに関してGoogleと契約を結んだことを報じた。しかし、Appleの文書は初めてこの関係を正式に認めた。

この情報は2018年1月発行のApple iOS 11セキュリティー・ガイドに書かれている。そこにはユーザーのファイルが小さな断片に分割かつ暗号化されて保管されていると説明されている。暗号化キーとメタデータ情報はAppleの自社サーバーに保管される。しかし、暗号化されたファイル自身はサードパーティーのサービスに保管される。

ユーザーは、AmazonやGoogleが自分のiCloudデータを管理しているとは思いもよらないだろうが、暗号化キーがなければAmazonとGoogleはこれらのファイルをどうすることもできない。つまり、AmazonやGoogleにデータを見られる可能性は極めて低い。

「暗号化されたファイルの断片にユーザーを特定できる情報は含まれておらず、S3、Google Cloud Platformなどのサードパーティー製ストレージサービスを利用して保存される」と文書に書かれている。

かつてAppleは、Microsoft Azureとの提携関係に言及したことがある。文書の文言はいまひとつ明確ではない。Appleは名前を出さずに他のサービスも使っているかもしれない。

いずれにせよ、これはいわゆる「非対称競争」の好例だ。AppleとGoogleはスマートフォン市場のシェア争いで非常に激しい戦いを繰り広げているが、AppleはGoogleの顧客でもある。AppleはAmazonやMicrosoftとも別の分野で競合している。したがってAppleがライバルとの関係を完全に断ち切るためには、クラウドホスティングをいっそう強化する必要がありそうだ。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

クラウドアプリケーションのセキュリティとコンプライアンスチェックを自動化するChefのInSpec 2.0

データのリポジトリをAmazonでロックすることを忘れて、機密データを露出した、なんて話を何度聞いたことか。それは、稀（まれ）ではなく、びっくりするほど多い。そこでChefは、devやopsの人びとがそんな事件を防ごうとするときの、お手伝いをしたいと考えた。今日同社がリリースしたInSpec 2.0は、クラウド上でアプリケーションのセキュリティとコンプライアンスを自動化する作業を助ける。

InSpecは無料のオープンソースツールで、開発チームはこれを使ってセキュリティとコンプライアンスのルールをコードで表現できる。前の1.0は、アプリケーションの正しいセットアップに主眼を置いた。今度のバージョンは、その能力を企業がアプリケーションを動かしているクラウドに拡張し、クラウドのセキュリティポリシーに合ったコンプライアンスのルールを書いてテストできるようにした。AWSとAzureをサポートし、Docker, IIS, NGINX, PostgreSQLなどなど30種のよく使われる構成が最初からある。

今日の継続的開発の環境では、複数のアプリケーションを複数のクラウドで動かすことが容易ではない。コンプライアンスを人間が継続的にモニタするためには、データベースを露出したままにしておく方が楽だ。

Chefはこの問題の解決を、コンプライアンスを自動化するツールで助ける。何をロックするかなどについて最初に開発とオペレーションが協議しなければならないが、合意に達したらInSpecを使って、クラウドの構成の正しさをチェックするためのルールを書ける。それには、InSpecのスクリプト言語を使う。

Chefのマーケティング部長Julian Dunnによると、スクリプト言語を使い慣れている人ならとっつきやすいだろう、と言う。“InSpecの言語はクラウドに特有のルールをカスタマイズして書くのに適している。クラウドのデプロイのチェックもね”、と彼は語る。

スクリプト言語の例。コードサンプル提供: Chef

“この言語は、読みやすくて書きやすいことを心がけて設計した。プログラミングの経験はないがスクリプトは書いているセキュリティの技術者が、想定ユーザーだ”、とDunnは言う。スクリプトを書いたら、それを自分のコードに対してテストする。そしてコンプライアンス違反が見つかったら、直す。

InSpecは、VulcanoSecを買収した結果として作れた。このドイツのコンプライアンスとセキュリティ企業をChefが買収したのは、2015年だ。InSpec 2.0はオープンソースで、Githubからダウンロードできる。

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

Googleがサードパーティ製のクラウドソフトウェアをショッピングできるストアを開店

Googleが、企業などの顧客にクラウド上のサードパーティ製ソフトウェアを売るためのデジタルストアを立ち上げる。このニュースを最初に報じたBloombergは、この動きはAmazon Web Servicesなどクラウドの先頭企業集団に、この検索大手が後れを取らないための最近の努力の一環だ、と言っている。

Googleが単独でストアを立ち上げるのではなく、MobileIronとパートナーする。後者は2014年に上場したモバイルのデバイス管理企業だ。この新しいストアに関するGoogleのブログ記事によると、このコラボレーションによって、Google Cloud上のコマースプラットホームOrbiteraに、MobileIronのアプリ配布やセキュリティ、アナリティクスなどの能力が統合される。

Googleによると、このホワイトレーベル方式のサービスには、複数のサービスを顧客の層別に同梱（バンドル）したり、独自のブランドを作ったり、顧客のデバイスやデータやサードパーティのクラウドサービスにアクセスできたり、ユーザーやアプリを限定するセキュリティ、利用状況のアナリティクスなど、いくつかの機能が最初から提供されている。

GoogleがOrbiteraを買収したのは2016年で、そのときは買収価額が1億ドルあまりと言われた。Orbiteraはクラウドベースのソフトウェアを売買するプラットホームを開発したが、Googleによる買収によって、AmazonのAWSやSalesforce, Microsoftなどと競合してクラウド上でエンタープライスサービスを売っていけるように改良された。

Googleのこの新しいイニシアチブにはコンペティターがいる。Bloombergの指摘によると、AT&Tは、ユーザーがVPNで安全に接続できるクラウドサービスを提供している。しかしそれでも、一回のアクセスで容易かつ簡単に多くのクラウドサービス〜クラウドソフトウェアの中から気に入ったものを選べるこのような‘ストア’は、ユーザーにとって便利だろう。あちこちアクセスして探すよりは。

うまく行けば、これはGoogleの新しい強みになるかもしれない。

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