新しい企業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+