エンタープライズ | SEO-LPO.net

Dropboxの最新アップデートでモバイル上のコラボレーションがとてもスムーズに

Dropboxが今日（米国時間5/22）発表したアップデートで、モバイルからの利用機能が強化され、外回りの社員がDropboxに保存されているファイルの変更に追従しやすくなった。

典型的なユースケースを挙げると、チームで共有しているファイルについて、AさんがBさんの意見や承認を求めている、とする。Bさんがそれをちゃんとやってくれたか知りたいときには、メールやテキストメッセージを使う。これでは、なめらかなワークフローとは言えない。

そこでDropboxの最新のモバイルアプリでは、メールなどほかのアプリを使わなくても、Dropboxアプリの中で、誰がそのファイルを見たか、誰が何をやったか、などが分かる。

またファイルのレビューを求めるときも、通知が相手のホーム画面に出るから、メールなどを見る必要がない。

写真提供: Dropbox

DropboxのプロダクトマネージャーJoey Loiによると、チームメンバーのいろんなアクティビティがDropboxの中ですべて分かるから、すっきりとしたワークフローになる。“今回のアップデートでは、コラボレーションのループがDropbox内で完全に閉じることを考えた。コラボレーションとは要するにフィードバックのフローだから、Dropboxの外へ出なくても最後まですべてのフィードバックができる、ということだ。ぼくがファイルのどこかを変えたら、同僚はすぐにその変更が分かる”、とLoiは説明する。つまり、フィードバックループが閉じるのが早い。ループの形もシンプル。

また今度からは、頻繁に開いているファイルはホーム画面の上部に、Google DriveのRecentsのように出るから、仕事の流れがワンステップ早い。また、頻繁にアクセスするファイルをDropboxのリストの上部に集めることもできる。今の仕事で使っているファイルを、いちいち探さなくてもよい。

そして、メールで送ってきたファイルをドラッグ＆ドロップでDropboxに入れることが、モバイルでもできるようになった。

ひとつひとつはどれも些細な変化だけど、これでモバイルのDropboxでファイルを扱うことが、ずいぶん楽になる。Loiはこう言う: “モバイル上でチームのコラボレーションを円滑にすることに、とくに配慮した”。

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

ParabolaはExcelで苦闘している人々を救う――簡単プログラミング・アプリが220万ドルを調達

最近いわゆる知識労働者の仕事はますます複雑、困難になっている。そうしたタスクの多くはPythonでスクリプトを書けば簡単に実行できる場合が多い。しかし知識労働者の誰もがプログラミング言語を習得しているわけではない。Alex Yaseenはコンピューター言語の知識なしで複雑なタスクが実行できるツールを提供していこうと考えている。

Yaseenは自分が開発しているParabolaのようなツールがプログラミング言語を習得していない知識労働者と複雑なタスクとの間のギャップを埋める役にたつと信じている。プログラミングせずにこうした課題を処理しようとすれば、従来は巨大なExcelシートを作成する必要があった。これに対してParabolaはプログラミングの技能を必要とせずに表計算アプリで複雑な作業する場合に必要となる単調でミスを犯しやすい繰り返しを自動的に実行してくれる。このほど同社はMatrix Partnersがリードする新しいラウンドで220万ドルを調達したと発表した。

YaseenはParabolaについてこう説明している。

理屈からいって将来誰もがPythonその他のプログラミング言語を使うようになるとは思えない。これは間違いないだろう。それと同時に、多くの投資家と話をして、知識労働者間の競争はますます激しくなり、ますます高い効率性を求められるようになるだろうという点で意見が一致した。われわれはこのギャップを埋めるために何ができるかを考え、高度な技術的知識がなくても扱えるツールを提供しようと考えている。いわばエンジニアリングの知識なしにエンジニアになれるようなツールだ。

簡単にいえば Parabolaは複雑なタスクをビジュアルなワークフローに分解し、フローチャートをレゴブロック式に組み立てれば、その内容を実行してくれるようなツールだ。その部品は通常の表計算アプリ、Microsoft ExcelやGoogleスプレッドシートなどが持つのと同様の機能だが、Parabolaの場合、ツールは実行の繰り返しや分岐を簡単に設定できる。また作業をモデル化して全体を見通すことが容易であり、修正にも部品のドラグ・アンド・ドロップで柔軟に対応できる。

Parabolaが想定しているのは財務や販売の専門家で、Excelのシートを数十枚開き、数百ステップのマクロを実行しなければならないような作業を日常行っているユーザーだ。Parabola上で作業をモデル化すれば、あとは表計算シートの仕様による細部の修正などに煩わされることなく、処理が実行できるという。同時にParabolaのユーザー・インターフェイスは表計算をベースにしているので、多くのユーザーに抵抗が少ない。Yaseenによれば、表計算アプリがポピュラーなのは簡単に再計算ができるところが大きいという。

Yassenによれば表計算アプリは大量データの複雑な処理にはもともと向いていない。それでも多くのユーザーが表計算でタスクを実行しようとするのは、一部を修正した後、ワンクリックで即座に結果を見ることができるからだという。「エンジニアでない人々のマインドセットはエンジニアとは異なる。処理の効率性より、試行錯誤してその結果をすぐに見られることを優先する傾向が強い。プログラミング言語はこうした使い方に向いておらず、それが非エンジニア系の人々が表計算アプリを使い続ける理由だ」という。

〔日本版〕トップのGIFビデオにParabolaを利用した作業の流れが例示されている。これによればデータソースとしてDropboxとSalesforceのファイルを選び、テーブル結合、カラム分離、グループ化などの部品で処理した後、結果をGoogleスプレッドシートに出力すると同時にSalesforceに書き戻している。それぞれの部品を追加するときに作動条件を指定している。Parabolaのサイトには各種の実例が掲載されている。

[原文へ]

（翻訳：滑川海彦@Facebook Google+）

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）

デザインスケッチからコードを起こすAIとコンピュータービジョンのUizardが80万ドルを調達

アプリケーションを作る工程には、誰かが描いたスケッチを見つめながらそれをコードに換えていく、面倒で時間のかかる関門がある。でも実際やってることは毎回同じだから、もっと楽にできるやり方があるはずだ。フロントエンドのデザインからHTMLやCSS、そして実働コードを起こしていくこれまでのソフトウェア開発は、費用も時間もかかり、かったるい反復作業が多い。

そしてこの問題を解決する方法の多くが、むしろかえって複雑だったりする。ワイヤーフレームのようなスケッチを単純にコードに換えてくれて、デベロッパーはアプリケーションのもっと難しい部分に集中できる、というやり方はありえないだろうか？

この課題に挑戦したのが、コペンハーゲンのUizardだ。

Uizardはコンピュータービジョンの技術とAIを利用して、ナプキンの裏に描いたようなラフスケッチのデザインを、バックエンドに挿入できるソースコードに換える。

このほど同社は、ニューヨークのLDV Capitalがリードするプレシードのラウンドで、80万ドルを調達した。このラウンドには、ByFounders, The Nordic Web Ventures, 7percent Ventures, New York Venture Partners, 起業家でDatekの協同ファウンダーPeter Stern、Philipp Moehring、AngelListのAndy Chungらが参加した。得られた資金はチームの増員とプロダクトのベータローンチに充てられる。

同社は2017年6月に最初の研究プロジェクト“pix2code”（画素をコードへ）を発表したとき注目を浴び、そのGitHub上の実装は、Facebook PrepackやGoogle TensorFlowの登場よりも前に、第二回mosttrendingプロジェクト賞を取った。

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

Rackspaceが企業のSalesforce導入を助けるRelationEdgeを買収、アプリケーション管理の部門を充実へ

Rackspaceが今日（米国時間5/17）、Salesforceの実装パートナーでデジタルエージェンシーのRelationEdgeを買収したことを発表した。価額など買収の条件は公表されていない。

Rackspaceは今でも多くの人が、ホスティングとマネージドクラウドサービスとIaaSの企業だと思っている。そしてRelationEdgeは、企業がSalesforceのSaaSを実装しようとするとき、それを支援し管理するサービスだ。しかしRackSpaceは近年、業態の多様化に努めており、各種SaaSアプリケーションの管理サービスもそのポートフォリオに含めようとしている。その最初の試みが、昨年のTriCoreの買収で、こちらもやはりエンタープライズのアプリケーション管理を提供する企業だ。本日の買収も、同じ路線上にある。

Rackspace Application ServicesのゼネラルマネージャーGerard Brossardによると、アプリケーション管理サービスに関しては同社はまだ草創期だが、これらの新しい提供物により新たな顧客を獲得しつつあり、既存の顧客もRackspaceにIaaSを超えた管理サービスを求めるようになっている。そして、“これによってSaaSの管理サービスの分野に参入できるし、しかもSalesforceはエンタープライズSaaSのリーダー格だ”、という。

一方、業績も良く、社員が125名もいるRelationEdgeは、なぜ身売りするのか？　RelationEdgeのファウンダーでCEOのMatt Stoykaはこう語る: “まるで木々の自然成長のように、わずかな資金でここまで伸びてきたが、目の前にはもっと大きな機会がある。しかしそれをものにするためには、現状を超えた力が必要だ。つまり社員と企業の両方にとって、正しい新居が必要なのだ”。

彼によると、両社は社風も似ているそうだ。とくに、技術そのものよりも、それが生み出す結果を重視するところが。

当面、RelationEdgeのブランドはそのまま残り、Rackspaceとしても、現状のリーダーシップによる企業の独立性を尊重する、とBrossardは言っている。RelationEdgeのブランドイメージは無視できない、ということだ。

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

現場労働者をハイテク化するParsable、シリーズCで4000万ドルを調達

人工知能、機械学習、ロボットなどのテクノロジーによるオートメーション化が産業労働者の職を奪うという懸念が日々メディアで語られている。これに対してサンフランシスコのスタートアップ、Parsableは別の未来像を考えている。Parsableでは、オートメーション化に取り残されかねない何百万人もの産業労働者にデジタル・テクノロジーを自由に利用できるソリューションを提供しようとしている。

ParsableはConnected Workerと呼ばれるプラットフォームを開発した。これは現在印刷ベースのマニュアルを利用している各種の現場労働者にデスクトップ・パソコンなしで情報テクノロジーの進歩の成果を利用できるようにする。今日（米国時間5/16）、同社はシリーズCのラウンドで4000万ドルのベンチャー資金調達に成功したことを発表した。

今回のラウンドはFuture Fundがリードし、B37やLightspeed Venture Partners、Airbus Ventures、Aramco Venturesなどの既存の投資家も参加した。シリーズCの4000万ドルを加えて同社が調達した資金総額は7000万ドルとなる。

Parsableのプラットフォームはほとんどすべてのスマートフォンとタブレットで利用可能だ。デスクトップ、ノートその他の伝統的パソコンを使うことが不可能な作業環境で、たとえば機械の間を歩きながらでも、労働者はモバイル・デバイスをタップしたりスワイプしたりすることで必要な情報をインプットできる。

写真提供：Parsable

現場労働者はテクノロジーの進歩に追いつくために十分な手立てを与えられてこなかったと同社は考えている。Parsableは2013年に創立されているが、CEOのLawrence Whittleは「われわれは当初からコンピューター・エンジニアが必要と考えるものではなく、産業労働者自身が実際に必要とするプロダクトを作ろうと努めてきた」と語った。ただしこれを実現するためには長期にわたる予備調査が必要だった。

同じ作業を25年も続けてきたベテラン労働者に使ってもらうためには、プロダクトはこれ以上ないほどシンプルである必要がある。同時にテクノロジーを利用する度合いがもっと高い若い労働者にも違和感を抱かせないものでなければならない。つまりFacebookやSMSのような親しみやすいユーザー・インーフェイスが必要だと判明した。

Whittleの説明によれば「われわれは紙ベースのマニュアルやメモ帳の代わりに、さらに高機能、高効率でしかも事故を防止するなど安全面でも優れたデジタル版を提供しようとしている」という。

Whittleはこの努力を機械にセンサーを取り付けて機能をアップさせることに例えた。ただしParsableの場合は、新たな能力は機械ではなく労働者に付加される。「われわれはセンサーやインターネットへの接続能力を機械ではなく労働者に付与して仕事の効率化を図る」という。

同社はプラットフォームに柔軟性をもたせ、テクノロジーの進歩に合わせて新しい機能を追加できる仕組みにしている。たとえば、Pasableプラットフォームはスマートメガネをサポートしており、Whittleによればこれはプラットフォームの作業の10%を占めるまでになっている。テクノロジーがどのように進歩するかは予測不可能なため、新しいテクノロジーが現れた時点でそれを取り入れることができる柔軟性がプラットフォームには必須だという。

現在Parsableには30社の大企業ユーザーがあり、3万人がプラットフォームに登録している。ユーザーにはEcolab、Schlumberger、Silgan、Shellなどの著名企業が含まれる。同社の社員は現在80名前後だが今年の第3四半期末までには100になるとWhittleは語った。

画像：タブレットを利用してオートメーションの状態をチェックする女性エンジニア　Getty Images

[原文へ]

（翻訳：滑川海彦@Facebook Google+）

リアルタイムデータベースのMemSQLが$30Mを調達、毎秒1兆レコードののスキャンを誇る

リアルタイムデータベースのMemSQLが今日、シリーズDで3000万ドルを調達したことを発表した。これで同社の調達総額は1億1000万ドルになる。このラウンドをリードしたのはGV（元Google Ventures）とGlynn Capitalで、これまでの投資家Accell, Caffeinated Capital, Data Collective, およびIA Venturesも参加した。

MemSQLデータベースは分散リレーショナルデータベースで、標準的なSQLドライバーとクェリを実装し、それらによるトランザクションとアナリティクスをサポートしている。それは、データの取り入れ技術がとくに優れているとされ、1日に数百万のイベントをプッシュできると同時に、レコードをリアルタイムでクェリできる。同社が最近示したところによると、12のサーバーにまたがるクラスター上の1兆あまりの列を1秒でスキャンできた。

このデータベースは、大手のパブリッククラウド上やオンプレミスでデプロイできる。

MemSQLの最近の発表によると、今期第四四半期の登録ユーザー数は前年同期比で200%増加した。これは投資家を喜ばせる数字だが、しかしこの市場は競争が厳しく、多数の強力な古顔たちのほかに、スタートアップやオープンソースのプロジェクトも少なくない。現在のMemSQLのユーザーには、Uber, Akamai, Pinterest, Dell EMC, Comcastなどがいる。

GVのゼネラルパートナーAdam Ghobarahは、今日（米国時間5/15）の発表声明でこう述べている: “MemSQLは大規模かつ高速なオペレーショナルアナリシスを提供でき、動的でインテリジェントなアプリケーションを作れるため、エンタープライズ系のユーザーが増えている。同社はエンタープライズ顧客の増加とともに、数字で明確に表せるほどの成功を収めつつあり、継続的にスケールしている同社に投資できることは喜ばしい”。

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

Google Compute Engineに最大3844GBのバーチャルマシン登場

ときおり「もっとRAMが必要だ」という状況に出くわす。メモリーを大食いする巨大エンタープライズ・アプリ、たとえばSAPのHANAデータベースなどを運用しているときだ。非常に高いパフォーマンスを必要するタスクを実行するときもそうだ。これまでGoogleのクラウド・プラットフォームでCompute Engineを利用する際の最大メモリー割当は624GBだった。しかし今日（米国時間5/15）、メモリー割当の大幅拡大が公式ブログで発表された。新たに導入されたクラスでは最大160台のバーチャルコアに3844GBを割り当てることができる。

新しいクラスはn1-ultramemと名付けられ、既存のn1-megamemクラスの一員となる。n1-ultramemはコアの数によって3種類に分けられている。もちろん高いパフォーマンスを得るにはそれなりのコストが必要だ。いちばん「低い」バージョン、40コア、938GB RAMの場合は月額3221ドルだ。トップエンドの160コア、3844GBのバージョンとなると月額1万2885ドルとなる。

1時間当たりの料金表を下にエンベッドした。

これらの新しいバーチャルマシンの投入でGoogleもハイパフォーマンスのクラウド・コンピューティング市場でAWSプラットフォームと互角にわたりあえるようになった。実際GoogleのほうがAWSよりコンピューティング・パワーがわずかに強力だ。これは新しいプロセッサーを用いており、コアの数自体も多いためだ。

Googleは、当然ながら、n1-ultramemの典型的なユースケースとしてSAP HANAを挙げている。公式ブログには「クラウドへの移行をためらっている理由が、現在社内で実行しているSAP HANAデータベースのインスタンスをロードできるほど大容量のクラウド・メモリーが見当たらなかったからだとすれば、われわれのCompute Engineをチェックしていただきたい。アプリケーションが次々にクラウドに移行する中、データベースだけをオンプレミスで運用しなければならない理由はなくなった」と書かれている。

新しいultramemマシンが利用できるリージョンは現在、us-central1、 us-east1、europe-west1だが、今後さらに拡大される。

[原文へ]

（翻訳：滑川海彦@Facebook Google+）

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）

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）

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

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

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

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

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

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

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

container-inspect
container-list
dashboard

View Slideshow

Previous Next Exit

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

[原文へ]
（翻訳：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）

Dropbox創業者ドリュー・ハウストン、9月のDisrupt SFで思いを語る

Dropboxは5億人以上の人々にとって欠くことのできない重要なツールとなった。われわれがファウンダー・CEOであるDrew HoustonをTechCrunch Disruptのステージに迎えることに興奮しているのはそれが理由だ

Dropboxがスタートしたのは2007年のことで、Houstonはこの10年間でDropboxを今日の巨人へと育て上げた。

その間、Houstonはいくつもの厳しい決断を下してきた。

数年前、HoustonはDropboxのインフラストラクチャーをAWSから移動する決断を下した。2014年、Houstonは当時上場を検討していたBoxに遅れをとらないために5億ドルを負債による融資で資金調達した。そして2017年3月、DropboxはJP Morganからさらに6000万ドルの負債による資金調達を実施した。

Houstonは、Appleからの9桁（1億ドル以上）の買収を断ったとも報じられている。

その間ずっと、HoustonはDropboxをプラスのキャッシュフローへと導き、昨年には年間売上予測10億ドルを見据える会社へと成長させた。

そしてもちろん、今年の株式上場を果たすことになった決断を忘れることはできない。

Houstonが初めてTechCrunch読者の前で自分について話したのは2008年のTC50で、スタートアップバトルフィールドの中だった。そのTC50でHoustonが話したときのビデオがここにある。

来る9月のDisrupt San Franciscoでは、Houstonを迎えてここまでの道のりや株式公開の決断、そしてDropboxの将来について話してもうのがたのしみだ。

ショウは9月5日から7日まで開催される。スーパー早割チケットはまだ買うことができる！

[原文へ]

（翻訳：Nob Takahashi / facebook ）

Google Cloudのマネージドデータベースサービスがクラウドサービスとしての機能を充実

Googleがクラウドから提供しているデータベースが今日（米国時間4/25）、アップデートされた。画期的な新製品に生まれ変わったわけではないけど、それらのアップデートはすべて、企業がクラウドへ移行するときに経験するさまざまな痛点に対処している。

Googleのプロダクト管理のディレクターDominic Preussによると、Googleは長年、データベースの世界における思想のリーダーを自負している。思想のリーダーとは言ってもこれまでは、Bigtableに関するペーパーなどが主で、実際の製品で示す思想ではなかった。しかし最近では、グローバル分散データベースCloud Spannerが示すように、市場でもその姿が目立つようになった。

Preussによると、Googleのエンタープライズユーザーは彼らの既存のワークロードをクラウドへ移すことから始めるところが多い。しかしそれが一巡したら、新しいアプリケーションをクラウドに載せようとする。そしてそのとき求めるのが、クラウドのプロバイダーがアプリケーションやインフラの管理を肩代わりしてくれる、いわゆるマネージドサービスだ。

今日の発表も、エンタープライズに、彼らが求めるある種のマネージドデータベースサービスを提供していくことがメインのテーマだ。

まずそれは、ベータでローンチされるCloud Memorystore for Redisだ。これは完全に管理されるインメモリのデータストアで、大きなバッファリングをインメモリのキャッシュでやりたい、などのニーズに応える。

ビッグデータワークロード用のNoSQLデータベースサービスCloud Bigtableに、新しい機能が加わった。その、いずれregional replication（リージョナルレプリケーション）という正式名で呼ばれることになる機能は、オンプレミスのワークロードにApache Cassandraを使っていたエンタープライズに、Google Cloudにおけるその代替系を与える。そして、この、異なるゾーンにまたがるレプリケーションにより、Google Cloudに保存するデータの可用性と耐久性が高くなる。

今回のアップデートには、Cloud SQL for PostgreSQLのSLAにおける可用性を99.95%にすることも含まれる。またCloud Spannerには、コミットのタイムスタンプがつく。

Googleのクラウドデータベース周辺には、今後どんな新メンバーが登場するのか。Preussはその答を言わないが、今同社はエンタープライズができるだけ多くのワークロードをクラウドへ移行できるようにしたい、と考えているそうだ。つまり、マネージドサービスが今後も増える、ということだろう。

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

HeptioがKubernetesとOpenStack用のロードバランサーをオープンソースでローンチ

Heptioは、コンテナのエコシステムの中でおもしろい企業のひとつだ。まず同社は、Kubernetesを作った三人の技術者のうちの二人、Craig McLuckieとJoe Bedaが作った企業だ。しかしそれだけでなく、同社が開発している技術と、これまで調達した巨額の資金も、注目に値する。

同社の今日（米国時間4/23）の発表によれば、2018年第一四半期の売上は前四半期比で140%増加した。さらにまた、社員数は2017年の初めに比べて4倍に増加した。元の数の発表がないから、これらが実際にどれだけすごいことかよく分からないが、なにしろ同社が好調で、今急成長中のKubernetesのエコシステムに自分の足場をしっかり築きつつあることは分かる。

これらの数字の発表と並んで同社は今日、新しいオープンソースプロジェクトのローンチを発表した。それは、クラスターリカバリツールArkや、KubernetesのクラスターモニタリングツールSonobuoyなど、同社の既存のツール集合に、新たに加わるものだ。

そのHeptio Gimbalと呼ばれる新しいツールは、そのユースケースが非常に特殊で、少数のユーザーにしか関心がないと思われるが、でも彼らにとってはライフラインだ。GimbalはYahoo Japaの子会社Actapioとの共同開発で、エンタープライズがトラフィックをKubernetesのクラスターやOpenStackのデプロイへルートするタスクを助ける。多くのエンタープライズが今ではこれらの技術を並列で動かしていて、一部はOpenStackを超えてもっとKubernetes中心のアーキテクチャへ移行しつつあるが、でもOpenStackへのこれまでの投資の成果を今すぐ完全に捨て去る気はない。

ActapioのCEO Norifumi Matsuyaはこう述べている: “われわれがHeptioにアプローチしたのは、OpenStackなどのバックエンドシステムへのこれまでの投資を無駄にすることなく、自分たちのインフラストラクチャをKubernetesで現代化したかったからだ。アプリケーションを大きなスケールでデリバリすることが、うちのビジネスにとってもっとも重要だ。そのためには、より高速なサービスディスカバリーと、即時のロールバックとパフォーマンスの測定を可能とするカナリア分析を伴う、デプロイメント能力が必要だった。Gimbalはわが社のデベロッパーたちに、これらのチャレンジへの対応能力を与え、彼らの生産性を上げるとともに、システムのパフォーマンスを最適化する”。

GimbalはHeptioの既存のオープンソースツールの多くを利用し、またCloud Native Computing Foundationのクラウドネイティブプロジェクト群の一つであるEnvoyプロキシも使っている。今のところGimbalは、OpenStackの2016年のMitakaリリースのみサポートしているが、今後はVMwareやEC2もサポートしていく予定だ。

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

Pivotal Software、IPO初日は5%高、5.55億ドルを調達

株式市場の投資家たちは、金曜日（米国時間4/20）にデビューを飾ったPivotalSoftwareに対してどっちつかずの反応を示した。IPO価格15ドルでスタートした同社は15.73ドルで引けた。

実際新たな投資家にとっての急騰は起こらず、提示された価格幅の中間程度の株価でPivotal調達した金額は5.55億ドルだった。同社の時価総額は30億ドルを超えた。

大企業向けクラウドサービスを提供する同社は、その過半数をDellが所有している。これは2016年にDellがEMCを買収した結果だ。Pivotalは2012年にEMCとVMWareからスピンオフした。

その後、17億ドルの資金をMicrosoft, FordおよびGeneral Electric

から調達した。

S-1申請書には同社の事業が以下のように記載されている。

Pivotalは「最高水準のクラウドネイティブなプラットフォームを提供し、当社顧客のソフトウェア開発とIT運用に戦略的優位性を与える」ことを目標としている。当社のクラウドネイティブプラットフォームである Pivotal Cloud Foundry (‘PCF’)は、新しいクラウドネイティブアプリケーションあるいは既存アプリケーションの改訂にともなう開発、運営の複雑さを減らすことで、ソフトウェア開発を加速させる。

申請書類によると、Pivotは2月締めの会計年度で売上5億940万ドルだった。これは前年の4億1630万ドル、前々年の2億8090万ドルから上昇している。

しかし同社は未だに大きな損失を出している。2018年度の損失は1億6350万ドルで、2017年の2億3250万ドル、2016年の2億8250万ドル、から改善されている。

「多くの損失があり、安定した利益を維持するのに十分な売上は得られないかもしれない」と、 IPO申請の必須項目である「リスク因子」の項目で同社は警告している。

Pivotalは、IBM、Oracleといったインフラストラクチャーおよびミドルウェアの伝統的ベンダーと競合することも認めている。さらに、RedHatなどの企業が提供する「オープンソースに基づく製品」とも競合すると同社は書いている。そのほかPivotalは、SAP Clude Platform、Amazon Web ServiceおよびMicrosoft Azureなどのからの挑戦も受ける。

Pivotalは、強力なセキュリティーと使いやすいプラットフォームで差別化すると信じている。また、ブランド認知度が高く評判も良いとも言っている。同社は米国特許を118件所有、73件出願中であり、革新的な企業であり続けると断言する。

Morgan StanleyとGoldman Sachsが引受会社となり、Davis PolkおよびFenwick & Westが法律顧問を務めた。

同社はニュヨーク証券取引所に上場され、銘柄記号は “PVTL” となる。

低調だった冬のあと、この春はIT企業のIPOが盛んだった。Dropbox、Spotify、およびZuoraがここ数週間で上場した。DocuSign、Smartsheet、Carbon Black、およびPluralsightの各社は来月中にデビューが予定されている。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

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にもある。

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

cloud.govの公式参加でアメリカ政府省庁のCloud Foundryの採用が容易になった

ボストンで行われたCloud Foundry Summitで、アメリカ政府のアプリケーションプラットホームcloud.govがCloud Foundryの公認プラットホームになり、そのほかの公認プロバイダー、IBM, Pivotal, SAP, そして今日からはSUSEなどとの互換性が保証される、と発表された。これによりcloud.govは、初めてのCloud Foundry公認政府機関になる。

この認定により、Cloud Foundryをサポートするさまざまなプラットホームのすべてが、お互いの互換性を確実に保証される。政府という文脈ではこれは、省庁が容易に彼らのワークロードを複数のクラウド間で移動できることを意味する（それらのクラウドがすべてに政府の証明があるとして）。しかしさらに重要と思われるのは、スキルのポータビリティが確実になることだ。それにより、コントラクター（政府下請）の起用や選択も容易になる。オープンソースのCloud Foundryは民間セクターでも広く採用され、Fortune 500社の半分は利用しているから、アプリケーションを構築するプラットホームを決めるときも、そのことが重要な要素になる場合が多い。

cloud.govは、General Services Administration（米国総務庁）の18階オフィス(18F)が、アメリカ政府の公開Webサイトやアプリケーションを改良するために立ち上げたサイトで、最初からCloud Foundryの上に構築されている。オーストラリアとイギリスの類似省庁も、同じ決定によりCloud Foundryプラットホームに標準化している。Cloud Foundryが認定事業を始めたのは数年前だが、昨年は個々のデベロッパーのスキルを認定するための事業を立ち上げた。

政府のワークロードを動かせるためには、そのクラウドプラットホームは一定のセキュリティ要件を満たす必要がある。Cloud Foundry FoundationのCTO Chip Childersによると、18Fがcloud.govのためにFedRAMPの認可でやった仕事が、アップストリームのプロジェクトのより良いコントロールに役立っている。そして彼は、このプラットホームを採用した政府のすべてが、そのすべてのプロジェクトに貢献してきた、と強調した。

〔参考: Cloud Foundry Wikipedia（日本語Wikipedia）〕

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

アプリケーションにチャット（会話）機能をつける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）

FargateによってAWSはコンテナをもっとクラウドネイティブにしたい（Kubernetesなどのインフラを完全抽象化）

AWSのデベロッパーカンファレンスre:Inventは、たくさんの発表があるので、同社自身の重要な新製品の、影が薄くなってしまうこともある。同社の待望のElastic Container Service for Kubernetesはかなり大きく報道されたが、より斬新なコンテナサービスであるFargateのローンチは今もまだ、あまり知られていない。

今週たまたま会う機会があったAmazonのCTOでAWS担当VP（そしてEDMの熱心なファン） Werner Vogelsも、それを認める。彼曰く、“Fargateはそのほかの発表の下に埋もれてしまったようだ。しかしそれは、コンテナをもっとクラウドネイティブにするための重要なステップだと思うし、すでにかなりの数の顧客がFargateを採用している。”

Fargateは、AWSのコンテナサービス、Elastic Container Service(ECS)やElastic Kubernetes Service(EKS)のために、コンテナを動かすためのインフラストラクチャを抽象化する技術だ。ユーザーはコンテナオーケストレーションエンジンを指定するだけで、あとのことはこのサービスがやってくれる。個々のサーバーやクラスターをユーザーが管理する必要はない。むしろユーザーは単純に、ECSやEKSに、Fargateでコンテナをローンチすると告げ、そのアプリケーションのCPUとメモリの要求を定義し、あとはサービスにまかせる。

Fargateに関する長いブログ記事を今日（米国時間4/11）発表したVogelsにとってこのサービスは、デベロッパーが、インフラを気にせずに自分のアプリケーションだけに集中できるようにするというAWSのミッションの一環だ。彼曰く“クラウドの初期のころを、よく思い出す。AWSが登場するまでは、クラウドから仮想マシンを提供するサービスしかなかったんだ。多くの企業がそれを利用してビジネスを築き成功させてきたが、でも仮想マシンを動かすときには、依然としてハードウェアを管理しなければならない。[…] われわれがAWSのクラウドコンピューティングサービスの中核であるECSをかつて導入したときに起きたことの一つは、いろんなものをハードウェアから切り離してしまったことだ。[…]それによってデベロッパーの生産性は、ものすごく上がったと思うね”。

しかしAWSやECSの上でコンテナを動かそうとすると、初期のコンテナツールでは、コンテナを実際に動かすこととは無関係な多くのことを、やらなければならなかった。“それは、クラウドの初期と同じだ”、とVogelsは語る。“仮想マシンがコンテナにとってのハードウェアになってしまっている。デベロッパーはコンテナのオーケストレーションのために、VMを相手に大量の作業をしなければならない”。

しかしAmazonの顧客が求めるのは単純に自分のコンテナを動かすことだけだ。Vogelsの言う“ハードウェアに直接触（さわ）るような管理作業”なんか、やりたくない。“それはまるで、クラウド以前の時代に戻ったみたいだ”、とVogelsは述べ、そして今日のブログ記事では、“コンテナのオーケストレーションは、あまりクラウドネイティブではない、といつも感じていた”、と言っている。

Vogelsは、インフラストラクチャを気にしなければならないならそれはクラウドネイティブではない、と考えているようだ。彼によると、AWSの最初の約束は、インフラストラクチャに関してはAWSが面倒見るからデベロッパーはビジネスにとって重要なことだけに専念すればよい、というものだった。その哲学をさらに徹底したサービスがFargateであり、Lambdaだろう。

ECSやEKSのようなクラウドサービスがあっても、クラスターはまだ完全に自動的に動くわけではなくて、つねに必要とはしない能力や容量でも、ユーザー自身が確保（プロビジョニング）しなければならない。Fargateの約束は、そのようなスケーリングを自動化し、ユーザーは実際に必要とする能力と容量だけに支払えばよい、という状態にすることだ。

Vogelsはこう言う: “顧客は、ソフトウェアを作りたいだけだし、自分のアプリケーションを作りたいだけだ。このコンテナをどの仮想マシンに置くか、なんてことで悩みたくはない。でも今は、デベロッパーがそれをやっている。Fargateがあれば、ユーザーはタスクに対するCPUのタイプを指定するだけで、スケーリングは自動的に行われる。実際に使う能力容量に対してだけ、支払えばよいのだ”。

インフラの抽象化という点では、Fargateはコンテナのためにそれをやるのだが、AWS Lambdaのようなプロダクトはもっと徹底している。それは Vogelsにとってはひとつの連続体であり、顧客の要望が生んだものだ。今のAWSはコンテナをきわめて重視しているが、彼の現実的な見方によれば、近未来がコンテナ一色に塗りつぶされてしまうわけではなくて、VMを必要とする開発ニーズも残る、VMはなくならない、という。

Lambdaのようなサーバーレスのプロダクトでは、インフラストラクチャのことをまったく考える必要がない。コンテナのことすらも。ユーザーはただ単に、やりたい処理を指定するだけだ。そしてそのコードの実行に対して支払う。しかもVogelsの視界の中では、VMとコンテナとサーバーレスは一つの連続体の各部だ。顧客は、そのどれからどれへ移行してもよい。彼によると、今ではコンテナを完全に飛び越えて、何もかもサーバーレスで行くエンタープライズも見かけるようになった、という。

〔関連記事: 昨年のre:InventにおけるFargateの発表〕

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

container-inspect

container-list

dashboard