フランスのクラウドプラットホームもGPUインスタンスでデータ指向ユーザー狙う

フランスのClever Cloudは、PaaS(Platform as a Service)タイプのクラウドホスティングサービスだ。同社は米国時間7月4日、機械学習のためのGPUインスタンスをローンチし、それをClever Gridという新しいブランド名で提供することになった。。

同社が使用するGPUはNvidiaのGeForce GTX 1070、分単位で課金される。最もベーシックなインスタンスが1時間0.42ユーロ(約51円)、1日10ユーロ(約1200円)、1か月300ユーロ(約36500円)だ。このお値段でメモリー6GB、8コアCPU、1GPU、ストレージ250GBを使える。

もちろん仕様アップは可能で、GPUインスタンスの最大仕様はメモリー60GB、32コアCPU、4GPUとなる。その料金は、月額1200ユーロ(約14万6000円)だ。

Screen Shot 2019 07 04 at 6.59.39 PM

クラウドインフラストラクチャについてあまりよく知らない、データサイエンティストなどのユーザーのためにClever Cloudは、インフラストラクチャの管理をできるだけ抽象化している。ユーザーは自分のPythonコードをWebインタフェイスから自分のクラウドインスタンスの上で直接実行できる。

GPUインスタンスはTensorflowやscikit-learn、CUDA、Keras、pytorchなどをサポートしている。GPUインスタンスの上でDockerのコンテナを動かせる。

Clever CloudはGitHubのリポジトリを直接統合しているから便利だ。自分のGitHubアカウントにコネクトして、そのリポジトリでクラウドのインスタンスをスタートできる。するとユーザーのコードがサーバー上でデプロイし実行される。

そんなシームレスなデプロイに加えて、Clever Cloudにはモニタリングやバックアップ、セキュリティアップデートなど、ユーザーのサービスが円滑に動くための、ユーザー環境の脇を固める機能がいろいろある。

Clever Cloudのクライアントには、Airbus(エアバス)、MAIF、Compte Nickel、Sogeti、South African Ministry of Health(南アフリカ保健省)などが名を連ねる。

Clever Grid

[原文へ]

(翻訳: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

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

ボストンで行われたCloud Foundry Summitで、アメリカ政府のアプリケーションプラットホームcloud.govCloud 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

Red HatのコンテナプラットホームOpenShiftのアップデートに外部サービスへの接続インタフェイスを導入

Red Hatが今日(米国時間8/9)、OpenShiftプラットホームの今四半期のアップデートをリリースし、社内や社外のさまざまなサービスへの接続を作る機能、Service Catalogを新たに加えた。

OpenShiftは、KubernetesDockerをベースとするPaaSで、コンテナのスタンダードとしてOpen Container Initiativeを採用している。KubernetesはGoogleで開発されたコンテナ管理プラットホーム、Dockeは広く使われているコンテナ作成プラットホームだ。

企業が仮想マシンからコンテナへ移行していくに伴い、OpenShiftのようなコンテナデプロイプラットホームのニーズがますます高まっている。そして今やRed Hatの顧客の中には、Deutsche Bank, Volvo, United Healthのような有名大企業もいる。

Red HatでOpenShiftを担当するプロダクトマネージャーJoe Fernandesによると、コンテナへ移行しようとする企業は最近ますます多くなり、すべての企業が何らかの形でコンテナの採用を目指していると言っても過言ではない。今では“いちいち表に書ききれないほど多い”、と彼は言う。

同社の、コンテナを利用する顧客ベースの増大とともに、大企業のIT部門の現実的なニーズを満たす、コンテナ化アプリケーションの展開プラットホームが重要になっている。とくに最近よく聞くニーズは、コンテナ化したアプリケーションが社内や外部のサービスに容易に接続できるようにしてほしい、という要望だ。

Service Catalogは、アプリケーションストアみたいな機能で、デベロッパーがそこへ行って構成済みのコネクターを見つけ、それらをサービスへのインタフェイスとして利用する。それは会社のOracleデータベースへのコネクターのこともあれば、AWSやAzureのようなパブリッククラウド、すなわち社外的サービスへのコネクターのこともある。Fernandesによると、アプリケーションストアの比喩は適切だが、今のところ正規の調達の手順は組み込まれていない。それが今後の課題だ、という。

これまでも、顧客がサービスへの接続を自作できたが、それには大量の作業を要した。ユーザーの面倒な作業を要しない、パッケージ化されたやり方でないと、時間と労力を取られすぎる。

そのために登場したService Catalogは、今回のリリースではテクニカルプレビューだ。次のリリースは、今年の終わりになる。

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

GoogleがオープンソースのSaaS、Cloud Foundry Foundationのゴールド・スポンサーになる

MOUNTAIN VIEW, CA - SEPTEMBER 02:  The new Google logo is displayed on a sign outside of the Google headquarters on September 2, 2015 in Mountain View, California.  Google has made the most dramatic change to their logo since 1999 and have replaced their signature serif font with a new typeface called Product Sans.  (Photo by Justin Sullivan/Getty Images)

GoogleがCloud Foundry Foundationにゴールド会員として参加する。しかしGoogleは最近、この財団の元CEO Sam Ramjiを社員に迎えたぐらいだから、参加自体はそれほど大きなニュースでもない。

Cloud Foundryのゴールド会員にはほかに、Accenture, Allstate, CenturyLink, Huawai, Phillips, Verizonなどがいる。しかしGoogleはCisco, IBM, SAPなどのように、大型のスポンサーを意味する最高ランクのプラチナ会員にはならなかった。

Google CloudのVP Brian Stevensが発表声明の中で言っている: “Google Cloud Platformは最初からすべてのデベロッパーと企業にとって等しく一様にもっともオープンなクラウドサービスであることを目標としている。Google Cloud Platformは、彼らが立派なソフトウェアを容易に構築して動かすことのできるプラットホームでありたい。そのための努力の重要な部分のひとつが、オープンソースコミュニティの活発なメンバーとして、デベロッパーと直接的に協働していくことである…それが世界中のどこの、新興スタートアップであれ、あるいは大企業のデベロッパーであれ、分けへだてなく”。

多くの点でCloud Foundryは、OpenStackというInfrastructure-as-a-Service(IaaS)に対して、それらのインフラをベースとするPlatform-as-a-Service(PaaS)という性格を持つ(GoogleはOpenStackのスポンサーでもある)。StevensによるとGoogleは、加盟する前からCloud Foundryのコミュニティとはすでに密接に協働しており、Google Cloud Platformの上でCloud Foundryを利用できるようにしている。また同社のハイブリッドモニタリングソリューションStackdriverをはじめ、一部のクラウドサービスも、Cloud Foundryを統合している。

Cloud Foundryのユーザーが自分の好きなクラウドプラットホームを使うことを、もちろんGoogleは妨げるものではないが、でも彼らの多くが有力大企業なので、Googleの今後の営業努力の対象にはなる。Sam Ramjiを迎えたからには、近い将来きっと、Google/Cloud Foundry関連のニュースを私たちは見ることになるだろう。

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

開発・デバッグ、数百デバイスへの反映も一発、HerokuのようなIoT PaaS「Isaax」が登場

PaaSやBaaSの便利さは、Web開発者なら誰でも知っているだろう。特にプロトタイピングのとき、自分でサーバーを立てたりデータベースの設定など準備が不要というのは開発のハードルを大いに下げてくれる。コードをクラウドに投げれば即プロダクトが動き出す。おっと表示が崩れてるのはバグだ、修正、修正っと、またコードを手元で修正してプッシュすれば、これまた即サービスに反映される。Salesforceに巨額買収されたHerokuのようなPaaSは実に素晴らしいものだ。

ではIoTのサービス開発はどうか。

PaaSやIaaSがあるさ、オッケー、オッケー。バックエンドはNode.jsでもRailsでもいいね? でも、デバイスの管理とか認証、ハートビートとかどうするんだっけ? ていうか、数十台とか数百台単位でデバイスが広まったときのソフトウェアのアップデートって、何を使えばいいんだっけ?

そんな課題を解決する日本のスタートアップ企業、XSHELLが今日、IoT向けのプラットフォームサービス「Isaax」(アイザックス)をベータ版として公開した。同時に、グローバル・ブレインISID(電通国際情報サービス)に対して第三者割当増資を実施したことを発表した。実際の投資タイミングは2015年末と2016年8月の2度に分かれているが、2社合わせて総額8000万円のシード投資ということになる。

ISIDは最近Fintech関連のイベントのFIBCや、大手町のFintech拠点であるFino Labなどスタートアップ企業への投資や協業で知っている読者も多いと思うが、純粋なエンジニアリング方面での投資はめずらしい。金融システムや電通グループ向けシステムのほか、自動車産業向けのシステムなども手がけていることから、ISIDとしてはIoT時代への布石という意味合いもあるようだ。

xshell01

左からグローバル・ブレインの熊倉次郎氏(パートナー)、XSHELL共同創業者でCEOの瀬戸山七海氏、同COOのベセディン・ドミトリ氏

開封から15分以内でSlack温度計を実装、その場で投資決定

XSHELLを創業したのは慶應SFCに通っていた現在25歳の瀬戸山七海氏だ。情報系の学部在学中に起業して、複数デバイスの協調動作を取り入れたパワードスーツの開発をしていた。3体のパワードスーツが協調動作すれば、非常に重たい物体を持ち上げるときに多地点測量して重心を推定するなど、これまでにない価値が生み出せるのでは、と考えたそうだ。実際には安定した低遅延無線ネットワークを前提にすることができないためにリアルタイム処理は難しく、このアイデアはうまくプロダクトに結びつかなかった。このときの経験からIsaaxのアイデアにたどり着いたという。

Isaaxの説明の前に面白いエピソードを1つ。今回の投資を担当するグローバル・ブレインのパートナーでベンチャーキャピタリストの熊倉次郎氏がTechCrunch Japanの取材に対して語った投資の意思決定に関してだ。

デジタル温度計で室温を測り、それをSlackでつぶやく―、そんな良くあるIoTの習作のような成果物を投資家たちの前でピッチする15分間で実装できたら投資しようじゃないか、となった。瀬戸山氏は未開封のIntel Edisonのパッケージを開けるところから始めて、実際にSlackへ温度を投げるコードを15分足らずで完成。IoT開発の速度を上げるというバリュープロポジションに対して、実践デモで説得したそうだ。「誰も投資に反対とは言えませんでしたね(笑)」(グローバル・ブレイン熊倉氏)と投資の意思決定が行われたという。

さすがに自分が慣れた開発環境なら、たいていのものは15分でプロトタイプを完成させるライブコーディングくらいできるだろうとも思うが、興味深い話ではある。

CLIのコマンド一発で複数デバイスにコードを反映

Isaxx(アイザックスと読む、もう1度念のため。この記事中4度めの登場だけど)は、Herokuに似ている。Go言語で書かれたコマンドラインツールがあって、そのサブコマンドを使うことで、まずベースとなるコードの雛形を生成し、その後デバイスとクラウドに対して必要なコードを一発で転送できる。

「フルスタックエンジニア」という、それが何を指していて実際に生存が確認されているのかも良く分からない謎の言葉が生まれて久しい。ハードウェアやシステムに近いプログラミングから、モバイル、フロントエンドなど、あらゆるプログラミング言語や技術トレンドに精通していて、サービス全体を1人で実装できるエンジニアのことだ。

XSHELL瀬戸山氏は、IoT分野でそんなスーパーハッカーはほぼ存在しないという。

「IoT実証実験のコストは60%がソフトウェア開発だと言われています。IoTの開発にはデータ処理や認証技術、センサー、WAN、セキュリティー、製造管理などの知識が必要です。IoT検定というのがあるのですが、全部で19項目の知識が必要です。Wantedlyの全てのスキルセットを持つ人を検索すると60万人の登録中19項目全てのスキルセットを持つ人はゼロです。IsaxxではJavaScript、Python、Ruby、PHP、Golang、C++のいずれかの言語の1つが使えれば、デバイスのアプリも含めて開発、デバッグ、ローンチ後のアップデートなどが可能です」

リリース直前のMac版IsaxxのCLIツールをTechCrunch Japan編集部でダウンロードしてみたところ、サブコマンドとして「app show/create/delete」、「device show/init/config」、「cloud cluster/project/device/login/logout/quick」などが利用可能となっていた。例えばデバイス初期化コマンドを発行すると、デバイスの種類を聞かれ、デバイス側に常駐させるデーモンのバイナリイメージをネットからダウンロードし、これがデバイスに転送されるという流れ。クラウド操作のサブコマンドとしては、さらに「cluster create/register/deregister/list/status/delete」などがある。

xshell02

IsaxxはMIPS系も含めてLinuxが稼働するモジュール、RaspberryPi、Intel Edison、Onion Omega、Pocket CHIPなどが使える。Arduinoに対応しないのかという質問に対して瀬戸山氏は「今は1980年代に似ています。当時オープンシステム、専用機、汎用機が戦っていました。IoTも同じで、5〜8ドルのLinuxが主流になっていくと見ています」と説明する。

ハードの世界にウェブアプリの世界を持ち込む

Isaxxでは1デバイスでの開発とデバッグという「開発フェーズ」から、複数台での「検証フェーズ」、数十台、数百台をセルラーネットワークで繋ぐ「事業フェーズ」まで対応する。コードの反映にかかる所要時間は開発や検証段階で1、2秒。数百台のデバイスにセルラー経由でアップデートをかけるとなると、さすがに3分程度かかるそうだが、それでもこれは従来の組み込み開発やM2Mの世界からしたら、大きな進歩かもしれない。例えば、従来カラオケボックスのリモコンのソフトウェアアップデートとなると、個体管理やアップデートの仕組みがシステム化されてこなかったため、数百人がかりによる属人的な職人芸となっていた現場もあるそうだ。

XSHELL瀬戸山CEOは「ハードウェアの世界にウェブアプリの世界観を持ち込む」のがIsaxxの狙いと話していて、「例えば既存サービスに対して変更を加えて、後から登場したデバイスと連携するようなことが可能になります」という。これまでIoTの実証実験で7人の開発者で6カ月(2400万円)ほどかかっていたものを、1人の開発者、2週間の開発期間(50万円)に短縮できるとしている。何より、ウェブ開発で使われるプログラミング言語であれば使える開発者は非常に多い、というわけだ。

JavaScriptだけできればIoTサービスのプロトタイピングが可能になる、という世界観は興味深い。ただ一方で、実際の製品レベルのサービスにしていくときに、各分野の知識なり専門家なりがなくていいのかと言えば、そんなわけにはいかないのではないか。北米市場の話だが、現在販売されているスマートロック16種のうち12種でセキュリティーが破られた、という話がある。「セキュリティーについてはプラットフォームが保証してくれています」と開発者が言うようなプロダクトは、ぼくなら使いたくはない。IoTで広く使われるプロトコル、MQTTのベストプラクティスを知らずに消費電力やトラフィックといったリソースの最適化ができるとも思えない。

もう1つ、すでにIoTと呼ぶべきデバイスやプロダクトを開発している人であれば、「Linuxモジュールが対象」という点に違和感を覚えるかもしれない。多くのIoT製品は、そもそもOSを搭載していないからだ。カラオケのリモコンのようにリッチなUIを扱う組み込みデバイスと呼ぶべきものが対象であればいいが、Linuxのフットプリントはそこまで小さくない。特にスマホを経由して使うタイプのIoTであれば、複雑な処理はiOS上で行うというのも現時点では現実的なアプローチだろう。そう考えると、Isaxxは、今後1年とか2年かけて実用性を検証するユースケースで、ある程度ノード側に処理をオフロードするタイプのアプリケーションから立ち上がる市場がターゲットになるのかもしれない。

XSHELLでは今回のIsaxxのプラットフォームサービスのほかにも「Rapid」と名付けた受託開発サービスも提供していく。これはPoC案件(Proof of Concept)を中心として、自分たちのサービスのドッグフーディングをする意味が強いのだとか。「顧客を巻き込むという意味もありますが、PaaSとしてやっていくためにはベストプラクティスを知ってないといけない」(瀬戸山CEO)。

IoT市場の予測として2020年に全世界で530億台のデバイスが稼働するという数字を総務省が発表している。XSHELLでは、このうち国内シェア0.8%(770万台)を獲得して1デバイスあたり月100円の課金となれば、年商100億円となるとソロバンを弾いている。「IoT、IoTと言われ始めて2、3年して、なぜ誰もIoTでブレークスルーできていないか? それはPoCの数が少ないから。開発コストが高くて稟議が通らないという事情もあるのではないか」と瀬戸山CEOは話す。ちょうどHerokuがそうだったように、「プロの事業会社から、趣味のホビィストまで、誰もが使えるIoTプラットフォームサービスを作りたい。そういうミッションもあります」という。

新しい企業ITの形: モバイル-クラウドエンタプライズ

[筆者: Sravish Sridhar]

編集者注記: Sravish Sridharは、KinveyのファウンダでCEOだ。

エンタプライズITは今、Webベースのクライアント/サーバシステムからモバイル-クラウドへ、というプラットホームシフトを経験しつつある。大手のテクベンダたち全員が、このシフトを機会としてとらえ、Platform as a Service(PaaS)やBackend as a Service(BaaS)の技術を立ち上げ、あるいは買収して、その機に乗じようとしている。

FacebookはParseを買収し、PayPalはStackMobを買収、SalesforceはSalesforce Platform Mobile Servicesをローンチ、AWSは独自のモバイルツールのスイートをリリース、PivotalはPivotal CF Mobile Servicesをローンチ、そしてRed Hatはごく最近FeedHenryを買収。…と数えていけばきりがない。

長年PaaSは、アプリケーション開発の未来だ、と喧伝されていた。デベロッパはアプリケーションサーバとスケーラブルなインフラストラクチャにセルフサービスで自由にアクセスでき、自分のところのインフラチームから解放される。そしてBaaSは、アクセルをさらに一段踏み込み、コンテキストと抽象化を伴うモバイル固有の機能、たとえばプッシュ通知のアプリへの簡単な組み込み、などバックエンド機能の使いやすい抽象化を提供する。

そのほかBaaSは、アイデンティティデータベースや、データとファイルの保存、ユーザ独自のビジネスロジックを動かせる環境、なども提供する。つまりBaaSは、企業のクラウドコンピューティングの一環として、デベロッパがモバイルやタブレットやWebのアプリ/アプリケーションを動かすために必要とするクラウド上のバックエンドを、容易にセットアップ/使用/そして運用できるようにする。

では一体、何が変化を引き起こしたのか? エンタプライズにおける、このような変化の動因は何か? 今その界隈の動きが活発なのはなぜか? 二つの(互いに関連した)理由を思いつく: PaaSはデベロッパサービスとして不完全であり、しかも今ではコモディティ化している。そして、モバイルツールセットのプロバイダは、顧客がどんなクラウドを利用するかに関して、影響を及ぼしうる(後述)。

PaaSは不完全なサービス

PaaSはそのままでは何もない地盤であり、エンタプライズITが次世代のアプリケーションを構築できるためには、そこにモバイル機能…内製またはベンダから購入…の層を加えなければならない。

しかしBaaSのプラットホームなら、上記の‘加える’の部分を省略していきなり開発を始められる。BaaSは、クライアントデバイスのモバイル機能の完全なワンセットを提供する(キャッシング、データのシンク、暗号化、位置対応機能、などなど)。さらにBaaSは、次世代アプリケーションのすべてが必要とするモバイルバックエンド機能も提供する: アイデンティティ管理、データサービス、エンゲージメントサービス(プッシュ通知、アクセス解析など)、そしてビジネスロジック。提供されるこれらの機能の一つ一つは、完全なSaaS形式であり、それらをコンテキストで結びつけることにより、良質なユーザ体験を作り出す。

第一世代のモバイルツール…各種のMEAPやモバイルSDK…は、企業がそれぞれ一回かぎりのアプリケーションをローンチするためのツールやサービスを提供した。しかし今日のエンタプライズITは、今および今後、どんなユースケースのためのどんなアプリケーションでも動かせるための…一回かぎりではない…標準化されたプラットホームがほしい、と思い始めている。そういう標準的汎用的なプラットホームがあれば、個々のビジネスラインがセルフサービス方式でそれを自主的に使えるのだ。

PaaSのコモディティ化

モバイルはエンタプライズにおけるクラウドの採用に拍車をかけている。この二者は理想のカップルだ。企業は革新的なモバイルアプリとユースケースで競争に勝ちたいし、それと同時にモバイルの世界の激しい変化のペースに取り残されたくない。そしてこの二つの望みを共に満たすものは、クラウドベースのモバイルサービスプロバイダしかない。だからクラウドとモバイルは、もはや切り離せない。

それと同時に、インフラやプラットホームのプロバイダたちは、自分たちの提供物がますますコモディティ化してきたことに気づいている。OpenShiftがオープンソースで入手できるし、Google App Engineは無料、それに、いつも派手に報道されるGoogleとAmazonの価格戦争が、インフラストラクチャの料金を信じがたいほど低く押し下げている。さらに、この状況にプラスして、クラウドプロバイダは他社製品への移行が簡単にできる、他社製品に移行するのがやさしいし、トラブルもほとんどない。そこでPaaSプロバイダの多くは、独自のモバイル付加価値サービスをセットすることによって、自社製品の現在の顧客が浮気をしないように努力する。買収が盛んに行われるのも、今やほとんどのプラットホームが実質的に標準的なコモディティになっていて、A社からB社への移行に苦労が伴わないからだ。とくにBaaS専業の独立系プラットホームは、買った側が簡単に構成して、自分の環境でその日から動かせる。俺はどこにも買われたくない、と思っているのは大手のPaaSだけだ。

これからどうなる?

BaaSの連中は今後もモバイルのツールセットを作り続けるだろう。企業のいろんなユースケースに対応して、自社製品の魅力を高めるためだ。またデベロッパ向けには使いやすさとエレガンスを増し、企業ITのためにはセキュリティとスケーラビリティとコントロールを確保する。BaaSを兼ねているようなPaaSプロバイダは、企業が自分たちのクラウドを使うよう努力するが、BaaS専業のところは、クライアントのニーズにもっとも合ったクラウドプロバイダを選ぶ。

BaaSを利用してバックエンドの苦労から解放されると、エンタプライズITでは内部開発のエコシステムが再興する。そのエコシステムには、Jenkinsのような継続的インテグレーション、Gitのようなソースコントロール管理、Jiraのような問題追跡サービスなどが含まれるようになる。重要な違いは、これまでのようにIBMやSAPなどから一つの全体的なアプリケーション開発スイートを買うのではなく、現代的で開発効果の高いモバイルエンタプライズは、目的に合った個別のベストソリューションをいろいろ選び、自分たち独自のニーズに合った環境を構成することだ。

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


DockerがPaaSプラットホームのdotCloudをcloudControlに売ってコンテナビジネスに専念

オープンソースのアプリケーションコンテナ技術Dockerの開発とメンテナンスを行っているDocker, Incが、同社のPaaSビジネスdotCloudをベルリンのcloudControlに売却したことを発表した。これによりDockerは、本業のコンテナソフトウェアに、より集中できることになる。

DockerのCEO Ben Golubは本誌TechCrunchに、これからは同社のビジネスのDockerの部分に集中したい、と語った。“これまでの18か月でDockerのユーザ数は急増した。今ではそれは、わが社が全力を上げてそれに集中しなければならないほどのレベルだ。そこでdotCloudには、もっと顧客のためになる新居を見つけてあげることになった”。

Golubによると、一定の厳しい条件を満たす買い手を探すのに苦労をした。まずそれは、すでに市場で高く評価されているPaaSベンダであること。そしてdotCloudプラットホームのメンテナンスを継続できる力量があること。つまり、dotCloudの500あまりの既存の顧客をぶんどることが、ねらいではないこと。

dotCloudのWebサイトでデベロッパサポートマネージャAndrew Rothfusが、“dotCloud PaaSプラットホームが、合衆国に進出しようとしているドイツのPaaSプロバイダcloudControl GmbHの合衆国の子会社に買収されたことを発表できることは、欣快至極である”、と述べている。

そのブログ記事はさらに、dotCloudの名前の存続と、顧客の事業の継続性(現状維持)を約束している。そしてそのために、新しい親会社とのスムーズな統合化のために、あらゆる努力を惜しまない、と。

Golubはこう付言する: “cloudControlはヨーロッパでは大手であり、合衆国進出もねらっているぐらいだから、能力は高い”。

Dockerは今とても人気の高いコンテナ技術であり、デベロッパたちの想像力をとりこにしている。本誌TechCrunchの6月の記事は、Dockerについて次のように述べている:

“Docker 1.0はGoogleが開発した新しいコンテナ技術の実装系の一つで、アプリケーションを、これまでのように変更を加えたり、開発サイクルの新しいステージに入るたびに、まったく新たな再インストールや再構成を必要とせず、安全に配布できる”。

dotCloudはもともと同社のミッションの一部ではないので、今回の売却は好機であった。またベルリンのcloudControlにとっても、意義のある買収だった。どちらもPaaSを主力とする企業であり、どちらも顧客のアプリケーションをクラウドに展開〜管理〜スケールすることが技術の中心だ。両社はいわば“似た者夫婦”であり、dotCloudはcloudControlに、既存の顧客によるインスタントな成長を与え、また合衆国市場におけるインスタントな足場も与える。

そもそも会社がDocker, Inc.に名前を変えてから以降、dotCloudには不安定感があった。そして今回の買収によりdotCloudの顧客企業はむしろ、このプラットホームのPaaSとしての長期的な存続に関して、より安心感を持てるようになった、と言える。

Golubによると、今Dockerの社員は50名で、うち4名がdotCloudを担当していた。彼らは今後もDockerの社員として、所有権の移行期90日間はdotCloudのサポートにあたり、その後はDocker本体の仕事に移行する。

Golubは買収の価額等を公表しなかったが、目的はお金ではなく、あくまでも、dotCloudの顧客たちに良き新居を見つけてあげることにあった、と言っている。“それはおもしろい取り引きだったけど、主な狙いは顧客たちに良い家を見つけてあげて、われわれが安心してDockerに専念できるようにすることだった”。

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


Heroku上のプロジェクトをスマホから管理するアプリLovelyHeroku

LovelyHerokuは、人気のPaaS(platform-as-a-service) Heroku上のプロジェクトをスマートフォンから管理する、という新種のアプリだ。これは、スマートフォンの普及によってデベロッパやITスタッフたちの仕事のやり方も変わった、ということを示す典型的なアプリだ。

このサービスを作ったのは、クロアチアのコンピュータ科学の教授Matija Bogdanovicaと、各種オープンソースプロジェクトへの寄与貢献者として知られているMario Danicだ。MarioはかつてKickstarterからの資金でSlicehostとそのコミュニティを作り、のちにそれをRackspaceが買収した。LovelyHerokuを使うとデベロッパは自分の仕事を複数のアカウントから管理でき、パスワードを変えたり、アプリをスケールしたり、アプリに新しいドメインを割り当てたり、SSHキーを配備したり、新たなコラボ要因を加えたり、等々といったことができる。

Danicはホスティング企業6syncを作って今でも稼働させているが、今日Skypeで行ったインタビューで、LovelyHerokuは自分のフラストレーションから閃いたアイデアだ、と言った。そしてあたりを見回すと、システムアドミニストレータにリモートでアクセスしたくて苦労しているデベロッパが多い。彼の以前の顧客たちや、仲間のHerokuユーザたちも同じ問題を経験していた。彼の同僚たちは、ラップトップのふたを開けずにHerokuにアクセスしたい、とも言った。

“ぼくが始めて大規模なFOSS(Free Open Source Software)に手を染め、Googleが登場したばかりの7年前なら、優秀な技術が何よりも優先する、と言っただろう。でも今は、いちばんたいせつなのは顧客の体験と顧客そのものだ、と言いたいね”。

デベロッパやITマネージャが自分たちのアプリのために使っているクラウドサービスにアクセスする方法は、ほかにもある。RackspaceやAmazon Web Servicesにも、それらのサービスをモニタするためのモバイルアプリがある。VictorOpsのiOS/Androidモバイルアプリは、企業のモニタリングシステムの出力をリアルタイムでストリーミングさせて見ることができる。これらのアプリはいずれも、異状をアプリからのアラートやSMSやメールで通知する機能がある。

しかしLovelyHerokuは、対象がHerokuだけ、という点がユニークだ。Herokuはもっとも人気のあるPaaSだが、このサービスはあえてターゲットを絞り込むことによって、そこでのユーザ体験に具体的に即した支援を、デベロッパたちに提供しようとしている。

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


Google App EngineでのPHP利用がオープン化

Google App EngineにおけるPHPの扱いが「プレビュー」となった。招待制であったのが、完全にオープンとなったのだ。これにともなってPHPアプリケーションについても直ちに公開できるようになる。

Googleが4番めのランタイム限後としてPHPに対応したのは今年のGoogle I/Oにおいてのことだった。PHPは世界中で広く利用されており、Facebook、WordPress、そしてDrupalなどでも利用されている言語だ。

PHPへの対応を初めて以来、Googleではplug-in for WordPressや、またPHPを使ったファイルの読み書きの機能などを追加してきている。

PHP対応がオープンになったことで、開発者はGoogle App Engineを通じてPHPアプリケーションの開発、テスト、デプロイができるようになる。別の選択しとしては、これまでも使っていた人がいるであろうDevTableCodeEnvyを使い続けるという手もある。どちらも統合開発環境だ。また自前の開発環境があるのなら、ビルド、実行、デバッグまでを行ったのち、JetBrainのPHPStorm IDEを使ってGAEへのデプロイを行うこともできる。

Google I/OでPHPへの対応が発表されるまで、このPHP対応が最も多くリクエストされる機能だった。今回の「プレビュー」化も多くの人から歓迎されるアップデートとなるに違いない。

Web Technology Surveysによると、全ウェブサイトの81.2%でPHPが用いられているのだそうだ。但し、現在は急速な「モバイル化」ないし「クラウド化」などへ、さらなる真価を遂げつつある時期だとも言える。最近行われたZend PHP ConferenceにおいてもAPIモデル、ダイナミックなデータ構造、モバイル対応、クラウド内で完結する動作するアプリケーションについてに注目が集まっていた。

PHPに対応している他のPaaS環境としてはZendのPHP CloudJelastic、およびEngineYardなどがある。

原文へ

(翻訳:Maeda, H


AWS、OpsWorksをリリース―Chefと連動してアプリ公開のライフサイクルをクラウド上で効率化する画期的サービス

amazon-web-services-copie

AWS(Amazon Web Services)はトラフィックの規模に応じて自由にスケールさせながらアプリの配信を管理するOpsWorksOpsWorksという新サービスをスタートさせた。

より興味が持たれるのは、新しく生まれつつ在るPasS(Platform as a Service)分野に破壊的革新をもたらす可能性があることだ。DevOps〔開発者が同時に運用者であるシステム〕の運用管理ツールの分野ではChefとPuppetが激しく競争しているが、そのインフラは次第に複雑さを増している。

プレスリリースによると、このサービスはリソース・プロビジョニング、コンフィグレーション管理、アプリケーション公開、ソフトウェアのアップデート、利用状況のモニタとアクセス管理などを含めたアプリの全ライフサイクルを管理するという。AmazonのCTO、Werner Vogelsによれば、AWS OpsWorksはベルリンのPeritor社(Scalariumの開発元で、AWSが2012年に買収)の開発によるものだという。

OpsWorksはデベロッパーに多層のレイヤーを提供する。レイヤーはデベロッパーが公開しようとする各種のAWSインスタンスの設計図の役割を果たす。レイヤーは特定のインスタンスのコンフィグレーションを設定したり、関連するAWSのリソース、たとえばElastic IPアドレスを取得したりするのに用いられる。デベロッパーはこれによってAWSのクラウド環境を容易に動的に管理できる。新サービスはRuby、PHP、HAProxy、Memcached、MySQLをサポートしている。さらにデベロッパーカスタム・レイヤーを開発して利用することができる。OpsWorksはChefと連動しており、必要に応じて特定のイベントに関連づけられたChefのレシピ〔運用自動化のスクリプト〕を呼び出すことが可能だという。

デベロッパーはOpsWorksは異なるレイヤーに自由にインスタンスを割り当てることができる。.

またOpsWorksではあらゆる面で処理の自動化が図られている。たとえばこのサービスはアプリの定義して公開する。デベロッパーはOpsWorksにソースコードの場所を教えておくだけで、後はこのサービスがデータベースのコンフィグレーションなどの作業を自動的に進めてくれる。

OpsWorksは非常に大きな影響を与える可能性がある。Hacker Newsのコメント欄にもあったが、Herokuを置き換える可能性もある。またOpsWorksがChefと連動する点については、Puppetに与える影響が注目される。

いずれにせよ、PaaS/DevOps市場は急速な拡大、進歩を続けており、OpsWorksの出現でアプリの公開管理の自動化とスピードアップはいっそう進むことになるだろう。

[原文へ]

(翻訳:滑川海彦 Facebook Google+